Tutorial Azure 1

Contents
Documentação de Máquinas Virtuais

Visão geral
Sobre as Máquinas Virtuais do Linux
Sobre as Máquinas Virtuais do Windows
Inícios rápidos
Criar uma VM do Linux
CLI
Portal
PowerShell
Modelo de ARM
Criar uma VM do Windows
CLI
Portal
PowerShell
Modelo de ARM
Tutoriais
Linux
1 - Criar / gerenciar VMs
1 - Criar / gerenciar discos
3 - Automatizar a configuração
4 - Criar imagens da VM
5 - VMs altamente disponíveis
6 – Criar um conjunto de dimensionamento
7 - VMs de balanceamento de carga
8 - Gerenciar a rede
Windows
1 - Criar / gerenciar uma VM
1 - Criar / gerenciar discos
3 - Automatizar a configuração
4 - Criar imagens da VM
5 - VMs altamente disponíveis
6 – Criar um conjunto de dimensionamento
7 - VMs de balanceamento de carga
8 - Gerenciar a rede
Cargas de trabalho
Red Hat
Cloud Foundry
OpenShift
Visão geral do OpenShift
OpenShift Container Platform 4.x
Pré-requisitos do OpenShift Container Platform 3.11
OpenShift Container Platform 3.11
Marketplace Autogerenciado do OpenShift Container Platform 3.11
Azure Stack
Tarefas pós-implantação do OpenShift Container Platform 3.11
Solucionar problemas das implantações do OpenShift Container Platform 3.11
Implantar OKD
SAP no Azure
Oracle
Elasticsearch
Rehosting de mainframe
SQL em Máquinas Virtuais
HPC (Computação de Alto Desempenho)
Instâncias
Tamanhos
Visão geral
Alterar o tamanho da VM
CLI
Portal ou PowerShell
VM geração 2
Propósito geral
Visão geral
Série Av2
Série B expansível
Série DCsv2
Séries Dv2 e DSv2
Séries Dv3 e DSv3
Séries Dav4 e Dasv4
Séries Ddv4 e Ddsv4
Séries Dv4 e Dsv4
Otimizado para computação
Visão geral
Série Fsv2
Otimizado para memória
Visão geral
Séries Dv2 e DSv2 11-15
Séries Ev3 e Esv3
Séries Eav4 e Easv4
Séries Edv4 e Edsv4
Séries Ev4 e Esv4
Série M
Série Mv2
VCPUs restritas
Otimizado para armazenamento
Visão geral
Série Lsv2
Otimizar desempenho
Linux
Windows
GPU – Computação acelerada
Visão geral
Série NC
Série NCv2
Série NCv3
Série NCasT4_v3
Série ND
Série NDv2
Série NV
Série NVv3
Série NVv4
Configurar drivers de GPU NVIDIA
Linux
Windows
Configurar drivers de GPU AMD
FPGA – computação acelerada
Visão geral
Série NP
Computação de alto desempenho
Visão geral
Série H
Série HB
Série HBv2
Série HC
Cotas do vCPU
CLI
PowerShell
VMs do Azure sem disco temporário
Convenções de nomenclatura de tamanhos de VM do Azure
Gerações anteriores
Tamanhos isolados
ACU (Unidades de computação do Azure)
Pontuações de parâmetro de comparação
Linux
Windows
Hosts dedicados
Visão geral
CLI
Portal
PowerShell
Máquinas Virtuais Spot do Azure
Visão geral
CLI
Portal
PowerShell
Modelo de ARM
Códigos do Erro
Opções de compra
Benefício Híbrido do Azure
Linux
Windows
Use a licença de Benefício Híbrido do Azure
Usar Direitos de Hospedagem de Multilocatários para Windows 10
Instâncias reservadas
Pagar antecipadamente por VMs
Pagar antecipadamente por Hosts Dedicados
O que são as reservas do Azure?
Flexibilidade do tamanho da instância
Criar VMs do Linux
Distribuições endossadas
Como usar a CLI
Usar um modelo ARM
Usar a API REST
Copiar uma VM usando a CLI
Criar com o Jenkins
Integrar o Jenkins com o Azure DevOps
Configurar a estratégia de implantação distribuída
Configurar a estratégia de implantação canário
Configurar estratégia de implantação azul-verde
CI/CD com o Azure Pipelines (YAML)
Criar pilha LAMP
Servidor Web seguro com TLS\SSL
Linux
Windows
Conectar-se a VMs do Linux
SSH para VMs do Linux
Em Linux ou macOS
No Windows
No portal
Etapas detalhadas
Área de Trabalho Remota para Linux
Criar VMs do Windows
Como usar C#
Usar disco especializado
Portal
PowerShell
Criar VM com Chef
Usar Java
Python
Usar modelo ARM
Conectar-se a VMs do Windows
WinRM
Extensões
Visão geral
Linux
Recursos do Linux
Agente de VM do Linux
Windows
recursos do Windows
Agente de VM do Windows
Azure Disk Encryption
Linux
Windows
Cofre de Chave do Azure
Linux
Windows
Backup do Azure para SQL Server
Backup do Azure para SQL Server
Custom Script
Linux — Versão 2
Windows
Antimalware de IaaS do Windows
Instantâneo da VM
Linux
Windows
Extensão do Observador de Rede
Linux
Windows
Atualizar para a versão mais recente
Drivers InfiniBand
Linux
Windows
Drivers de GPU NVIDIA
Linux
Windows
Drivers de GPU AMD
Windows
Azure Monitor
Agente do Azure Monitor
Extensão de diagnóstico
Log Analytics
Linux
Windows
Azure Monitor para VMs
Dependency Agent do Linux
Dependency Agent do Windows
PowerShell DSC
DSC e Linux
DSC e Windows
Identificador de credenciais
Usar modelos
Acessar máquina virtual
Extensões de terceiros
Chef
Retorno Stackify
Symantec
Instalação da extensão restrita
Linux
Windows
Atualizar agente do Linux
Exportar extensões
Solucionar problemas
Problemas com sistemas Linux habilitados para Python 3
Migrar de Clássica para o Azure Resource Manager
Desativação a partir de 1º de março de 2023
Visão geral da migração
Aprofunde-se na migração
Planejar a migração
Migrar usando a CLI
Migrar usando o PowerShell
Erros comuns de migração
Ferramentas da comunidade para a migração
Perguntas frequentes
Noções básicas de gerenciamento
Gerenciar recursos
Linux
Windows
Sincronização do tempo
Linux
Windows
Como executar scripts em uma VM
Extensão de script personalizado
Linux
Windows
Executar Comando
Linux
Windows
Hybrid Runbook Worker
Console serial
Linux
Windows
Habilitar a virtualização aninhada
Armazenamento de arquivos
Montagem do Linux usando o SMB
Copie os arquivos para uma VM do Linux
Atualizações e patches
Infraestrutura de atualização do Red Hat
Imagens
Localizar imagens do Azure Marketplace
CLI
PowerShell
Imagens do cliente Windows
Imagens personalizadas do Linux
Visão geral
Provisionamento do Linux
Requisitos específicos de distribuição do Linux
Etapas genéricas
CentOS
Debian
Flatcar Container Linux
FreeBSD
Filtro de pacote FreeBSD
Oracle Linux
OpenBSD
Red Hat
SUSE
Ubuntu
Usar cloud-init
Visão geral da inicialização de nuvem
Aprofundamento
Solução de problemas
Configurar nome do host da máquina virtual
Atualizar pacotes em uma máquina virtual
Adicionar um usuário a uma máquina virtual
Configurar o arquivo de permuta
Executar o script bash existente
Criar imagens do Linux sem um agente de provisionamento
Desabilitar provisionamento de Agente do Linux
Capturar a VM para a imagem gerenciada
Imagens personalizadas do Windows
Preparar um VHD para carregar
Carregar um VHD e criar uma imagem gerenciada
Capturar uma imagem gerenciada
Criar uma VM por meio de uma imagem gerenciada
Visual Studio
Galerias de Imagens Compartilhadas
Visão geral
CLI
Criar uma galeria
Criar uma imagem
De uma VM
De um disco gerenciado ou instantâneo
Clonar uma imagem gerenciada
Copiar de outra galeria
Criar uma máquina virtual
Generalizada
Especializada
Atualizar recursos de imagem
Registro de aplicativo para compartilhamento
Linux
Windows
PowerShell
Criar uma galeria
Criar uma versão de imagem
De uma VM
De um disco gerenciado ou instantâneo
Clonar uma imagem gerenciada
Copiar de outra galeria
Generalizada
Especializada
Atualizar recursos de imagem
Registro de aplicativo para compartilhamento
Portal
Criar uma galeria, uma imagem e uma VM
Linux
Windows
Modelos do Resource Manager
Criar uma Galeria de Imagens Compartilhadas
Criar uma definição de imagem em uma Galeria de Imagens Compartilhadas
Criar uma versão de imagem em uma Galeria de Imagens Compartilhadas
Criar uma VM por meio de uma versão de imagem
Solucionar problemas de imagens compartilhadas
Usar chaves gerenciadas pelo cliente
Disco gerenciado da versão da imagem
Informações do plano de compra
Construtor de imagens (versão prévia)
Visão geral
CLI
Linux
Windows
PowerShell
Segurança
Controles de segurança do Azure Policy
Usar uma VNET
CLI
PowerShell
Opções de rede
Configurar permissões
CLI
PowerShell
Tarefa do DevOps
Referência de modelo do Construtor de Imagens
Criar para galerias de imagens
Linux
Windows
Atualizar uma imagem existente
Linux
Windows
Armazenar scripts
Como criar uma imagem com o Packer
Linux
Windows
Disponibilidade e escala
Conjuntos de dimensionamento
Disponibilidade
Colocalização
Desempenho de rede
Estados e ciclo de vida
Autoscale
Alta disponibilidade
Conjuntos de disponibilidade
Linux
Windows
Criar um conjunto de disponibilidade
Como alterar o conjunto de disponibilidade
Criar um grupo de posicionamento de proximidade
CLI
Portal
PowerShell
Criar VM em zona de disponibilidade
Discos
Introdução aos discos gerenciados
Selecione um tipo de disco para VMs IaaS
Discos compartilhados
Habilitar discos compartilhados
Criptografia
Criptografia no servidor
Visão geral da criptografia do lado do servidor
Habilitar chaves gerenciadas pelo cliente
Portal
PowerShell
CLI
Habilitar a criptografia no host
Portal
PowerShell
CLI
Habilitar criptografia dupla em repouso
Portal
PowerShell
CLI
Cenários do Azure Disk Encryption
Visão geral do Azure Disk Encryption
Windows
Linux
Linux
Windows
CLI
Linux
Windows
PowerShell
Linux
Windows
Portal
Linux
Windows
Cofre de chaves para o Azure Disk Encryption
Linux
Windows
Scripts de exemplo
Linux
Windows
Azure Disk Encryption em uma rede isolada
Como verificar o status de criptografia
Como configurar LVM e RAID sobre a criptografia
Como redimensionar volumes LVM criptografados
Redimensionar partições do sistema operacional Linux com GPT
Linux
Windows
Linux
Windows
Azure Disk Encryption – versão anterior
Visão geral
Linux
Windows
Cofre de chaves para o Azure Disk Encryption
Linux
Windows
Cenários de criptografia de disco
Linux
Windows
Desempenho e otimização de custos
Discos Ultra
Desempenho de máquina virtual e disco
Reservas de Armazenamento em Disco
Reservar Armazenamento em Disco
Design para alto desempenho
Métricas relacionadas ao disco
Intermitência de disco
Níveis de desempenho de disco
Alterar o nível de desempenho de disco
CLI e PowerShell
Portal
Habilitar acelerador de gravação
Submeter um disco a benchmark
Metas da escalabilidade para os discos
Backup e proteção de dados
Habilitar instantâneos incrementais
Backup de Disco do Azure
Visão geral
Configurar o Backup de Disco do Azure
Restaurar discos com Backup de Disco do Azure
Backup e recuperação de desastres para discos
Instantâneo de um disco – CLI
Instantâneo de um disco – PowerShell
Fazer backup de discos não gerenciados
Discos do SO Efêmero
Migração e conversão
Converter disco em outro tipo de disco
CLI
PowerShell
Migrar para os SSDs premium com o Azure Site Recovery
Linux
Windows
Como migrar para Managed Disks
VM não gerenciada para Managed Disks
CLI
PowerShell
Adicionar um disco de dados
Linux
CLI do Azure
Portal do Azure
Windows
Azure PowerShell
Portal do Azure
Alterar a letra da unidade de disco temporária
Desanexar um disco
Linux
Windows
Expandir o disco do sistema operacional
Linux
Windows
Gerenciamento do armazenamento
Implantar discos com modelo ARM
Importar/exportar um disco com segurança
Configurar links privados para discos – CLI
Configurar links privados para discos – Portal
Fazer upload de um VHD para um disco – PowerShell
Carregar um vhd para um disco – CLI
Baixe um VHD
Linux
Windows
Usar Gerenciador de Armazenamento para gerenciar discos
Trocar o disco do sistema operacional – CLI
Trocar o disco do sistema operacional – PowerShell
Mapear o disco gerenciado para o disco do convidado – Linux
Mapear o disco gerenciado para o disco do convidado – Windows
Localizar discos desconectados
CLI
PowerShell
Portal
Perguntas frequentes de discos
Exemplos de código
CLI
Criar disco gerenciado com base em um VHD
Criar um disco gerenciado com base em um instantâneo
Copiar um disco gerenciado para a mesma assinatura ou para uma diferente
Copiar um instantâneo para a mesma assinatura ou para uma diferente
Exportar um instantâneo como um VHD para uma conta de armazenamento
Exportar um disco gerenciado como um VHD para uma conta de armazenamento
PowerShell
Criar disco gerenciado com base em um VHD
Criar um disco gerenciado com base em um instantâneo
Copiar um instantâneo para a mesma assinatura ou para uma diferente
Exportar um instantâneo como um VHD para uma conta de armazenamento
Exportar um disco gerenciado como um VHD para uma conta de armazenamento
Criar um instantâneo de um VHD
Rede
Visão geral
Criar rede virtual
Como abrir as portas para uma VM
CLI
PowerShell
Portal
Como atribuir um endereço IP público
Como usar várias NICs
Linux usando a CLI
Windows usando o PowerShell
Usar rede acelerada
Como atribuir o nome DNS público
Localizar e excluir NICs desconectados
Resolução DNS
Como usar o DNS interno
Segurança
Visão geral
Central de Segurança do Azure
Linhas de base de segurança
Linux
Windows
Recomendações
Acesso Just-In-Time
Política
Visão geral
Controles por política
Referência de política
Como usar políticas
Linux
Windows
Bastion
Visão geral
Criar um Bastion host
Portal
PowerShell
CLI
Conexão SSH do Bastion
Conexão RDP do Bastion
Como usar controles de acesso
Criar um cofre de chaves
CLI
PowerShell
Atenuando a execução especulativa
Ingressar uma VM do Linux no Azure Active Directory
Red Hat Enterprise Linux
CentOS
Ubuntu
Configurar identidades gerenciadas
Portal
CLI
PowerShell
Modelo do Azure Resource Manager
REST
SDKs do Azure
Credenciais do Active Directory do Linux
Manutenção e atualizações
Visão geral
Aplicação de patch automática de convidado de VM (versão prévia)
Atualização automática de extensão (versão prévia)
Controle de manutenção
Notificações de manutenção
Visão geral
CLI
Portal
PowerShell
Manutenção da plataforma
Visão geral
CLI
PowerShell
Portal
Eventos agendados
Linux
Windows
Acompanhar e atualizar VMs
Linux
Windows
Atualizações de imagem do SO do conjunto de dimensionamento de máquinas
virtuais
Atualizações automáticas do SO
Controle de manutenção
Visão geral (versão prévia)
PowerShell (versão prévia)
Monitoramento
Visão geral
Monitoramento de VMs
Windows
Agentes
Visão geral dos agentes
Extensão de Diagnóstico do Azure
Visão geral
Extensão de diagnóstico do Linux
Versão 4.0
Versão 3.0
Coletar métricas com o Telegraf
Agente do Log Analytics
Visão geral
Agentes do Linux
Gateway do Log Analytics
Gerenciamento de agentes
Integridade do agente
Fontes de dados
Visão geral
Dados JSON personalizados
Dados de desempenho do CollectD
syslog
Contadores de desempenho
Desempenho de aplicativo Linux
Logs personalizados
Campos Personalizados
Extensão de VM do Log Analytics
Agente do Linux do Log Analytics
Azure Monitor para VMs
Visão geral
Perguntas frequentes sobre disponibilidade geral
Habilitar o monitoramento
Habilitar a visão geral de monitoramento
Habilitar para VM do Azure única
Habilitar usando o Azure Policy
Habilitar usando o Azure PowerShell
Habilitar para o ambiente Híbrido
Mapear dependências
Monitorar desempenho
Analisar dados com consultas de log
Visualizar os dados com pastas de trabalho
Criar regras de alerta
Atualizar o Dependency Agent
Desabilitar o monitoramento
Uso de VM
Marcar uma VM
CLI
Portal
PowerShell
Modelo
Monitorizar metadados
CLI
PowerShell
Obter métricas de uso com o REST
Diagnóstico de inicialização
Backup e recuperação
Visão geral
Interrupções de serviço
Fazer backup de VMs
Visão geral
Inícios rápidos
CLI
PowerShell
Portal
Modelo
Fazer backup de várias VMs
Opções de restauração
Matriz de suporte
Preços
Recuperação de desastre
Visão geral
Habilitar a recuperação de desastre
Linux
Windows
Habilitar a recuperação de desastre para uma VM
Executar uma análise detalhada da recuperação de desastre para uma VM
Fazer failover de uma VM para outra região
Mover e migrar VMs
Alterar a assinatura ou o grupo de recursos
CLI
PowerShell
Alterar assinatura para VMs do Marketplace
Mover VMs para outra região
Mover para uma zona de disponibilidade
Mover as configurações de controle de manutenção para outra região
Mover os recursos de configuração de controle de manutenção para outra região
Como migrar AWS e VMs locais
Migrar do (AWS) Amazon Web Services para o Azure
Como carregar uma VM local
Como usar o Azure Site Recovery
Automação de infraestrutura
Visão geral
Dados personalizados
Ansible
Terraform
Jenkins
Azure DevOps
Recursos
Cloud Adoption Framework
Centro de arquitetura
P e R da Microsoft
Modelos de início rápido do Azure
Preços
Disponibilidade regional
Desenvolva suas habilidades com o Microsoft Learn
Roteiro do Azure
Calculadora de preço
Exemplos
Repositório de exemplos da CLI do Azure
Repositório de exemplos do PowerShell
Comandos comuns da CLI
Comandos comuns do PowerShell
Comandos de rede comuns do PowerShell
Descrição do modelo de VM
Implantações clássicas
VMs do Linux usando implantação clássica
VMs do Windows usando implantação clássica
Linux
Windows
Máquinas virtuais do Linux no Azure
03/03/2021 • 12 minutes to read • Edit Online
VM (Máquinas Virtuais) do Azure é um dos vários tipos de recursos de computação sob demanda escalonáveis
oferecidos pelo Azure. Normalmente, você escolhe uma VM quando precisar de mais controle sobre o ambiente
de computação do que as outras opções oferecem. Este artigo fornece informações sobre o que você deve
considerar antes de criar uma VM, como criá-la e como gerenciá-la.
Uma VM do Azure oferece a flexibilidade da virtualização sem a necessidade de comprar e manter o hardware
físico que a executa. No entanto, você ainda precisa manter a VM executando tarefas, como configurar, corrigir e
instalar o software que será executado nela.
Máquinas virtuais do Azure podem ser usadas de várias maneiras. Alguns exemplos são:
Desenvolvimento e teste – as VMs do Azure oferecem uma rápida e maneira fácil de criar um
computador com configurações específicas, necessárias para codificar e testar um aplicativo.
Aplicativos na nuvem – como a demanda por seu aplicativo pode flutuar, pode fazer sentido, em termos
econômicos, executá-lo em uma VM no Azure. Você paga por VMs extras quando precisa delas e as desliga
quando não são necessárias.
Datacenter estendido – máquinas virtuais em uma rede virtual do Azure podem ser facilmente conectadas
à rede de sua organização.
O número de VMs que o aplicativo usa pode ser escalado verticalmente e horizontalmente para atender às suas
necessidades.
O que é necessário pensar antes de criar uma VM?

Sempre há uma infinidade de considerações de design quando você cria uma infraestrutura de aplicativo no
Azure. Estes aspectos de uma VM são importantes a considerar antes de começar:
Os nomes dos recursos do aplicativo
O local onde os recursos são armazenados
O tamanho da VM
O número máximo de VMs que podem ser criadas
O sistema operacional que a VM executa
A configuração da VM após ela ser iniciada
Os recursos relacionados dos quais a VM precisa
Locais
Todos os recursos criados no Azure são distribuídos entre várias regiões geográficas em todo o mundo.
Normalmente, a região é chamada local quando você cria uma VM. Para uma VM, a localização especifica onde
os discos rígidos virtuais são armazenados.
Esta tabela mostra algumas das maneiras de obter uma lista dos locais disponíveis.
M ÉTO DO DESC RIÇ Ã O
Portal do Azure Selecione um local na lista quando você criar uma VM.
Azure PowerShell Use o comando Get-AzLocation.

API REST Use a operação Listar locais.
CLI do Azure Use a operação az account list-locations.
Disponibilidade
O Azure anunciou um Contrato de Nível de Serviço de máquina virtual de única instância de 99,9%, o melhor
que há no mercado, desde que você implante a VM com armazenamento premium para todos os discos. Para
sua implantação se qualificar para o Contrato de Nível de Serviço de 99,95% padrão de VM, você ainda
precisará implantar duas ou mais VMs que executem sua carga de trabalho dentro de um conjunto de
disponibilidade. Um conjunto de disponibilidade garante que suas VMs sejam distribuídas entre vários
domínios de falha nos datacenters do Azure, além de serem implantadas em hosts com janelas de manutenção
diferentes. O SLA completo do Azure explica a disponibilidade garantida do Azure como um todo.
Tamanho da VM
O tamanho da VM que você usa é determinado pela carga de trabalho que deseja executar. O tamanho que você
escolhe, em seguida, determina fatores como capacidade de processamento, memória e armazenamento. O
Azure oferece uma grande variedade de tamanhos para oferecer suporte a muitos tipos de usos.
O Azure cobra um preço por hora com base no tamanho da VM e do sistema operacional. Para horas parciais, o
Azure cobrará somente os minutos usados. O armazenamento terá o preço e será cobrado separadamente.
Limites de VM
Sua assinatura do Azure tem limites de cota padrão que podem afetar a implantação de muitas VMs para seu
projeto. O limite atual por assinatura é de 20 VMs por região. Os limites podem ser aumentados pelo
preenchimento de um tíquete de suporte para solicitar um aumento
Managed Disks
Os Managed Disks trata da criação da conta de Armazenamento do Azure e do gerenciamento em segundo
plano para você, além de garantir que você não tenha que se preocupar com os limites de escalabilidade da
conta de armazenamento. Especifique o tamanho do disco e o nível de desempenho (Standard ou Premium) e o
Azure cria e gerencia o disco. À medida que você adiciona discos ou dimensiona a VM para cima e para baixo,
não é preciso se preocupar com o armazenamento que está sendo usado. Se você estiver criando novas VMs,
use o CLI do Azure ou o portal do Azure para criar VMs com SO gerenciado e discos de dados. Caso tenha VMs
com discos não gerenciados, você poderá convertê-las para que tenham suporte do Managed Disks.
Você também pode gerenciar suas imagens personalizadas em uma conta de armazenamento por região do
Azure e usá-las para criar centenas de VMs na mesma assinatura. Para saber mais sobre os Managed Disks,
confira a Visão geral dos Managed Disks.
Distribuições
O Microsoft Azure dá suporte à execução de várias distribuições populares do Linux fornecidas e mantidas por
diversos parceiros. Você pode encontrar distribuições disponíveis no Azure Marketplace. A Microsoft trabalha
ativamente com várias comunidades do Linux para adicionar ainda mais opções à lista de Distribuições do Linux
endossadas pelo Azure.
Se sua distribuição preferencial do Linux não estiver presente na galeria no momento, você poderá "trazer sua
própria VM do Linux" criando e carregando um VHD do Linux no Azure.
A Microsoft trabalha junto com parceiros para garantir que as imagens disponíveis sejam atualizadas e
otimizadas para um runtime do Azure. Para obter mais informações sobre as ofertas de parceiros do Azure,
confira os seguintes links:
Linux no Azure – Distribuições endossadas
SUSE – Azure Marketplace – SUSE Linux Enterprise Server
Red Hat – Azure Marketplace – Red Hat Enterprise Linux
Canonical – Azure Marketplace – Ubuntu Server
Debian – Azure Marketplace – Debian
FreeBSD – Azure Marketplace – FreeBSD
Flatcar – Azure Marketplace – Flatcar do Contêiner do Linux
RancherOS - Azure Marketplace - RancherOS
Bitnami - Bitnami Library para Azure
Mesosphere - Azure Marketplace - Mesosphere DC/OS no Azure
Docker – Azure Marketplace – Imagens do Docker
Jenkins - Azure Marketplace - CloudBees Jenkins Platform
Cloud-init
Para obter uma cultura apropriada do DevOps, toda a infraestrutura deve ser codificada. Quando toda a
infraestrutura reside no código, ela pode ser recriada com facilidade. O Azure funciona com as principais
ferramentas de automação, como a Ansible, Chef, SaltStack e Puppet. O Azure também tem suas próprias
ferramentas de automação:
Modelos do Azure
Azure VMaccess
O Azure dá suporte a cloud-init na maioria das distribuições Linux que dão suporte a ele. Trabalhamos
ativamente com nossos parceiros endossados de distribuição de Linux para termos imagens de cloud-init
habilitadas disponíveis no marketplace do Azure. Essas imagens farão com que as implantações e as
configurações de cloud-init funcionem perfeitamente com VMs e conjuntos de dimensionamento de máquinas
virtuais.
Como usar o cloud-init em VMs Linux do Azure
Armazenamento
Introdução ao Armazenamento do Microsoft Azure
Adicionar um disco a uma VM do Linux usando a CLI do Azure
Como anexar um disco de dados a uma VM Linux no Portal do Azure
Rede
Visão geral da Rede Virtual
Endereços IP no Azure
Abertura de portas para uma VM Linux no Azure
Criar um nome de domínio totalmente qualificado no portal do Azure
Residência de dadosResidência de dados

No Azure, o recurso para habilitar o armazenamento de dados do cliente em apenas uma região está disponível
atualmente apenas na região do Sudeste da Ásia (Singapura), na área geográfica do Pacífico Asiático, e na região
Sul do Brasil (Estado de São Paulo), na área geográfica do Brasil. Para todas as outras regiões, os dados do
cliente são armazenados na Área geográfica. Para obter mais informações, confira Central de Confiabilidade.
Próximas etapas
Crie sua primeira VM!
Portal
CLI do Azure
PowerShell
Máquinas virtuais do Windows no Azure
VM (Máquinas Virtuais) do Azure é um dos vários tipos de recursos de computação sob demanda escalonáveis
oferecidos pelo Azure. Normalmente, você escolhe uma VM quando precisar de mais controle sobre o ambiente
de computação do que as outras opções oferecem. Este artigo fornece informações sobre o que você deve
considerar antes de criar uma VM, como criá-la e como gerenciá-la.
Uma VM do Azure oferece a flexibilidade da virtualização sem a necessidade de comprar e manter o hardware
físico que a executa. No entanto, você ainda precisa manter a VM executando tarefas, como configurar, corrigir e
instalar o software que será executado nela.
Máquinas virtuais do Azure podem ser usadas de várias maneiras. Alguns exemplos são:
Desenvolvimento e teste – as VMs do Azure oferecem uma rápida e maneira fácil de criar um
computador com configurações específicas, necessárias para codificar e testar um aplicativo.
Aplicativos na nuvem – como a demanda por seu aplicativo pode flutuar, pode fazer sentido, em termos
econômicos, executá-lo em uma VM no Azure. Você paga por VMs extras quando precisa delas e as desliga
quando não são necessárias.
Datacenter estendido – máquinas virtuais em uma rede virtual do Azure podem ser facilmente conectadas
à rede de sua organização.
O número de VMs que o aplicativo usa pode ser escalado verticalmente e horizontalmente para atender às suas
necessidades.
O que é necessário pensar antes de criar uma VM?

Sempre há uma infinidade de considerações de design quando você cria uma infraestrutura de aplicativo no
Azure. Estes aspectos de uma VM são importantes a considerar antes de começar:
Os nomes dos recursos do aplicativo
O local onde os recursos são armazenados
O tamanho da VM
O número máximo de VMs que podem ser criadas
O sistema operacional que a VM executa
A configuração da VM após ela ser iniciada
Os recursos relacionados dos quais a VM precisa
Locais
Todos os recursos criados no Azure são distribuídos entre várias regiões geográficas em todo o mundo.
Normalmente, a região é chamada local quando você cria uma VM. Para uma VM, a localização especifica onde
os discos rígidos virtuais são armazenados.
Esta tabela mostra algumas das maneiras de obter uma lista dos locais disponíveis.
Portal do Azure Selecione um local na lista quando você criar uma VM.
Azure PowerShell Use o comando Get-AzLocation.

API REST Use a operação Listar locais.
CLI do Azure Use a operação az account list-locations.
Disponibilidade
O Azure anunciou um Contrato de Nível de Serviço de máquina virtual de única instância de 99,9%, o melhor
que há no mercado, desde que você implante a VM com armazenamento premium para todos os discos. Para
sua implantação se qualificar para o Contrato de Nível de Serviço de 99,95% padrão de VM, você ainda
precisará implantar duas ou mais VMs que executem sua carga de trabalho dentro de um conjunto de
disponibilidade. Um conjunto de disponibilidade garante que suas VMs sejam distribuídas entre vários
domínios de falha nos datacenters do Azure, além de serem implantadas em hosts com janelas de manutenção
diferentes. O SLA completo do Azure explica a disponibilidade garantida do Azure como um todo.
Tamanho da VM
O tamanho da VM que você usa é determinado pela carga de trabalho que deseja executar. O tamanho que você
escolhe, em seguida, determina fatores como capacidade de processamento, memória e armazenamento. O
Azure oferece uma grande variedade de tamanhos para oferecer suporte a muitos tipos de usos.
O Azure cobra um preço por hora com base no tamanho da VM e do sistema operacional. Para horas parciais, o
Azure cobrará somente os minutos usados. O armazenamento terá o preço e será cobrado separadamente.
Limites de VM
Sua assinatura do Azure tem limites de cota padrão que podem afetar a implantação de muitas VMs para seu
projeto. O limite atual por assinatura é de 20 VMs por região. Os limites podem ser aumentados pelo
preenchimento de um tíquete de suporte para solicitar um aumento
Imagens e discos de sistema operacional
As máquinas virtuais usam VHDs (discos rígidos virtuais) para armazenar seus dados e sistema operacional
(SO). Os VHDs também são usados para as imagens que você pode optar por instalar um sistema operacional.
O Azure fornece muitas imagens do marketplace para usar com várias versões e tipos de sistemas operacionais
Windows Server. As imagens do Marketplace são identificadas por editor de imagem, oferta, sku e versão
(normalmente, a versão é especificada como a versão mais recente). Há suporte somente para sistemas
operacionais de 64 bits. Para saber mais informações sobre os sistemas operacionais convidados, funções e
recursos com suporte, consulte Suporte de software para servidores Microsoft para máquinas virtuais do
Microsoft Azure.
Esta tabela mostra algumas maneiras de encontrar as informações de uma imagem.
Portal do Azure Os valores são especificados automaticamente quando você

seleciona uma imagem a ser usada.
Azure PowerShell Get-AzVMImagePublisher -Location location

Get-AzVMImageOffer -Location location -Publisher
publisherName
Get-AzVMImageSku -Location location -Publisher
publisherName -Offer offerName
APIs REST Listar editores de imagem

Listar ofertas de imagem
Listar skus de imagem
CLI do Azure az vm image list-publishers --location location

az vm image list-offers --location location --publisher
publisherName
az vm image list-skus --location location --publisher
publisherName --offer offerName
Você pode optar por carregar e usar sua própria imagem e, quando faz isso, o nome do editor, da oferta e da
sku não são usados.
Extensões
As extensões de VM dão à VM recursos adicionais por meio de configuração pós-implantação e tarefas
automatizadas.
Estas tarefas comuns podem ser realizadas usando extensões:
Executar scripts personalizados – a Extensão de Script Personalizado o ajuda a configurar as cargas de
trabalho na VM executando o script quando a VM é provisionada.
Implantar e gerenciar configurações – a Extensão de Configuração de Estado Desejado (DSC) do
PowerShell ajuda a configurar o DSC em uma VM para gerenciar configurações e ambientes.
Coletar dados de diagnóstico – a Extensão de Diagnóstico do Azure o ajuda a configurar a VM para
coletar dados de diagnóstico que podem ser usados para monitorar a integridade do aplicativo.
Recursos relacionados
Os recursos nesta tabela são usados por VM e precisam existir ou ser criados quando a VM é criada.
REC URSO O B RIGATÓ RIO DESC RIÇ Ã O
Grupo de recursos Sim A VM deve estar contida em um grupo

de recursos.
Conta de armazenamento Sim A VM precisa da conta de

armazenamento para armazenar seus
discos rígidos virtuais.
Rede virtual Sim A VM deve ser membro de uma rede

virtual.
Endereço IP público Não A VM pode ter um endereço IP público

atribuído a ela para acessá-la
remotamente.
Interface de rede Sim A VM precisa de interface de rede para

se comunicar na rede.
Discos de dados Não A VM pode incluir discos de dados

para expandir os recursos de
armazenamento.

Próximas etapas
Crie sua primeira VM!
Portal
PowerShell
CLI do Azure
Início Rápido: Criar uma máquina virtual Linux com
a CLI do Azure
Este início rápido mostra como usar a CLI (interface de linha de comando) do Azure para implantar uma VM
(máquina virtual) Linux no Azure. A CLI do Azure é usada para criar e gerenciar recursos do Azure da linha de
comando ou em scripts.
Neste tutorial, vamos instalar Ubuntu o 16.04 LTS. Para mostrar a VM em ação, você se conectará a ela usando
SSH e instalará o servidor Web NGINX.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Iniciar o Azure Cloud Shell

O Azure Cloud Shell é um shell interativo grátis que pode ser usado para executar as etapas neste artigo. Ele
tem ferramentas do Azure instaladas e configuradas para usar com sua conta.
Para abrir o Cloud Shell, basta selecionar Experimentar no canto superior direito de um bloco de código. Você
também pode abrir o Cloud Shell em uma guia separada do navegador indo até https://shell.azure.com/bash.
Selecione Copiar para copiar os blocos de código, cole-o no Cloud Shell e selecione Enter para executá-lo.
Se preferir instalar e usar a CLI localmente, este início rápido exigirá a CLI do Azure versão 2.0.30 ou posterior.
Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do
Azure.
Criar um grupo de recursos

Crie um grupo de recursos com o comando az group create. Um grupo de recursos do Azure é um contêiner
lógico no qual os recursos do Azure são implantados e gerenciados. O exemplo a seguir cria um grupo de
recursos chamado myResourceGroup na localização eastus:
az group create --name myResourceGroup --location eastus
Criar máquina virtual

Crie uma VM com o comando az vm create.
O exemplo a seguir cria uma VM chamada myVM e adiciona uma conta de usuário chamada azureuser. O
parâmetro --generate-ssh-keys é usado para gerar automaticamente uma chave SSH e colocá-la no local de
chave padrão ( ~/.ssh). Para usar um conjunto específico de chaves, use a opção --ssh-key-value .
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys
A criação da VM e dos recursos de suporte demora alguns minutos. O seguinte exemplo de saída mostra que a
operação de criação de VM foi bem-sucedida.
{
"fqdns": "",
"id":
"/subscriptions/<guid>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "40.68.254.142",
"resourceGroup": "myResourceGroup"
}
Observe a sua própria publicIpAddress na saída da sua VM. Este endereço é usado para acessar a VM na
próxima etapa.
Abra a porta 80 para tráfego da Web

Por padrão, somente conexões de SSH são abertas quando você criar uma VM do Linux no Azure. Use az vm
open-port para abrir a porta TCP 80 para uso com o servidor web NGINX:
az vm open-port --port 80 --resource-group myResourceGroup --name myVM
Conectar-se à máquina virtual

SSH para sua VM, como de costume. Substitua publicIpAddress pelo endereço IP público da VM como
observado na saída anterior da sua VM:
ssh azureuser@publicIpAddress
Instalar servidor Web

Para ver a VM em ação, instale o servidor Web do NGINX. Atualize suas fontes de pacote e, em seguida, instale o
pacote mais recente do NGINX.
sudo apt-get -y update

sudo apt-get -y install nginx
Quando terminar, digite exit para sair da sessão SSH.
Ver o servidor Web em ação

Use um navegador da Web de sua escolha para exibir a página inicial padrão do NGINX. Use o endereço IP
público de sua VM como o endereço Web. O seguinte exemplo mostra o site padrão do NGINX:
Limpar os recursos
Quando não for mais necessário, você pode usar o comando az group delete para remover o grupo de recursos,
a VM e todos os recursos relacionados.
az group delete --name myResourceGroup
Próximas etapas
Neste início rápido, você implantou uma máquina virtual simples, abriu uma porta de rede para o tráfego da
Web e instalou um servidor Web básico. Para saber mais sobre máquinas virtuais do Azure, continue o tutorial
para VMs do Linux.
Tutoriais de máquina virtual do Linux Azure
Início Rápido: Criar uma máquina virtual do Linux
no portal do Azure
As máquinas virtuais (VM) do Azure podem ser criadas por meio do Portal do Azure. O portal do Azure é uma
interface de usuário baseada em navegador para criar recursos do Azure. Este início rápido mostra como usar o
portal do Azure para implantar uma máquina virtual (VM) Linux que executa o Ubuntu 18.04 LTS. Para ver a VM
em ação, você também habilita o SSH na VM e instala o servidor Web do NGINX.
Entrar no Azure
Entre no portal do Azure, se você ainda não fez isso.

1. Digite máquinas vir tuais na pesquisa.
2. Em Ser viços , selecione Máquinas vir tuais .
3. Na página Máquinas Vir tuais , selecione Adicionar . A página Criar uma máquina vir tual é aberta.
4. Na guia Básico , em Detalhes do projeto , verifique se a assinatura correta está selecionada e, em
seguida, escolha Criar grupo de recursos. Digite myResourceGroup no nome*.
5. Em Detalhes da instância , digite myVM para o Nome da máquina vir tual , escolha Leste dos EUA
para Região e escolha Ubuntu 18.04 LTS para sua Imagem . Deixe os outros padrões.
6. Em Conta do administrador , selecione Chave pública SSH .

7. Em Nome de usuário , digite azureuser.
8. Em Origem de chave pública SSH , mantenha o padrão de Gerar novo par de chaves e digite
myKey como o Nome do par de chaves .
9. Em Regras de por ta de entrada > Por tas de entrada públicas , escolha Permitir por tas
selecionadas e, em seguida, selecione SSH (22) e HTTP (80) na lista suspensa.
10. Deixe os padrões restantes e, em seguida, selecione o botão Examinar + criar na parte inferior da
página.
11. Na página Criar uma máquina vir tual , você pode ver os detalhes sobre a VM que você está prestes a
criar. Quando estiver pronto, selecione Criar .
12. Quando a janela Gerar novo par de chaves for aberta, selecione Baixar chave privada e criar
recurso . O arquivo de chave será baixado como myKey.pem . Verifique se você sabe o local de
download do arquivo .pem , pois precisará do caminho para ele na próxima etapa.
13. Depois que a implantação for concluída, selecione Ir para o recurso .
14. Na página da nova VM, selecione o endereço IP público e copie-o para a área de transferência.

Crie uma conexão SSH com a VM.
1. Se estiver usando um computador Mac ou Linux, abra um prompt do Bash. Se estiver usando um
computador Windows, abra um prompt do PowerShell.
2. No prompt, abra uma conexão SSH com a máquina virtual. Substitua o endereço IP por aquele da VM e
substitua o caminho para o .pem pelo caminho para o local de download do arquivo de chave.
ssh -i .\Downloads\myKey1.pem azureuser@10.111.12.123
TIP
A chave SSH criada pode ser usada na próxima vez que você criar uma VM no Azure. Basta selecionar Usar uma chave
armazenada no Azure em Origem de chave pública SSH na próxima vez que criar uma VM. Você já tem a chave
privada no computador e, portanto, não precisará baixar nada.

Para ver a VM em ação, instale o servidor Web do NGINX. Na sua sessão de SSH, atualize suas fontes de pacote
e, em seguida, instale o pacote mais recente do NGINX.


Use um navegador da Web de sua escolha para exibir a página inicial padrão do NGINX. Digite o endereço IP
público da VM como o endereço Web. O endereço IP público pode ser encontrado na página de visão geral de
VM ou como parte da cadeia de conexão SSH usada anteriormente.
Limpar os recursos
Quando o grupo de recursos, a máquina virtual e todos os recursos relacionados não forem mais necessários,
exclua-os. Para fazer isso, selecione o grupo de recursos da máquina virtual, selecione Excluir , em seguida,
confirme o nome do grupo de recursos para excluir.
Próximas etapas
Neste início rápido, você implantou uma máquina virtual simples, criou um Grupo de Segurança de Rede e uma
regra e instalou um servidor Web básico. Para saber mais sobre máquinas virtuais do Azure, continue o tutorial
para VMs do Linux.
Início Rápido: Criar uma máquina virtual do Linux
no Azure com o PowerShell
O módulo do Azure PowerShell é usado para criar e gerenciar recursos do Azure da linha de comando do
PowerShell ou em scripts. Este início rápido mostra como usar o módulo do Azure PowerShell para implantar
uma VM Linux (máquina virtual) no Azure. Este início rápido usa a imagem do marketplace do Ubuntu 18.04
LTS da Canonical. Para ver a VM em ação, você também habilitará o SSH na VM e instalará o servidor Web do
NGINX.

Para abrir o Cloud Shell, basta selecionar Experimentar no canto superior direito de um bloco de código.
Selecione Copiar para copiar os blocos de código, cole o código no Cloud Shell e depois pressione Enter para
executá-lo.
Criar o par de chaves SSH

Use ssh-keygen para criar um par de chaves SSH. Se você já tiver um par de chaves SSH, você pode ignorar esta
etapa.
ssh-keygen -m PEM -t rsa -b 4096
Você será solicitado a fornecer um nome de arquivo para o par de chaves ou poderá pressionar Enter para usar
o local padrão de /home/<username>/.ssh/id_rsa . Você também poderá criar uma senha para as chaves, se
desejar.
Para obter mais informações sobre como criar pares de chave SSH, confira Como usar chaves SSH com o
Windows.
Se você criar o par de chaves SSH usando o Cloud Shell, ele será armazenado em uma conta de armazenamento
criada automaticamente pelo Cloud Shell. Não exclua essa conta de armazenamento ou compartilhamento de
arquivo nela até depois de recuperar suas chaves ou você perderá o acesso à VM.

Crie um grupo de recursos do Azure com New-AzResourceGroup. Um grupo de recursos é um contêiner lógico
no qual os recursos do Azure são implantados e gerenciados:
New-AzResourceGroup -Name "myResourceGroup" -Location "EastUS"
Criar recursos de rede virtual

Crie uma rede virtual, sub-rede e um endereço IP público. Esses recursos são usados para fornecer
conectividade de rede para a VM e conectá-la à Internet:
# Create a subnet configuration

$subnetConfig = New-AzVirtualNetworkSubnetConfig `
-Name "mySubnet" `
-AddressPrefix 192.168.1.0/24
# Create a virtual network

$vnet = New-AzVirtualNetwork `
-ResourceGroupName "myResourceGroup" `
-Location "EastUS" `
-Name "myVNET" `
-AddressPrefix 192.168.0.0/16 `
-Subnet $subnetConfig
# Create a public IP address and specify a DNS name

$pip = New-AzPublicIpAddress `
-AllocationMethod Static `
-IdleTimeoutInMinutes 4 `
-Name "mypublicdns$(Get-Random)"
Crie uma regra de tráfego e um Grupo de Segurança de Rede do Azure. O Grupo de Segurança de Rede protege
a VM com regras de entrada e saída. No exemplo a seguir, uma regra de entrada é criada para a porta TCP 22
que permite conexões SSH. Para permitir o tráfego da Web de entrada, uma regra de entrada para a porta TCP
80 também é criada.
# Create an inbound network security group rule for port 22

$nsgRuleSSH = New-AzNetworkSecurityRuleConfig `
-Name "myNetworkSecurityGroupRuleSSH" `
-Protocol "Tcp" `
-Direction "Inbound" `
-Priority 1000 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 22 `
-Access "Allow"
# Create an inbound network security group rule for port 80

$nsgRuleWeb = New-AzNetworkSecurityRuleConfig `
-Name "myNetworkSecurityGroupRuleWWW" `
-Protocol "Tcp" `
-Priority 1001 `
-Access "Allow"
# Create a network security group

$nsg = New-AzNetworkSecurityGroup `
-Name "myNetworkSecurityGroup" `
-SecurityRules $nsgRuleSSH,$nsgRuleWeb
Crie a NIC (placa de adaptador de rede virtual) com New-AzNetworkInterface. A NIC virtual conecta a VM a uma
sub-rede, um Grupo de Segurança de Rede e um endereço IP público.
# Create a virtual network card and associate with public IP address and NSG
$nic = New-AzNetworkInterface `
-Name "myNic" `
-SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $pip.Id `
-NetworkSecurityGroupId $nsg.Id

Para criar uma VM no PowerShell, você deve criar uma configuração que tem configurações como a imagem
para opções de autenticação, tamanho e uso. Em seguida, a configuração é usada para compilar a VM.
Defina as credenciais do SSH, as informações do sistema operacional e o tamanho de VM. Neste exemplo, a
chave SSH é armazenada no ~/.ssh/id_rsa.pub .
# Define a credential object

$securePassword = ConvertTo-SecureString ' ' -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential ("azureuser", $securePassword)
# Create a virtual machine configuration

$vmConfig = New-AzVMConfig `
-VMName "myVM" `
-VMSize "Standard_D1" | `
Set-AzVMOperatingSystem `
-Linux `
-ComputerName "myVM" `
-Credential $cred `
-DisablePasswordAuthentication | `
Set-AzVMSourceImage `
-PublisherName "Canonical" `
-Offer "UbuntuServer" `
-Skus "18.04-LTS" `
-Version "latest" | `
Add-AzVMNetworkInterface `
-Id $nic.Id
# Configure the SSH key

$sshPublicKey = cat ~/.ssh/id_rsa.pub
Add-AzVMSshPublicKey `
-VM $vmconfig `
-KeyData $sshPublicKey `
-Path "/home/azureuser/.ssh/authorized_keys"
Agora, combine as definições de configuração anteriores para criar com New-AzVM:
New-AzVM `
-Location eastus -VM $vmConfig
Levará alguns minutos para que sua VM seja implantada. Quando a implantação for concluída, vá para a
próxima seção.
Conectar-se à VM
Crie uma conexão SSH com a VM usando o endereço IP público. Para ver o endereço IP público da VM, use o
cmdlet Get-AzPublicIpAddress:
Get-AzPublicIpAddress -ResourceGroupName "myResourceGroup" | Select "IpAddress"
Usando o mesmo shell que você usou para criar o par de chaves SSH, cole o comando a seguir no shell para
criar uma sessão SSH. Substitua 10.111.12.123 pelo endereço IP da VM.
ssh azureuser@10.111.12.123
Quando solicitado, o nome de usuário de logon é azureuser. Se uma frase secreta é usada com as chaves SSH,
você precisa inseri-la, quando solicitado.
Instalar o NGINX
Para ver a VM em ação, instale o servidor Web do NGINX. Na sua sessão de SSH, atualize suas fontes de pacote
e, em seguida, instale o pacote mais recente do NGINX.


Use um navegador da Web de sua escolha para exibir a página inicial padrão do NGINX. Insira o endereço IP
público da VM como o endereço Web. O endereço IP público pode ser encontrado na página de visão geral de
VM ou como parte da cadeia de conexão SSH usada anteriormente.
Limpar os recursos
Quando não forem mais necessários, você poderá usar o cmdlet Remove-AzResourceGroup para remover o
grupo de recursos, a VM e todos os recursos relacionados:
Remove-AzResourceGroup -Name "myResourceGroup"
Próximas etapas
Neste início rápido, você implantou uma máquina virtual simples, criou um Grupo de Segurança de Rede e uma
regra e instalou um servidor Web básico. Para saber mais sobre máquinas virtuais do Azure, continue o tutorial
para VMs do Linux.
Início Rápido: Criar uma máquina virtual do Ubuntu
Linux usando um modelo do Resource Manager
Este guia de início rápido mostra como usar um modelo do Azure Resource Manager para implantar uma VM
(máquina virtual) do Ubuntu Linux no Azure.
Um modelo ARM é um arquivo JSON (JavaScript Object Notation) que define a infraestrutura e a configuração
do projeto. O modelo usa a sintaxe declarativa. Na sintaxe declarativa, você descreve a implantação pretendida
sem gravar a sequência de comandos de programação para criar a implantação.
Se seu ambiente atender aos pré-requisitos e você estiver familiarizado com o uso de modelos ARM, selecione o
botão Implantar no Azure . O modelo será aberto no portal do Azure.
Pré-requisitos
Examinar o modelo
O modelo usado neste início rápido é proveniente dos Modelos de Início Rápido do Azure.
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string",
"defaultValue": "simpleLinuxVM",
"metadata": {
"description": "The name of you Virtual Machine."
}
},
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
},
"authenticationType": {
"type": "string",
"defaultValue": "password",
"allowedValues": [
"sshPublicKey",
"password"
],
"metadata": {
"description": "Type of authentication to use on the Virtual Machine. SSH key is recommended."
}
},
"adminPasswordOrKey": {
"type": "securestring",
"metadata": {
"description": "SSH Key or password for the Virtual Machine. SSH key is recommended."
}
},
},
"dnsLabelPrefix": {
"type": "string",
"defaultValue": "[toLower(concat('simplelinuxvm-', uniqueString(resourceGroup().id)))]",
"metadata": {
"description": "Unique DNS Name for the Public IP used to access the Virtual Machine."
}
},
"ubuntuOSVersion": {
"type": "string",
"defaultValue": "18.04-LTS",
"allowedValues": [
"12.04.5-LTS",
"14.04.5-LTS",
"16.04.0-LTS",
"18.04-LTS"
],
"metadata": {
"description": "The Ubuntu version for the VM. This will pick a fully patched image of this given
Ubuntu version."
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
},
"VmSize": {
"type": "string",
"defaultValue": "Standard_B2s",
"metadata": {
"description": "The size of the VM"
}
},
"virtualNetworkName": {
"type": "string",
"defaultValue": "vNet",
"metadata": {
"description": "Name of the VNET"
}
},
"subnetName": {
"type": "string",
"defaultValue": "Subnet",
"metadata": {
"description": "Name of the subnet in the virtual network"
}
},
"networkSecurityGroupName": {
"type": "string",
"defaultValue": "SecGroupNet",
"metadata": {
"description": "Name of the Network Security Group"
}
}
},
"variables": {
"publicIpAddressName": "[concat(parameters('vmName'), 'PublicIP' )]",
"networkInterfaceName": "[concat(parameters('vmName'),'NetInt')]",
"subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('virtualNetworkName'),
parameters('subnetName'))]",
"osDiskType": "Standard_LRS",
"subnetAddressPrefix": "10.1.0.0/24",
"addressPrefix": "10.1.0.0/16",
"linuxConfiguration": {
"disablePasswordAuthentication": true,
"ssh": {
"publicKeys": [
"publicKeys": [
{
"path": "[concat('/home/', parameters('adminUsername'), '/.ssh/authorized_keys')]",
"keyData": "[parameters('adminPasswordOrKey')]"
}
]
}
}
},
"resources": [
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2020-06-01",
"name": "[variables('networkInterfaceName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups/', parameters('networkSecurityGroupName'))]",
"[resourceId('Microsoft.Network/virtualNetworks/', parameters('virtualNetworkName'))]",
"[resourceId('Microsoft.Network/publicIpAddresses/', variables('publicIpAddressName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"subnet": {
"id": "[variables('subnetRef')]"
},
"privateIPAllocationMethod": "Dynamic",
"publicIpAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPAddressName'))]"
}
}
}
],
"networkSecurityGroup": {
"id": "
[resourceId('Microsoft.Network/networkSecurityGroups',parameters('networkSecurityGroupName'))]"
}
}
},
{
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2020-06-01",
"name": "[parameters('networkSecurityGroupName')]",
"properties": {
"securityRules": [
{
"name": "SSH",
"properties": {
"priority": 1000,
"protocol": "TCP",
"access": "Allow",
"direction": "Inbound",
"sourceAddressPrefix": "*",
"sourcePortRange": "*",
"destinationAddressPrefix": "*",
"destinationPortRange": "22"
}
}
]
}
},
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2020-06-01",
"name": "[parameters('virtualNetworkName')]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('addressPrefix')]"
]
},
"subnets": [
{
"name": "[parameters('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetAddressPrefix')]",
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}
]
}
},
{
"type": "Microsoft.Network/publicIpAddresses",
"apiVersion": "2020-06-01",
"name": "[variables('publicIpAddressName')]",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"publicIpAllocationMethod": "Dynamic",
"publicIPAddressVersion": "IPv4",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsLabelPrefix')]"
},
"idleTimeoutInMinutes": 4
}
},
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2020-06-01",
"name": "[parameters('vmName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces/', variables('networkInterfaceName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('VmSize')]"
},
"storageProfile": {
"osDisk": {
"createOption": "fromImage",
"managedDisk": {
"storageAccountType": "[variables('osDiskType')]"
}
},
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "[parameters('ubuntuOSVersion')]",
"version": "latest"
}
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', variables('networkInterfaceName'))]"
}
]
},
"osProfile": {
"computerName": "[parameters('vmName')]",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPasswordOrKey')]",
"linuxConfiguration": "[if(equals(parameters('authenticationType'), 'password'), json('null'),
variables('linuxConfiguration'))]"
}
}
}
],
"outputs": {
"adminUsername": {
"type": "string",
"value": "[parameters('adminUsername')]"
},
"hostname": {
"type": "string",
"value": "[reference(variables('publicIPAddressName')).dnsSettings.fqdn]"
},
"sshCommand": {
"type": "string",
"value": "[concat('ssh ', parameters('adminUsername'), '@',
reference(variables('publicIPAddressName')).dnsSettings.fqdn)]"
}
}
}
Vários recursos do Azure estão definidos no modelo:

Microsoft.Network/vir tualNetworks/subnets : criar uma sub-rede.
Microsoft.Storage/storageAccounts : criar uma conta de armazenamento.
Microsoft.Network/networkInterfaces : criar um NIC.
Microsoft.Network/networkSecurityGroups : criar um grupo de segurança de rede.
Microsoft.Network/vir tualNetworks : criar uma rede virtual.
Microsoft.Network/publicIPAddresses : criar um endereço IP público.
Microsoft.Compute/vir tualMachines : criar uma máquina virtual.
Implantar o modelo
1. Selecione a imagem a seguir para entrar no Azure e abrir um modelo. O modelo cria um cofre de chaves
e um segredo.
2. Selecione ou insira os seguintes valores. Use os valores padrão, quando disponíveis.

Assinatura : selecione uma assinatura do Azure.
Grupo de recursos : selecione um grupo de recursos existente na lista suspensa ou selecione Criar ,
insira um nome exclusivo para o grupo de recursos e clique em OK .
Local : selecione um local. Por exemplo, Centro dos EUA .
Nome de usuário administrador : forneça um nome de usuário, como azureuser.
Tipo de autenticação : Você pode escolher entre usar uma chave SSH ou uma senha.
Senha de administrador ou chave dependendo do que você escolher para o tipo de autenticação:
Se você escolher password , a senha deverá ter pelo menos 12 caracteres e atender aos
requisitos de complexidade definidos.
Se você escolher sshPublicKey , cole o conteúdo da sua chave pública.
Prefixo do rótulo DNS : insira um identificador exclusivo a ser usado como parte do rótulo DNS.
Versão do sistema operacional Ubuntu : selecione qual versão do Ubuntu você deseja executar na
VM.
Local : o padrão será o mesmo local que o grupo de recursos, se ele já existir.
Tamanho da VM : selecione o tamanho a ser usado para a VM.
Nome da Rede Vir tual : nome a ser usado para a vNet.
Nome da sub-rede : nome da sub-rede que a VM deve usar.
Nome do Grupo de Segurança de Rede : nome do NSG.
3. Selecione Examinar + criar . Após a conclusão da validação, selecione Criar para criar e implantar a VM.
O portal do Azure é usado para implantar o modelo. Além do portal do Azure, você também pode usar a CLI do
Azure, o Azure PowerShell e a API REST. Para saber mais sobre outros métodos de implantação, confira
Implantar modelos.
Examinar os recursos implantados

Você pode usar o portal do Azure para verificar a VM e outros recursos que foram criados. Após a conclusão da
implantação, selecione Acesse o grupo de recursos para ver a VM e outros recursos.
Limpar os recursos
Quando não for mais necessário, exclua o grupo de recursos, que excluirá a VM e todos os recursos no grupo de
recursos.
1. Selecione o Grupo de recursos .
2. Na página do grupo de recursos, selecione Excluir .
3. Quando solicitado, digite o nome do grupo de recursos e depois selecione Excluir .
Próximas etapas
Neste guia de início rápido, você implantou uma máquina virtual simples usando um modelo do Resource
Manager. Para saber mais sobre máquinas virtuais do Azure, continue o tutorial para VMs do Linux.
Início Rápido: Criar uma máquina virtual do
Windows com a CLI do Azure
A CLI do Azure é usada para criar e gerenciar recursos do Azure da linha de comando ou em scripts. Este início
rápido mostra como usar a CLI do Azure para implantar uma VM (máquina virtual) no Azure que executa o
Windows Server 2016. Para ver a VM em ação, você habilita o protocolo RDP na VM e instala o servidor Web do
IIS.

também pode iniciar o Cloud Shell em uma guia separada do navegador indo até https://shell.azure.com/bash.
Selecione Copiar para copiar os blocos de código, cole o código no Cloud Shell e depois pressione Enter para
executá-lo.


Crie uma VM com az vm create. O exemplo a seguir cria uma VM chamada myVM. Este exemplo usa azureuser
para um nome de usuário administrativo.
Você precisará fornecer uma senha que atenda aos requisitos de senha para as VMs do Azure. Usando o
exemplo abaixo, você deverá inserir uma senha na linha de comando. Você também pode adicionar o parâmetro
--admin-password com um valor para a senha. O nome de usuário e a senha podem ser usados posteriormente
para se conectar às VMs.
az vm create \
--name myVM \
--image win2016datacenter \
--admin-username azureuser
{
"fqdns": "",
"id":
"macAddress": "00-0D-3A-23-9A-49",
}
Observe a sua própria publicIpAddress na saída da sua VM. Este endereço é usado para acessar a VM na
próxima etapa.

Por padrão, somente conexões de RDP são abertas quando você criar uma VM do Windows no Azure. Use az
vm open-port para abrir a porta TCP 80 para uso com o servidor web IIS:

Use o comando a seguir para criar uma sessão de área de trabalho remota no computador local. Substitua o
endereço IP pelo endereço IP público da VM. Quando solicitado, insira as credenciais usadas quando a VM foi
criada:
mstsc /v:publicIpAddress

Para ver a VM em ação, instale o servidor Web do IIS. Abra um prompt do PowerShell na VM e execute o
seguinte comando:
Install-WindowsFeature -name Web-Server -IncludeManagementTools
Quando terminar, feche a conexão RDP com a VM.

Com o IIS instalado e a porta 80 agora aberta na VM pela Internet, use um navegador da Web de sua escolha
para exibir a página inicial padrão do IIS. Use o endereço IP público da VM obtido em uma etapa anterior. O
seguinte exemplo mostra o site padrão do IIS:
Limpar os recursos
a VM e todos os recursos relacionados:
Próximas etapas
para VMs do Windows.
Tutoriais de máquina virtual do Windows Azure
Windows no Portal do Azure
As máquinas virtuais (VM) do Azure podem ser criadas por meio do Portal do Azure. Esse método fornece uma
interface de usuário baseada em navegador para criar as VMS seus recursos relacionados. Este início rápido
mostra como usar portal do Azure para implantar uma VM (máquina virtual) no Azure que executa o Windows
Server 2019. Para ver a VM em ação, você habilita o protocolo RDP na VM e instala o servidor Web do IIS.
Entrar no Azure
Entre no Portal do Azure em https://portal.azure.com.

1. Digite máquinas vir tuais na pesquisa.
2. Em Ser viços , selecione Máquinas vir tuais .
3. Na página Máquinas Vir tuais , selecione Adicionar .
4. Na guia Básico , em Detalhes do projeto , verifique se a assinatura correta está selecionada e, em
seguida, escolha Criar grupo de recursos. Digite myResourceGroup para o nome.
5. Em Detalhes da instância , digite myVM para o Nome da máquina vir tual e escolha Leste dos EUA
para a Região e, em seguida, escolha Windows Server 2019 Datacenter para Imagem . Deixe os outros
padrões.
6. Em Conta de administrador , forneça um nome de usuário, como azureuser e uma senha. A senha deve
ter no mínimo 12 caracteres e atender a requisitos de complexidade definidos.
7. Em Regras de por ta de entrada , escolha Permitir por tas selecionadas e, em seguida, selecione
RDP (3389) e HTTP (80) na lista suspensa.
8. Deixe os padrões restantes e, em seguida, selecione o botão Examinar + criar na parte inferior da
página.

Inicie uma conexão da área de trabalho remota para a máquina virtual. Estas instruções ensinam a se conectar
aàsua VM de um computador com Windows. Em um Mac, você precisa de um cliente RDP, como este Cliente de
Área de Trabalho Remota da Mac App Store.
1. Selecione o botão Conectar na página de visão geral de sua máquina virtual.
2. Na página Conectar-se à máquina vir tual , mantenha as opções padrão para se conectar por endereço
IP pela porta 3389 e clique em Baixar arquivo RDP .
3. Abra o arquivo RDP baixado e clique em Conectar quando solicitado.
4. Na janela Segurança do Windows , selecione Mais opções e Usar uma conta diferente . Digite o
nome do usuário como localhost \nomedeusuário, insira a senha que você criou para a máquina virtual
e, sem seguida, clique em OK .
5. Você pode receber um aviso do certificado durante o processo de logon. Clique em Sim ou em
Continuar para criar a conexão.

seguinte comando:
Exibir a página de boas-vindas do IIS

No portal, selecione a VM e na visão geral da VM, use o botão Clique para copiar à direita do endereço IP
para copiá-lo e colá-lo em uma guia do navegador. A página de boas-vinda do IIS padrão será aberta e deve ter
esta aparência:
Limpar os recursos
exclua-os.
Selecione o grupo de recursos da máquina virtual e, em seguida, selecione Excluir . Confirme o nome do grupo
de recursos terminar de excluir os recursos.
Próximas etapas
Início Rápido: criar uma máquina virtual do
Windows no Azure com o PowerShell
PowerShell ou em scripts. Este início rápido mostra como usar o módulo do Azure PowerShell para implantar
uma VM (máquina virtual) no Azure que executa o Windows Server 2016. Você também habilitará o protocolo
RDP para a VM e instalará o servidor Web do IIS para mostrar a VM em ação.

também pode iniciar o Cloud Shell em uma guia separada do navegador indo até
https://shell.azure.com/powershell. Selecione Copiar para copiar os blocos de código, cole o código no Cloud
Shell e depois pressione Enter para executá-lo.
Criar grupo de recursos

no qual os recursos do Azure são implantados e gerenciados.
New-AzResourceGroup -Name myResourceGroup -Location EastUS

Crie uma VM com New-AzVM. Forneça nomes para cada um dos recursos e o cmdlet New-AzVM os criará, caso
ainda não existam.
Quando solicitado, forneça um nome de usuário e uma senha a serem usados como credenciais de entrada para
a VM:
New-AzVm `
-Name "myVM" `
-Location "East US" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-PublicIpAddressName "myPublicIpAddress" `
-OpenPorts 80,3389

Após a conclusão da implantação, habilite o protocolo RDP na VM. Para ver a VM em ação, o servidor Web do
IIS é então instalado.
Para ver o endereço IP público da VM, use o cmdlet Get-AzPublicIpAddress:
Get-AzPublicIpAddress -ResourceGroupName "myResourceGroup" | Select "IpAddress"
Use o comando a seguir para criar uma sessão de área de trabalho remota no computador local. Substitua o
endereço IP pelo endereço IP público da VM.
mstsc /v:publicIpAddress
Na janela Segurança do Windows , selecione Mais opções e Usar uma conta diferente . Digite o nome do
usuário como localhost \nomedeusuário, insira a senha que você criou para a máquina virtual e, sem seguida,
clique em OK .
Você pode receber um aviso do certificado durante o processo de logon. Clique em Sim ou em Continuar para
criar a conexão

seguinte comando:

Com o IIS instalado e a porta 80 agora aberta na VM pela Internet, use um navegador da Web de sua escolha
para exibir a página inicial padrão do IIS. Use o endereço IP público da VM obtido em uma etapa anterior. O
seguinte exemplo mostra o site padrão do IIS:
Limpar os recursos
Remove-AzResourceGroup -Name myResourceGroup
Próximas etapas
Windows usando um modelo do Resource Manager
Este guia de início rápido mostra como usar um modelo do Azure Resource Manager para implantar uma VM
(máquina virtual) do Windows no Azure.
Um modelo ARM é um arquivo JSON (JavaScript Object Notation) que define a infraestrutura e a configuração
do projeto. O modelo usa a sintaxe declarativa. Na sintaxe declarativa, você descreve a implantação pretendida
sem gravar a sequência de comandos de programação para criar a implantação.
Se seu ambiente atender aos pré-requisitos e você estiver familiarizado com o uso de modelos ARM, selecione o
botão Implantar no Azure . O modelo será aberto no portal do Azure.
Pré-requisitos
Examinar o modelo
O modelo usado neste início rápido é proveniente dos Modelos de Início Rápido do Azure.
{
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
}
},
"adminPassword": {
"minLength": 12,
"metadata": {
"description": "Password for the Virtual Machine."
}
},
"dnsLabelPrefix": {
"type": "string",
"defaultValue": "[toLower(concat(parameters('vmName'),'-', uniqueString(resourceGroup().id,
parameters('vmName'))))]",
"metadata": {
}
},
"publicIpName": {
"type": "string",
"defaultValue": "myPublicIP",
"metadata": {
"description": "Name for the Public IP used to access the Virtual Machine."
}
},
"publicIPAllocationMethod": {
"type": "string",
"type": "string",
"defaultValue": "Dynamic",
"allowedValues": [
"Dynamic",
"Static"
],
"metadata": {
"description": "Allocation method for the Public IP used to access the Virtual Machine."
}
},
"publicIpSku": {
"type": "string",
"defaultValue": "Basic",
"allowedValues": [
"Basic",
"Standard"
],
"metadata": {
"description": "SKU for the Public IP used to access the Virtual Machine."
}
},
"OSVersion": {
"type": "string",
"defaultValue": "2019-Datacenter",
"allowedValues": [
"2008-R2-SP1",
"2012-Datacenter",
"2012-R2-Datacenter",
"2016-Nano-Server",
"2016-Datacenter-with-Containers",
"2016-Datacenter",
"2019-Datacenter",
"2019-Datacenter-Core",
"2019-Datacenter-Core-smalldisk",
"2019-Datacenter-Core-with-Containers",
"2019-Datacenter-Core-with-Containers-smalldisk",
"2019-Datacenter-smalldisk",
"2019-Datacenter-with-Containers-smalldisk"
],
"metadata": {
"description": "The Windows version for the VM. This will pick a fully patched image of this given
Windows version."
}
},
"vmSize": {
"type": "string",
"defaultValue": "Standard_D2_v3",
"metadata": {
"description": "Size of the virtual machine."
}
},
"location": {
"type": "string",
"metadata": {
}
},
"vmName": {
"type": "string",
"defaultValue": "simple-vm",
"metadata": {
"description": "Name of the virtual machine."
}
}
},
"variables": {
"storageAccountName": "[concat('bootdiags', uniquestring(resourceGroup().id))]",
"nicName": "myVMNic",
"subnetName": "Subnet",
"subnetPrefix": "10.0.0.0/24",
"virtualNetworkName": "MyVNET",
"subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'),
variables('subnetName'))]",
"networkSecurityGroupName": "default-NSG"
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2019-06-01",
"name": "[variables('storageAccountName')]",
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"properties": {}
},
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2020-06-01",
"name": "[parameters('publicIPName')]",
"sku": {
"name": "[parameters('publicIpSku')]"
},
"properties": {
"publicIPAllocationMethod": "[parameters('publicIPAllocationMethod')]",
"dnsSettings": {
}
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('networkSecurityGroupName')]",
"properties": {
"securityRules": [
{
"name": "default-allow-3389",
"properties": {
"priority": 1000,
"access": "Allow",
"destinationPortRange": "3389",
"protocol": "Tcp",
"destinationAddressPrefix": "*"
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('virtualNetworkName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
],
"properties": {
"addressSpace": {
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]",
"id": "[resourceId('Microsoft.Network/networkSecurityGroups',
variables('networkSecurityGroupName'))]"
}
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('nicName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPName'))]",
"[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworkName'))]"
],
"properties": {
{
"properties": {
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPName'))]"
},
"subnet": {
}
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces', variables('nicName'))]"
],
"properties": {
"vmSize": "[parameters('vmSize')]"
},
"osProfile": {
"adminPassword": "[parameters('adminPassword')]"
},
"storageProfile": {
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "[parameters('OSVersion')]",
"version": "latest"
},
"osDisk": {
"createOption": "FromImage",
"managedDisk": {
"storageAccountType": "StandardSSD_LRS"
}
},
"dataDisks": [
{
"diskSizeGB": 1023,
"lun": 0,
"createOption": "Empty"
}
]
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', variables('nicName'))]"
}
]
},
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts',
variables('storageAccountName'))).primaryEndpoints.blob]"
}
}
}
}
],
"outputs": {
"hostname": {
"type": "string",
"value": "[reference(parameters('publicIPName')).dnsSettings.fqdn]"
}
}
}
Vários recursos do Azure estão definidos no modelo:

Microsoft.Network/vir tualNetworks/subnets : criar uma sub-rede.
Microsoft.Storage/storageAccounts : criar uma conta de armazenamento.
Microsoft.Network/publicIPAddresses : criar um endereço IP público.
Microsoft.Network/networkSecurityGroups : criar um grupo de segurança de rede.
Microsoft.Network/vir tualNetworks : criar uma rede virtual.
Microsoft.Network/networkInterfaces : criar um NIC.
Microsoft.Compute/vir tualMachines : criar uma máquina virtual.
Implantar o modelo
1. Selecione a imagem a seguir para entrar no Azure e abrir um modelo. O modelo cria um cofre de chaves
e um segredo.
2. Selecione ou insira os seguintes valores. Use os valores padrão, quando disponíveis.

Assinatura : selecione uma assinatura do Azure.
Grupo de recursos : selecione um grupo de recursos existente na lista suspensa ou selecione Criar ,
insira um nome exclusivo para o grupo de recursos e clique em OK .
Local : selecione um local. Por exemplo, Centro dos EUA .
Nome de usuário administrador : forneça um nome de usuário, como azureuser.
Senha do administrador : forneça uma senha a ser usada para a conta do administrador. A senha
deve ter no mínimo 12 caracteres e atender a requisitos de complexidade definidos.
Prefixo do rótulo DNS : insira um identificador exclusivo a ser usado como parte do rótulo DNS.
Versão do sistema operacional Windows : selecione qual versão do Windows você deseja
executar na VM.
Tamanho da VM : selecione o tamanho a ser usado para a VM.
Local : o padrão será o mesmo local que o grupo de recursos, se ele já existir.
3. Selecione Examinar + criar . Após a conclusão da validação, selecione Criar para criar e implantar a VM.
O portal do Azure é usado para implantar o modelo. Além do portal do Azure, você também pode usar o Azure
PowerShell, a CLI do Azure e a API REST. Para saber mais sobre outros métodos de implantação, confira
Implantar modelos.
Examinar os recursos implantados

Você pode usar o portal do Azure para verificar a VM e outros recursos que foram criados. Após a conclusão da
implantação, selecione Acesse o grupo de recursos para ver a VM e outros recursos.
Limpar os recursos
Quando não for mais necessário, exclua o grupo de recursos, que excluirá a VM e todos os recursos no grupo de
recursos.
1. Selecione o Grupo de recursos .
2. Na página do grupo de recursos, selecione Excluir .
3. Quando solicitado, digite o nome do grupo de recursos e depois selecione Excluir .
Próximas etapas
Neste guia de início rápido, você implantou uma máquina virtual simples usando um modelo do Resource
Manager. Para saber mais sobre máquinas virtuais do Azure, continue o tutorial para VMs do Linux.
Tutorial: Criar e gerenciar VMs do Linux com a CLI
do Azure
Máquinas virtuais do Azure fornecem um ambiente de computação totalmente configurável e flexível. Este
tutorial aborda itens básicos de implantação de máquina virtual do Azure, como a seleção de um tamanho de
VM, seleção de uma imagem de VM e implantação de uma VM. Você aprenderá como:
Criar e conectar-se a uma VM
Selecionar e usar imagens de VM
Exibir e usar tamanhos específicos de VM
Redimensionar uma VM
Exibir e compreender o estado da VM
Este tutorial usa a CLI dentro do Azure Cloud Shell, que é constantemente atualizada para a versão mais recente.
Para abrir o Cloud Shell, selecione Experimentar na parte superior de um bloco de código qualquer.
Se você optar por instalar e usar a CLI localmente, este tutorial exigirá que você execute a CLI do Azure versão
2.0.30 ou posterior. Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar, consulte
Instalar a CLI do Azure.

Crie um grupo de recursos com o comando az group create.
Um grupo de recursos do Azure é um contêiner lógico no qual os recursos do Azure são implantados e
gerenciados. Você deve criar um grupo de recursos antes de criar uma máquina virtual. Neste exemplo,
criaremos um grupo de recursos chamado myResourceGroupVM na região eastus.
az group create --name myResourceGroupVM --location eastus
O grupo de recursos é especificado ao criar ou modificar uma VM, que pode ser visto durante este tutorial.

Crie uma máquina virtual com o comando az vm create.
Há várias opções disponíveis ao criar uma máquina virtual, como a imagem do sistema operacional, as
credenciais administrativas e o dimensionamento do disco. O exemplo a seguir cria uma VM chamada myVM
que executa o Servidor Ubuntu. Uma conta de usuário chamada azureuser é criada na VM, e as chaves SSH são
geradas, se ainda não existirem no local de chave padrão ( ~/.ssh):
az vm create \
--resource-group myResourceGroupVM \
--name myVM \
--image UbuntuLTS \
--generate-ssh-keys
A criação da VM pode levar alguns minutos. Depois que a VM tiver sido criada, a CLI do Azure envia
informações sobre a VM. Anote o publicIpAddress , esse endereço pode ser usado para acessar a máquina
virtual...
{
"fqdns": "",
"id": "/subscriptions/d5b9d4b7-6fc1-0000-0000-
000000000000/resourceGroups/myResourceGroupVM/providers/Microsoft.Compute/virtualMachines/myVM",
"macAddress": "00-0D-3A-23-9A-49",
"resourceGroup": "myResourceGroupVM"
}
Conectar-se a uma VM
Agora você pode se conectar à VM com o SSH no Azure Cloud Shell ou do computador local. Substitua o
endereço IP de exemplo com o publicIpAddress observado na etapa anterior.
Depois de conectado à VM, você pode instalar e configurar aplicativos. Quando tiver terminado, você fechará a
sessão SSH normalmente:
exit
Entender as imagens de VM
O Azure marketplace inclui muitas imagens que podem ser usadas para criar VMs. Nas etapas anteriores, uma
máquina virtual foi criada usando uma imagem do Ubuntu. Nesta etapa, a CLI do Azure é usada para pesquisar
no marketplace para uma imagem CentOS, que é usado para implantar uma segunda máquina virtual.
Para ver uma lista dos mais usados imagens, use o comando lista de imagens de vm az.
az vm image list --output table
A saída do comando retorna as imagens da VM mais populares no Azure.

Offer Publisher Sku Urn
UrnAlias Version
------------- ---------------------- ------------------ -------------------------------------------------
------------- ------------------- ---------
WindowsServer MicrosoftWindowsServer 2016-Datacenter MicrosoftWindowsServer:WindowsServer:2016-
Datacenter:latest Win2016Datacenter latest
WindowsServer MicrosoftWindowsServer 2012-R2-Datacenter MicrosoftWindowsServer:WindowsServer:2012-R2-
Datacenter:latest Win2012R2Datacenter latest
WindowsServer MicrosoftWindowsServer 2008-R2-SP1 MicrosoftWindowsServer:WindowsServer:2008-R2-
SP1:latest Win2008R2SP1 latest
WindowsServer MicrosoftWindowsServer 2012-Datacenter MicrosoftWindowsServer:WindowsServer:2012-
Datacenter:latest Win2012Datacenter latest
UbuntuServer Canonical 16.04-LTS Canonical:UbuntuServer:16.04-LTS:latest
UbuntuLTS latest
CentOS OpenLogic 7.3 OpenLogic:CentOS:7.3:latest
CentOS latest
openSUSE-Leap SUSE 42.2 SUSE:openSUSE-Leap:42.2:latest
openSUSE-Leap latest
RHEL RedHat 7.3 RedHat:RHEL:7.3:latest
RHEL latest
SLES SUSE 12-SP2 SUSE:SLES:12-SP2:latest
SLES latest
Debian credativ 8 credativ:Debian:8:latest
Debian latest
CoreOS CoreOS Stable CoreOS:CoreOS:Stable:latest
CoreOS latest
Uma lista completa pode ser vista, adicionando o --all argumento. A lista de imagens também pode ser
filtrada por --publisher ou –-offer . Neste exemplo, a lista está filtrada para todas as imagens com uma oferta
que corresponde a CentOS .
az vm image list --offer CentOS --all --output table
Resultado parcial:
Offer Publisher Sku Urn Version

---------------- ---------------- ---- -------------------------------------- -----------
CentOS OpenLogic 6.5 OpenLogic:CentOS:6.5:6.5.201501 6.5.201501
Para implantar uma VM usando uma imagem específica, anote o valor da coluna Urn, o qual consiste no
publicador, oferta, SKU e, opcionalmente, um número de versão para identificar a imagem. Ao especificar a
imagem, o número de versão da imagem pode ser substituído por "mais recente", que seleciona a versão mais
recente da distribuição. Neste exemplo, o --image argumento é usado para especificar a versão mais recente de
uma imagem do CentOS 6.5.
az vm create --resource-group myResourceGroupVM --name myVM2 --image OpenLogic:CentOS:6.5:latest --generate-

ssh-keys
Entender os tamanhos de VM
Um tamanho de máquina virtual determina a quantidade de recursos de computação, como memória, CPU e
GPU que estão disponíveis para a máquina virtual. Máquinas virtuais precisam ser dimensionada
adequadamente para a carga de trabalho esperada. Se a carga de trabalho aumentar, uma máquina virtual
existente pode ser redimensionada.
Tamanhos de VM
A tabela a seguir categoriza tamanhos em casos de uso.
TYPE TA M A N H O S C O M UN S DESC RIÇ Ã O
Propósito geral B, Dsv3, Dv3, DSv2, Dv2, Av2, DC CPU/memória equilibrados. Ideal para
desenvolvimento/teste e para
aplicativos de pequeno a médio porte
e soluções de dados.
Computação otimizada Fsv2 Relação de CPU/memória alta. Boa

para aplicativos de tráfego médio,
dispositivos de rede e processos em
lote.
Memória otimizada Esv3, Ev3, M, DSv2, Dv2 Relação de memória/núcleo alta. Ótima
para banco de dados relacionais,
caches médios a grandes e análises na
memória.
Armazenamento otimizado Lsv2, Ls Alta taxa de transferência de disco e de

E/S. Ideal para Big Data, SQL e bancos
de dados NoSQL.
GPU NV, NVv2, NC, NCv2, NCv3, ND VMs especializadas, destinadas para
renderização gráfica e edição de vídeo
pesadas.
Alto desempenho H Nossas VMs de CPU mais potentes

com adaptadores de rede de alto
rendimento (RDMA) opcionais.
Encontrar tamanhos de VM disponíveis

Para ver uma lista de tamanhos de VM disponíveis em uma região específica, use o comando lista-tamanhos de
vm az.
az vm list-sizes --location eastus --output table
Resultado parcial:
MaxDataDiskCount MemoryInMb Name NumberOfCores OsDiskSizeInMb
ResourceDiskSizeInMb
------------------ ------------ ---------------------- --------------- ---------------- ---------------
-------
2 3584 Standard_DS1 1 1047552
7168
4 7168 Standard_DS2 2 1047552
14336
8 14336 Standard_DS3 4 1047552
28672
16 28672 Standard_DS4 8 1047552
57344
4 14336 Standard_DS11 2 1047552
28672
8 28672 Standard_DS12 4 1047552
57344
16 57344 Standard_DS13 8 1047552
114688
32 114688 Standard_DS14 16 1047552
229376
1 768 Standard_A0 1 1047552
20480
2 1792 Standard_A1 1 1047552
71680
4 3584 Standard_A2 2 1047552
138240
8 7168 Standard_A3 4 1047552
291840
4 14336 Standard_A5 2 1047552
138240
16 14336 Standard_A4 8 1047552
619520
8 28672 Standard_A6 4 1047552
291840
16 57344 Standard_A7 8 1047552
619520
Criar VM com um tamanho específico

No exemplo de criação de VM anterior, um tamanho não foi fornecido, que resulta em um tamanho padrão. Um
tamanho de VM pode ser selecionado no momento da criação usando criar vm az e --size argumento.
az vm create \
--name myVM3 \
--image UbuntuLTS \
--size Standard_F4s \
--generate-ssh-keys
Após a implantação de uma VM, ela pode ser redimensionada para aumentar ou diminuir a alocação de
recursos. Você pode exibir atual do tamanho de uma VM com az vm show:
az vm show --resource-group myResourceGroupVM --name myVM --query hardwareProfile.vmSize
Antes de redimensionar uma VM, verifique se o tamanho desejado está disponível no cluster da VM atual. O
comando az vm lista-vm--opções de redimensionamento retorna a lista de tamanhos.
az vm list-vm-resize-options --resource-group myResourceGroupVM --name myVM --query [].name

Se o tamanho desejado estiver disponível, a VM poderá ser redimensionada a partir de um estado ligado. No
entanto, ela é reinicializada durante a operação. Use o az vm redimensionar comando para executar o
redimensionamento.
az vm resize --resource-group myResourceGroupVM --name myVM --size Standard_DS4_v2
Se o tamanho desejado não estiver no cluster atual, a VM precisará ser desalocada antes que a operação de
redimensionamento ocorra. Utilize o comando az vm deallocate para parar e desalocar a máquina virtual.
Observe que quando a VM é ligada novamente, todos os dados no disco temporário podem ser removidos. O
endereço IP público também altera a menos que um endereço IP estático está sendo usado.
az vm deallocate --resource-group myResourceGroupVM --name myVM
Quando desalocados, o redimensionamento pode ocorrer.
az vm resize --resource-group myResourceGroupVM --name myVM --size Standard_GS1
Após o redimensionamento, a VM pode ser iniciada.
az vm start --resource-group myResourceGroupVM --name myVM
Estados de energia da VM
Uma VM do Azure pode ter um dentre vários estados de energia. Esse estado representa o estado atual da VM
do ponto de vista do hipervisor.
Estados de energia
ESTA DO DE EN ERGIA DESC RIÇ Ã O
Iniciando Indica que a máquina virtual está sendo iniciada.
Executando Indica que a máquina virtual está em execução.
Parando Indica que a máquina virtual está sendo interrompida.
Parado Indica que a máquina virtual foi parada. Máquinas virtuais

no estado interrompido ainda incorrerá em encargos de
computação.
Desalocando Indica que a máquina virtual está sendo desalocada.
Desalocada Indica que a máquina virtual é removido do hipervisor, mas

ainda estão disponíveis no plano de controle. Máquinas
virtuais no estado Desalocado não incorrem em encargos de
computação.
- Indica que o estado de energia da máquina virtual é

desconhecido.
Localizar o estado de energia

Para recuperar o estado de uma VM específica, use o comando az vm get-instance-view. Especifique um nome
válido para uma máquina virtual e grupo de recursos.
az vm get-instance-view \
--name myVM \
--query instanceView.statuses[1] --output table
Saída:
ode DisplayStatus Level

------------------ --------------- -------
PowerState/running VM running Info
Para recuperar o estado de energia de todas as VMs na sua assinatura, use a API Máquinas Virtuais – Listar
Todas com o parâmetro statusOnly definido como true.
Tarefas de gerenciamento
Durante o ciclo de vida de uma máquina virtual, você talvez queira executar tarefas de gerenciamento, como
iniciar, interromper ou excluir uma máquina virtual. Além disso, é possível que você queira criar scripts para
automatizar tarefas repetitivas ou complexas. Usando a CLI do Azure, muitas tarefas comuns de gerenciamento
podem ser executadas em linha de comando ou em scripts.
Obter o endereço IP
Esse comando retorna os endereços IP públicos e privados de uma máquina virtual.
az vm list-ip-addresses --resource-group myResourceGroupVM --name myVM --output table
Como interromper uma máquina virtual
az vm stop --resource-group myResourceGroupVM --name myVM
Como iniciar uma máquina virtual
az vm start --resource-group myResourceGroupVM --name myVM
Excluir grupo de recursos

Excluir um grupo de recursos exclui todos os recursos contidos nele, tais como a VM, rede virtual e disco. O
parâmetro --no-wait retorna o controle ao prompt sem aguardar a conclusão da operação. O parâmetro
--yes confirma que você deseja excluir os recursos sem um prompt adicional para fazer isso.
az group delete --name myResourceGroupVM --no-wait --yes
Próximas etapas
Neste tutorial, você aprendeu sobre a criação e o gerenciamento básico de VM e como:
Avança para o próximo tutorial para saber mais sobre os discos de VM.
Criar e gerenciar discos de VM
Tutorial – Gerenciar discos do Azure com o Azure
CLI
Máquinas virtuais (VMs) do Azure usam discos para armazenar o sistema operacional, aplicativos e dados. Ao
criar uma VM, é importante escolher um tamanho de disco e a configuração apropriada para a carga de
trabalho esperada. Este tutorial mostra como implantar e gerenciar os discos de VM. Você saberá mais sobre:
Discos de sistema operacional e discos temporários
Discos de dados
Discos Standard e Premium
Desempenho do disco
Anexar e preparar os discos de dados
Instantâneos de disco
Discos padrão do Azure

Quando uma máquina virtual do Azure é criada, dois discos são automaticamente anexados à máquina virtual.
Disco do sistema operacional - Os discos do sistema operacional podem ser dimensionados para até 2 TB e
hospedar o sistema operacional das máquinas virtuais. O disco do sistema operacional é rotulado /dev/sda por
padrão. A configuração de cache do disco do SO é otimizada para desempenho do SO. Devido a essa
configuração, o disco do sistema operacional não deve ser usado para aplicativos ou dados. Para aplicativos e
dados, utilize um disco de dados, que é detalhado posteriormente neste tutorial.
Disco temporário - Discos temporários utilizam uma unidade de estado sólido localizada no mesmo host do
Azure que a máquina virtual. Os discos temporários são altamente eficazes e podem ser usados para operações
como o processamento de dados temporário. No entanto, se a VM for movida para um novo host, todos os
dados armazenados em um disco temporário serão removidos. O tamanho do disco temporário é determinado
pelo tamanho da máquina virtual. Os discos temporários são rotulados /dev/sdb e têm um ponto de montagem
de /mnt.
Discos de dados do Azure

Para instalar aplicativos e dados de armazenamento, outros discos de dados podem ser adicionados. Os discos
de dados devem ser usados em qualquer situação onde o armazenamento de dados durável e responsivo é
desejado. O tamanho da máquina virtual determina quantos discos de dados podem ser anexados a uma VM.
Tipos de disco da máquina virtual

O Azure fornece dois tipos de discos.
Discos Standard - apoiados por HDDs e oferecem armazenamento econômico e eficaz. Os discos Standard são
ideais para uma carga de trabalho econômica de desenvolvimento e teste.
Discos Premium – apoiados por disco de baixa latência e alto desempenho baseado em SSD. Perfeitos para
VMs que executam carga de trabalho de produção. Os tamanhos de VM com um S no nome do tamanho
normalmente são compatíveis com o Armazenamento Premium. Por exemplo, as VMs das séries DS, DSv2, GS e
FS são compatíveis com o Armazenamento Premium. Ao escolher o tamanho de um disco, o valor é
arredondado para o tipo seguinte. Por exemplo, se o tamanho do disco for maior que 64 GB, mas menor que
128 GB, o tipo de disco será P10.
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
M P1 P2 P3 P4 P6 P 10 P 15 P 20 P 30 P 40 P 50 P 60 P 70 P 80
Tam 4 8 16 32 64 128 256 512 1.0 2.0 4.0 8.1 16. 32.
anh 24 48 96 92 384 767
o
do
disc
o
em
GiB
IOP 120 120 120 120 240 500 1.1 2.3 5.0 7.5 7.5 16. 18. 20,
S 00 00 00 00 00 000 000 000
pro
visi
ona
da
por
disc
o
Taxa 25 25 25 25 50 100 125 150 200 250 250 500 750 900
de MB MB MB MB MB MB MB MB MB MB/ MB/ MB/ MB/ MB/
tran /s /s /s /s /s /s /s /s /s s s s s s
sfer
ênci
a
pro
visi
ona
da
por
disc
o
Má 3.5 3.5 3.5 3.5 3.5 3.5 3.5 3.5

xim 00 00 00 00 00 00 00 00
o
de
IOP
S
de
inte
rmit
ênci
a
por
disc
o
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Taxa 170 170 170 170 170 170 170 170

de MB MB MB MB MB MB MB MB
tran /s /s /s /s /s /s /s /s
sfer
ênci
a
de
inte
rmit
ênci
a
máx
ima
por
disc
o
Dur 30 30 30 30 30 30 30 30
açã min min min min min min min min
o
máx
ima
da
inte
rmit
ênci
a
Qu Não Não Não Não Não Não Não Não Sim, Sim, Sim, Sim, Sim, Sim,
alifi até até até até até até
cad um um um um um um
o ano ano ano ano ano ano
par
a
rese
rva
Quando você provisiona um disco de armazenamento premium, ao contrário do armazenamento padrão, a

capacidade, IOPS e taxa de transferência de disco são garantidos. Por exemplo, se você criar um disco P50, o
Azure provisionará uma capacidade de armazenamento de 4.095 GB, 7.500 IOPS e uma taxa de transferência de
250 MB/s para o disco. O aplicativo pode usar a capacidade e o desempenho no todo ou em parte. Os discos
SSD Premium são projetados para fornecer as latências baixas de milissegundos de dígito único e a IOPS de
destino e a taxa de transferência descritas na tabela anterior 99,9% do tempo.
Embora a tabela acima identifique a IOPS máxima por disco, um nível mais alto de desempenho pode ser obtido
com a distribuição de vários discos de dados. Por exemplo, 64 discos de dados podem ser anexados à VM
Standard_GS5. Se cada um desses discos for dimensionado como um P30, será possível chegar a um máximo
de 80.000 IOPS. Para obter informações detalhadas sobre o máximo de IOPS por VM, veja Tipos e tamanhos de
VM.
O Azure Cloud Shell é um shell interativo gratuito que pode ser usado para executar as etapas neste artigo. Ele
Para abrir o Cloud Shell, selecione Experimentar no canto superior direito de um bloco de código. Você
Criar e anexar discos

Discos de dados podem ser criados e anexados no momento da criação de VM ou a uma VM existente.
Anexar disco na criação da VM
az group create --name myResourceGroupDisk --location eastus
Crie uma máquina virtual com o comando az vm create. O exemplo a seguir cria uma VM chamada myVM,
adiciona uma conta de usuário chamada azureuser e gera as chaves SSH, caso ainda não existam. O
--datadisk-sizes-gb argumento é utilizado para especificar que um disco adicional deve ser criado e anexado à
máquina virtual. Para criar e anexar mais de um disco, utilize uma lista delimitada por espaço dos valores de
tamanho de disco. No exemplo a seguir, uma VM é criada com dois discos de dados, ambos os 128 GB. Como os
tamanhos de disco são 128 GB, esses discos são configurados como P10, que fornecem o máximo de 500 IOPS
por disco.
az vm create \
--resource-group myResourceGroupDisk \
--name myVM \
--image UbuntuLTS \
--size Standard_DS2_v2 \
--generate-ssh-keys \
--data-disk-sizes-gb 128 128
Anexar disco à máquina virtual existente

Para criar e anexar um novo disco a uma máquina virtual existente, utilize o comando az vm disk attach. O
exemplo a seguir cria um disco premium de 128 gigabytes de tamanho e anexa-o à VM criada na última etapa.
az vm disk attach \
--vm-name myVM \
--name myDataDisk \
--size-gb 128 \
--sku Premium_LRS \
--new
Preparar discos de dados

Depois que um disco é anexado à máquina virtual, o sistema operacional precisa ser configurado para usar o
disco. O exemplo a seguir mostra como configurar um disco manualmente. Esse processo também pode ser
automatizado utilizando a inicialização por nuvem, que é abordada em um tutorial posterior.
Crie uma conexão SSH com a máquina virtual. Substitua o endereço IP de exemplo pelo endereço IP público de
sua máquina virtual.
ssh 10.101.10.10
Particione o disco com parted .
sudo parted /dev/sdc --script mklabel gpt mkpart xfspart xfs 0% 100%
Grave um sistema de arquivos na partição utilizando o comando mkfs . Use partprobe para tornar o sistema
operacional ciente da alteração.
sudo mkfs.xfs /dev/sdc1

sudo partprobe /dev/sdc1
Monte o novo disco para que ele seja acessível no sistema operacional.
sudo mkdir /datadrive && sudo mount /dev/sdc1 /datadrive
O disco agora pode ser acessado por meio do ponto de montagem /datadrive , que pode ser verificado ao
executar o comando df -h .
df -h | grep -i "sd"
A saída mostra a nova unidade montada em /datadrive .
Filesystem Size Used Avail Use% Mounted on

/dev/sda1 29G 2.0G 27G 7% /
/dev/sda15 105M 3.6M 101M 4% /boot/efi
/dev/sdb1 14G 41M 13G 1% /mnt
/dev/sdc1 50G 52M 47G 1% /datadrive
Para garantir que a unidade seja remontada após uma reinicialização, ela deve ser adicionada ao arquivo
/etc/fstab. Para fazer isso, obtenha o UUID do disco com o blkid utilitário.
sudo -i blkid
A saída exibe o UUID da unidade, /dev/sdc1 nesse caso.
/dev/sdc1: UUID="33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e" TYPE="xfs"
NOTE
A edição inadequada do arquivo /etc/fstab pode resultar em um sistema não inicializável. Se não tiver certeza, consulte a
documentação de distribuição para obter informações sobre como editá-lo corretamente. Também é recomendável que
um backup do arquivo /etc/fstab seja criado antes da edição.
Abra o arquivo /etc/fstab em um editor de texto conforme a seguir:

sudo nano /etc/fstab
Adicione uma linha semelhante a esta ao arquivo /etc/fstab, substituindo o valor UUID pelo seu.
UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e /datadrive xfs defaults,nofail 1 2
Quando terminar de editar o arquivo, use Ctrl+O para gravar o arquivo e Ctrl+X para sair do editor.
Agora que o disco foi configurado, feche a sessão SSH.
exit
Tirar um instantâneo do disco

Ao criar um instantâneo do disco, o Azure cria uma cópia do disco de apenas leitura, de um ponto no tempo.
Instantâneos de máquina virtual do Azure são úteis para salvar rapidamente o estado de uma máquina virtual
antes de fazer alterações de configuração. No caso de um problema ou erro, a VM pode ser restaurada usando
um instantâneo. Quando uma máquina virtual tem mais de um disco, um instantâneo é tirado de cada disco
independentemente dos outros. Para fazer backups consistentes de aplicativos, considere parar a máquina
virtual antes de tirar instantâneos de disco. Como alternativa, utilize o serviço de Backup do Azure, que permite
realizar backups automáticos, enquanto a máquina virtual está em execução.
Create snapshot
Antes de criar um instantâneo, você precisará da ID ou do nome do disco. Use az vm show para capturar a ID do
disco. Neste exemplo, a ID do disco é armazenada em uma variável e utilizada em uma etapa posterior.
osdiskid=$(az vm show \
-g myResourceGroupDisk \
-n myVM \
--query "storageProfile.osDisk.managedDisk.id" \
-o tsv)
Agora que você tem a ID, use az snapshot create para criar um instantâneo do disco.
az snapshot create \
--source "$osdiskid" \
--name osDisk-backup
Como criar o disco a partir de um instantâneo

Esse instantâneo pode ser convertido em um disco usando az disk create, que pode ser usado para recriar a
máquina virtual.
az disk create \
--name mySnapshotDisk \
--source osDisk-backup
Como restaurar a máquina virtual a partir de um instantâneo

Para demonstrar a recuperação da máquina virtual, exclua a máquina virtual existente usando az vm delete.
az vm delete \
--name myVM
Crie uma nova máquina virtual a partir do disco de instantâneo.
az vm create \
--name myVM \
--attach-os-disk mySnapshotDisk \
--os-type linux
Reanexar um disco de dados

Todos os discos de dados precisam ser anexados novamente à máquina virtual.
Use o comando az disk list para localizar o nome do disco de dados. Este exemplo coloca o nome do disco em
uma variável chamada datadisk , que será usada na próxima etapa.
datadisk=$(az disk list \

--query "[?contains(name,'myVM')].[id]" \
-o tsv)
Use o comando az vm disk attach para anexar o disco.
az vm disk attach \
–g myResourceGroupDisk \
--vm-name myVM \
--name $datadisk
Próximas etapas
Neste tutorial, você aprendeu sobre tópicos de discos da VM como:
Discos de dados
Desempenho do disco
Vá para o próximo tutorial para saber como automatizar a configuração da máquina virtual.
Automatizar a configuração da VM
Tutorial – Como usar a inicialização de nuvem para
personalizar uma máquina virtual do Linux no
Azure na primeira inicialização
Em um tutorial anterior, você aprendeu como SSH em uma máquina virtual (VM) e instalar manualmente o
NGINX. Para criar VMs de maneira rápida e consistente, alguma forma de automação, em geral, é desejada. Uma
abordagem comum para personalizar uma VM na primeira inicialização é utilizar inicialização de nuvem. Neste
tutorial, você aprenderá a:
Criar um arquivo de configuração cloud-init
Criar uma VM que usa um arquivo cloud-init
Exibir um aplicativo Node.js em execução após a criação da VM
Usar o Key Vault para armazenar certificados com segurança
Automatizar implantações seguras de NGINX com cloud-init
Visão geral da inicialização de nuvem

Inicialização de nuvem é uma abordagem amplamente utilizada para personalizar uma VM do Linux, quando ela
é inicializada pela primeira vez. Você pode utilizar a inicialização de nuvem para instalar pacotes e gravar
arquivos, ou para configurar usuários e segurança. Como a inicialização de nuvem é executada durante o
processo de inicialização inicial, não há etapa adicional ou agentes necessários para aplicar a configuração.
A inicialização de nuvem também funciona em distribuições. Por exemplo, você não usa apt-get install nem
yum install para instalar um pacote. Em vez disso, você pode definir uma lista de pacotes para instalar.
Inicialização de nuvem usa automaticamente a ferramenta de gerenciamento de pacote nativo de distribuição
que você selecionar.
Estamos trabalhando com parceiros para incluir a inicialização de nuvem e trabalhar nas imagens que eles
fornecem para o Azure. Para obter informações detalhadas sobre o suporte para cloud-init para cada
distribuição, confira Suporte para cloud-init para VMs no Azure.
Criar arquivo de configuração cloud-init

Para ver a inicialização de nuvem em ação, crie uma VM que instala o NGINX e execute um simples "Hello
World" do aplicativo do Node. js. A seguinte configuração de inicialização de nuvem instala os pacotes
necessários, cria um aplicativo do Node. js, em seguida, inicializa e inicia o aplicativo.
No seu prompt do Bash ou no Cloud Shell, crie um arquivo chamado cloud-init.txt e cole a configuração a seguir.
Por exemplo, digite sensible-editor cloud-init.txt para criar o arquivo e ver uma lista de editores disponíveis.
Certifique-se de que o arquivo de inicialização de nuvem inteiro seja copiado corretamente, especialmente a
primeira linha:
#cloud-config
package_upgrade: true
packages:
- nginx
- nodejs
- npm
write_files:
- owner: www-data:www-data
path: /etc/nginx/sites-available/default
content: |
server {
listen 80;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection keep-alive;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
- owner: azureuser:azureuser
path: /home/azureuser/myapp/index.js
content: |
var express = require('express')
var app = express()
var os = require('os');
app.get('/', function (req, res) {
res.send('Hello World from host ' + os.hostname() + '!')
})
app.listen(3000, function () {
console.log('Hello world app listening on port 3000!')
})
runcmd:
- service nginx restart
- cd "/home/azureuser/myapp"
- npm init
- npm install express -y
- nodejs index.js
Para obter mais informações sobre opções de configuração de inicialização de nuvem, consulte exemplos de
configuração de inicialização de nuvem.

Antes de criar uma máquina virtual, crie um grupo de recursos com o az group create. O seguinte exemplo cria
um grupo de recursos chamado myResourceGroupAutomate no local eastus:
az group create --name myResourceGroupAutomate --location eastus
Agora, crie uma VM com az vm create. Utiçize o --custom-data parâmetro para passar no arquivo de
configuração de inicialização de nuvem. Forneça o caminho completo para a configuração cloud-init.txt se você
salvou o arquivo fora do seu diretório de trabalho atual. O exemplo a seguir cria uma VM chamada myVM:
az vm create \
--resource-group myResourceGroupAutomate \
--name myAutomatedVM \
--image UbuntuLTS \
--custom-data cloud-init.txt
Demora alguns minutos para que a VM seja criada, os pacotes para instalar e iniciar o aplicativo. Há tarefas em
segundo plano que continuarão em execução depois que a CLI do Azure faz você voltar para o prompt. Pode
demorar mais alguns minutos antes que você possa acessar o aplicativo. Quando a VM tiver sido criada,
observe o publicIpAddress exibido pela CLI do Azure. Esse endereço é usado para acessar o aplicativo do Node.
js por meio de um navegador da web.
Para permitir o tráfego da web para acessar sua VM, abra a porta 80 da Internet com az vm open-port:
az vm open-port --port 80 --resource-group myResourceGroupAutomate --name myAutomatedVM
Testar o aplicativo da web

Agora, abra um navegador da Web e insira http://<publicIpAddress> na barra de endereços. Forneça seu
próprio endereço de IP público do processo de criação da máquina virtual. Seu aplicativo Node.js é exibido
como mostrado no exemplo a seguir:
Injetar certificados do Cofre de chave

Essa seção mostra como você pode armazenar certificados no Cofre de Chaves do Azure e colocá-los durante a
implantação da máquina virtual com segurança. Em vez de usar uma imagem personalizada que inclui os
certificados embutida, esse processo garante que os certificados mais recentes são injetados em uma máquina
virtual na primeira inicialização. Durante o processo, o certificado nunca deixa a plataforma Azure ou é exposto
em um script, o histórico de linha de comando ou o modelo.
O Azure Key Vault protege chaves e segredos criptográficos, como certificados ou senhas. O Cofre da Chave
simplifica o processo de gerenciamento de chaves e permite que você tenha controle das chaves que acessam e
criptografam seus dados. Este cenário apresenta alguns conceitos de Cofre da Chave para criar e usar um
certificado, porém não é uma visão geral detalhada sobre como usar o Cofre da Chave.
As etapas a seguir mostram como você pode:
Criar um Cofre de chaves do Azure
Gerar ou carregar um certificado para o Cofre da Chave
Criar um segredo do certificado para inserir em uma máquina virtual
Criar uma máquina virtual e inserir o certificado
Primeiro, crie um Cofre de Chaves com o az keyvault create e habilitá-lo para uso quando você implanta uma
máquina virtual. Cada Cofre de Chave requer um nome exclusivo e deve estar escrito com todas as letras
minúsculas. Substitua mykeyvault no exemplo a seguir com seu próprio nome exclusivo de Cofre da Chave:
keyvault_name=mykeyvault
az keyvault create \
--name $keyvault_name \
--enabled-for-deployment
Gerar certificado e armazenar no Cofre da Chave

Para uso em produção, você deve importar um certificado válido assinado por um fornecedor confiável com o
az keyvault certificate import. Para este tutorial, o exemplo a seguir mostra como você pode gerar um
certificado autoassinado com criar certificado de keyvault az que usa a política de certificado padrão:
az keyvault certificate create \

--vault-name $keyvault_name \
--name mycert \
--policy "$(az keyvault certificate get-default-policy --output json)"
Preparar o certificado para uso com a VM

Para usar o certificado durante o processo de criação de VM, obtenha a identificação do seu certificado com as
versões secretas de az keyvault. A VM precisa do certificado em um determinado formato para colocá-lo na
inicialização, então, converta o certificado com az vm secret format. O exemplo a seguir atribui a saída desses
comandos variáveis de facilidade de uso nas próximas etapas:
secret=$(az keyvault secret list-versions \

--name mycert \
--query "[?attributes.enabled].id" --output tsv)
vm_secret=$(az vm secret format --secret "$secret" --output json)
Criar a configuração de inicialização de nuvem para proteger o NGINX

Quando você cria uma VM, certificados e chaves são armazenados no diretório protegido /var/lib/waagent/ .
Para automatizar adicionando o certificado para a máquina virtual e configurando o NGINX, você pode usar
uma configuração de inicialização de nuvem atualizada do exemplo anterior.
Crie um arquivo chamado cloud-init-secured.txt e cole a configuração a seguir. Se você usar o Cloud Shell, crie o
arquivo de configuração de nuvem init lá e não em seu computador local. Por exemplo, digite
sensible-editor cloud-init-secured.txt para criar o arquivo e ver uma lista de editores disponíveis. Certifique-
se de que o arquivo de inicialização de nuvem inteiro seja copiado corretamente, especialmente a primeira linha:
#cloud-config
packages:
- nginx
- nodejs
- npm
write_files:
path: /etc/nginx/sites-available/default
content: |
server {
listen 80;
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/mycert.cert;
ssl_certificate_key /etc/nginx/ssl/mycert.prv;
location / {
}
}
path: /home/azureuser/myapp/index.js
content: |
var app = express()
})
})
runcmd:
- secretsname=$(find /var/lib/waagent/ -name "*.prv" | cut -c -57)
- mkdir /etc/nginx/ssl
- cp $secretsname.crt /etc/nginx/ssl/mycert.cert
- cp $secretsname.prv /etc/nginx/ssl/mycert.prv
- npm init
- nodejs index.js
Criar VM segura
Agora, crie uma VM com az vm create. Os dados do certificado são injetados no cofre da chave com o
--secrets parâmetro. Como no exemplo anterior, você também passa a configuração de inicialização de nuvem
com o --custom-data parâmetro:
az vm create \
--name myVMWithCerts \
--image UbuntuLTS \
--custom-data cloud-init-secured.txt \
--secrets "$vm_secret"
Demora alguns minutos para que a VM seja criada, os pacotes para instalar e iniciar o aplicativo. Há tarefas em
segundo plano que continuarão em execução depois que a CLI do Azure faz você voltar para o prompt. Pode
demorar mais alguns minutos antes que você possa acessar o aplicativo. Quando a VM tiver sido criada,
observe o publicIpAddress exibido pela CLI do Azure. Esse endereço é usado para acessar o aplicativo do Node.
js por meio de um navegador da web.
az vm open-port \
--name myVMWithCerts \
--port 443
Testar o aplicativo da Web protegido

Agora, abra um navegador da Web e insira https://<publicIpAddress> na barra de endereços. Forneça seu
próprio endereço IP público, conforme mostrado na saída do processo de criação de VM anterior. Se você usou
um certificado autoassinado, aceite o aviso de segurança:
Seu site NGINX e Node. js seguro é exibido como no exemplo a seguir:
Próximas etapas
Neste tutorial, você configurou as VMs na primeira inicialização com cloud-init. Você aprendeu a:
Criar um arquivo de configuração cloud-init
Criar uma VM que usa um arquivo cloud-init
Exibir um aplicativo Node.js em execução após a criação da VM
Usar o Key Vault para armazenar certificados com segurança
Automatizar implantações seguras de NGINX com cloud-init
Vá para o próximo tutorial para aprender a gerenciar imagens de VM.
Criar imagens de VM personalizada
Tutorial: Criar uma imagem personalizada de uma
VM do Azure com a CLI do Azure
Imagens personalizadas são como imagens do marketplace, mas você mesmo as cria. As imagens
personalizadas podem ser usadas para configurações de inicialização como o pré-carregamento de aplicativos,
configurações de aplicativos e outras configurações do sistema operacional. Neste tutorial, você criará sua
própria imagem personalizada de uma máquina virtual do Azure. Você aprenderá como:
Criar uma definição de imagem
Criar uma VM de uma imagem
Compartilhar uma galeria de imagens
Se você optar por instalar e usar a CLI localmente, este tutorial exigirá que execute a CLI do Azure versão 2.4.0
ou posterior. Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar, consulte
Visão geral
Uma Galeria de Imagens Compartilhadas simplifica o compartilhamento da imagem personalizada em sua
organização. Imagens personalizadas são como imagens do marketplace, mas você mesmo as cria. As imagens
configurações de aplicativos e outras configurações do sistema operacional.
A Galeria de Imagens Compartilhadas permite que você compartilhe suas imagens de VM personalizadas com
outras pessoas. Escolha quais imagens você deseja compartilhar, em quais regiões deseja torná-las disponíveis e
com quem deseja compartilhá-las.
O recurso Galeria de Imagens Compartilhadas tem vários tipos de recursos:
REC URSO DESC RIÇ Ã O
Origem da imagem Este é um recurso que pode ser usado sozinho ou para criar
uma versão da imagem em uma galeria de imagens. Uma
origem de imagem pode ser uma VM do Azure existente
generalizada ou especializada, uma imagem gerenciada, um
instantâneo ou uma versão de imagem em outra galeria de
imagens.
Galeria de imagens Como o Azure Marketplace, uma galeria de imagens é um

repositório para gerenciar e compartilhar imagens, mas você
controla quem tem acesso.
Definição da imagem As definições de imagem são criadas dentro de uma galeria e

transportam informações sobre a imagem e os requisitos
para usá-la internamente. Isso inclui se a imagem é Windows
ou Linux, notas sobre a versão e requisitos mínimos e
máximos de memória. É uma definição de um tipo de
imagem.
Versão da imagem Uma versão da imagem é usada para criar uma VM ao

usar uma galeria. Você pode ter diversas versões de uma
imagem conforme necessário para seu ambiente. Como uma
imagem gerenciada, quando você usa uma versão da
imagem para criar uma VM, a versão da imagem é usada
para criar novos discos para a VM. Versões de imagem
podem ser usadas várias vezes.
Antes de começar
As etapas abaixo detalham como pegar uma VM existente e transformá-la em uma imagem personalizada
reutilizável que você pode usar para criar novas instâncias de VM.
Para concluir o exemplo neste tutorial, você deverá ter uma máquina virtual. Se necessário, confira o Início
rápido da CLI para criar uma VM a ser usada neste tutorial. Ao trabalhar no tutorial, substitua os nomes dos
recursos se necessário.

Criar uma galeria de imagens

Uma galeria de imagens é o principal recurso usado para habilitar o compartilhamento de imagens.
Caracteres permitidos para o nome da galeria são letras maiúsculas ou minúsculas, dígitos, pontos e pontos
finais. O nome da galeria não pode conter traços. Os nomes das galerias devem ser exclusivos dentro de sua
assinatura.
Criar uma galeria de imagens usando az sig create. O exemplo a seguir cria um grupo de recursos da galeria
chamado myGalleryRG no Leste dos EUA, bem como uma galeria chamada myGallery.
az group create --name myGalleryRG --location eastus

az sig create --resource-group myGalleryRG --gallery-name myGallery
Obter informações sobre a VM

Você pode ver uma lista das VMs disponíveis usando az vm list.
az vm list --output table
Quando souber o nome da VM e em qual grupo de recursos ela está, obtenha a ID da VM usando az vm get-
instance-view.
az vm get-instance-view -g MyResourceGroup -n MyVm --query id
Copie a ID da VM para usar mais tarde.

As definições de imagem criam um agrupamento lógico para as imagens. Elas são usadas para gerenciar
informações sobre as versões da imagem que são criadas dentro delas.
Os nomes das definições de imagem podem ser compostos por letras maiúsculas ou minúsculas, dígitos,
pontos, traços e pontos finais.
Para obter mais informações sobre os valores que pode especificar para uma definição de imagem, confira
Definições de imagem.
Crie uma definição de imagem na galeria usando az sig image-definition create.
Neste exemplo, a definição da imagem se chama myImageDefinition e é referente a uma imagem especializada
do SO Linux.
az sig image-definition create \

--resource-group myGalleryRG \
--gallery-name myGallery \
--gallery-image-definition myImageDefinition \
--publisher myPublisher \
--offer myOffer \
--sku mySKU \
--os-type Linux \
--os-state specialized
Copie a ID da definição da imagem da saída para usar mais tarde.
Criar a versão da imagem

Crie uma versão da imagem com base na VM usando az image gallery create-image-version.
Caracteres permitidos para a versão da imagem são números e pontos. Os números devem estar dentro do
intervalo de um inteiro de 32 bits. Formato: MajorVersion.MinorVersion.Patch.
Neste exemplo, a versão de nossa imagem é 1.0.0 e criaremos duas réplicas na região do Centro-Oeste dos EUA,
uma na região Centro-Sul dos EUA e uma na região Leste dos EUA 2 usando o armazenamento com
redundância de zona. As regiões de replicação precisam incluir a região em que a VM de origem fica localizada.
Substitua o valor de --managed-image neste exemplo pela ID da VM da etapa anterior.
az sig image-version create \
--gallery-image-version 1.0.0 \
--target-regions "westcentralus" "southcentralus=1" "eastus=1=standard_zrs" \
--replica-count 2 \
--managed-image "/subscriptions/<Subscription
ID>/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM"
NOTE
Você precisa esperar que a versão da imagem seja compilada e replicada completamente antes de poder usar a mesma
imagem gerenciada para criar outra versão da imagem.
Você também pode armazenar a imagem no armazenamento Premium adicionando
--storage-account-type premium_lrs , ou no Armazenamento com redundância de zona adicionando
--storage-account-type standard_zrs ao criar a versão da imagem.
Criar a VM
Crie a VM usando az vm create e o parâmetro --specialized para indicar que se trata de uma imagem
especializada.
Use a ID de definição de imagem de --image para criar a VM com base na versão mais recente da imagem que
está disponível. Você também pode criar a VM com base em uma versão específica fornecendo a ID de versão
da imagem de --image .
Neste exemplo, estamos criando uma VM com base na versão mais recente da imagem myImageDefinition.

az vm create --resource-group myResourceGroup \
--name myVM \
--image "/subscriptions/<Subscription
ID>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition" \
--specialized
Compartilhar a galeria
Você pode compartilhar imagens entre assinaturas usando o Azure RBAC (controle de acesso baseado em
função do Azure). Você pode compartilhar imagens no nível da galeria, da definição da imagem e da versão da
imagem. Qualquer usuário que tenha permissões de leitura para uma versão de imagem, mesmo entre
assinaturas, poderá implantar uma VM usando a versão da imagem.
Recomendamos que você compartilhe com outros usuários no nível da galeria. Para obter a ID do objeto da
galeria, use az sig show.
az sig show \
--query id
Use a ID do objeto como um escopo, juntamente com um endereço de email e az role assignment create para
conceder a um usuário acesso à galeria de imagens compartilhadas. Substitua <email-address> e <gallery iD>
pelas suas informações.
az role assignment create \
--role "Reader" \
--assignee <email address> \
--scope <gallery ID>
Para obter mais informações sobre como compartilhar recursos usando o Azure RBAC, confira Adicionar ou
remover atribuições de função do Azure usando a CLI do Azure.
Construtor de Imagens do Azure

O Azure também oferece um serviço integrado ao Packer, o Construtor de Imagens de VM do Azure. Basta
descrever suas personalizações em um modelo e ele cuidará da criação da imagem.
Próximas etapas
Neste tutorial, você criou uma imagem de VM personalizada. Você aprendeu a:
Avance para o próximo tutorial para saber mais sobre máquinas virtuais de alta disponibilidade.
Criar VMs altamente disponíveis
Tutorial: Criar e implantar máquinas virtuais
altamente disponíveis com a CLI do Azure
Neste tutorial, você aprenderá a aumentar a disponibilidade e a confiabilidade de suas soluções de Máquina
Virtual no Azure usando uma funcionalidade chamada Conjuntos de Disponibilidade. Os Conjuntos de
disponibilidade garantem que as VMs implantadas no Azure sejam distribuídas entre vários clusters de
hardware isolados. Isso garante que, se ocorrer uma falha de hardware ou de software no Azure, apenas um
subconjunto de suas VMs será afetado e a solução geral permanecerá disponível e operacional.
Neste tutorial, você aprenderá como:
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
Visão geral
Um Conjunto de disponibilidade é uma funcionalidade de agrupamento lógico que você pode usar no Azure
para garantir que os recursos da VM colocados nele sejam isolados uns dos outros quando forem implantados
em um datacenter do Azure. O Azure garante que as VMs colocadas em um Conjunto de disponibilidade sejam
executadas em vários servidores físicos, racks de computação, unidades de armazenamento e comutadores de
rede. Se uma falha de hardware ou software do Azure ocorrer, apenas um subconjunto de suas VMs será
afetado e seu aplicativo geral permanecerá disponível e ativo para seus clientes. Os Conjuntos de
Disponibilidade são uma funcionalidade essencial quando você deseja compilar soluções de nuvem confiáveis.
Vamos considerar uma solução comum baseada em VM na qual você pode ter quatro servidores Web front-end
e usar duas VMs de back-end que hospedam um banco de dados. Com o Azure, convém definir dois conjuntos
de disponibilidade antes de implantar suas VMs: um conjunto de disponibilidade para a camada "Web" e um
conjunto de disponibilidade para a camada "banco de dados". Ao criar uma nova VM, você pode especificar o
conjunto de disponibilidade como um parâmetro para o comando az vm create e o Azure garantirá
automaticamente que as VMs criadas dentro do conjunto de disponibilidade sejam isoladas em vários recursos
de hardware físico. Se o hardware físico no qual um de seus servidores Web ou VMs do servidor de banco de
dados estiverem em execução enfrentar um problema, você saberá que outras instâncias de seu servidor Web e
VMs de banco de dados permanecerão em execução, pois estão em um hardware diferente.

Crie um conjunto de disponibilidade usando az vm availability-set create. Nesse exemplo, o número de
domínios de atualização e de falha são definidos para 2 para o conjunto de disponibilidade chamado
myAvailabilitySet no grupo de recursos myResourceGroupAvailability.
Primeiro, crie um grupo de recursos com az group create, em seguida, crie um conjunto de disponibilidade:
az group create --name myResourceGroupAvailability --location eastus
az vm availability-set create \
--resource-group myResourceGroupAvailability \
--name myAvailabilitySet \
--platform-fault-domain-count 2 \
--platform-update-domain-count 2
Os Conjuntos de Disponibilidade permitem que você isole os recursos em "domínios de falha" e "domínios de
atualização". Um domínio de falha representa uma coleção isolada de recursos de servidor + rede +
armazenamento. No exemplo anterior, o conjunto de disponibilidade em pelo menos dois domínios de falha
quando nossas VMs são implantadas. O conjunto de disponibilidade também é distribuído entre dois atualizar
domínios . Dois domínios de atualização garantem que durante a atualização de software do Azure os recursos
de VM estarão isolados, impedindo que todos os softwares que executem em nossa VM sejam atualizados ao
mesmo tempo.
Criar VMs dentro de um conjunto de disponibilidade

As VMs devem ser criadas dentro do conjunto de disponibilidade para assegurar a distribuição correta pelo
hardware. Uma VM existente não pode ser adicionada a um conjunto de disponibilidade após sua criação.
Quando uma VM é criada com az vm create, você usa o parâmetro --availability-set para especificar o nome
do conjunto de disponibilidade.
for i in `seq 1 2`; do

az vm create \
--name myVM$i \
--availability-set myAvailabilitySet \
--vnet-name myVnet \
--subnet mySubnet \
--image UbuntuLTS \
--generate-ssh-keys
done
Agora há duas máquinas virtuais dentro do conjunto de disponibilidade. Como elas estão no mesmo conjunto
de disponibilidade, o Azure garantirá que as VMs e todos os seus recursos (incluindo discos de dados) sejam
distribuídos entre o hardware físico isolado. Essa distribuição ajuda a garantir uma disponibilidade muito maior
de nossa solução de VM geral.
A distribuição do conjunto de disponibilidade pode ser exibida no portal, vá para grupos de recursos >
myResourceGroupAvailability > myAvailabilitySet. As VMs são distribuídas entre as duas falhas e domínios de
atualização, conforme mostrado no exemplo a seguir:
Conferir os tamanhos de VM disponíveis
VMs adicionais podem ser adicionadas ao conjunto de disponibilidade mais tarde, onde os tamanhos de VM
estão disponíveis no hardware. Use az vm availability-set list-sizes para listar todos os tamanhos disponíveis no
cluster de hardware para o conjunto de disponibilidade:
az vm availability-set list-sizes \
--output table
Próximas etapas
Neste tutorial, você aprendeu a:
Avance para o próximo tutorial para saber mais sobre conjuntos de disponibilidade de máquinas virtuais.
Criar um conjunto de dimensionamento de máquinas virtuais
Para saber mais sobre as zonas de disponibilidade, confira a Documentação das Zonas de Disponibilidade.
Mais documentação sobre conjuntos de disponibilidade e Zonas de Disponibilidade também está disponível
aqui.
Para experimentar zonas de disponibilidade, visite Criar uma máquina virtual do Linux em uma zona de
disponibilidade com a CLI do Azure
Tutorial: Criar um conjunto de dimensionamento de
máquinas virtuais e implantar um aplicativo
altamente disponível no Linux com a CLI do Azure
Um conjunto de dimensionamento de máquinas virtuais permite implantar e gerenciar um conjunto de

máquinas virtuais idênticas de dimensionamento automático. Dimensione o número de VMs no conjunto de
dimensionamento manualmente ou defina regras para o dimensionamento automático com base no uso de
recursos, como CPU, demanda de memória ou tráfego de rede. Neste tutorial, você implantará um conjunto de
dimensionamento de máquinas virtuais no Azure. Você aprenderá como:
Usar cloud-init para criar um aplicativo para escala
Aumentar ou diminuir o número de instâncias em um conjunto de dimensionamento
Criar regras de dimensionamento automático
Exibir informações de conexão para instâncias do conjunto de dimensionamento
Usar discos de dados com conjunto de dimensionamento
Visão geral do conjunto de escala

máquinas virtuais idênticas de dimensionamento automático. As VMs em um conjunto de dimensionamento
são distribuídas entre domínios de falha lógica e domínios de atualização em um ou mais grupos de
posicionamento. Esses são grupos de VMs configuradas de maneira semelhante, da mesma forma que os
conjuntos de disponibilidade.
VMs são criadas conforme necessário em um conjunto de escala. Você define regras de dimensionamento
automático para controlar como e quando as VMs são adicionadas ou removidas do conjunto de
dimensionamento. Essas regras podem ser disparados com base em métricas como carga de CPU, utilização de
memória ou tráfego de rede.
Escala define suporte até 1.000 VMs quando você usar uma imagem da plataforma Windows Azure. Para cargas
de trabalho com requisitos significativos de personalização de VM ou instalação, você pode querer criar uma
imagem de VM personalizada. Você pode criar até 300 VMs em um conjunto de dimensionamento ao usar uma
imagem personalizada.
Criar um aplicativo para escala

Para uso em produção, você poderá criar uma imagem VM personalizada que inclui o aplicativo instalado e
configurado. Para este tutorial, permite personalizar as VMs na primeira inicialização para ver rapidamente uma
escala definida em ação.
Um tutorial anterior, você aprendeu como personalizar uma máquina virtual de Linux na primeira inicialização
com cloud-init. Você pode utilizar o mesmo arquivo de configuração de inicialização de nuvem para instalar o
NGINX e executar um aplicativo simples do Node. js 'Hello, World'.
No shell atual, crie um arquivo chamado cloud-init.txt e cole a configuração a seguir. Por exemplo, crie o arquivo
no Cloud Shell e não em seu computador local. Insira sensible-editor cloud-init.txt para criar o arquivo e ver
uma lista de editores disponíveis. Certifique-se de que o arquivo de inicialização de nuvem inteiro seja copiado
corretamente, especialmente a primeira linha:
#cloud-config
packages:
- nginx
- nodejs
- npm
write_files:
- path: /etc/nginx/sites-available/default
content: |
server {
listen 80;
location / {
}
}
- path: /home/azureuser/myapp/index.js
content: |
var app = express()
})
})
runcmd:
- npm init
- nodejs index.js
Criar um conjunto de escala

Antes de criar uma máquina virtual, crie um grupo de recursos com o az group create. O seguinte exemplo cria
um grupo de recursos chamado myResourceGroupScaleSet no local eastus:
az group create --name myResourceGroupScaleSet --location eastus
Crie um conjunto de dimensionamento de máquinas virtuais com az vmss create. O exemplo a seguir cria uma
conjunto nomeada de escala myScaleSet, usa o arquivo de nuvem-int para personalizar a VM e gera chaves
SSH, se não existirem:
az vmss create \
--resource-group myResourceGroupScaleSet \
--name myScaleSet \
--image UbuntuLTS \
--upgrade-policy-mode automatic \
--custom-data cloud-init.txt \
--generate-ssh-keys
Leva alguns minutos para criar e configurar todos os recursos e as VMs do conjunto de dimensionamento. Há
tarefas em segundo plano que continuarão em execução depois que a CLI do Azure faz você voltar para o
prompt. Pode demorar mais alguns minutos antes que você possa acessar o aplicativo.
Permitir o tráfego da web

Um balanceador de carga foi criado automaticamente como parte do conjunto de dimensionamento de
máquinas virtuais. O balanceador de carga distribui o tráfego entre um conjunto de VMs definidas usando
regras do balanceador de carga. Você pode aprender mais sobre conceitos de Balanceador de carga e a
configuração no próximo tutorial, como carga de máquinas virtuais de saldo no Azure.
Para permitir o tráfego acessar o aplicativo web, crie uma regra com criar regra de balanceamento de carga de
rede az. O exemplo a seguir cria uma regra chamada myLoadBalancerRuleWeb:
az network lb rule create \

--name myLoadBalancerRuleWeb \
--lb-name myScaleSetLB \
--backend-pool-name myScaleSetLBBEPool \
--backend-port 80 \
--frontend-ip-name loadBalancerFrontEnd \
--frontend-port 80 \
--protocol tcp
Testar seu aplicativo

Para ver seu aplicativo Node. js na web, obter o endereço IP público de sua balanceador de carga com az rede ip
público exibir. O seguinte exemplo obtém o endereço IP de myScaleSetLBPublicIP, criado como parte do
conjunto de dimensionamento:
az network public-ip show \

--name myScaleSetLBPublicIP \
--query [ipAddress] \
--output tsv
Insira o endereço IP público em um navegador da Web. O aplicativo é exibido, incluindo o nome do host da VM
para a qual o balanceador de carga distribui o tráfego:
Para ver a escala definida em ação, você pode forçar atualização seu navegador da web para ver o balanceador
de carga distribuir tráfego entre todas as VMs que executam seu aplicativo.
Durante todo o ciclo de vida do conjunto de dimensionamento, você poderá precisar executar uma ou mais
tarefas de gerenciamento. Além disso, talvez você deseje criar scripts que automatizam várias tarefas do ciclo de
vida. A CLI do Azure fornece uma maneira rápida de realizar essas tarefas. Estas são algumas tarefas comuns.
Exibição de VMs em um conjunto de escala
Para exibir uma lista de VMs em execução no seu conjunto de escala, use instâncias de lista az vmss da seguinte
maneira:
az vmss list-instances \
--name myScaleSet \
--output table
A saída deverá ser semelhante ao seguinte exemplo:
InstanceId LatestModelApplied Location Name ProvisioningState ResourceGroup

VmId
------------ -------------------- ---------- ------------ ------------------- -----------------------
------------------------------------
1 True eastus myScaleSet_1 Succeeded MYRESOURCEGROUPSCALESET
c72ddc34-6c41-4a53-b89e-dd24f27b30ab
3 True eastus myScaleSet_3 Succeeded MYRESOURCEGROUPSCALESET
44266022-65c3-49c5-92dd-88ffa64f95da
Aumentar ou diminuir manualmente as instâncias de VM

Para ver o número de instâncias que você fez em um conjunto de escala, use az vmss show e consulte
sku.capacity:
az vmss show \
--name myScaleSet \
--query [sku.capacity] \
--output table
Manualmente, é possível aumentar ou diminuir o número de máquinas virtuais no conjunto de

dimensionamento com az vmss scale. O seguinte exemplo aumenta o número de VMs no conjunto de
dimensionamento para 3:
az vmss scale \
--name myScaleSet \
--new-capacity 3
Obter informações de conexão

Para obter informações de conexão sobre as VMs nos conjuntos de dimensionamento, use az vmss list-instance-
connection-info. Esse comando gera o endereço IP público e as portas para cada VM que permite a conexão
com o SSH:
az vmss list-instance-connection-info \
--name myScaleSet
Usar discos de dados com conjuntos de dimensionamento
Você pode criar e usar discos de dados com conjuntos de dimensionamento. Em um tutorial anterior, você
aprendeu como Gerenciar discos do Azure que descreve as práticas recomendadas e as melhorias de
desempenho para a criação de aplicativos em discos de dados, em vez do disco do sistema operacional.
Criar conjunto de dimensionamento com discos de dados
Para criar um conjunto de dimensionamento e anexar discos de dados, adicione o parâmetro
--data-disk-sizes-gb ao comando az vmss create. O exemplo a seguir cria um conjunto de dimensionamento
com discos de dados de 50Gb anexados a cada instância:
az vmss create \
--name myScaleSetDisks \
--image UbuntuLTS \
--data-disk-sizes-gb 50
Quando as instâncias são removidas de um conjunto de dimensionamento, todos os discos de dados anexados
também são removidos.
Adicionar discos de dados
Para adicionar um disco de dados a instâncias no conjunto de dimensionamento, use az vmss disk attach. O
exemplo a seguir adiciona um disco de 50Gb a cada instância:
az vmss disk attach \

--name myScaleSet \
--size-gb 50 \
--lun 2
Desanexar discos de dados

Para remover um disco de dados para instâncias no conjunto de dimensionamento, use az vmss disk detach. O
exemplo a seguir remove o disco de dados no LUN 2 de cada instância:
az vmss disk detach \

--name myScaleSet \
--lun 2
Próximas etapas
Neste tutorial, você criou um conjunto de dimensionamento de máquinas virtuais. Você aprendeu a:
Usar cloud-init para criar um aplicativo para escala
Exibir informações de conexão para instâncias do conjunto de dimensionamento
Usar discos de dados com conjunto de dimensionamento
Avança para o próximo tutorial para saber mais sobre conceitos de máquinas virtuais de balanceamento de
carga.
Balancear carga de máquinas virtuais
Tutorial: balancear carga de máquinas virtuais do
Linux no Azure para criar um aplicativo altamente
disponível com a CLI do Azure
O balanceamento de carga fornece um nível mais alto de disponibilidade, distribuindo as solicitações de entrada
em várias máquinas virtuais. Neste tutorial, você aprenderá sobre os diferentes componentes do balanceador
de carga do Azure que distribuem o tráfego e fornecem alta disponibilidade. Você aprenderá como:
Criar um balanceador de carga do Azure
Criar uma investigação de integridade do balanceador de carga
Criar regras de tráfego para o balanceador de carga
Usar cloud-init para criar um aplicativo básico do Node.js
Criar máquinas virtuais e anexar a um balanceador de carga
Exibir um balanceador de carga em ação
Adicionar e remover as VMs de um balanceador de carga
Visão geral do Balanceador de Carga do Azure

Um Azure Load Balancer é um balanceador de carga de Camada 4 (TCP, UDP) que fornece alta disponibilidade
distribuindo o tráfego de entrada entre VMs íntegros. Uma investigação de integridade do balanceador de carga
monitora uma determinada porta em cada VM e distribui o tráfego somente para uma VM operacional.
Você define uma configuração de IP de front-end que contém um ou mais endereços IP públicos. Essa
configuração de IP de front-end permite que seu balanceador de carga e os aplicativos estejam acessíveis pela
Internet.
As máquinas virtuais conectam-se a um balanceador de carga usando a placa de interface de rede virtual (NIC).
Para distribuir o tráfego para as máquinas virtuais, um pool de endereços de back-end contém os endereços IP
das NICs virtuais conectadas ao balanceador de carga.
Para controlar o fluxo do tráfego, você precisará definir regras do balanceador de carga para portas específicas e
protocolos que mapeiam para suas VMs.
Se você seguiu o tutorial anterior para criar um conjunto de escala de máquina virtual, um balanceador de carga
foi criado para você. Todos esses componentes foram configurados como parte do conjunto de
dimensionamento.
Criar o balanceador de carga do Azure

Esta seção fornece detalhes sobre como criar e configurar cada componente do balanceador de carga. Antes de
criar seu balanceador de carga, crie um grupo de recursos com o az group create. O seguinte exemplo cria um
grupo de recursos chamado myResourceGroupLoadBalancer no local eastus:
az group create --name myResourceGroupLoadBalancer --location eastus
Criar um endereço IP público

Para acessar seu aplicativo na Internet, você precisará de um endereço IP público para o balanceador de carga.
Crie um endereço IP público com az network public-ip create. O exemplo a seguir cria um endereço IP público
chamado myPublicIP no grupo de recursos myResourceGroupLoadBalancer:
az network public-ip create \

--resource-group myResourceGroupLoadBalancer \
--name myPublicIP
Criar um balanceador de carga

Crie um balanceador de carga com az network lb create. O exemplo a seguir cria um balanceador de carga
chamado myLoadBalancer e atribui o endereço myPublicIP para a configuração de IP front-end:
az network lb create \
--name myLoadBalancer \
--frontend-ip-name myFrontEndPool \
--backend-pool-name myBackEndPool \
--public-ip-address myPublicIP
Criar uma investigação de integridade

Para permitir que o balanceador de carga monitore o status de seu aplicativo, use uma investigação de
integridade. A investigação de integridade adiciona ou remove dinamicamente VMs da rotação do balanceador
de carga com base na resposta às verificações de integridade. Por padrão, uma VM é removida da distribuição
do balanceador de carga após duas falhas consecutivas em intervalos de 15 segundos. Crie uma investigação de
integridade com base em um protocolo ou página de verificação de integridade específica ao seu aplicativo.
O exemplo a seguir cria uma investigação de TCP. Você também pode criar investigações de HTTP
personalizadas para obter verificações de integridade mais refinadas. Ao usar uma investigação de HTTP
personalizada, você deverá criar a página de verificação de integridade, como healthcheck.js. A investigação
deve retornar a reposta HTTP 200 OK para o balanceador de carga a fim de manter o host em rotação.
Para criar uma investigação de integridade TCP, consulte az network lb probe create. O exemplo a seguir cria
uma investigação de integridade chamada myHealthProbe:
az network lb probe create \

--lb-name myLoadBalancer \
--name myHealthProbe \
--protocol tcp \
--port 80
Criar uma regra de balanceador de carga

Uma regra de balanceador de carga é usada para definir como o tráfego é distribuído para as VMs. Definir a
configuração de IP de front-end para o tráfego de entrada e o pool de IP de back-end para receber o tráfego,
junto com as portas de origem e de destino necessárias. Para ter certeza de que apenas VMs íntegras recebem
tráfego, defina também a investigação de integridade a ser usada.
Crie uma regra de balanceador de carga com az network lb rule create. O exemplo a seguir cria uma regra
chamada myLoadBalancerRule, usa a investigação de integridade myHealthProbe e equilibra o tráfego na porta
80:
az network lb rule create \

--name myLoadBalancerRule \
--protocol tcp \
--frontend-port 80 \
--backend-port 80 \
--frontend-ip-name myFrontEndPool \
--backend-pool-name myBackEndPool \
--probe-name myHealthProbe
Configurar rede virtual

Antes de implantar algumas VMs e poder testar o balanceador, crie os recursos de suporte de rede virtual. Para
saber mais sobre redes virtuais, veja o tutorial Gerenciar Redes Virtuais do Azure.
Criar recursos da rede
Crie a rede virtual com az network vnet create. O exemplo a seguir cria uma rede virtual chamada myVnet com
uma sub-rede chamada mySubnet:
az network vnet create \

--name myVnet \
--subnet-name mySubnet
Para adicionar um grupo de segurança de rede, utilize az network nsg create. O exemplo a seguir cria um grupo
de segurança de rede denominado myNetworkSecurityGroup:
az network nsg create \

--name myNetworkSecurityGroup
Crie uma regra de grupo de segurança de rede com az network nsg create. O exemplo a seguir cria uma regra
de grupo de segurança de rede chamada myNetworkSecurityGroupRule:
az network nsg rule create \

--nsg-name myNetworkSecurityGroup \
--name myNetworkSecurityGroupRule \
--priority 1001 \
--protocol tcp \
--destination-port-range 80
NICs virtuais são criadas com az network nic create. O exemplo a seguir cria três NICs virtuais. (Uma NIC virtual
para cada VM criada para seu aplicativo nas etapas a seguir). Você pode criar VMs e NICs virtuais adicionais a
qualquer momento e adicioná-las ao balanceador de carga:
az network nic create \
--name myNic$i \
--subnet mySubnet \
--network-security-group myNetworkSecurityGroup \
--lb-address-pools myBackEndPool
done
Quando todos os três NICs virtuais forem criados, prossiga para a próxima etapa
Criar máquinas virtuais

Criar configuração de inicialização de nuvem
Em um tutorial anterior sobre Como personalizar uma máquina virtual do Linux na primeira inicialização, você
aprendeu a automatizar a personalização de VM com a inicialização de nuvem. Você pode utilizar o mesmo
arquivo de configuração de inicialização de nuvem para instalar o NGINX e executar um aplicativo simples do
Node. js 'Olá, Mundo' na próxima etapa. Para ver o balanceador de carga em ação, no final do tutorial, acesse
este simples aplicativo em um navegador da web.
No shell atual, crie um arquivo chamado cloud-init.txt e cole a configuração a seguir. Por exemplo, crie o arquivo
no Cloud Shell e não em seu computador local. Insira sensible-editor cloud-init.txt para criar o arquivo e ver
uma lista de editores disponíveis. Certifique-se de que o arquivo de inicialização de nuvem inteiro seja copiado
corretamente, especialmente a primeira linha:
#cloud-config
packages:
- nginx
- nodejs
- npm
write_files:
content: |
server {
listen 80;
location / {
}
}
- path: /home/azureuser/myapp/index.js
content: |
var app = express()
})
})
runcmd:
- npm init
- nodejs index.js

Para melhorar a alta disponibilidade do seu aplicativo, coloque suas VMs em um conjunto de disponibilidade.
Para obter mais informações sobre conjuntos de disponibilidade, consulte o tutorial anteriorComo criar
máquinas virtuais altamente disponíveis.
Crie um conjunto de disponibilidade com az vm availability-set create. O exemplo a seguir cria um conjunto de
disponibilidade chamado myAvailabilitySet:
--name myAvailabilitySet
Agora, você podecriar as VMs com az vm create. O exemplo a seguir cria três VMs e gera chaves SSH, se elas
ainda não existirem:
az vm create \
--name myVM$i \
--nics myNic$i \
--image UbuntuLTS \
--no-wait
done
Há tarefas em segundo plano que continuarão em execução depois que a CLI do Azure faz você voltar para o
prompt. O parâmetro --no-wait não espera até que todas as tarefas sejam concluídas. Pode demorar mais
alguns minutos antes que você possa acessar o aplicativo. A investigação de integridade do balanceador de
carga detecta automaticamente quando o aplicativo está em execução em cada VM. Quando o aplicativo estiver
em execução, a regra do balanceador de carga começará a distribuir o tráfego.
Testar o balanceador de carga

Obtenha o endereço IP público de seu balanceador de carga com az network public-ip show. O exemplo a seguir
obtém o endereço IP para myPublicIP criado anteriormente:

--name myPublicIP \
--query [ipAddress] \
--output tsv
Você pode inserir o endereço IP público em um navegador da Web. Lembre-se - leva alguns minutos para a
VMs estar pronta antes do balanceador de carga distribuir tráfego a eles. O aplicativo é exibido, incluindo o
nome do host da VM para a qual o balanceador de carga distribui o tráfego, como no exemplo a seguir:
Para ver o balanceador de carga distribuir tráfego entre todas as três VMs que executam seu aplicativo, você
poderá forçar a atualização de seu navegador da Web.
Adicionar e remover as VMs

Talvez seja necessário fazer a manutenção nas VMs que executam seu aplicativo, como a instalação de
atualizações do sistema operacional. Para lidar com o aumento de tráfego em seu aplicativo, talvez seja
necessário adicionar outras VMs. Esta seção mostra como remover ou adicionar uma VM do balanceador de
carga.
Remover uma VM do balanceador de carga
Você pode remover uma VM do pool de endereços de back-end com az network nic ip-config address-pool
remove. O exemplo a seguir remove a NIC virtual para myVM2 de myLoadBalancer:
az network nic ip-config address-pool remove \
--nic-name myNic2 \
--ip-config-name ipConfig1 \
--address-pool myBackEndPool
Para ver o balanceador de carga distribuir tráfego entre as duas VMs restantes que executam seu aplicativo,
você poderá forçar a atualização de seu navegador da Web. Agora você pode executar a manutenção na VM,
como instalação de atualizações do sistema operacional ou execução de uma reinicialização da VM.
Para exibir uma lista de VMs com NICs virtuais conectadas ao balanceador de carga, use az network lb address-
pool show. Consultar e filtrar a ID da NIC virtual da seguinte maneira:
az network lb address-pool show \

--name myBackEndPool \
--query backendIpConfigurations \
--output tsv | cut -f4
A saída é semelhante ao exemplo a seguir, que mostra que a NIC virtual para máquina virtual 2 não é parte do
pool de endereços de back-end:
/subscriptions/<guid>/resourceGroups/myResourceGroupLoadBalancer/providers/Microsoft.Network/networkInterfac
es/myNic1/ipConfigurations/ipconfig1
/subscriptions/<guid>/resourceGroups/myResourceGroupLoadBalancer/providers/Microsoft.Network/networkInterfac
es/myNic3/ipConfigurations/ipconfig1
Adicionar uma VM ao balanceador de carga

Após executar a manutenção da VM, ou se você precisar expandir a capacidade, você poderá adicionar uma VM
ao pool de endereços de back-end com az network nic ip-config address-pool add. O exemplo a seguir adiciona
a NIC virtual para myVM2 a myLoadBalancer:
az network nic ip-config address-pool add \

--nic-name myNic2 \
--ip-config-name ipConfig1 \
--address-pool myBackEndPool
Para verificar que a NIC virtual está conectada ao pool de endereços de back-end, use az network lb address-
pool show de novo da etapa anterior.
Próximas etapas
Neste tutorial, você criou um balanceador de carga e anexou VMs. Você aprendeu a:
Usar cloud-init para criar um aplicativo básico do Node.js
Avance para o próximo tutorial para aprender mais sobre os componentes de rede virtual do Azure.
Gerencie VMs e redes virtuais
Tutorial: Criar e gerenciar redes virtuais do Azure
para máquinas virtuais do Linux com a CLI do
Azure
As máquinas virtuais do Azure usam a rede do Azure para comunicação de rede interna e externa. Este tutorial
explica como implantar duas máquinas virtuais e configurar a rede do Azure para essas VMs. Os exemplos neste
tutorial supõem que as VMs estão hospedando um aplicativo Web com um back-end de banco de dados. No
entanto, não há implantação de aplicativo no tutorial. Neste tutorial, você aprenderá como:
Criar a rede virtual e a sub-rede
Criar uma VM de front-end
Protegem o tráfego de rede
Criar uma VM de back-end
Visão Geral da VM
As redes virtuais do Azure habilitam conexões de rede seguras entre máquinas virtuais, a Internet e outros
serviços do Azure, como o Banco de Dados SQL do Azure. As redes virtuais são divididas em segmentos lógicos
chamados sub-redes. As sub-redes são usadas para controlar o fluxo de rede e como um limite de segurança.
Ao implantar uma máquina virtual, ela geralmente inclui um adaptador de rede virtual, que é anexado a uma
sub-rede.
Conforme você conclui o tutorial, os seguintes recursos de rede virtual são criados:
myVNet – a rede virtual que as VMs usam para se comunicar entre si e com a Internet.
myFrontendSubnet – a sub-rede em myVNet usada pelos recursos de front-end.
myPublicIPAddress – o endereço IP público usado para acessar myFrontendVM da Internet.
myFrontentNic – Adaptador de rede usado pelo myFrontendVM para se comunicar com myBackendVM.
myFrontendVM – a VM usada para comunicação entre a Internet e myBackendVM.
myBackendNSG – o grupo de segurança de rede que controla a comunicação entre o myFrontendVM e
myBackendVM.
myBackendSubnet – a sub-rede associada a myBackendNSG e usada pelos recursos de back-end.
myBackendNic – O adaptador de rede usado pelo myBackendVM para se comunicar com myFrontendVM.
myBackendVM -a VM que usa a porta 22 e 3306 para se comunicar com myFrontendVM.

Para este tutorial, uma única rede virtual é criada com duas sub-redes. Uma sub-rede de front-end para
hospedar um aplicativo Web e uma sub-rede de back-end para hospedar um servidor de banco de dados.
Antes de criar uma máquina virtual, crie um grupo de recursos com o az group create. O exemplo abaixo cria
um grupo de recursos denominado myRGNetwork no local eastus.
az group create --name myRGNetwork --location eastus
Criar rede virtual

Use o comando az network vnet create para criar uma rede virtual. Neste exemplo, a rede é denominada
mvVNet e recebe um prefixo de endereço de 10.0.0.0/16. Uma sub-rede também é criada com o nome de
myFrontendSubnet e um prefixo de 10.0.1.0/24. Mais tarde neste tutorial, uma VM de front-end será conectada
a essa sub-rede.
--resource-group myRGNetwork \
--name myVNet \
--address-prefix 10.0.0.0/16 \
--subnet-name myFrontendSubnet \
--subnet-prefix 10.0.1.0/24
Criar sub-rede
Uma nova sub-rede é adicionada à rede virtual usando o comando az network vnet subnet create. Neste
exemplo, a sub-rede é denominada myBackendSubnet e recebe um prefixo de endereço de 10.0.2.0/24. Essa
sub-rede é usada com todos os serviços de back-end.
az network vnet subnet create \

--vnet-name myVNet \
--name myBackendSubnet \
--address-prefix 10.0.2.0/24
Neste ponto, uma rede foi criada e segmentada em duas sub-redes, uma para os serviços de front-end e outra
para serviços de back-end. Na próxima seção, as máquinas virtuais serão criadas e conectadas a essas sub-
redes.

Um endereço IP público permite que os recursos do Azure sejam acessados pela Internet. O método de alocação
do endereço IP público pode ser configurado como dinâmico ou estático. Por padrão, um endereço IP público é
alocado dinamicamente. Os endereços IP dinâmicos são liberados quando uma VM é desalocada. Esse
comportamento faz com que o endereço IP se altere durante operações que incluam uma desalocação de VM.
O método de alocação pode ser definido como estático, o que garante que o endereço IP permaneça atribuído a
uma VM mesmo durante um estado desalocado. Ao usar um endereço IP alocado estaticamente, o próprio
endereço IP não poderá ser especificado. Em vez disso, ele é alocado de um pool de endereços disponíveis.
az network public-ip create --resource-group myRGNetwork --name myPublicIPAddress
Ao criar uma máquina virtual com o comando az vm create, o método de alocação do endereço IP público
padrão será dinâmico. Ao criar uma máquina virtual usando o comando az vm create, inclua o argumento
--public-ip-address-allocation static para atribuir um endereço IP público estático. Essa operação não é
demonstrada neste tutorial, mas, na próxima seção, um endereço IP alocado dinamicamente é alterado para um
endereço alocado estaticamente.
Alterar método de alocação
O método de alocação de endereço IP pode ser alterado usando o comando az network public-ip update. Neste
exemplo, o método de alocação do endereço IP da máquina virtual front-end é alterado para estático.
Primeiro, desaloque a VM.
az vm deallocate --resource-group myRGNetwork --name myFrontendVM
Use o comando az network public-ip update para atualizar o método de alocação. Nesse caso, o
--allocation-method está sendo definido como estático.
az network public-ip update --resource-group myRGNetwork --name myPublicIPAddress --allocation-method static
Inicie a VM.
az vm start --resource-group myRGNetwork --name myFrontendVM --no-wait
Sem endereço IP público

Geralmente, uma VM não precisa ficar acessível pela Internet. Para criar uma máquina virtual sem um endereço
IP público, use o argumento --public-ip-address "" com um conjunto vazio de aspas duplas. Essa configuração
é demonstrada mais tarde neste tutorial.

Use o comando az vm create para criar a VM denominada myFrontendVM usando myPublicIPAddress.
az vm create \
--name myFrontendVM \
--subnet myFrontendSubnet \
--nsg myFrontendNSG \
--public-ip-address myPublicIPAddress \
--image UbuntuLTS \
--generate-ssh-keys

Um NSG (grupo de segurança de rede) contém uma lista de regras de segurança que permitem ou negam o
tráfego de rede para recursos conectados a VNets (redes virtuais) do Azure. Os NSGs podem ser associados a
sub-redes ou adaptadores de rede individuais. Quando um NSG está associado um adaptador de rede, ele se
aplica somente à VM associada. Quando um NSG está associado a uma sub-rede, as regras se aplicam a todos
os recursos conectados à sub-rede.
Regras de grupo de segurança de rede
As regras NSG definem portas de rede pelas quais o tráfego é permitido ou negado. As regras podem incluir
intervalos de endereços IP de origem e de destino, para que o tráfego seja controlado entre sistemas ou sub-
redes específicos. As regras NSG também incluem uma prioridade (entre 1 e 4096). As regras são avaliadas na
ordem de prioridade. Uma regra com uma prioridade 100 é avaliada antes de uma regra com prioridade 200.
Todos os NSGs contêm um conjunto de regras padrão. As regras padrão não podem ser excluídas, mas como
recebem a prioridade mais baixa, elas podem ser substituídas pelas regras que você criar.
As regras padrão para NSGs são:
Rede vir tual: o tráfego que começa e termina em uma rede virtual é permitido nas direções de entrada e
saída.
Internet: o tráfego de saída é permitido, mas o tráfego de entrada é bloqueado.
Balanceador de carga: o balanceador de carga do Azure permite investigar a integridade de suas VMs e
instâncias de função. Se não estiver usando um conjunto de balanceamento de carga, você poderá substituir
essa regra.
Criar grupos de segurança de rede
Um grupo de segurança de rede pode ser criado ao mesmo tempo que uma VM usando o comando az vm
create. Ao fazer isso, o NSG é associado ao adaptador de rede das VMs e uma regra NSG é criada
automaticamente para permitir o tráfego na porta 22 de qualquer origem. No início deste tutorial, o NSG de
front-end foi criado automaticamente com a máquina virtual de front-end. Uma regra NSG também foi criada
para a porta 22 automaticamente.
Em alguns casos, pode ser útil criar um NSG previamente, como quando as regras SSH padrão não devem ser
criadas ou quando o NSG deve ser conectado a uma sub-rede.
Use o comando az network nsg create para criar um grupo de segurança de rede.
az network nsg create --resource-group myRGNetwork --name myBackendNSG
Em vez de associar o NSG a um adaptador de rede, ele é associado a uma sub-rede. Nessa configuração, todas
as VMs conectadas à sub-rede herdam as regras NSG.
Atualize a sub-rede existente denominada myBackendSubnet com o novo NSG.
az network vnet subnet update \

--name myBackendSubnet \
--network-security-group myBackendNSG
Proteger o tráfego de entrada

Quando a máquina virtual front-end foi criada, uma regra NSG foi criada para permitir o tráfego de entrada na
porta 22. Essa regra permite conexões de SSH para a máquina virtual. Para este exemplo, o tráfego também
deve ser permitido na porta 80. Essa configuração permite que um aplicativo Web seja acessado na VM.
Use o comando az network nsg rule create para criar uma regra de porta 80.

--nsg-name myFrontendNSG \
--name http \
--access allow \
--protocol Tcp \
--direction Inbound \
--priority 200 \
--source-address-prefix "*" \
--source-port-range "*" \
--destination-address-prefix "*" \
A VM de front-end só está acessível nas portas 22 e 80. Todos os outros tráfegos de entrada são bloqueados no
grupo de segurança de rede. Ele pode ser útil para visualizar as configurações de regra do NSG. Retorne a
configuração da regra do NSG como comando az network rule list.
az network nsg rule list --resource-group myRGNetwork --nsg-name myFrontendNSG --output table
Garantir VM para tráfego de VM

As regras de grupo de segurança de rede também podem se aplicar entre VMs. Neste exemplo, a VM de front-
end precisa se comunicar com a VM de back-end nas portas 22 e 3306. Essa configuração permite conexões de
SSH da VM front-end e também que um aplicativo na VM de front-end se comunique com um banco de dados
MySQL de back-end. Todo o tráfego deve ser bloqueado entre as máquinas virtuais de front-end e back-end.
Use o comando az network nsg rule create para criar uma regra de porta 22. Observe que o argumento
--source-address-prefix especifica um valor de 10.0.1.0/24. Essa configuração garante que apenas o tráfego da
sub-rede de front-end seja permitido pelo NSG.

--nsg-name myBackendNSG \
--name SSH \
--access Allow \
--protocol Tcp \
--priority 100 \
--source-address-prefix 10.0.1.0/24 \
--destination-port-range "22"
Agora, adicione uma regra para o tráfego MySQL na porta 3306.

--name MySQL \
--access Allow \
--protocol Tcp \
--priority 200 \
--source-address-prefix 10.0.1.0/24 \
--destination-port-range "3306"
Por fim, como os NSGs têm uma regra padrão permitindo todo o tráfego entre as VMs na mesma rede virtual,
uma regra pode ser criada para os NSGs de back-end bloquearem todo o tráfego. Observe aqui que a
--priority recebe um valor de 300 , que é menor que as regras NSG e MySQL. Essa configuração garante que
os tráfegos SSH e MySQL ainda sejam permitidos pelo NSG.

--name denyAll \
--access Deny \
--protocol Tcp \
--priority 300 \
--source-address-prefix "*" \
--destination-port-range "*"
Criar VM back-end
Agora, crie uma máquina virtual, que é anexada ao myBackendSubnet. Observe que o argumento --nsg possui
um valor vazio com aspas duplas. Um NSG não precisa ser criado com a máquina virtual. A máquina virtual está
conectada à sub-rede de back-end, que é protegida com o NSG de back-end criado previamente. Esse NSG
aplica-se à VM. Além disso, observe aqui que o argumento --public-ip-address possui um valor vazios com
aspas duplas. Essa configuração cria uma VM sem um endereço IP público.
az vm create \
--name myBackendVM \
--subnet myBackendSubnet \
--public-ip-address "" \
--nsg "" \
--image UbuntuLTS \
--generate-ssh-keys
A VM de back-end só está acessível nas portas 22 e 3306 da sub-rede de front-end. Todos os outros tráfegos de
entrada são bloqueados no grupo de segurança de rede. Ele pode ser útil para visualizar as configurações de
regra do NSG. Retorne a configuração da regra do NSG como comando az network rule list.
az network nsg rule list --resource-group myRGNetwork --nsg-name myBackendNSG --output table
Próximas etapas
Neste tutorial, você criou e protegeu redes do Azure em relação às máquinas virtuais. Você aprendeu a:
Criar VM back-end
Para saber como proteger seus discos de VM, confira Backup e recuperação de desastre para discos.
Tutorial: Criar e gerenciar as VMs do Windows com
o Azure PowerShell
Máquinas virtuais do Azure fornecem um ambiente de computação totalmente configurável e flexível. Este
tutorial aborda itens básicos de tarefas de implantação de VM (máquina virtual) do Azure, como a seleção de
um tamanho de VM, a seleção de uma imagem de VM e a implantação de uma VM. Você aprenderá como:


Crie um grupo de recursos com o comando New-AzResourceGroup.
gerenciados. Você deve criar um grupo de recursos antes de criar uma máquina virtual. No exemplo a seguir,
um grupo de recursos chamado myResourceGroupVM é criado na região EastUS :
New-AzResourceGroup `
-ResourceGroupName "myResourceGroupVM" `
-Location "EastUS"

Há várias opções disponíveis ao criar uma VM, como a imagem do sistema operacional, a configuração de rede
e as credenciais administrativas. Este exemplo cria uma VM, denominada myVM, que executa a versão padrão
do Windows Server 2016 Datacenter.
Defina o nome de usuário e a senha necessários para a conta de administrador na VM com Get-Credential:
$cred = Get-Credential
Crie a VM com New-AzVM.

New-AzVm `
-Name "myVM" `
-Credential $cred
Conectar-se a uma VM
Após a implantação, crie uma conexão de área de trabalho remota com a VM.
Execute os comandos a seguir para retornar o endereço IP público da VM. Anote esse endereço IP para se
conectar a ele com o navegador para testar a conectividade à Web em uma etapa futura.
Get-AzPublicIpAddress `
-ResourceGroupName "myResourceGroupVM" | Select IpAddress
Use o comando a seguir em seu computador local para criar uma sessão remota de área de trabalho com a VM.
Substitua o endereço IP pelo publicIPAddress da VM. Quando solicitado, insira as credenciais usadas ao criar a
VM.
mstsc /v:<publicIpAddress>
Na janela Segurança do Windows , selecione Mais opções e Usar uma conta diferente . Digite o nome de
usuário e a senha que você criou para a VM e clique em OK .
Noções básicas sobre as imagens do Marketplace

O Azure Marketplace inclui muitas imagens que podem ser usadas para criar uma nova VM. Nas etapas
anteriores, uma VM foi criada usando a imagem do Windows Server 2016 Datacenter. Nesta etapa, o módulo do
PowerShell é usado para pesquisar no marketplace por outras imagens do Windows, que também pode ser
usado como base para novas VMs. Este processo consiste em localizar o publicador, a oferta, o SKU e,
opcionalmente, um número de versão para identificar a imagem.
Use o comando Get-AzVMImagePublisher para retornar uma lista de editores de imagem:
Get-AzVMImagePublisher -Location "EastUS"
Use o comando Get-AzVMImageOffer para retornar uma lista de ofertas de imagem. Com este comando, a lista
retornada é filtrada no editor especificado chamado MicrosoftWindowsServer :
Get-AzVMImageOffer `
-PublisherName "MicrosoftWindowsServer"
Os resultados serão algo parecido com este exemplo:

Offer PublisherName Location
----- ------------- --------
Windows-HUB MicrosoftWindowsServer EastUS
WindowsServer MicrosoftWindowsServer EastUS
WindowsServer-HUB MicrosoftWindowsServer EastUS
O comando Get-AzVMImageSku filtrará o nome do editor e da oferta para retornar uma lista com nomes de
imagem.
Get-AzVMImageSku `
-PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer"
Os resultados serão algo parecido com este exemplo:
Skus Offer PublisherName Location

---- ----- ------------- --------
2008-R2-SP1 WindowsServer MicrosoftWindowsServer EastUS
2008-R2-SP1-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2012-Datacenter WindowsServer MicrosoftWindowsServer EastUS
2012-Datacenter-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2012-R2-Datacenter WindowsServer MicrosoftWindowsServer EastUS
2012-R2-Datacenter-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-Server-Core WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-Server-Core-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-with-Containers WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-with-Containers-smalldisk WindowsServer MicrosoftWindowsServer EastUS
2016-Datacenter-with-RDSH WindowsServer MicrosoftWindowsServer EastUS
2016-Nano-Server WindowsServer MicrosoftWindowsServer EastUS
Essas informações podem ser usadas para implantar uma VM com uma imagem específica. Este exemplo
implanta uma VM usando a versão mais recente de um Windows Server 2016 com imagem de contêineres.
New-AzVm `
-Name "myVM2" `
-PublicIpAddressName "myPublicIpAddress2" `
-ImageName "MicrosoftWindowsServer:WindowsServer:2016-Datacenter-with-Containers:latest" `
-Credential $cred `
-AsJob
O parâmetro -AsJob cria a VM como uma tarefa em segundo plano, para que os prompts do PowerShell sejam
exibidos de volta para você. Você pode exibir os detalhes de trabalhos em segundo plano com o cmdelt
Get-Job .
Entender os tamanhos de VM
O tamanho da VM determina a quantidade de recursos de computação, como memória, CPU e GPU que estão
disponíveis para a VM. As máquinas virtuais devem ser criadas usando um tamanho de VM adequado para a
carga de trabalho. Se uma carga de trabalho aumentar, uma máquina virtual existente também poderá ser
redimensionada.
Tamanhos de VM
A tabela a seguir categoriza tamanhos em casos de uso.
TYPE TA M A N H O S C O M UN S DESC RIÇ Ã O
Propósito geral B, Dsv3, Dv3, DSv2, Dv2, Av2, DC CPU/memória equilibrados. Ideal para
desenvolvimento/teste e para
aplicativos de pequeno a médio porte
e soluções de dados.
Computação otimizada Fsv2 Relação de CPU/memória alta. Boa

para aplicativos de tráfego médio,
dispositivos de rede e processos em
lote.
Memória otimizada Esv3, Ev3, M, DSv2, Dv2 Relação de memória/núcleo alta. Ótima
para banco de dados relacionais,
caches médios a grandes e análises na
memória.
Armazenamento otimizado Lsv2, Ls Alta taxa de transferência de disco e de

E/S. Ideal para Big Data, SQL e bancos
de dados NoSQL.
GPU NV, NVv2, NC, NCv2, NCv3, ND VMs especializadas, destinadas para
renderização gráfica e edição de vídeo
pesadas.
Alto desempenho H Nossas VMs de CPU mais potentes

com adaptadores de rede de alto
rendimento (RDMA) opcionais.
Encontrar tamanhos de VM disponíveis

Para ver uma lista de tamanhos de VM disponíveis em uma região específica, use o comando Get-AzVMSize.
Get-AzVMSize -Location "EastUS"
Após a implantação de uma VM, ela pode ser redimensionada para aumentar ou diminuir a alocação de
recursos.
Antes de redimensionar uma VM, verifique se o tamanho desejado está disponível no cluster da VM atual. O
comando Get-AzVMSize retorna uma lista de tamanhos.
Get-AzVMSize -ResourceGroupName "myResourceGroupVM" -VMName "myVM"
Se o tamanho estiver disponível, a VM poderá ser redimensionada com base em um estado ligado. No entanto,
ela será reinicializada durante a operação.
$vm = Get-AzVM `
-VMName "myVM"
$vm.HardwareProfile.VmSize = "Standard_DS3_v2"
Update-AzVM `
-VM $vm `
-ResourceGroupName "myResourceGroupVM"
Se o tamanho desejado não estiver disponível no cluster atual, a VM precisará ser desalocada antes que a
operação de redimensionamento ocorra. Desalocar uma VM removerá todos os dados no disco temporário e
alterará o endereço IP público, a menos que um endereço IP estático esteja sendo usado.
Stop-AzVM `
-Name "myVM" -Force
$vm = Get-AzVM `
-VMName "myVM"
$vm.HardwareProfile.VmSize = "Standard_E2s_v3"
Update-AzVM -VM $vm `
-ResourceGroupName "myResourceGroupVM"
Start-AzVM `
-Name $vm.name
Estados de energia da VM
Uma VM do Azure pode ter um dentre vários estados de energia.
ESTA DO DE EN ERGIA DESC RIÇ Ã O
Iniciando A máquina virtual está sendo iniciada.
Executando A máquina virtual está em execução.
Parando A máquina virtual está sendo interrompida.
Parado A máquina virtual está parada. Máquinas virtuais no estado

interrompido ainda incorrerá em encargos de computação.
Desalocando A VM está sendo desalocada.
Desalocada Indica que a VM é removida do hipervisor, mas ainda está

disponível no plano de controle. As máquinas virtuais no
estado Deallocated não incorrem em encargos de
computação.
- O estado de energia da VM é desconhecido.
Para obter o estado de uma VM específica, use o comando Get-AzVM. Especifique nomes válidos para uma VM e
um grupo de recursos.
Get-AzVM `
-Name "myVM" `
-Status | Select @{n="Status"; e={$_.Statuses[1].Code}}
A saída será parecida com este exemplo:
Status
------
PowerState/running
Durante o ciclo de vida de uma VM, é possível que você queira executar tarefas de gerenciamento, como
inicialização, interrupção ou exclusão de uma VM. Além disso, é possível que você queira criar scripts para
automatizar tarefas repetitivas ou complexas. Usando o Azure PowerShell, muitas tarefas comuns de
gerenciamento podem ser executadas em linha de comando ou em scripts.
Parar uma VM
Interrompa e desaloque uma VM com Stop-AzVM:
Stop-AzVM `
-Name "myVM" -Force
Se você quiser manter a VM em um estado de provisionamento, use o parâmetro -StayProvisioned.

Iniciar uma VM
Start-AzVM `
-Name "myVM"
Excluir grupo de recursos

Tudo dentro de um grupo de recursos é excluído quando você o exclui.
Remove-AzResourceGroup `
-Name "myResourceGroupVM" `
-Force
Próximas etapas
Neste tutorial, você aprendeu sobre a criação e o gerenciamento básico de VM e como:
Avança para o próximo tutorial para saber mais sobre os discos de VM.
Criar e gerenciar discos de VM
Tutorial – Gerenciar discos do Azure com o Azure
PowerShell
Máquinas virtuais do Azure usam discos para armazenar o sistema operacional de VMs, aplicativos e dados. Ao
criar uma VM, é importante escolher um tamanho de disco e a configuração apropriada para a carga de
trabalho esperada. Este tutorial aborda a implantação e gerenciamento de discos de VM. Você saberá mais
sobre:
Discos de dados
Desempenho do disco

Discos padrão do Azure

Quando uma máquina virtual do Azure é criada, dois discos são automaticamente anexados à máquina virtual.
Disco do sistema operacional - Os discos do sistema operacional podem ser dimensionados para até 4
terabytes e hospedar o sistema operacional das máquinas virtuais. Se você criar uma VM (máquina virtual) com
base em uma imagem do Azure Marketplace, normalmente 127 GB (mas algumas imagens têm tamanhos de
disco de sistema operacional menores). O disco do SO é atribuído à letra da unidade C: por padrão. A
configuração de cache do disco do SO é otimizada para desempenho do SO. O disco do SO não deve hospedar
aplicativos nem dados. Para aplicativos e dados, use um disco de dados, que é detalhado posteriormente neste
artigo.
Disco temporário - Discos temporários utilizam uma unidade de estado sólido localizada no mesmo host do
Azure que a máquina virtual. Os discos temporários são altamente eficazes e podem ser usados para operações
como o processamento de dados temporário. No entanto, se a VM for movida para um novo host, todos os
dados armazenados em um disco temporário serão removidos. O tamanho do disco temporário é determinado
pelo tamanho da máquina virtual. Os discos temporários são atribuídos à letra da unidade D: por padrão.
Discos de dados do Azure

Os discos de dados extras podem ser adicionados para instalação de aplicativos e armazenamento de dados. Os
discos de dados devem ser usados em qualquer situação onde o armazenamento de dados durável responsivo
é necessário. O tamanho da máquina virtual determina quantos discos de dados podem ser anexados a uma
VM.
Tipos de disco da máquina virtual
O Azure fornece dois tipos de discos.
Discos Standard - apoiados por HDDs e oferecem armazenamento econômico e eficaz. Os discos Standard são
ideais para uma carga de trabalho econômica de desenvolvimento e teste.
Discos Premium – apoiados por disco de baixa latência e alto desempenho baseado em SSD. Perfeitos para
VMs que executam carga de trabalho de produção. Os tamanhos de VM com um S no nome do tamanho
normalmente são compatíveis com o Armazenamento Premium. Por exemplo, as VMs das séries DS, DSv2, GS e
FS são compatíveis com o Armazenamento Premium. Ao escolher o tamanho de um disco, o valor é
arredondado para o tipo seguinte. Por exemplo, se o tamanho do disco for maior que 64 GB, mas menor que
128 GB, o tipo de disco será P10.
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Tam 4 8 16 32 64 128 256 512 1.0 2.0 4.0 8.1 16. 32.
anh 24 48 96 92 384 767
o
do
disc
o
em
GiB
IOP 120 120 120 120 240 500 1.1 2.3 5.0 7.5 7.5 16. 18. 20,
S 00 00 00 00 00 000 000 000
pro
visi
ona
da
por
disc
o
Taxa 25 25 25 25 50 100 125 150 200 250 250 500 750 900
sfer
ênci
a
pro
visi
ona
da
por
disc
o
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Má 3.5 3.5 3.5 3.5 3.5 3.5 3.5 3.5

xim 00 00 00 00 00 00 00 00
o
de
IOP
S
de
inte
rmit
ênci
a
por
disc
o
Taxa 170 170 170 170 170 170 170 170

sfer
ênci
a
de
inte
rmit
ênci
a
máx
ima
por
disc
o
Dur 30 30 30 30 30 30 30 30
o
máx
ima
da
inte
rmit
ênci
a
par
a
rese
rva
Embora a tabela acima identifique a IOPS máxima por disco, um nível mais alto de desempenho pode ser obtido
com a distribuição de vários discos de dados. Por exemplo, 64 discos de dados podem ser anexados à VM
Standard_GS5. Se cada um desses discos for dimensionado como um P30, será possível chegar a um máximo
de 80.000 IOPS. Para obter informações detalhadas sobre o máximo de IOPS por VM, veja Tipos e tamanhos de
VM.
Criar e anexar discos

Para concluir o exemplo neste tutorial, você deverá ter uma máquina virtual. Se necessário, crie uma máquina
virtual com os seguintes comandos.
Defina o nome de usuário e a senha necessários para a conta de administrador na máquina virtual com Get-
Credential:
Crie a máquina virtual com New-AzVM. Você será solicitado a inserir um nome de usuário e senha para a conta
de administradores para a VM.
New-AzVm `
-ResourceGroupName "myResourceGroupDisk" `
-Name "myVM" `
-PublicIpAddressName "myPublicIpAddress"
Crie a configuração inicial com New-AzDiskConfig. O exemplo a seguir configura um disco com tamanho de
128 gigabytes.
$diskConfig = New-AzDiskConfig `
-CreateOption Empty `
-DiskSizeGB 128
Crie o disco de dados com o comando New-AzDisk.
$dataDisk = New-AzDisk `
-ResourceGroupName "myResourceGroupDisk" `
-DiskName "myDataDisk" `
-Disk $diskConfig
Obtenha a máquina virtual à qual deseja adicionar o disco de dados com o comando Get-AzVM.
$vm = Get-AzVM -ResourceGroupName "myResourceGroupDisk" -Name "myVM"
Adicione o disco de dados à configuração da máquina virtual com o comando Add-AzVMDataDisk.

$vm = Add-AzVMDataDisk `
-VM $vm `
-Name "myDataDisk" `
-CreateOption Attach `
-ManagedDiskId $dataDisk.Id `
-Lun 1
Atualize a máquina virtual com o comando Update-AzVM.
Update-AzVM -ResourceGroupName "myResourceGroupDisk" -VM $vm
Preparar discos de dados

Depois que um disco é anexado à máquina virtual, o sistema operacional precisa ser configurado para usar o
disco. O exemplo a seguir mostra como configurar manualmente o primeiro disco adicionado à VM. Esse
processo também pode ser automatizado usando a extensão de script personalizado.
Configuração manual
Crie uma conexão RDP com a máquina virtual. Abra o PowerShell e execute este script.
Get-Disk | Where partitionstyle -eq 'raw' |

Initialize-Disk -PartitionStyle MBR -PassThru |
New-Partition -AssignDriveLetter -UseMaximumSize |
Format-Volume -FileSystem NTFS -NewFileSystemLabel "myDataDisk" -Confirm:$false
Verificar o disco de dados

Para verificar se o disco de dados está anexado, exiba StorageProfile para o DataDisks anexado.
$vm.StorageProfile.DataDisks
A saída deve ser semelhante ao exemplo a seguir:
Name : myDataDisk
DiskSizeGB : 128
Lun : 1
Caching : None
CreateOption : Attach
SourceImage :
VirtualHardDisk :
Próximas etapas
Neste tutorial, você aprendeu sobre tópicos de discos da VM como:
Discos de dados
Desempenho do disco
Vá para o próximo tutorial para saber como automatizar a configuração da máquina virtual.
Automatizar a configuração da VM
Tutorial – Implantar aplicativos em uma máquina
virtual do Windows no Azure com a Extensão de
Script Personalizado
Para configurar VMs (máquinas virtuais) de maneira rápida e consistente, é possível usar a Extensão de script
personalizada para Windows. Neste tutorial, você aprenderá a:
Usar a Extensão de Script Personalizado para instalar o IIS
Criar uma VM que usa a Extensão de Script Personalizado
Exibir um site do IIS em execução depois que a extensão é aplicada

Visão geral da extensão de script personalizado

A extensão de script personalizado baixa e executa scripts em VMs do Azure. Essa extensão é útil para a
configuração de implantação de postagem, instalação de software ou qualquer outra configuração/tarefa de
gerenciamento. Os scripts podem ser baixados do armazenamento do Azure ou do GitHub, ou fornecidos ao
Portal do Azure no tempo de execução da extensão.
A extensão de script personalizado se integra com modelos do Azure Resource Manager e também pode ser
executada usando a CLI do Azure, o PowerShell, o portal do Azure ou a API REST da máquina virtual do Azure.
Usar a Extensão de script personalizado com VMs do Linux e Windows.

Defina o nome de usuário e a senha do administrador para a VM com Get-Credential:
Agora você pode criar a VM com New-AzVM. O exemplo a seguir cria uma VM chamada myVM na localização
EastUs. Se ainda não existirem, o grupo de recursos myResourceGroupAutomate e recursos de rede de suporte
são criados. Para permitir o tráfego da web, o cmdlet também abre a porta 80.
New-AzVm `
-ResourceGroupName "myResourceGroupAutomate" `
-Name "myVM" `
-OpenPorts 80 `
-Credential $cred
Demora alguns minutos para que os recursos e a VM sejam criados.
Automatizar a instalação do IIS

Use Set-AzVMExtension para instalar a extensão de script personalizado. A extensão executa
powershell Add-WindowsFeature Web-Server para instalar o servidor Web do IIS e, em seguida, atualiza a página
Default.htm para mostrar o nome do host da VM:
Set-AzVMExtension -ResourceGroupName "myResourceGroupAutomate" `

-ExtensionName "IIS" `
-VMName "myVM" `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-TypeHandlerVersion 1.8 `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content -
Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}'
Testar o site
Obtenha o endereço IP público do balanceador de carga com Get-AzPublicIPAddress. O exemplo a seguir obtém
o endereço IP para myPublicIPAddress criado anteriormente:
Get-AzPublicIPAddress `
-ResourceGroupName "myResourceGroupAutomate" `
-Name "myPublicIPAddress" | select IpAddress
Você pode inserir o endereço IP público em um navegador da Web. O site é exibido, incluindo o nome do host
da VM para a qual o balanceador de carga distribui o tráfego como no exemplo a seguir:
Próximas etapas
Neste tutorial, você automatizou a instalação do IIS em uma VM. Você aprendeu a:
Usar a Extensão de Script Personalizado para instalar o IIS
Criar uma VM que usa a Extensão de Script Personalizado
Exibir um site do IIS em execução depois que a extensão é aplicada
Vá para o próximo tutorial para aprender a gerenciar imagens de VM.
Criar imagens de VM personalizada
Tutorial: Criar imagens de VM do Windows com o
Azure PowerShell
Imagens podem ser usadas para inicializar implantações e garantir a consistência entre várias VMs. Neste
tutorial, você cria uma imagem especializada de uma máquina virtual do Azure usando o PowerShell e a
armazena em uma Galeria de Imagens Compartilhadas. Você aprenderá como:
Antes de começar
As etapas abaixo detalham como transformar uma VM existente em uma imagem personalizada reutilizável que
você pode usar para criar VMs.
Para concluir o exemplo neste tutorial, você deverá ter uma máquina virtual. Se necessário, confira o Início
rápido do PowerShell para criar uma VM a ser usada neste tutorial. Ao trabalhar no tutorial, substitua os nomes
dos recursos se necessário.
Visão geral
O recurso Galeria de Imagens Compartilhadas tem vários tipos de recursos:
imagens.


imagem.


Obter a VM
Você pode ver uma lista das VMss que estão disponíveis em um grupo de recursos usando Get-AzVM. Depois
que souber o nome da VM e em qual grupo de recursos ela está, você poderá usar Get-AzVM novamente para
obter o objeto da VM e armazená-lo em uma variável para uso posterior. Este exemplo obtém uma VM chamada
sourceVM do grupo de recursos "myResourceGroup" e a atribui à variável $sourceVM.
$sourceVM = Get-AzVM `
-Name sourceVM `
-ResourceGroupName myResourceGroup

Crie um grupo de recursos com o comando New-AzResourceGroup.
gerenciados. No seguinte exemplo, um grupo de recursos chamado myGalleryRG é criado na região EastUS :
$resourceGroup = New-AzResourceGroup `
-Name 'myGalleryRG' `
-Location 'EastUS'

Uma galeria de imagens é o principal recurso usado para habilitar o compartilhamento de imagens. Os
caracteres permitidos para o nome da galeria são letras maiúsculas ou minúsculas, dígitos, pontos e pontos
assinatura.
Crie uma galeria de imagens usando New-AzGallery. O exemplo a seguir cria uma galeria chamada myGallery
no grupo de recursos myGalleryRG.
$gallery = New-AzGallery `
-GalleryName 'myGallery' `
-ResourceGroupName $resourceGroup.ResourceGroupName `
-Location $resourceGroup.Location `
-Description 'Shared Image Gallery for my organization'

informações sobre as versões da imagem que são criadas dentro delas. Os nomes das definições de imagem
podem ser compostos por letras maiúsculas ou minúsculas, dígitos, pontos, traços e pontos finais. Para obter
mais informações sobre os valores que pode especificar para uma definição de imagem, confira Definições de
imagem.
Crie a definição de imagem usando New-AzGalleryImageDefinition. Neste exemplo, a imagem da galeria se
chama myGalleryImage e foi criada para uma imagem especializada.
$galleryImage = New-AzGalleryImageDefinition `
-GalleryName $gallery.Name `
-Location $gallery.Location `
-Name 'myImageDefinition' `
-OsState specialized `
-OsType Windows `
-Publisher 'myPublisher' `
-Offer 'myOffer' `
-Sku 'mySKU'

Crie uma versão da imagem com base em uma VM usando New-AzGalleryImageVersion.
Neste exemplo, a versão da imagem é 1.0.0 e ela é replicada para os datacenters Leste dos EUA e Centro-Sul dos
EUA. Ao escolher as regiões de destino da replicação, você precisa incluir a região de origem como um destino
para a replicação.
Para criar uma versão da imagem da VM, use $vm.Id.ToString() para o -Source .
$region1 = @{Name='South Central US';ReplicaCount=1}
$region2 = @{Name='East US';ReplicaCount=2}
$targetRegions = @($region1,$region2)
New-AzGalleryImageVersion `
-GalleryImageDefinitionName $galleryImage.Name`
-GalleryImageVersionName '1.0.0' `
-TargetRegion $targetRegions `
-Source $sourceVM.Id.ToString() `
-PublishingProfileEndOfLifeDate '2020-12-01'
Pode levar algum tempo para replicar a imagem para todas as regiões de destino.

Agora que tem uma imagem especializada, você pode criar uma ou mais VMs. Usando o cmdlet New-AzVM.
Para usar a imagem, use Set-AzVMSourceImage e defina o -Id como a ID da definição de imagem
($galleryImage.ID, nesse caso) para sempre usar a versão mais recente da imagem.
Substitua os nomes dos recursos conforme necessário no exemplo.
# Create some variables for the new VM.

$resourceGroup = "myResourceGroup"
$location = "South Central US"
$vmName = "mySpecializedVM"
# Create a resource group

New-AzResourceGroup -Name $resourceGroup -Location $location
# Create the network resources.

$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name mySubnet -AddressPrefix 192.168.1.0/24
$vnet = New-AzVirtualNetwork -ResourceGroupName $resourceGroup -Location $location `
-Name MYvNET -AddressPrefix 192.168.0.0/16 -Subnet $subnetConfig
$pip = New-AzPublicIpAddress -ResourceGroupName $resourceGroup -Location $location `
-Name "mypublicdns$(Get-Random)" -AllocationMethod Static -IdleTimeoutInMinutes 4
$nsgRuleRDP = New-AzNetworkSecurityRuleConfig -Name myNetworkSecurityGroupRuleRDP -Protocol Tcp `
-Direction Inbound -Priority 1000 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * `
-DestinationPortRange 3389 -Access Allow
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $resourceGroup -Location $location `
-Name myNetworkSecurityGroup -SecurityRules $nsgRuleRDP
$nic = New-AzNetworkInterface -Name $vmName -ResourceGroupName $resourceGroup -Location $location `
-SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id
# Create a virtual machine configuration using $imageVersion.Id to specify the image version.
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize Standard_D1_v2 | `
Set-AzVMSourceImage -Id $galleryImage.Id | `
Add-AzVMNetworkInterface -Id $nic.Id
# Create a virtual machine

New-AzVM -ResourceGroupName $resourceGroup -Location $location -VM $vmConfig
Recomendamos que você compartilhe o acesso no nível da galeria de imagens. Use um endereço de email e o
cmdlet Get-AzADUser para obter a ID do objeto do usuário e, em seguida, use New-AzRoleAssignment para
conceder a ele acesso à galeria. Substitua o email de exemplo, alinne_montes@contoso.com neste exemplo, por
suas informações.
# Get the object ID for the user
$user = Get-AzADUser -StartsWith alinne_montes@contoso.com
# Grant access to the user for our gallery
New-AzRoleAssignment `
-ObjectId $user.Id `
-RoleDefinitionName Reader `
-ResourceName $gallery.Name `
-ResourceType Microsoft.Compute/galleries `
-ResourceGroupName $resourceGroup.ResourceGroupName
Limpar os recursos
grupo de recursos e todos os recursos relacionados:
# Delete the gallery

Remove-AzResourceGroup -Name myGalleryRG
# Delete the VM
Remove-AzResourceGroup -Name myResoureceGroup
Construtor de Imagens do Azure

O Azure também oferece um serviço integrado ao Packer, o Construtor de Imagens de VM do Azure. Basta
descrever suas personalizações em um modelo e ele cuidará da criação da imagem.
Próximas etapas
Neste tutorial, você criou uma imagem de VM especializada. Você aprendeu a:
Avance para o próximo tutorial para aprender como criar máquinas virtuais altamente disponíveis.
Criar VMs altamente disponíveis
altamente disponíveis com o Azure PowerShell
Neste tutorial, você aprenderá a aumentar a disponibilidade e confiabilidade de suas VMs (máquinas virtuais)
usando conjuntos de disponibilidade. Os conjuntos de disponibilidade garantem que as VMs implantadas no
Azure sejam distribuídas entre vários nós de hardware isolados em um cluster.
Verificar o Assistente do Azure
Visão geral do conjunto de disponibilidade

Um conjunto de disponibilidade é uma funcionalidade de agrupamento lógico para isolar recursos de VM uns
dos outros quando são implantados. O Azure garante que as VMs colocadas em um conjunto de disponibilidade
sejam executadas em vários servidores físicos, racks de computação, unidades de armazenamento e
comutadores de rede. Se ocorrer uma falha de hardware ou de software, somente um subconjunto de suas VMs
será afetado e a solução geral permanecerá operacional. Os conjuntos de disponibilidade são essenciais para a
criação de soluções de nuvem confiáveis.
e duas VMs de back-end. Com o Azure, convém definir dois conjuntos de disponibilidade antes de implantar
suas VMs: um para a camada Web e outro para a camada traseira. Quando você cria uma nova VM, especifica o
conjunto de disponibilidade como um parâmetro. O Azure garante que as VMs estejam isoladas entre vários
recursos de hardware físico. Se o hardware físico no qual um dos seus servidores está sendo executado tiver um
problema, você saberá que as outras instâncias dos seus servidores continuarão em execução porque estão em
um hardware diferente.
Use Conjuntos de Disponibilidade quando você deseja implantar soluções confiáveis baseadas em VM no Azure.


O hardware em um local é dividido em vários domínios de atualização e domínios de falha. Um domínios de
atualização é um grupo de VMs e hardware físico subjacente que podem ser reinicializados simultaneamente.
As VMs no mesmo domínio de falha compartilham armazenamentos comuns, bem como um comutador de
rede e fonte de energia comuns.
É possível criar um conjunto de disponibilidade usando New-AzAvailabilitySet. Neste exemplo, o número de
domínios de atualização e de falha é 2 e o conjunto de disponibilidade é chamado myAvailabilitySet.
Crie um grupos de recursos.
-Name myResourceGroupAvailability `
-Location EastUS
Crie um conjunto de disponibilidade gerenciado usando New-AzAvailabilitySet com o parâmetro -sku aligned .
New-AzAvailabilitySet `
-Name "myAvailabilitySet" `
-ResourceGroupName "myResourceGroupAvailability" `
-Sku aligned `
-PlatformFaultDomainCount 2 `
-PlatformUpdateDomainCount 2

hardware. Não é possível adicionar uma VM existente a um conjunto de disponibilidade após sua criação.
Ao criar uma VM com New-AzVM, você usa o parâmetro -AvailabilitySetName para especificar o nome do
conjunto de disponibilidade.
Primeiro, defina o nome de usuário e a senha de um administrador para a VM com Get-Credential:
Agora crie duas VMs com New-AzVM no conjunto de disponibilidade.
for ($i=1; $i -le 2; $i++)

{
New-AzVm `
-Name "myVM$i" `
-PublicIpAddressName "myPublicIpAddress$i" `
-AvailabilitySetName "myAvailabilitySet" `
-Credential $cred
}
Demora alguns minutos para criar e configurar ambas as VMs. Quando tiver terminado, você terá duas
máquinas virtuais distribuídas entre o hardware subjacente.
Se você analisar o conjunto de disponibilidade no portal acessando Grupos de Recursos >
myResourceGroupAvailability > myAvailabilitySet , verá como as VMs estão distribuídas entre os dois
domínios de atualização e de falha.
Quando cria uma VM dentro de um conjunto de disponibilidade, você precisa saber quais tamanhos de VM
estão disponíveis no hardware. Use o comando Get-AzVMSize para obter todos os tamanhos de máquinas
virtuais disponíveis que você pode implantar no conjunto de disponibilidade.
Get-AzVMSize `
-AvailabilitySetName "myAvailabilitySet"

Também é possível usar o Assistente do Azure para saber mais sobre como melhorar a disponibilidade das suas
VMs. O Assistente do Azure analisa a telemetria de uso e de configuração e, depois, recomenda soluções que
podem ajudar você a melhorar a economia, o desempenho, a disponibilidade e a segurança de seus recursos do
Azure.
Entre no portal do Azure, selecione Todos os ser viços e digite Assistente . O painel do Assistente mostra
recomendações personalizadas para a assinatura selecionada. Para saber mais, veja Introdução ao Assistente do
Azure.
Próximas etapas
Criar um conjunto de dimensionamento da VM
Tutorial: Criar um conjunto de dimensionamento de
máquinas virtuais e implantar um aplicativo
altamente disponível no Windows com o Azure
PowerShell

máquinas virtuais idênticas de dimensionamento automático. Você pode dimensionar manualmente o número
de VMs no conjunto de dimensionamento. Você também pode definir regras para o dimensionamento
automático com base no uso de recursos, como CPU, demanda de memória ou tráfego de rede. Neste tutorial,
você implantará um conjunto de dimensionamento de máquinas virtuais no Azure e saberá como:
Usar a Extensão de Script Personalizado para definir um site do IIS para dimensionar
Criar um balanceador de carga para o conjunto de dimensionamento

Visão geral do conjunto de escala

máquinas virtuais idênticas de dimensionamento automático. As VMs em um conjunto de dimensionamento
são distribuídas entre domínios de falha lógica e domínios de atualização em um ou mais grupos de
posicionamento. Os grupos de posicionamento são grupos de VMs configuradas de maneira semelhante, da
mesma forma que os conjuntos de disponibilidade.
VMs são criadas conforme necessário em um conjunto de escala. Você define regras de dimensionamento
automático para controlar como e quando as VMs são adicionadas ou removidas do conjunto de
dimensionamento. Essas regras podem ser disparados com base em métricas como carga de CPU, utilização de
memória ou tráfego de rede.
Escala define suporte até 1.000 VMs quando você usar uma imagem da plataforma Windows Azure. Para cargas
de trabalho com requisitos significativos de personalização de VM ou instalação, você pode querer criar uma
imagem de VM personalizada. Você pode criar até 600 VMs em um conjunto de dimensionamento usando uma
imagem personalizada.

Crie um conjunto de dimensionamento de máquinas virtuais com New-AzVmss. O exemplo a seguir cria um
conjunto de dimensionamento chamado myScaleSet que usa a imagem da plataforma do Datacenter do
Windows Server 2016. São criados automaticamente os recursos de rede do Azure para rede virtual, endereço
IP público e balanceador de carga. Quando solicitado, você poderá fornecer suas próprias credenciais
administrativas para as instâncias de VM no conjunto de dimensionamento:
New-AzVmss `
-ResourceGroupName "myResourceGroupScaleSet" `
-VMScaleSetName "myScaleSet" `
-PublicIpAddressName "myPublicIPAddress" `
-LoadBalancerName "myLoadBalancer" `
-UpgradePolicyMode "Automatic"
Leva alguns minutos para criar e configurar todos os recursos e as VMs do conjunto de dimensionamento.
Implantar um aplicativo de exemplo

Para testar seu conjunto de dimensionamento, instale um aplicativo Web básico. A Extensão de Script
Personalizado do Azure para baixar e executar um script que instala o IIS nas instâncias de VM. Essa extensão é
útil para a configuração de implantação de postagem, instalação de software ou qualquer outra
configuração/tarefa de gerenciamento. Para obter mais informações, consulte a Visão geral da Extensão de
Script Personalizado.
Usar a Extensão de Script Personalizado para instalar um servidor Web IIS básico. Aplique a Extensão do Script
Personalizado que instala o IIS da seguinte maneira:
# Define the script for your Custom Script Extension to run

$publicSettings = @{
"fileUris" = (,"https://raw.githubusercontent.com/Azure-Samples/compute-automation-
configurations/master/automate-iis.ps1");
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File automate-iis.ps1"
}
# Get information about the scale set

$vmss = Get-AzVmss `
-VMScaleSetName "myScaleSet"
# Use Custom Script Extension to install IIS and configure basic website
Add-AzVmssExtension -VirtualMachineScaleSet $vmss `
-Name "customScript" `
-Publisher "Microsoft.Compute" `
-Type "CustomScriptExtension" `
-Setting $publicSettings
# Update the scale set and apply the Custom Script Extension to the VM instances
Update-AzVmss `
-Name "myScaleSet" `
-VirtualMachineScaleSet $vmss
Permitir o tráfego para o aplicativo

Para permitir o acesso ao aplicativo Web básico, crie um grupo de segurança de rede com New-
AzNetworkSecurityRuleConfig e New-AzNetworkSecurityGroup. Para saber mais, confira Rede para os
conjuntos de dimensionamento de máquinas virtuais do Azure.
# Get information about the scale set

$vmss = Get-AzVmss `
#Create a rule to allow traffic over port 80

$nsgFrontendRule = New-AzNetworkSecurityRuleConfig `
-Name myFrontendNSGRule `
-Protocol Tcp `
-Direction Inbound `
-Priority 200 `
-Access Allow
#Create a network security group and associate it with the rule

$nsgFrontend = New-AzNetworkSecurityGroup `
-Location EastUS `
-Name myFrontendNSG `
-SecurityRules $nsgFrontendRule
$vnet = Get-AzVirtualNetwork `
-Name myVnet
$frontendSubnet = $vnet.Subnets[0]
$frontendSubnetConfig = Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $vnet `
-Name mySubnet `
-AddressPrefix $frontendSubnet.AddressPrefix `
-NetworkSecurityGroup $nsgFrontend
Set-AzVirtualNetwork -VirtualNetwork $vnet
# Update the scale set and apply the Custom Script Extension to the VM instances
Update-AzVmss `
-VirtualMachineScaleSet $vmss
Testar seu conjunto de dimensionamento

Para ver o conjunto de dimensionamento em ação, obtenha o endereço IP público do balanceador de carga com
Get-AzPublicIPAddress. O exemplo a seguir exibe o endereço IP de myPublicIP, criado como parte do conjunto
de dimensionamento:
-Name "myPublicIPAddress" | select IpAddress
Insira o endereço IP público em um navegador da Web. O aplicativo Web é exibido, incluindo o nome do host da
VM para a qual o balanceador de carga distribui o tráfego:
Para ver a escala definida em ação, você pode forçar atualização seu navegador da web para ver o balanceador
de carga distribuir tráfego entre todas as VMs que executam seu aplicativo.
Durante todo o ciclo de vida do conjunto de dimensionamento, você poderá precisar executar uma ou mais
tarefas de gerenciamento. Além disso, talvez você deseje criar scripts que automatizam várias tarefas do ciclo de
vida. O Azure PowerShell fornece uma maneira rápida de realizar essas tarefas. Estas são algumas tarefas
comuns.
Exibição de VMs em um conjunto de escala
Para exibir uma lista de instâncias de VM em um conjunto de dimensionamento, use Get-AzVmssVM da
seguinte forma:
Get-AzVmssVM `
A saída de exemplo abaixo mostra duas instâncias de VM no conjunto de dimensionamento:
ResourceGroupName Name Location Sku InstanceID ProvisioningState

----------------- ---- -------- --- ---------- -----------------
MYRESOURCEGROUPSCALESET myScaleSet_0 eastus Standard_DS1_v2 0 Succeeded
MYRESOURCEGROUPSCALESET myScaleSet_1 eastus Standard_DS1_v2 1 Succeeded
Para exibir informações adicionais sobre uma instância específica de VM, adicione o parâmetro -InstanceId a
Get-AzVmssVM. O exemplo abaixo exibe informações sobre a instância de VM 1:
Get-AzVmssVM `
-VMScaleSetName "myScaleSet" `
-InstanceId "1"
Aumentar ou diminuir as instâncias de VM

Para ver o número de instâncias que você tem atualmente em um conjunto de dimensionamento, use Get-
AzVmss e consulte sku.capacity:
Get-AzVmss -ResourceGroupName "myResourceGroupScaleSet" `

-VMScaleSetName "myScaleSet" | `
Select -ExpandProperty Sku
Manualmente, é possível aumentar ou diminuir o número de máquinas virtuais no conjunto de
dimensionamento com Update-AzVmss. O seguinte exemplo aumenta o número de VMs no conjunto de
dimensionamento para 3:
# Get current scale set

$scaleset = Get-AzVmss `
# Set and update the capacity of your scale set

$scaleset.sku.capacity = 3
Update-AzVmss -ResourceGroupName "myResourceGroupScaleSet" `
-VirtualMachineScaleSet $scaleset
A atualização para o número especificado de instâncias no conjunto de dimensionamento leva alguns minutos.
Configurar regras de dimensionamento automático
Em vez de dimensionar manualmente o número de instâncias no conjunto de dimensionamento, defina regras
de dimensionamento automático. Essas regras monitoram as instâncias no conjunto de dimensionamento e
respondem adequadamente com base nas métricas e nos limites que você define. O exemplo a seguir escala
horizontalmente o número de instâncias em um quando a carga média da CPU é maior que 60% por um
período superior a 5 minutos. Se, em seguida, a carga média da CPU cair abaixo de 30% em um período
superior a 5 minutos, as instâncias serão reduzidas horizontalmente em uma instância:
# Define your scale set information
$mySubscriptionId = (Get-AzSubscription)[0].Id
$myResourceGroup = "myResourceGroupScaleSet"
$myScaleSet = "myScaleSet"
$myLocation = "East US"
$myScaleSetId = (Get-AzVmss -ResourceGroupName $myResourceGroup -VMScaleSetName $myScaleSet).Id
# Create a scale up rule to increase the number instances after 60% average CPU usage exceeded for a 5-
minute period
$myRuleScaleUp = New-AzAutoscaleRule `
-MetricName "Percentage CPU" `
-MetricResourceId $myScaleSetId `
-Operator GreaterThan `
-MetricStatistic Average `
-Threshold 60 `
-TimeGrain 00:01:00 `
-TimeWindow 00:05:00 `
-ScaleActionCooldown 00:05:00 `
-ScaleActionDirection Increase `
-ScaleActionValue 1
# Create a scale down rule to decrease the number of instances after 30% average CPU usage over a 5-minute
period
$myRuleScaleDown = New-AzAutoscaleRule `
-MetricName "Percentage CPU" `
-MetricResourceId $myScaleSetId `
-Operator LessThan `
-MetricStatistic Average `
-Threshold 30 `
-TimeGrain 00:01:00 `
-TimeWindow 00:05:00 `
-ScaleActionCooldown 00:05:00 `
-ScaleActionDirection Decrease `
-ScaleActionValue 1
# Create a scale profile with your scale up and scale down rules
$myScaleProfile = New-AzAutoscaleProfile `
-DefaultCapacity 2 `
-MaximumCapacity 10 `
-MinimumCapacity 2 `
-Rule $myRuleScaleUp,$myRuleScaleDown `
-Name "autoprofile"
# Apply the autoscale rules

Add-AzAutoscaleSetting `
-Location $myLocation `
-Name "autosetting" `
-ResourceGroup $myResourceGroup `
-TargetResourceId $myScaleSetId `
-AutoscaleProfile $myScaleProfile
Para obter mais informações de design sobre o uso do dimensionamento automático, consulte Melhores
práticas de dimensionamento automático.
Próximas etapas
Neste tutorial, você criou um conjunto de dimensionamento de máquinas virtuais. Você aprendeu a:
Usar a Extensão de Script Personalizado para definir um site do IIS para dimensionar
Criar um balanceador de carga para o conjunto de dimensionamento
Avança para o próximo tutorial para saber mais sobre conceitos de máquinas virtuais de balanceamento de
carga.
Balancear carga de máquinas virtuais
Tutorial: Balancear a carga de máquinas virtuais do
Windows no Azure para criar um aplicativo
altamente disponível com o Azure PowerShell
O balanceamento de carga fornece um nível mais alto de disponibilidade, distribuindo as solicitações de entrada
em várias máquinas virtuais. Neste tutorial, você aprenderá sobre os diferentes componentes do balanceador
de carga do Azure que distribuem o tráfego e fornecem alta disponibilidade. Você aprenderá como:
Usar a Extensão de Script Personalizado para criar um site do IIS básico
Visão geral do Balanceador de Carga do Azure

Um Azure Load Balancer é um balanceador de carga de Camada 4 (TCP, UDP) que fornece alta disponibilidade
distribuindo o tráfego de entrada entre VMs íntegros. Uma investigação de integridade do balanceador de carga
monitora uma determinada porta em cada VM e distribui o tráfego somente para uma VM operacional.
Você define uma configuração de IP de front-end que contém um ou mais endereços IP públicos. Essa
configuração de IP de front-end permite que seu balanceador de carga e os aplicativos estejam acessíveis pela
Internet.
As máquinas virtuais conectam-se a um balanceador de carga usando a placa de interface de rede virtual (NIC).
Para distribuir o tráfego para as máquinas virtuais, um pool de endereços de back-end contém os endereços IP
das NICs virtuais conectadas ao balanceador de carga.
Para controlar o fluxo do tráfego, você precisará definir regras do balanceador de carga para portas específicas e
protocolos que mapeiam para suas VMs.

Criar o balanceador de carga do Azure

Esta seção fornece detalhes sobre como criar e configurar cada componente do balanceador de carga. Antes de
criar o balanceador de carga, crie um grupo de recursos com New-AzResourceGroup. O seguinte exemplo cria
um grupo de recursos chamado myResourceGroupLoadBalancer no local EastUS :
-ResourceGroupName "myResourceGroupLoadBalancer" `
-Location "EastUS"

Para acessar seu aplicativo na Internet, você precisará de um endereço IP público para o balanceador de carga.
Crie um endereço IP público com New-AzPublicIpAddress. O exemplo a seguir cria um endereço IP público
chamado myPublicIP no grupo de recursos myResourceGroupLoadBalancer:
$publicIP = New-AzPublicIpAddress `
-AllocationMethod "Static" `
-Name "myPublicIP"
Criar um balanceador de carga

Crie um pool de IPs de front-end com New-AzLoadBalancerFrontendIpConfig. O seguinte exemplo cria um pool
de IPs de front-end chamado myFrontEndPool e anexa o endereço myPublicIP:
$frontendIP = New-AzLoadBalancerFrontendIpConfig `
-Name "myFrontEndPool" `
-PublicIpAddress $publicIP
Crie um pool de endereços de back-end com New-AzLoadBalancerBackendAddressPoolConfig. As VMs são

anexadas a este pool de back-end nas etapas restantes. O seguinte exemplo cria um pool de endereços de back-
end chamado myBackEndPool:
$backendPool = New-AzLoadBalancerBackendAddressPoolConfig `
-Name "myBackEndPool"
Agora crie o balanceador de carga com New-AzLoadBalancer. O exemplo a seguir cria um balanceador de carga
denominado myLoadBalancer usando os pools de IP de front-end e back-end criados nas etapas anteriores:
$lb = New-AzLoadBalancer `
-Name "myLoadBalancer" `
-FrontendIpConfiguration $frontendIP `
-BackendAddressPool $backendPool
Criar uma investigação de integridade

Para permitir que o balanceador de carga monitore o status de seu aplicativo, use uma investigação de
integridade. A investigação de integridade adiciona ou remove dinamicamente VMs da rotação do balanceador
de carga com base na resposta às verificações de integridade. Por padrão, uma VM é removida da distribuição
do balanceador de carga após duas falhas consecutivas em intervalos de 15 segundos. Crie uma investigação de
integridade com base em um protocolo ou página de verificação de integridade específica ao seu aplicativo.
O exemplo a seguir cria uma investigação de TCP. Você também pode criar investigações de HTTP
personalizadas para obter verificações de integridade mais refinadas. Ao usar uma investigação de HTTP
personalizada, você deverá criar a página de verificação de integridade, como healthcheck.aspx. A investigação
deve retornar a reposta HTTP 200 OK para o balanceador de carga a fim de manter o host em rotação.
Para criar uma investigação de integridade TCP, use Add-AzLoadBalancerProbeConfig. O exemplo a seguir cria
uma investigação de integridade chamada myHealthProbe que monitora cada VM na porta TCP**80:
Add-AzLoadBalancerProbeConfig `
-Name "myHealthProbe" `
-LoadBalancer $lb `
-Protocol tcp `
-Port 80 `
-IntervalInSeconds 15 `
-ProbeCount 2
Para aplicar a investigação de integridade, atualize o balanceador de carga com Set-AzLoadBalancer:
Set-AzLoadBalancer -LoadBalancer $lb
Criar uma regra de balanceador de carga

Uma regra de balanceador de carga é usada para definir como o tráfego é distribuído para as VMs. Definir a
configuração de IP de front-end para o tráfego de entrada e o pool de IP de back-end para receber o tráfego,
junto com as portas de origem e de destino necessárias. Para ter certeza de que apenas VMs íntegras recebem
tráfego, defina também a investigação de integridade a ser usada.
Crie uma regra de balanceador de carga com Add-AzLoadBalancerRuleConfig. O seguinte exemplo cria uma
regra de balanceador de carga chamada myLoadBalancerRule e faz o balanceamento de carga do tráfego na
porta TCP**80:
$probe = Get-AzLoadBalancerProbeConfig -LoadBalancer $lb -Name "myHealthProbe"
Add-AzLoadBalancerRuleConfig `
-Name "myLoadBalancerRule" `
-LoadBalancer $lb `
-FrontendIpConfiguration $lb.FrontendIpConfigurations[0] `
-BackendAddressPool $lb.BackendAddressPools[0] `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80 `
-Probe $probe
Atualize o balanceador de carga com Set-AzLoadBalancer:
Set-AzLoadBalancer -LoadBalancer $lb
Configurar rede virtual

Antes de implantar algumas VMs e poder testar o balanceador, crie os recursos de suporte de rede virtual. Para
saber mais sobre redes virtuais, veja o tutorial Gerenciar Redes Virtuais do Azure.
Criar recursos da rede
Crie uma rede virtual com New-AzVirtualNetwork. O exemplo a seguir cria uma rede virtual chamada myVnet
com uma sub-rede chamada mySubnet:
# Create subnet config
-Name "mySubnet" `
# Create the virtual network

-Name "myVnet" `
As NICs virtuais são criadas com New-AzNetworkInterface. O exemplo a seguir cria três NICs virtuais. (Uma NIC
virtual para cada VM criada para seu aplicativo nas etapas a seguir). Você pode criar VMs e NICs virtuais
adicionais a qualquer momento e adicioná-las ao balanceador de carga:
for ($i=1; $i -le 3; $i++)

{
New-AzNetworkInterface `
-Name myVM$i `
-Subnet $vnet.Subnets[0] `
-LoadBalancerBackendAddressPool $lb.BackendAddressPools[0]
}

Para melhorar a alta disponibilidade do seu aplicativo, coloque suas VMs em um conjunto de disponibilidade.
Crie um conjunto de disponibilidade com New-AzAvailabilitySet. O exemplo a seguir cria um conjunto de
disponibilidade chamado myAvailabilitySet:
$availabilitySet = New-AzAvailabilitySet `
-Sku aligned `
Defina o nome de usuário e a senha de um administrador para as VMs com Get-Credential:
Agora, é possível criar as VMs com New-AzVM. O exemplo a seguir cria três VMs e os componentes de rede
virtual exigidos, se eles ainda não existirem:
for ($i=1; $i -le 3; $i++)
{
New-AzVm `
-Name "myVM$i" `
-OpenPorts 80 `
-Credential $cred `
-AsJob
}
O parâmetro -AsJob cria a VM como uma tarefa em segundo plano, para que os prompts do PowerShell sejam
exibidos de volta para você. Você pode exibir os detalhes de trabalhos em segundo plano com o cmdelt Job .
Demora alguns minutos para criar e configurar todas as três VMs.
Instalar o IIS com a extensão de script personalizado
Em um tutorial anterior sobre Como personalizar uma máquina virtual do Windows, você aprendeu a
automatizar a personalização de VM com a Extensão do Script Personalizado para Windows. Você pode usar a
mesma abordagem para instalar e configurar o IIS em suas VMs.
Use Set-AzVMExtension para instalar a extensão de script personalizado. A extensão executa
powershell Add-WindowsFeature Web-Server para instalar o servidor Web do IIS e, em seguida, atualiza a página
Default.htm para mostrar o nome do host da VM:
for ($i=1; $i -le 3; $i++)

{
Set-AzVMExtension `
-VMName myVM$i `
-Publisher Microsoft.Compute `
-ExtensionType CustomScriptExtension `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server; powershell Add-Content -
Path \"C:\\inetpub\\wwwroot\\Default.htm\" -Value $($env:computername)"}' `
-Location EastUS
}
Testar o balanceador de carga

Obtenha o endereço IP público do balanceador de carga com Get-AzPublicIPAddress. O exemplo a seguir obtém
o endereço IP para myPublicIP criado anteriormente:
-Name "myPublicIP" | select IpAddress
Você pode inserir o endereço IP público em um navegador da Web. O site é exibido, incluindo o nome do host
da VM para a qual o balanceador de carga distribui o tráfego como no exemplo a seguir:
Para ver o balanceador de carga distribuir tráfego entre todas as três VMs que executam seu aplicativo, você
poderá forçar a atualização de seu navegador da Web.
Adicionar e remover as VMs

Talvez seja necessário fazer a manutenção nas VMs que executam seu aplicativo, como a instalação de
atualizações do sistema operacional. Para lidar com o aumento de tráfego em seu aplicativo, talvez seja
necessário adicionar outras VMs. Esta seção mostra como remover ou adicionar uma VM do balanceador de
carga.
Remover uma VM do balanceador de carga
Obtenha a placa de adaptador de rede com Get-AzNetworkInterface; em seguida, defina a propriedade
LoadBalancerBackendAddressPools da NIC virtual como $null. Por fim, atualize a NIC virtual:
$nic = Get-AzNetworkInterface `
-Name "myVM2"
$nic.Ipconfigurations[0].LoadBalancerBackendAddressPools=$null
Set-AzNetworkInterface -NetworkInterface $nic
Para ver o balanceador de carga distribuir tráfego entre as duas VMs restantes que executam seu aplicativo,
você poderá forçar a atualização de seu navegador da Web. Agora você pode executar a manutenção na VM,
como instalação de atualizações do sistema operacional ou execução de uma reinicialização da VM.
Adicionar uma VM ao balanceador de carga
Após executar a manutenção da VM ou se precisar expandir a capacidade, defina a propriedade
LoadBalancerBackendAddressPools da NIC virtual para o BackendAddressPool de Get-AzLoadBalancer:
Obtenha o balanceador de carga:
$lb = Get-AzLoadBalancer `
-ResourceGroupName myResourceGroupLoadBalancer `
-Name myLoadBalancer
$nic.IpConfigurations[0].LoadBalancerBackendAddressPools=$lb.BackendAddressPools[0]
Set-AzNetworkInterface -NetworkInterface $nic
Próximas etapas
Neste tutorial, você criou um balanceador de carga e anexou VMs. Você aprendeu a:
Usar a Extensão de Script Personalizado para criar um site do IIS básico
Avance para o próximo tutorial para aprender a gerenciar a rede de VM.
Gerencie VMs e redes virtuais
Tutorial: Criar e gerenciar redes virtuais do
Microsoft Azure para as máquinas virtuais do
Windows com o Microsoft Azure PowerShell
As máquinas virtuais do Azure usam a rede do Azure para comunicação de rede interna e externa. Este tutorial
explica como implantar duas máquinas virtuais e configurar a rede do Azure para essas VMs. Os exemplos neste
tutorial supõem que as VMs estão hospedando um aplicativo Web com um back-end de banco de dados. No
entanto, não há implantação de aplicativo no tutorial. Neste tutorial, você aprenderá como:
Criar VM back-end
Visão Geral da VM
As redes virtuais do Azure habilitam conexões de rede seguras entre máquinas virtuais, a Internet e outros
serviços do Azure, como o Banco de Dados SQL do Azure. As redes virtuais são divididas em segmentos lógicos
chamados sub-redes. As sub-redes são usadas para controlar o fluxo de rede e como um limite de segurança.
Ao implantar uma máquina virtual, ela geralmente inclui um adaptador de rede virtual, que é anexado a uma
sub-rede.
Ao concluir este tutorial, você poderá ver estes recursos criados:
myVNet – a rede virtual que as VMs usam para se comunicar entre si e com a Internet.
myFrontendSubnet – a sub-rede em myVNet usada pelos recursos de front-end.
myPublicIPAddress – o endereço IP público usado para acessar myFrontendVM da Internet.
myFrontendNic – a interface de rede usada pelo myFrontendVM para se comunicar com myBackendVM.
myFrontendVM – a VM usada para comunicação entre a Internet e myBackendVM.
myBackendNSG – o grupo de segurança de rede que controla a comunicação entre o myFrontendVM e
myBackendVM.
myBackendSubnet – a sub-rede associada a myBackendNSG e usada pelos recursos de back-end.
myBackendNic – O adaptador de rede usado pelo myBackendVM para se comunicar com myFrontendVM.
myBackendVM – A VM que usa a porta 1433 para se comunicar com myFrontendVM.

Criar sub-rede
Para este tutorial, uma única rede virtual é criada com duas sub-redes. Uma sub-rede de front-end para
hospedar um aplicativo Web e uma sub-rede de back-end para hospedar um servidor de banco de dados.
Antes de criar uma rede virtual, crie um grupo de recursos usando New-AzResourceGroup. O exemplo abaixo
cria um grupo de recursos denominado myRGNetwork no local EastUS :
New-AzResourceGroup -ResourceGroupName myRGNetwork -Location EastUS
Crie uma configuração de sub-rede chamada myFrontendSubnet usando New-AzVirtualNetworkSubnetConfig:
$frontendSubnet = New-AzVirtualNetworkSubnetConfig `
-Name myFrontendSubnet `
E, criar uma configuração de sub-rede chamada myBackendSubnet:
$backendSubnet = New-AzVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
Criar rede virtual

Crie uma VNET denominada myVNet usando myFrontendSubnet e myBackendSubnet usando New-
AzVirtualNetwork:
-ResourceGroupName myRGNetwork `
-Location EastUS `
-Name myVNet `
-Subnet $frontendSubnet, $backendSubnet
Neste ponto, uma rede foi criada e segmentada em duas sub-redes, uma para os serviços de front-end e outra
para serviços de back-end. Na próxima seção, as máquinas virtuais serão criadas e conectadas a essas sub-
redes.

Um endereço IP público permite que os recursos do Azure sejam acessados pela Internet. O método de alocação
do endereço IP público pode ser configurado como dinâmico ou estático. Por padrão, um endereço IP público é
alocado dinamicamente. Os endereços IP dinâmicos são liberados quando uma VM é desalocada. Esse
comportamento faz com que o endereço IP se altere durante operações que incluam uma desalocação de VM.
O método de alocação pode ser definido como estático, o que garante que o endereço IP permaneça atribuído a
uma VM mesmo durante um estado desalocado. Se estiver usando um endereço IP estático, o próprio endereço
IP não poderá ser especificado. Em vez disso, ele será alocado de um pool de endereços disponíveis.
Crie um endereço IP público denominado myPublicIPAddress usando New-AzPublicIpAddress:
-Location EastUS `
-AllocationMethod Dynamic `
-Name myPublicIPAddress
Você pode alterar o parâmetro -AllocationMethod para Static para atribuir um endereço IP público estático.

Para uma VM se comunicar em uma rede virtual, ela precisará de uma adaptador de rede virtual (NIC). Crie uma
NIC usando New-AzNetworkInterface:
$frontendNic = New-AzNetworkInterface `
-Location EastUS `
-Name myFrontend `
-PublicIpAddressId $pip.Id
Defina o nome de usuário e a senha necessários para a conta de administrador na VM usando Get-Credential.
Você usa essas credenciais para conectar-se à VM nas etapas adicionais:
Crie as VMs usando New-AzVM.
New-AzVM `
-Credential $cred `
-Name myFrontend `
-PublicIpAddressName myPublicIPAddress `
-Size Standard_D1 `
-SubnetName myFrontendSubnet `
-VirtualNetworkName myVNet

Um NSG (grupo de segurança de rede) contém uma lista de regras de segurança que permitem ou negam o
tráfego de rede para recursos conectados a VNets (redes virtuais) do Azure. Os NSGs podem ser associados a
sub-redes ou adaptadores de rede individuais. Um NSG associado a um adaptador de rede se aplica somente à
VM associada. Quando um NSG está associado a uma sub-rede, as regras se aplicam a todos os recursos
conectados à sub-rede.
Regras de grupo de segurança de rede
As regras NSG definem portas de rede pelas quais o tráfego é permitido ou negado. As regras podem incluir
intervalos de endereços IP de origem e de destino, para que o tráfego seja controlado entre sistemas ou sub-
redes específicos. As regras NSG também incluem uma prioridade (entre 1 e 4096). As regras são avaliadas na
ordem de prioridade. Uma regra com uma prioridade 100 é avaliada antes de uma regra com prioridade 200.
Rede vir tual: o tráfego que começa e termina em uma rede virtual é permitido nas direções de entrada e
saída.
Internet: o tráfego de saída é permitido, mas o tráfego de entrada é bloqueado.
Balanceador de carga: o balanceador de carga do Azure permite investigar a integridade de suas VMs e
instâncias de função. Se não estiver usando um conjunto de balanceamento de carga, você poderá substituir
essa regra.
Criar grupos de segurança de rede
Crie uma regra de entrada denominada myFrontendNSGRule para permitir o tráfego da Web em
myFrontendVM usando New-AzNetworkSecurityRuleConfig:
$nsgFrontendRule = New-AzNetworkSecurityRuleConfig `
-Name myFrontendNSGRule `
-Protocol Tcp `
-Priority 200 `
-Access Allow
Você pode limitar o tráfego interno para myBackendVM apenas de myFrontendVM criando um NSG para a sub-
rede de back-end. O exemplo a seguir cria uma regra NSG chamada myBackendNSGRule:
$nsgBackendRule = New-AzNetworkSecurityRuleConfig `
-Name myBackendNSGRule `
-Protocol Tcp `
-Priority 100 `
-SourceAddressPrefix 10.0.0.0/24 `
-Access Allow
Adicione um grupo de segurança de rede chamado myFrontendNSG usando New-AzNetworkSecurityGroup:
$nsgFrontend = New-AzNetworkSecurityGroup `
-Location EastUS `
-Name myFrontendNSG `
-SecurityRules $nsgFrontendRule
Agora, adicione um grupo de segurança de rede chamado myBackendNSG usando New-

AzNetworkSecurityGroup:
$nsgBackend = New-AzNetworkSecurityGroup `
-Location EastUS `
-Name myBackendNSG `
-SecurityRules $nsgBackendRule
Adicione os grupos de segurança de rede às sub-redes.

-Name myVNet
$frontendSubnet = $vnet.Subnets[0]
$backendSubnet = $vnet.Subnets[1]
$frontendSubnetConfig = Set-AzVirtualNetworkSubnetConfig `
-Name myFrontendSubnet `
-AddressPrefix $frontendSubnet.AddressPrefix `
-NetworkSecurityGroup $nsgFrontend
$backendSubnetConfig = Set-AzVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix $backendSubnet.AddressPrefix `
-NetworkSecurityGroup $nsgBackend

A maneira mais fácil de criar a VM de back-end para este tutorial é usar uma imagem do SQL Server. Este
tutorial apenas cria a VM com o servidor de banco de dados, mas não fornece informações sobre como acessá-
lo.
Crie myBackendNic:
$backendNic = New-AzNetworkInterface `
-Location EastUS `
-Name myBackend `
-SubnetId $vnet.Subnets[1].Id
Defina o nome de usuário e a senha necessários para a conta de administrador na VM com Get-Credential:
Crie myBackendVM.
New-AzVM `
-Credential $cred `
-Name myBackend `
-ImageName "MicrosoftSQLServer:SQL2016SP1-WS2016:Enterprise:latest" `
-SubnetName MyBackendSubnet `
-VirtualNetworkName myVNet
A imagem neste exemplo tem o SQL Server instalado, mas não é usada neste tutorial. Ela está incluída para
mostrar como é possível configurar uma VM para lidar com o tráfego da Web e uma VM para lidar com o
gerenciamento de banco de dados.
Próximas etapas
Neste tutorial, você criou e protegeu redes do Azure em relação às máquinas virtuais.
Para saber como proteger seus discos de VM, confira Backup e recuperação de desastre para discos.
Cargas de trabalho do Red Hat no Azure
As cargas de trabalho do Red Hat são compatíveis por meio de uma variedade de ofertas no Azure. As imagens
do Red Hat Enterprise Linux (RHEL) estão no núcleo das cargas de trabalho do RHEL, assim como a RHUI
(Infraestrutura de atualização do Red Hat).
Imagens do Red Hat Enterprise Linux

O Azure oferece uma ampla gama de imagens do RHEL no Azure. Essas imagens são disponibilizadas por meio
de dois modelos de licenciamento diferentes: Pagamento Conforme o Uso e BYOS (traga sua própria
assinatura). As novas imagens do RHEL no Azure são publicadas quando novas versões do RHEL são lançadas e
atualizadas em todo o ciclo de vida, conforme necessário.
Imagens de Pagamento Conforme o Uso
O Azure oferece uma variedade de imagens do RHEL de Pagamento Conforme o Uso. Essas imagens vêm
adequadamente qualificadas para o RHEL e são anexadas a uma fonte de atualizações (Infraestrutura de
Atualização do Red Hat). Essas imagens cobram um valor Premium pelo direito e pelas atualizações do RHEL. As
variações das imagens do RHEL de Pagamento Conforme o Uso incluem:
RHEL Standard.
RHEL for SAP.
RHEL for SAP com serviços de alta disponibilidade e atualização.
O ideal é usar as imagens de Pagamento Conforme o Uso se você não quer se preocupar com o pagamento
separado do número apropriado de assinaturas.
Imagens do Red Hat Gold
O Azure também oferece imagens do Red Hat Gold ( rhel-byos ). Essas imagens podem ser úteis para os clientes
que têm assinaturas existentes do Red Hat e que desejam usá-las no Azure. Você precisa habilitar suas
assinaturas existentes do Red Hat para o Red Hat Cloud Access para usá-las no Azure. O acesso a essas imagens
é concedido automaticamente quando suas assinaturas do Red Hat são habilitadas para Acesso à Nuvem e
atendem aos requisitos de qualificação. O uso dessas imagens permite que um cliente evite a cobrança dupla
que poderá ocorrer com o uso das imagens de Pagamento Conforme o Uso.
Saiba como habilitar suas assinaturas do Red Hat para o Cloud Access com o Azure.
Saiba como localizar imagens do Red Hat Gold no portal do Azure, na CLI do Azure ou no cmdlet do
PowerShell.
NOTE
A cobrança dupla incorre quando um usuário paga duas vezes por assinaturas do RHEL. Esse cenário geralmente ocorre
quando um cliente usa o Gerenciador de Assinaturas do Red Hat para anexar um direito a uma VM do RHEL de
Pagamento Conforme o Uso. Por exemplo, um cliente que usa o Gerenciador de Assinaturas para anexar um direito de
pacotes do SAP a uma imagem de Pagamento Conforme o Uso do RHEL é indiretamente cobrado duas vezes, pois ele
paga duas vezes pelo RHEL. Ele paga uma vez por meio do valor Premium de Pagamento Conforme o Uso e outra por
meio da assinatura do SAP. Esse cenário não ocorre com os usuários de imagens BYOS.
Imagens da Geração 2
As VMs (máquinas virtuais) da Geração 2 fornecem alguns recursos mais recentes em comparação com as VMs
da Geração 1. Para obter mais informações, confira a documentação da Geração 2. A principal diferença da
perspectiva de imagens do RHEL é que as VMs da Geração 2 usam uma UEFI em vez da interface de firmware
do BIOS. Elas também usam uma GPT (tabela de partição GUID) em vez de um MBR (registro mestre de
inicialização) no tempo de inicialização. O uso de uma GPT permite, entre outras coisas, tamanhos de disco do
sistema operacional maiores que 2 TB. Além disso, as VMs da série Mv2 são executadas apenas nas imagens da
Geração 2.
As imagens do RHEL da Geração 2 estão disponíveis no Azure Marketplace. Procure "gen2" no SKU da imagem
na lista de todas as imagens exibidas quando você usa a CLI do Azure. Acesse a guia Avançado no processo de
implantação da VM para implantar uma VM da Geração 2.
Infraestrutura de atualização do Red Hat

O Azure fornece a Infraestrutura de Atualização do Red Hat somente para VMs do RHEL de Pagamento
Conforme o Uso. A RHUI é efetivamente um espelho das CDNs do Red Hat, mas é acessível apenas para as VMs
do RHEL de Pagamento Conforme o Uso do Azure. Você terá acesso aos pacotes apropriados dependendo da
imagem do RHEL implantada. Por exemplo, uma imagem do RHEL for SAP tem acesso aos pacotes do SAP, além
dos pacotes básicos do RHEL.
Comportamento de atualização da RHUI
As imagens do RHEL conectadas à RHUI são, por padrão, atualizadas para a última versão secundária do RHEL
quando um yum update é executado. Esse comportamento significa que uma VM do RHEL 7.4 poderá ser
atualizada para o RHEL 7.7 se uma operação yum update for executada nela. Esse comportamento ocorre por
design na RHUI. Para atenuar esse comportamento de atualização, mude de repositórios regulares do RHEL
para repositórios de Suporte de Atualização Estendida.
Próximas etapas
Saiba mais sobre as imagens do RHEL no Azure.
Saiba mais sobre a Infraestrutura de Atualização do Red Hat.
Saiba mais sobre a oferta de imagens do Red Hat Gold ( rhel-byos ).
OpenShift no Azure
O OpenShift é uma plataforma de aplicativo de contêiner aberta e extensível que traz docker e Kubernetes para
a empresa.
O OpenShift inclui Kubernetes para gerenciamento e orquestração do contêiner. Ele adiciona ferramentas
concentradas no desenvolvedor e em operações que permitem:
Desenvolvimento rápido de aplicativos.
Implantação e dimensionamento fáceis.
Manutenção de ciclo de vida de longo prazo para equipes e aplicativos.
Há várias versões do OpenShift disponíveis. Dessas versões, somente duas estão disponíveis atualmente para
que os clientes implantem no Azure: plataforma de contêiner OpenShift e OKD (anteriormente OpenShift
Origin).
Red Hat OpenShift no Azure

Microsoft Azure Red Hat OpenShift é uma oferta totalmente gerenciada do OpenShift em execução no Azure.
Esse serviço é gerenciado e suportado pela Microsoft e Red Hat em conjunto. Para obter mais detalhes, consulte
a documentação do serviço do Azure Red Hat OpenShift .
Plataforma do Contêiner do OpenShift

Plataforma de contêiner é uma versão comercial pronta para empresa do e suportada pelo Red Hat. Com essa
versão, o cliente adquire os direitos necessários para a Plataforma de Contêiner OpenShift e é responsável pela
instalação e o gerenciamento de toda a infraestrutura.
Como os próprios clientes "possuem" toda a plataforma, eles podem instalá-lo em seu datacenter local ou em
uma nuvem pública (como o Azure).
OKD
O OKD é um projeto upstream de software livre do OpenShift que tem o suporte da comunidade. O OKD pode
ser instalado em CentOS ou RHEL (Red Hat Enterprise Linux).
Próximas etapas
Configurar pré-requisitos comuns para OpenShift no Azure
Implantar o OpenShift Container Platform no Azure
Implantar a plataforma de contêiner OpenShift Self-Managed oferta do Marketplace
Implantar OpenShift no Azure Stack
Tarefas de pós-implantação
Solução de problemas de implantação do OpenShift
Implantar a plataforma de contêiner OpenShift 4. x
no Azure
Agora, há suporte para a implantação da OpenShift (plataforma de contêiner) 4,2 no Azure por meio do modelo
de IPI (infraestrutura de Installer-Provisioned). A página de aterrissagem para experimentar o OpenShift 4 é
try.openshift.com. Para instalar o OCP 4,2 no Azure, visite a página do Gerenciador de cluster do Red Hat
OpenShift . As credenciais do Red Hat são necessárias para acessar este site.
Observações
Um SP (entidade de serviço) Azure Active Directory (AAD) é necessário para instalar e executar o OCP 4. x no
Azure
O SP deve receber a permissão de API de Application. ReadWrite. OwnedBy para o grafo Azure
Active Directory
Um Administrador de Locatários do AAD deve conceder consentimento de administrador para que a
permissão da API entre em vigor
O SP deve receber as funções colaborador e administrador de acesso do usuário para a
assinatura
O modelo de instalação para OCP 4. x é diferente de 3. x e não há modelos de Azure Resource Manager
disponíveis para implantar o OCP 4. x no Azure
Se forem encontrados problemas durante o processo de instalação, entre em contato com a empresa
apropriada (Microsoft ou Red Hat)
DESC RIÇ Ã O DO P RO B L EM A P O N TO DE C O N TATO
Problemas específicos do Azure (AAD, SP, assinatura do Microsoft

Azure, etc.)
Problemas específicos do OpenShift (falhas de Red Hat

instalação/erros, assinatura do Red Hat, etc.)
Próximas etapas
Introdução ao OpenShift Container Platform
Pré-requisitos comuns para implantar a plataforma
de contêiner do OpenShift 3,11 no Azure
Este artigo descreve pré-requisitos comuns para implantar o OpenShift Container Platform ou OKD no Azure.
A instalação do OpenShift é feita por meio de guias estratégicos do Ansible. Ansible usa Secure Shell (SSH) para
se conectar a todos os hosts de cluster para concluir as etapas de instalação.
Quando o Ansible faz a conexão SSH com os hosts remotos, ele não pode inserir uma senha. Por esse motivo, a
chave privada não pode ter uma senha (senha) associada a ela ou a implantação falhará.
Como todas as máquinas virtuais (VMs) são implantadas por meio de modelos do Azure Resource Manager, a
mesma Chave pública é usada para acessar todas as VMs. A chave privada correspondente deve estar na VM
que executa todos os guias estratégicos também. Para executar essa ação com segurança, um cofre de chaves
do Azure é usado para passar a chave privada para a VM.
Se houver uma necessidade de armazenamento persistente para contêineres, então Volumes Persistentes serão
necessários. O OpenShift dá suporte a VHDs (discos rígidos virtuais) do Azure para volumes persistentes, mas o
Azure deve primeiro ser configurado como o provedor de nuvem.
Nesse modelo, o OpenShift:
Cria um objeto VHD em uma conta de armazenamento do Azure ou em um disco gerenciado.
Monta o VHD em uma VM e formata o volume.
Montará o volume no Pod.
Para que isso funcione, o OpenShift precisa de permissões para executar as tarefas no Azure. Uma entidade de
serviço é usada para essa finalidade. A Entidade de serviço é uma conta de segurança no Azure Active Directory
que tem as permissões para recursos.
A Entidade de serviço deve ter acesso a Contas de armazenamento e máquinas virtuais que compõem o cluster.
Se todos os recursos de cluster do OpenShift forem implantados em um único Grupo de recursos, a SP pode
receber permissões para esse Grupo de recursos.
Este guia descreve como criar os artefatos associados aos pré-requisitos.
Crie um KeyVault para gerenciar chaves SSH para o cluster OpenShift.
Crie uma Entidade de serviço para uso pelo Provedor de nuvem do Azure.
Entrar no Azure
Faça logon na sua assinatura do Azure com o comando az login e siga as instruções na tela ou clique em
Experimentar para usar o Cloud Shell.
az login

lógico no qual os recursos do Azure são implantados e gerenciados. Você deve usar um grupo de recursos
dedicado para hospedar o cofre de chaves. Esse grupo é separado do grupo de recursos no qual os recursos de
cluster OpenShift implantam.
O exemplo abaixo cria um grupo de recursos denominado keyvaultrg no local eastus:
az group create --name keyvaultrg --location eastus

Crie um KeyVault para armazenar as chaves de SSH para o cluster com o comando az keyvault create. O nome
do cofre de chaves deve ser globalmente exclusivo e deve ser habilitado para implantação de modelo, ou a
implantação falhará com o erro "KeyVaultParameterReferenceSecretRetrieveFailed".
O exemplo abaixo cria um keyvault denominado keyvault no grupo de recursos keyvaultrg:
az keyvault create --resource-group keyvaultrg --name keyvault \

--enabled-for-template-deployment true \
--location eastus
Criar uma chave SSH

Uma chave SSH é necessária para proteger o acesso ao cluster de OpenShift. Crie um par de chaves SSH usando
o comando ssh-keygen (no Linux ou Mac):
ssh-keygen -f ~/.ssh/openshift_rsa -t rsa -N ''
NOTE
O par de chaves SSH não pode ter uma senha / frase secreta.
Para obter mais informações sobre as chaves SSH no Windows, confira Como criar chaves SSH no Windows.
Certifique-se de exportar a chave privada no formato OpenSSH.
Armazenar chave privada SSH no Azure Key Vault

A implantação de OpenShift usa a chave SSH criada para proteger o acesso ao mestre OpenShift. Para habilitar
a implantação para recuperar a chave SSH com segurança, armazene a chave no Key Vault usando o comando a
seguir:
az keyvault secret set --vault-name keyvault --name keysecret --file ~/.ssh/openshift_rsa
Criar uma entidade de serviço

O OpenShift se comunica com o Azure usando um nome de usuário e a senha ou uma entidade de serviço. Uma
entidade de serviço do Azure é uma identidade de segurança que você pode usar com aplicativos, serviços e
ferramentas de automação como o OpenShift. Você controla e define as permissões referentes a quais
operações a entidade de serviço pode executar no Azure. É melhor fazer o escopo das permissões da entidade
de serviço para grupos de recursos específicos em vez de toda a assinatura.
Crie uma entidade de serviço com az ad sp create-for-rbac e gere as credenciais necessárias para o OpenShift.
O exemplo a seguir cria uma entidade de serviço e atribui permissões de colaborador de ti a um grupo de
recursos chamado openshiftrg.
Primeiro, crie o grupo de recursos chamado openshiftrg:
az group create -l eastus -n openshiftrg
Criar uma entidade de serviço:
az group show --name openshiftrg --query id
Salvar a saída do comando e usar no lugar de $scope no próximo comando
az ad sp create-for-rbac --name openshiftsp \

--role Contributor --scopes $scope \
Anote a propriedade appId e a senha retornada do comando:
{
"appId": "11111111-abcd-1234-efgh-111111111111",
"displayName": "openshiftsp",
"name": "http://openshiftsp",
"password": {Strong Password},
"tenant": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
}
WARNING
Certifique-se de anotar a senha segura, pois não será possível recuperar essa senha novamente.
Para obter mais informações sobre entidades de serviço, confira Criar entidade de serviço do Azure com a CLI
do Azure.
Pré-requisitos aplicáveis somente ao modelo do Resource Manager

Os segredos precisarão ser criados para a chave privada SSH (sshPrivateKey ), o segredo do cliente do Azure
AD (aadClientSecret ), a senha de administrador do OpenShift (openshiftPassword ) e a senha ou a chave de
ativação do Red Hat Subscription Manager (rhsmPasswordOrActivationKey ). Além disso, se forem usados
certificados TLS/SSL personalizados, seis segredos adicionais precisarão ser criados- routingcafile ,
routingcer tfile , routingkeyfile , mastercafile , mastercer tfile e masterkeyfile . Esses parâmetros serão
explicados em mais detalhes.
O modelo referencia nomes de segredo específicos, portanto, você deve usar os nomes em negrito listados
acima (diferencia maiúsculas de minúsculas).
Certificados personalizados
Por padrão, o modelo implantará um cluster OpenShift usando certificados autoassinados para o console Web
do OpenShift e o domínio de roteamento. Se você quiser usar certificados TLS/SSL personalizados, defina '
routingCertType ' como ' Custom ' e ' masterCertType ' como ' Custom '. Você precisará da autoridade de
certificação, do certificado e dos arquivos de chave no formato. pem para os certificados. É possível usar
certificados personalizados para um, mas não para o outro.
Você precisará armazenar esses arquivos em Key Vault segredos. Use o mesmo Key Vault como aquele usado
para a chave privada. Em vez de exigir 6 entradas adicionais para os nomes de segredo, o modelo é embutido
em código para usar nomes de segredo específicos para cada um dos arquivos de certificado TLS/SSL.
Armazene os dados do certificado usando as informações da tabela a seguir.
N O M E DO SEGREDO A RQ UIVO DE C ERT IF IC A DO
mastercafile arquivo de AC mestre
mastercertfile arquivo de certificado mestre
masterkeyfile arquivo de chave mestra
routingcafile arquivo de AC de roteamento
routingcertfile arquivo de certificado de roteamento
routingkeyfile arquivo de chave de roteamento
Crie os segredos usando o CLI do Azure. Veja abaixo um exemplo.
az keyvault secret set --vault-name KeyVaultName -n mastercafile --file ~/certificates/masterca.pem
Próximas etapas
Este artigo abordou os seguintes tópicos:
Crie um KeyVault para gerenciar chaves SSH para o cluster OpenShift.
Crie uma Entidade de serviço para uso pelo Provedor de Solução de nuvem do Azure.
Agora, implante um cluster de OpenShift:
Implantar a plataforma de contêiner do OpenShift
Implantar a plataforma de contêiner OpenShift Self-Managed oferta do Marketplace
Implantar a plataforma de contêiner OpenShift 3,11
no Azure
Você pode usar um dos vários métodos para implantar a plataforma de contêiner do OpenShift 3,11 no Azure:
Você pode implantar manualmente os componentes necessários da infraestrutura do Azure e, em seguida,
seguir a documentação da plataforma de contêiner do OpenShift.
Você também pode usar um modelo do Gerenciador de Recursos existente que simplifica a implantação do
cluster do OpenShift Container Platform.
Outra opção é usar a Oferta do Azure Marketplace.
Para ambas as opções, é necessária uma assinatura do Red Hat. Durante a implantação, a instância Red Hat
Enterprise Linux é registrada na Assinatura do Red Hat e anexada à ID do Pool que contém os direitos para o
OpenShift Container Platform. Certifique-se de que você tenha uma senha, uma ID do Pool e um Nome de
usuário de gerente de Assinatura do Red Hat (RHSM) válidos. Você pode usar uma Chave de Ativação, ID da
Organização e ID do Pool. Você pode verificar essas informações entrando em https://access.redhat.com.
Implantar usando o modelo do Gerenciador de recursos da

plataforma de contêiner OpenShift 3,11
Clusters privados
Implantar clusters OpenShift privados requer mais do que simplesmente não ter um IP público associado ao
balanceador de carga mestre (console Web) ou ao balanceador de carga (roteador). Um cluster privado
geralmente usa um servidor DNS personalizado (não o DNS padrão do Azure), um nome de domínio
personalizado (como contoso.com) e redes virtuais predefinidas. Para clusters privados, você precisa configurar
sua rede virtual com todas as sub-redes apropriadas e as configurações do servidor DNS com antecedência. Em
seguida, use existingMasterSubnetReference , existingInfraSubnetReference ,
existingCnsSubnetReference e existingNodeSubnetReference para especificar a sub-rede existente a ser
usada pelo cluster.
Se o mestre privado estiver selecionado (masterClusterType = Private), um IP privado estático precisará ser
especificado para masterPrivateClusterIp . Esse IP será atribuído ao front-end do balanceador de carga mestre.
O IP deve estar dentro do CIDR para a sub-rede mestre e não em uso. masterClusterDnsType deve ser
definido como "Custom" e o nome DNS mestre deve ser fornecido para masterClusterDns . O nome DNS deve
mapear para o IP privado estático e será usado para acessar o console do nos nós mestres.
Se o roteador privado for selecionado (routerClusterType = Private), um IP privado estático precisará ser
especificado para routerPrivateClusterIp . Esse IP será atribuído ao front-end do balanceador de carga de
infraestrutura. O IP deve estar dentro do CIDR para a sub-rede de infraestrutura e não em uso.
routingSubDomainType deve ser definido como "Custom" e o nome DNS do curinga para roteamento deve
ser fornecido para routingSubDomain .
Se os mestres privados e o roteador privado forem selecionados, o nome de domínio personalizado também
deverá ser inserido para DomainName
Após a implantação bem-sucedida, o nó de bastiões é o único nó com um IP público no qual você pode SSH.
Mesmo que os nós mestres estejam configurados para acesso público, eles não são expostos para acesso SSH.
Para implantar usando o modelo do Resource Manager, você usa um arquivo de parâmetros para fornecer os
parâmetros de entrada. Para personalizar ainda mais a implantação, bifurque o repositório do GitHub e altere os
itens apropriados.
Algumas opções comuns de personalização incluem, mas não estão limitadas a:
Tamanho de VM de bastião (variável em azuredeploy.json)
Convenções de nomenclatura (variáveis em azuredeploy.json)
Especificações de cluster do OpenShift – modificadas por meio do arquivo de hosts (deployOpenShift.sh)
Configurar o arquivo de parâmetros
O modelo do OpenShift Container Platform tem várias ramificações disponíveis para diferentes versões do
OpenShift Container Platform. Com base em suas necessidades, você pode implantar diretamente do repositório
ou você pode criar fork do repositório e fazer alterações personalizadas para os modelos ou scripts antes de
implantar.
Use o valor appId da entidade de serviço que você criou anteriormente para o parâmetro aadClientId .
O exemplo a seguir mostra um arquivo de parâmetros chamado azuredeploy.parameters.json com todas as
entradas necessárias.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"parameters": {
"_artifactsLocation": {
"value": "https://raw.githubusercontent.com/Microsoft/openshift-container-platform/master"
},
"location": {
"value": "eastus"
},
"masterVmSize": {
"value": "Standard_E2s_v3"
},
"infraVmSize": {
"value": "Standard_D4s_v3"
},
"nodeVmSize": {
"value": "Standard_D4s_v3"
},
"cnsVmSize": {
},
"osImageType": {
"value": "defaultgallery"
},
"marketplaceOsImage": {
"value": {
"publisher": "RedHat",
"offer": "RHEL",
"sku": "7-RAW",
"version": "latest"
}
},
"storageKind": {
"value": "changeme"
},
"openshiftClusterPrefix": {
"value": "changeme"
},
"minorVersion": {
"value": "69"
},
"masterInstanceCount": {
"value": 3
},
},
"infraInstanceCount": {
"value": 3
},
"nodeInstanceCount": {
"value": 3
},
"cnsInstanceCount": {
"value": 3
},
"osDiskSize": {
"value": 64
},
"dataDiskSize": {
"value": 64
},
"cnsGlusterDiskSize": {
"value": 128
},
"adminUsername": {
"value": "changeme"
},
"enableMetrics": {
"value": "false"
},
"enableLogging": {
"value": "false"
},
"enableCNS": {
"value": "false"
},
"rhsmUsernameOrOrgId": {
"value": "changeme"
},
"rhsmPoolId": {
"value": "changeme"
},
"rhsmBrokerPoolId": {
"value": "changeme"
},
"sshPublicKey": {
"value": "GEN-SSH-PUB-KEY"
},
"keyVaultSubscriptionId": {
"value": "255a325e-8276-4ada-af8f-33af5658eb34"
},
"keyVaultResourceGroup": {
"value": "changeme"
},
"keyVaultName": {
"value": "changeme"
},
"enableAzure": {
"value": "true"
},
"aadClientId": {
"value": "changeme"
},
"domainName": {
"value": "contoso.com"
},
"masterClusterDnsType": {
"value": "default"
},
"masterClusterDns": {
"value": "console.contoso.com"
},
"routingSubDomainType": {
"value": "nipio"
},
},
"routingSubDomain": {
"value": "apps.contoso.com"
},
"virtualNetworkNewOrExisting": {
"value": "new"
},
"virtualNetworkName": {
"value": "changeme"
},
"addressPrefixes": {
"value": "10.0.0.0/14"
},
"masterSubnetName": {
"value": "changeme"
},
"masterSubnetPrefix": {
"value": "10.1.0.0/16"
},
"infraSubnetName": {
"value": "changeme"
},
"infraSubnetPrefix": {
"value": "10.2.0.0/16"
},
"nodeSubnetName": {
"value": "changeme"
},
"nodeSubnetPrefix": {
"value": "10.3.0.0/16"
},
"existingMasterSubnetReference": {
"value": "/subscriptions/abc686f6-963b-4e64-bff4-
99dc369ab1cd/resourceGroups/vnetresourcegroup/providers/Microsoft.Network/virtualNetworks/openshiftvnet/subn
ets/mastersubnet"
},
"existingInfraSubnetReference": {
ets/infrasubnet"
},
"existingCnsSubnetReference": {
ets/cnssubnet"
},
"existingNodeSubnetReference": {
ets/nodesubnet"
},
"masterClusterType": {
"value": "public"
},
"masterPrivateClusterIp": {
"value": "10.1.0.200"
},
"routerClusterType": {
"value": "public"
},
"routerPrivateClusterIp": {
"value": "10.2.0.200"
},
"routingCertType": {
"value": "selfsigned"
},
"masterCertType": {
"value": "selfsigned"
}
}
}
Substitua os parâmetros por suas informações específicas.

Versões diferentes podem ter parâmetros diferentes. Portanto, verifique os parâmetros necessários para a
ramificação que você usar.
azuredeploy.Parameters.jsno arquivo explicado
P RO P RIEDA DE DESC RIÇ Ã O O P Ç Õ ES VÁ L IDA S VA LO R PA DRÃ O
_artifactsLocation URL para artefatos (JSON, https: /

scripts, etc.) /RAW.githubusercontent.co
m/Microsoft/openshift-
container-Platform/Master
location Região do Azure para

implantar recursos
masterVmSize Tamanho da VM mestre. Standard_E2s_v3

Selecione um dos tamanhos
de VM permitidos listados
na azuredeploy.jsno arquivo
infraVmSize Tamanho da VM de Standard_D4s_v3

infraestrutura. Selecione um
dos tamanhos de VM
permitidos listados na
azuredeploy.jsno arquivo
nodeVmSize Tamanho da VM do nó do Standard_D4s_v3

aplicativo. Selecione um dos
tamanhos de VM
cnsVmSize Tamanho da VM do nó do Standard_E4s_v3

armazenamento nativo do
contêiner (CNS). Selecione
um dos tamanhos de VM
osImageType A imagem RHEL a ser defaultgallery defaultgallery

usada. defaultgallery: sob marketplace
demanda; Marketplace:
imagem de terceiros
marketplaceOsImage Se osImageType for

Marketplace, insira os
valores apropriados para '
publicador ', ' oferta ', ' SKU
', ' versão ' da oferta do
Marketplace. Este
parâmetro é um tipo de
objeto
storageKind O tipo de armazenamento a gerenciado gerenciado

ser usado não gerenciado
openshiftClusterPrefix Prefixo de cluster usado mycluster

para configurar os nomes
de host para todos os nós.
Entre 1 e 20 caracteres
minoVersion A versão secundária da 69

plataforma de contêiner do
OpenShift 3,11 a ser
implantada
masterInstanceCount Número de nós mestres a 1, 3, 5 3

serem implantados
infraInstanceCount Número de nós de 1, 2, 3 3

infraestrutura a serem
implantados
nodeInstanceCount Número de nós a serem 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 2

implantados 11, 12, 13, 14, 15, 16, 17,
18, 19, 20, 21, 22, 23, 24,
25, 26, 27, 28, 29, 30
cnsInstanceCount Número de nós do CNS a 3, 4 3

serem implantados
osDiskSize Tamanho do disco do 64, 128, 256, 512, 1024, 64

sistema operacional para a 2048
VM (em GB)
dataDiskSize Tamanho do disco de dados 32, 64, 128, 256, 512, 64

a ser anexado aos nós para 1024, 2048
o volume do Docker (em
GB)
cnsGlusterDiskSize Tamanho do disco de dados 32, 64, 128, 256, 512, 128
a ser anexado aos nós do 1024, 2048
CNS para uso pelo
GlusterFS (em GB
adminUsername Nome de usuário do ocpadmin

administrador para o logon
do sistema operacional
(VM) e o usuário OpenShift
inicial
enableMetrics Habilitar métricas. As true false

métricas exigem mais false
recursos, portanto,
selecione o tamanho
adequado para a máquina
virtual de infraestrutura
enableLogging Habilite o registro em log. o true false

Pod elasticsearch requer 8 false
GB de RAM, portanto,
selecione o tamanho
adequado para a VM de
infraestrutura
enableCNS Habilitar o armazenamento true false

nativo do contêiner false
rhsmUsernameOrOrgId Nome de usuário ou ID da

organização do Red Hat
Subscription Manager
rhsmPoolId A ID do pool do
Gerenciador de assinaturas
do Red Hat que contém
seus direitos de OpenShift
para nós de computação
rhsmBrokerPoolId A ID do pool do
Gerenciador de assinaturas
do Red Hat que contém
seus direitos de OpenShift
para nós mestres e de infra-
estrutura. Se você não tiver
IDs de pool diferentes,
insira a mesma ID de pool
que ' rhsmPoolId '
sshPublicKey Copie sua chave pública

SSH aqui
keyVaultSubscriptionId A ID da assinatura que

contém o Key Vault
keyVaultResourceGroup O nome do grupo de

recursos que contém o Key
Vault
keyVaultName O nome da Key Vault que

você criou
enableAzure Habilitar o provedor de true true

nuvem do Azure false
aadClientId Azure Active Directory ID

do cliente também
conhecida como ID do
aplicativo para a entidade
de serviço
domainName Nome do nome de domínio nenhum

personalizado a ser usado
(se aplicável). Defina como
"nenhum" se não estiver
implantando um cluster
totalmente privado
masterClusterDnsType Tipo de domínio do console padrão padrão

Web do OpenShift. ' default custom
' usará o rótulo DNS do IP
de infraestrutura principal. '
Custom ' permite que você
defina seu próprio nome
masterClusterDns O nome DNS personalizado console.contoso.com

a ser usado para acessar o
console Web OpenShift se
você selecionou ' Custom '
para
masterClusterDnsType
routingSubDomainType Se definido como ' nipio ', nipio nipio

routingSubDomain usará custom
Nip.IO. Use ' Custom ' se
você tiver seu próprio
domínio que deseja usar
para roteamento
routingSubDomain O nome DNS do curinga apps.contoso.com

que você deseja usar para
roteamento se você
selecionou ' personalizado '
para
routingSubDomainType
virtualNetworkNewOrExisting Selecione se deseja usar pré-existente novo

uma rede virtual existente novo
ou criar uma nova rede
virtual
Nome do grupo de recursos

virtualNetworkResourceGroupName resourcegroup (). Name
para a nova rede virtual se
você selecionou ' novo '
para
virtualNetworkNewOrExisting
virtualNetworkName O nome da nova rede openshiftvnet

virtual a ser criada se você
selecionou ' novo ' para
virtualNetworkNewOrExisting
addressPrefixes Prefixo de endereço da 10.0.0.0/14

nova rede virtual
masterSubnetName O nome da sub-rede mastersubnet

mestre
masterSubnetPrefix CIDR usado para a sub- 10.1.0.0/16

rede mestre-precisa ser um
subconjunto do
addressPrefix
infraSubnetName O nome da sub-rede de infrasubnet

infraestrutura
infraSubnetPrefix CIDR usado para a sub- 10.2.0.0/16

rede de infraestrutura –
precisa ser um subconjunto
do addressPrefix
nodeSubnetName O nome da sub-rede do nó nodesubnet
nodeSubnetPrefix CIDR usado para a sub- 10.3.0.0/16

rede do nó-precisa ser um
subconjunto do
addressPrefix
Referência completa à sub-

existingMasterSubnetReference
rede existente para nós
mestres. Não é necessário
se estiver criando uma nova
vNet/sub-rede
existingInfraSubnetReferenceReferência completa à sub-

rede existente para nós de
infraestrutura. Não é
necessário se estiver
criando uma nova
vNet/sub-rede
existingCnsSubnetReference Referência completa para a

sub-rede existente para nós
do CNS. Não é necessário
se estiver criando uma nova
vNet/sub-rede
existingNodeSubnetReference Referência completa para a

sub-rede existente para nós
de computação. Não é
necessário se estiver
criando uma nova
vNet/sub-rede
masterClusterType Especifique se o cluster usa públicos públicos

nós mestres privados ou particulares
públicos. Se privado for
escolhido, os nós mestres
não serão expostos à
Internet por meio de um IP
público. Em vez disso, ele
usará o IP privado
especificado no
masterPrivateClusterIp
masterPrivateClusterIp Se nós mestres privados 10.1.0.200

forem selecionados, um
endereço IP privado deverá
ser especificado para ser
usado pelo balanceador de
carga interno para nós
mestres. Esse IP estático
deve estar dentro do bloco
CIDR para a sub-rede
mestre e ainda não está em
uso. Se os nós mestres
públicos forem
selecionados, esse valor não
será usado, mas ainda
deverá ser especificado
routerClusterType Especifique se o cluster usa públicos públicos

nós de infraestrutura particulares
privada ou pública. Se
privado for escolhido, os
nós de infra-estrutura não
serão expostos à Internet
por meio de um IP público.
Em vez disso, ele usará o IP
privado especificado no
routerPrivateClusterIp
routerPrivateClusterIp Se os nós de infraestrutura 10.2.0.200

privada forem selecionados,
um endereço IP privado
deverá ser especificado para
ser usado pelo balanceador
de carga interno para os
nós de infraestrutura. Esse
IP estático deve estar
dentro do bloco CIDR para
a sub-rede de infraestrutura
e ainda não está em uso. Se
os nós de infraestrutura
pública forem selecionados,
esse valor não será usado,
mas ainda deverá ser
especificado
routingCertType Usar certificado selfsigned selfsigned

personalizado para o custom
domínio de roteamento ou
o certificado autoassinado
padrão-siga as instruções
na seção de cer tificados
personalizados
masterCertType Usar certificado selfsigned selfsigned

personalizado para o custom
domínio mestre ou o
certificado autoassinado
padrão-siga as instruções
na seção de cer tificados
personalizados
Implantar usando a CLI do Azure
NOTE
O comando a seguir requer a CLI do Azure 2.0.8 ou posterior. Você pode verificar a versão CLI com o comando
az --version . Para atualizar a versão da CLI, consulte Instalar o Azure CLI.
O exemplo a seguir implanta o cluster do OpenShift e todos os recursos relacionados em um grupo de recursos
denominado openshiftrg, com um nome de implantação de myOpenShiftCluster. O modelo é referenciado
diretamente do repositório GitHub e um arquivo de parâmetros local chamado azuredeploy.parameters.json é
usado.
az deployment group create -g openshiftrg --name myOpenShiftCluster \

--template-uri https://raw.githubusercontent.com/Microsoft/openshift-container-
platform/master/azuredeploy.json \
--parameters @./azuredeploy.parameters.json
A implantação leva pelo menos 60 minutos para ser concluída, com base no número total de nós implantados e
nas opções configuradas. O FQDN do DNS de bastiões e a URL do console do OpenShift imprime no terminal
quando a implantação for concluída.
{
"Bastion DNS FQDN": "bastiondns4hawllzaavu6g.eastus.cloudapp.azure.com",
"OpenShift Console URL": "http://openshiftlb.eastus.cloudapp.azure.com/console"
}
Se você não quiser amarrar a linha de comando esperando a conclusão da implementação, inclua --no-wait
como uma das opções para a implementação do grupo. A saída da implantação pode ser recuperada do portal
do Azure na seção de implantação do grupo de recursos.
Conectar-se ao cluster OpenShift

Quando a implantação for concluída, recupere a conexão da seção de saída da implantação. Conecte-se ao
console do OpenShift com seu navegador usando a URL do console do OpenShift . Você também pode SSH
para o host bastião. A seguir está um exemplo em que o nome de usuário do administrador é clusteradmin e o
IP público de bastiões FQDN do DNS é bastiondns4hawllzaavu6g.eastus.cloudapp.azure.com:
$ ssh clusteradmin@bastiondns4hawllzaavu6g.eastus.cloudapp.azure.com
Limpar os recursos
o cluster OpenShift e todos os recursos relacionados.
az group delete --name openshiftrg
Próximas etapas
Solução de problemas de implantação do OpenShift no Azure
Configurar pré-requisitos
Antes de usar a oferta do Marketplace para implantar um cluster da plataforma de contêiner do OpenShift
autogerenciada 3,11 no Azure, alguns pré-requisitos devem ser configurados. Leia o artigo pré-requisitos do
OpenShift para obter instruções para criar uma chave SSH (sem uma frase secreta), cofre de chaves do Azure,
segredo do cofre de chaves e uma entidade de serviço.
Implantar usando a oferta do Marketplace

A maneira mais simples de implantar um cluster OpenShift da plataforma de contêiner autogerenciada 3,11 no
Azure é usar a oferta do Azure Marketplace.
Essa opção é a mais simples, mas também tem recursos de personalização limitados. A oferta do Marketplace
implanta a plataforma de contêiner OpenShift 3.11.82 e inclui as seguintes opções de configuração:
Nós mestres : tipo de instância de nós mestres três (3) com configurável.
Nós mestres : tipo de instância de nós mestres três (3) com configurável.
Nós : o número de nós (entre 1 e 9) e o tipo de instância são configuráveis.
Tipo de Disco : Discos gerenciados são usados.
Rede : suporte para rede nova ou existente e intervalo CIDR personalizado.
CNS : CNS pode ser habilitado.
Métricas : as métricas Hawkular podem ser habilitadas.
Registro em log : o log de EFK pode ser habilitado.
Provedor de nuvem do Azure : habilitado por padrão, pode ser desabilitado.
No canto superior esquerdo do portal do Azure, clique em criar um recurso , insira ' plataforma de contêiner
openshift ' na caixa de pesquisa e pressione Enter.
A página de resultados será aberta com a plataforma de contêiner do Red Hat OpenShift 3,11
autogerenciado na lista.
Clique na oferta para exibir os detalhes da oferta. Para implantar essa oferta, clique em criar . A interface do
usuário para inserir os parâmetros necessários será exibida. A primeira tela é a folha noções básicas .
Noções básicas
Para obter ajuda sobre qualquer um dos parâmetros de entrada, passe o mouse sobre o i ao lado do nome do
parâmetro.
Insira valores para os parâmetros de entrada e clique em OK .
PA RÂ M ET RO DE EN T RA DA DESC RIÇ Ã O DO PA RÂ M ET RO
Nome de usuário do administrador da VM O usuário administrador a ser criado em todas as instâncias

de VM
Chave pública SSH para usuário administrador Chave pública SSH usada para fazer logon na VM-não deve
ter uma frase secreta
Subscription Assinatura do Azure na qual implantar o cluster
Grupo de recursos Criar um novo grupo de recursos ou selecionar um grupo de

recursos vazio existente para recursos de cluster
Local Região do Azure na qual implantar o cluster

Configurações de infraestrutura
Insira valores para os parâmetros de entrada e clique em OK .
Prefixo do nome do cluster OCP Prefixo de cluster usado para configurar os nomes de host
para todos os nós. Entre 1 e 20 caracteres
Tamanho do nó mestre Aceite o tamanho da VM padrão ou clique em alterar

tamanho para selecionar um tamanho de VM diferente.
Selecione o tamanho apropriado da VM para sua carga de
trabalho
Tamanho do nó de infraestrutura Aceite o tamanho da VM padrão ou clique em alterar

trabalho
Número de nós de aplicativo Aceite o tamanho da VM padrão ou clique em alterar

trabalho
Tamanho do nó do aplicativo Aceite o tamanho da VM padrão ou clique em alterar

trabalho
Tamanho do host bastião Aceite o tamanho da VM padrão ou clique em alterar

trabalho
Rede virtual nova ou existente Criar uma nova vNet (padrão) ou usar uma vNet existente
Escolha as configurações de CIDR padrão ou personalize o Aceite intervalos CIDR padrão ou selecione inter valo de IP
intervalo de IP (CIDR) personalizado e insira informações de CIDR personalizadas.
As configurações padrão criarão vNet com CIDR/14, sub-
rede mestre com 10.1.0.0/16, rede de infraestrutura com
10.2.0.0/16 e sub-rede de computação e CNS com
10.3.0.0/16
Nome do grupo de recursos Key Vault O nome do grupo de recursos que contém o Key Vault
Nome do cofre de chaves O nome do Key Vault que contém o segredo com a chave
privada SSH. Somente caracteres alfanuméricos e traços são
permitidos e têm entre 3 e 24 caracteres
Nome do segredo O nome do segredo que contém a chave privada SSH.

Somente caracteres alfanuméricos e traços são permitidos
Alterar tamanho
Para selecionar um tamanho de VM diferente, clique em *alterar tamanho _. A janela seleção de VM será
aberta. Selecione o tamanho da VM que você deseja e clique em _ * selecionar * *.
Rede vir tual existente
Nome da rede virtual existente Nome da vNet existente
Nome da sub-rede para nós mestres Nome da sub-rede existente para nós mestres. Precisa conter
pelo menos 16 endereços IP e seguir o RFC 1918
Nome da sub-rede para nós de infraestrutura Nome da sub-rede existente para nós de infraestrutura.
Precisa conter pelo menos 32 endereços IP e seguir a RFC
1918
Nome da sub-rede para nós de computação e CNS Nome da sub-rede existente para nós de computação e CNS.
Precisa conter pelo menos 32 endereços IP e seguir a RFC
1918
Grupo de recursos para a rede virtual existente Nome do grupo de recursos que contém a vNet existente
Inter valo de IP personalizado
Intervalo de endereços para a rede virtual CIDR personalizado para a vNet
Intervalo de endereços da sub-rede que contém os nós CIDR personalizado para sub-rede mestre
mestres
Intervalo de endereços da sub-rede que contém os nós de CIDR personalizado para sub-rede de infraestrutura
infraestrutura
Intervalo de endereços para a sub-rede que contém os nós CIDR personalizado para os nós de computação e CNS
de computação e CNS
Insira valores para os parâmetros de entrada e clique em OK
Senha de usuário do administrador do OpenShift Senha para o usuário OpenShift inicial. Esse usuário também
será o administrador do cluster
Confirmar senha de usuário do administrador do OpenShift Digite novamente a senha de usuário do administrador do
OpenShift
Nome de usuário do Gerenciador de assinaturas do Red Hat Nome de usuário para acessar sua assinatura do Red Hat ou
ID da organização. Essa credencial é usada para registrar a
instância de RHEL em sua assinatura e não será armazenada
pela Microsoft ou Red Hat
Senha de usuário do Gerenciador de assinaturas do Red Hat Senha para acessar sua assinatura do Red Hat ou chave de
ativação. Essa credencial é usada para registrar a instância de
RHEL em sua assinatura e não será armazenada pela
Microsoft ou Red Hat
ID do pool OpenShift do Gerenciador de assinaturas do Red ID do pool que contém a qualificação da plataforma de
Hat contêiner OpenShift. Verifique se você tem direitos
suficientes da plataforma de contêiner do OpenShift para a
instalação do cluster
ID do pool OpenShift do Gerenciador de assinaturas do Red ID do pool que contém direitos de plataforma de contêiner
Hat para nós de agente/mestre OpenShift para nós de agente/mestre. Verifique se você tem
direitos suficientes da plataforma de contêiner do OpenShift
para a instalação do cluster. Se não estiver usando a ID do
pool do agente/mestre, insira a ID do pool para nós de
aplicativo
Configurar o provedor de nuvem do Azure Configure o OpenShift para usar o provedor de nuvem do
Azure. Necessário se estiver usando a anexação de disco do
Azure para volumes persistentes. O padrão é sim
GUID de ID do cliente da entidade de serviço do Azure AD GUID de ID do cliente da entidade de serviço do Azure AD –
também conhecido como AppID. Necessário somente se
configurar o provedor de nuvem do Azure definido como
Sim
Segredo da ID do cliente da entidade de serviço do Azure Segredo da ID do cliente da entidade de serviço do Azure
AD AD. Necessário somente se configurar o provedor de nuvem
do Azure definido como Sim
Configurações adicionais
A folha configurações adicionais permite a configuração do CNS para armazenamento GlusterFS, registro em
log, métricas e subdomínio do roteador. O padrão não instalará nenhuma dessas opções e usará nip.io como o
subdomínio do roteador para fins de teste. A habilitação do CNS instalará três nós de computação adicionais
com três discos anexados adicionais que hospedarão o GlusterFS pods.
Insira valores para os parâmetros de entrada e clique em OK
Configurar o armazenamento nativo do contêiner (CNS) Instala o CNS no cluster OpenShift e o habilita como
armazenamento. Será padrão se o provedor do Azure estiver
desabilitado
Configurar o log de cluster Instala a funcionalidade de log de EFK no cluster. Dimensionar

nós de infraestrutura apropriadamente para hospedar pods
de EFK
Configurar métricas para o cluster Instala as métricas de Hawkular no cluster OpenShift.

Dimensionar nós de infraestrutura apropriadamente para
hospedar pods de métricas de Hawkular
Subdomínio do roteador padrão Selecione nipio para teste ou personalizado para inserir seu
próprio subdomínio para produção
Configurações adicionais-parâmetros extras
CNS Tamanho do nó Aceite o tamanho do nó padrão ou selecione alterar

tamanho para selecionar um novo tamanho de VM
Insira seu subdomínio personalizado O domínio de roteamento personalizado a ser usado para
expor aplicativos por meio do roteador no cluster OpenShift.
Certifique-se de criar a entrada DNS de curinga apropriada]
Resumo
A validação ocorre neste estágio para verificar se a cota de núcleo é suficiente para implantar o número total de
VMs selecionadas para o cluster. Examine todos os parâmetros que foram inseridos. Se as entradas forem
aceitáveis, clique em OK para continuar.
Comprar
Confirme as informações de contato na página comprar e clique em comprar para aceitar os termos de uso e
iniciar a implantação do cluster da plataforma de contêiner do OpenShift.
Conectar-se ao cluster OpenShift
Quando a implantação for concluída, recupere a conexão da seção de saída da implantação. Conecte-se ao
console do OpenShift com seu navegador usando a URL do console do OpenShift . Você também pode SSH
para o host bastião. A seguir está um exemplo em que o nome de usuário do administrador é clusteradmin e o
IP público de bastiões FQDN do DNS é bastiondns4hawllzaavu6g.eastus.cloudapp.azure.com:
$ ssh clusteradmin@bastiondns4hawllzaavu6g.eastus.cloudapp.azure.com
Limpar os recursos
Próximas etapas
Implantar o OpenShift Container Platform ou OKD
no Azure Stack
O OpenShift pser implantado no Azure Stack. Há algumas diferenças importantes entre o Azure e o Azure Stack,
portanto a implantação será um pouco diferentes e os recursos também poderão variar.
Atualmente, o Provedor de Nuvem do Azure não funciona no Azure Stack. Por esse motivo, não será possível
anexar um disco como armazenamento persistente no Azure Stack. Em vez disso, você pode configurar outras
opções de armazenamento, como NFS, iSCSI, GlusterFS, etc. Como alternativa, você pode habilitar o CNS e usar
o GlusterFS para armazenamento persistente. Se o CNS estiver habilitado, serão implantados três nós adicionais
com o armazenamento adicional para uso do GlusterFS.
Você pode usar um dos vários métodos para implantar o OpenShift Container Platform ou OKD no Azure Stack:
Você pode implantar manualmente todos os componentes de infraestrutura necessários do Azure e, em
seguida, seguir a documentação do OpenShift Container Platform ou a documentação do OKD.
Você também pode usar um modelo do Gerenciador de Recursos existente que simplifica a implantação do
cluster do OpenShift Container Platform.
Você também pode usar um modelo do Resource Manager existente que simplifica a implantação do cluster
do OKD.
Se estiver usando o modelo do Resource Manager, selecione o branch apropriado (azurestack-release-3.x). Os
modelos do Azure não funcionarão, pois as versões de API são diferentes entre o Azure e o Azure Stack. A
referência da imagem de RHEL está codificada como uma variável no arquivo azuredeploy.json e precisará ser
alterada para corresponder à sua imagem.
"imageReference": {
"publisher": "Redhat",
"offer": "RHEL-OCP",
"sku": "7-4",
"version": "latest"
}
Para ambas as opções, é necessária uma assinatura do Red Hat. Durante a implantação, a instância Red Hat
Enterprise Linux é registrada na Assinatura do Red Hat e anexada à ID do Pool que contém os direitos para o
OpenShift Container Platform. Certifique-se de que você tenha uma senha, uma ID do Pool e um Nome de
usuário de gerente de Assinatura do Red Hat (RHSM) válidos. Como alternativa, você pode usar uma Chave de
Ativação, ID da Organização e ID do Pool. Você pode verificar essas informações entrando em
https://access.redhat.com.
Pré-requisitos do Azure Stack

Uma imagem de RHEL (OpenShift Container Platform) ou imagem do CentOS (OKD) precisa ser adicionada ao
seu ambiente do Azure Stack para implantar um cluster do OpenShift. Entre em contato com seu administrador
do Azure Stack para adicionar essas imagens. Encontre as instruções aqui:
https://docs.microsoft.com/azure/azure-stack/azure-stack-add-vm-image
https://docs.microsoft.com/azure/azure-stack/azure-stack-marketplace-azure-items
https://docs.microsoft.com/azure/azure-stack/azure-stack-redhat-create-upload-vhd
Implantar usando o modelo do Resource Manager do OpenShift
Container Platform ou do OKD
Para implantar usando o modelo do Gerenciador de Recursos, um arquivo de parâmetros é usado para fornecer
todos os parâmetros de entrada. Para personalizar ainda mais a implantação, bifurque o repositório do GitHub e
altere os itens apropriados.
Tamanho da imagem de RHEL (variável em azuredeploy.json)
Para obter as etapas implantar usando a CLI do Azure, siga a seção apropriada na seção OpenShift Container
Platform ou na seção OKD.
Próximas etapas
Depois de implantar um cluster OpenShift, você pode configurar itens adicionais. Este artigo cobre:
Como configurar o logon único entre o Active Directory do Azure (Azure AD)
Como configurar logs de Azure Monitor para monitorar o OpenShift
Como configurar métricas e logs
Como instalar o Open Service Broker para o Azure (OSBA)
Configurar o Logon Único usando o Azure Active Directory

Para usar o Azure Active Directory para autenticação, primeiro você precisa criar um registro de aplicativo do
Azure AD. Esse processo envolve duas etapas: o registro do aplicativo de criação e configuração de permissões.
Criar o Registro do aplicativo
Essas etapas usam a CLI do Azure para criar o Registro do aplicativo e a GUI (Portal) para definir as permissões.
Para criar o Registro do aplicativo, são necessárias cinco informações:
Nome de exibição: nome de registro do aplicativo (ex: OCPAzureAD)
Home Page: URL do console do OpenShift (por exemplo,
https://masterdns343khhde.westus.cloudapp.azure.com/console )
URI do identificador: URL do console do OpenShift (por exemplo,
https://masterdns343khhde.westus.cloudapp.azure.com/console )
URL de resposta: URL pública mestre e o nome de registro do aplicativo (por exemplo,
https://masterdns343khhde.westus.cloudapp.azure.com/oauth2callback/OCPAzureAD )
Senha: senha de segurança (use uma senha forte)
O exemplo a seguir criará um Registro de aplicativo usando as informações acima:
az ad app create --display-name OCPAzureAD --homepage

https://masterdns343khhde.westus.cloudapp.azure.com/console --reply-urls
https://masterdns343khhde.westus.cloudapp.azure.com/oauth2callback/hwocpadint --identifier-uris
https://masterdns343khhde.westus.cloudapp.azure.com/console --password {Strong Password}
Se o comando for bem-sucedido, você obterá uma saída JSON semelhante a esta:
{
"appId": "12345678-ca3c-427b-9a04-ab12345cd678",
"appPermissions": null,
"availableToOtherTenants": false,
"displayName": "OCPAzureAD",
"homepage": "https://masterdns343khhde.westus.cloudapp.azure.com/console",
"identifierUris": [
"https://masterdns343khhde.westus.cloudapp.azure.com/console"
],
"objectId": "62cd74c9-42bb-4b9f-b2b5-b6ee88991c80",
"objectType": "Application",
"replyUrls": [
"https://masterdns343khhde.westus.cloudapp.azure.com/oauth2callback/OCPAzureAD"
]
}
Anote a propriedade appId retornada do comando para uma etapa posterior.
No portal do Azure:
1. Selecione Azure Active Director y > registro de aplicativo .
2. Pesquise o Registro do seu aplicativo (ex: OCPAzureAD).
3. Nos resultados, clique no Registro do aplicativo.
4. Em Configurações , selecione Permissões necessárias .
5. Em Permissões necessárias , selecione Adicionar .
6. Clique em Etapa 1: selecionar a API e, em seguida, clique em Microsoft Azure Active Director y
(Microsoft.Azure.ActiveDirector y) . Na parte inferior, selecione Selecionar .
7. Na Etapa 2: selecionar as permissões, selecione Entrar e ler o perfil do usuário em Permissões

delegadas e clique em Selecionar .
8. Selecione Concluído .
Configurar o OpenShift para autenticação do Azure AD
Para configurar o OpenShift para usar o Azure AD como um provedor de autenticação, o arquivo
/etc/origin/master/master-config.yaml precisa ser editado em todos os nós mestres.
A Id do locatário pode ser encontrada usando o seguinte comando da CLI:
az account show
No arquivo yaml, localize as seguintes linhas:

oauthConfig:
assetPublicURL: https://masterdns343khhde.westus.cloudapp.azure.com/console/
grantConfig:
method: auto
identityProviders:
- challenge: true
login: true
mappingMethod: claim
name: htpasswd_auth
provider:
apiVersion: v1
file: /etc/origin/master/htpasswd
kind: HTPasswdPasswordIdentityProvider
Insira as seguintes linhas imediatamente após as linhas acima:
- name: <App Registration Name>

challenge: false
login: true
mappingMethod: claim
provider:
apiVersion: v1
kind: OpenIDIdentityProvider
clientID: <appId>
clientSecret: <Strong Password>
claims:
id:
- sub
preferredUsername:
- unique_name
name:
- name
email:
- email
urls:
authorize: https://login.microsoftonline.com/<tenant Id>/oauth2/authorize
token: https://login.microsoftonline.com/<tenant Id>/oauth2/token
Certifique-se de que o texto esteja alinhado corretamente em identityProviders. A Id do locatário pode ser
encontrada usando o seguinte comando da CLI: az account show
Reinicie os serviços do OpenShift Master em todos os nós mestres:
sudo /usr/local/bin/master-restart api

sudo /usr/local/bin/master-restart controllers
No Console do OpenShift, agora você verá duas opções para autenticação – htpasswd_auth e [Registro de
Aplicativo].
Monitorar OpenShift com logs de Azure Monitor

Existem três maneiras de adicionar o agente do Log Analytics ao OpenShift.
Instale o agente do Log Analytics para Linux diretamente em cada nó do OpenShift
Habilitar Azure Monitor extensão de VM em cada nó do OpenShift
Instalar o agente de Log Analytics como um OpenShift daemon-Set
Leia as instruções completas para obter mais detalhes.
Configurar métricas e logs
Com base na ramificação, os modelos do Azure Resource Manager para OpenShift Container Platform e OKD
podem fornecer parâmetros de entrada para permitir métricas e registro como parte da instalação.
A oferta do OpenShift Container Platform Marketplace também oferece uma opção para ativar as métricas e o
registro em log durante a instalação do cluster.
Se as métricas / registros não foram ativados durante a instalação do cluster, eles podem ser facilmente ativados
após o fato.
Azure Cloud Provider em uso
SSH para o bastião ou primeiro nó mestre (com base no modelo e na ramificação em uso) usando as
credenciais fornecidas durante a implementação. Emita o seguinte comando:
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml \
-e openshift_metrics_install_metrics=True \
-e openshift_metrics_cassandra_storage_type=dynamic
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml \
-e openshift_logging_install_logging=True \
-e openshift_logging_es_pvc_dynamic=true
Azure Cloud Provider não usado
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openshift-metrics/config.yml \
-e openshift_metrics_install_metrics=True
ansible-playbook /usr/share/ansible/openshift-ansible/playbooks/openshift-logging/config.yml \
-e openshift_logging_install_logging=True
Instalar o Service Broker para o Azure (OSBA)

O Open Service Broker para Azure, ou OSBA, permite provisionar os Serviços de Nuvem do Azure diretamente
do OpenShift. OSBA em uma implementação da API do Open Service Broker para o Azure. A API do Open
Service Broker é uma especificação que define um idioma comum para provedores de nuvem que os aplicativos
nativos da nuvem podem usar para gerenciar serviços de nuvem sem bloqueio.
Para instalar o OSBA no OpenShift, siga as instruções localizadas aqui: https://github.com/Azure/open-service-
broker-azure#openshift-project-template.
NOTE
Conclua apenas as etapas na seção modelo de projeto OpenShift e não na seção instalação inteira.
Próximas etapas
Solucionar problemas de implantação da
plataforma de contêiner do OpenShift 3,11 no Azure
Se o cluster do OpenShift não for implantado com êxito, o portal do Azure fornecerá a saída de erro. A saída
pode ser difícil de ler, o que dificulta a identificação do problema. Examine rapidamente essa saída para o código
de saída 3, 4 ou 5. A seguir, informações sobre esses três códigos de saída:
Código de Saída 3: Nome/senha de usuário de assinatura do Red Hat ou ID/chave de ativação estão
incorretos
Código de Saída 4: a ID do Pool do Red Hat está incorreta ou não há direitos disponíveis
Código de Saída 5: não foi possível provisionar o Volume do pool dinâmico do Docker
Para todos os outros códigos de saída, conecte-se ao (s) host (s) via ssh para visualizar os arquivos de log.
SSH para o host ansioso playbook. Para o modelo ou a oferta do Marketplace, use o host de bastiões. Do
bastião, você pode SSH para todos os outros nós no cluster (mestre, infra, CNS, compute). Você precisará ser
root para visualizar os arquivos de log. A raiz está desativada para o acesso SSH por padrão, portanto, não use
root para SSH em outros nós.
OKD
SSH para o host ansioso playbook. Para o modelo OLD (versão 3.9 e anterior), use o host master-0. Para o
modelo OLD (versão 3.10 e posterior), use o host de bastiões. Do ansible playbook host, você pode SSH para
todos os outros nós no cluster (mestre, infra, CNS, compute). Você precisará ser root (sudo su -) para visualizar
os arquivos de log. A raiz está desativada para o acesso SSH por padrão, portanto, não use root para SSH em
outros nós.
Arquivos de log
Os arquivos de log (stderr e stdout) para os scripts de preparação do host estão localizados em
/var/lib/waagent/custom-script/download/0 em todos os hosts. Se ocorreu um erro durante a preparação do
host, exiba esses arquivos de log para determinar o erro.
Se os scripts de preparação forem executados com êxito, os arquivos de log no
/var/lib/waagent/custom-script/download/1 diretório do host do guia estratégico Ansible precisarão ser
examinados. Se o erro ocorreu durante a instalação real do OpenShift, o arquivo stdout exibirá o erro. Use estas
informações para entrar em contato com o Suporte para obter mais assistência.
Saída de exemplo
TASK [openshift_storage_glusterfs : Load heketi topology] **********************
fatal: [mycluster-master-0]: FAILED! => {"changed": true, "cmd": ["oc", "--config=/tmp/openshift-glusterfs-
ansible-IbhnUM/admin.kubeconfig", "rsh", "--namespace=glusterfs", "deploy-heketi-storage-1-d9xl5", "heketi-
cli", "-s", "http://localhost:8080", "--user", "admin", "--secret",
"VuoJURT0/96E42Vv8+XHfsFpSS8R20rH1OiMs3OqARQ=", "topology", "load", "--json=/tmp/openshift-glusterfs-
ansible-IbhnUM/topology.json", "2>&1"], "delta": "0:00:21.477831", "end": "2018-05-20 02:49:11.912899",
"failed": true, "failed_when_result": true, "rc": 0, "start": "2018-05-20 02:48:50.435068", "stderr": "",
"stderr_lines": [], "stdout": "Creating cluster ... ID: 794b285745b1c5d7089e1c5729ec7cd2\n\tAllowing file
volumes on cluster.\n\tAllowing block volumes on cluster.\n\tCreating node mycluster-cns-0 ... ID:
45f1a3bfc20a4196e59ebb567e0e02b4\n\t\tAdding device /dev/sdd ... OK\n\t\tAdding device /dev/sde ...
OK\n\t\tAdding device /dev/sdf ... OK\n\tCreating node mycluster-cns-1 ... ID:
596f80d7bbd78a1ea548930f23135131\n\t\tAdding device /dev/sdc ... Unable to add device: Unable to execute
command on glusterfs-storage-4zc42: Device /dev/sdc excluded by a filter.\n\t\tAdding device /dev/sde ...
OK\n\t\tAdding device /dev/sdd ... OK\n\tCreating node mycluster-cns-2 ... ID:
42c0170aa2799559747622acceba2e3f\n\t\tAdding device /dev/sde ... OK\n\t\tAdding device /dev/sdf ...
OK\n\t\tAdding device /dev/sdd ... OK", "stdout_lines": ["Creating cluster ... ID:
794b285745b1c5d7089e1c5729ec7cd2", "\tAllowing file volumes on cluster.", "\tAllowing block volumes on
cluster.", "\tCreating node mycluster-cns-0 ... ID: 45f1a3bfc20a4196e59ebb567e0e02b4", "\t\tAdding device
/dev/sdd ... OK", "\t\tAdding device /dev/sde ... OK", "\t\tAdding device /dev/sdf ... OK", "\tCreating node
mycluster-cns-1 ... ID: 596f80d7bbd78a1ea548930f23135131", "\t\tAdding device /dev/sdc ... Unable to add
device: Unable to execute command on glusterfs-storage-4zc42: Device /dev/sdc excluded by a filter.",
"\t\tAdding device /dev/sde ... OK", "\t\tAdding device /dev/sdd ... OK", "\tCreating node mycluster-cns-2
... ID: 42c0170aa2799559747622acceba2e3f", "\t\tAdding device /dev/sde ... OK", "\t\tAdding device /dev/sdf
... OK", "\t\tAdding device /dev/sdd ... OK"]}
PLAY RECAP *********************************************************************

mycluster-cns-0 : ok=146 changed=57 unreachable=0 failed=0
mycluster-infra-0 : ok=143 changed=55 unreachable=0 failed=0
mycluster-master-0 : ok=502 changed=198 unreachable=0 failed=1
mycluster-node-0 : ok=143 changed=55 unreachable=0 failed=0
mycluster-node-1 : ok=143 changed=55 unreachable=0 failed=0
localhost : ok=13 changed=0 unreachable=0 failed=0
INSTALLER STATUS ***************************************************************

Initialization : Complete (0:00:39)
Health Check : Complete (0:00:24)
etcd Install : Complete (0:01:24)
Master Install : Complete (0:14:59)
Master Additional Install : Complete (0:01:10)
Node Install : Complete (0:10:58)
GlusterFS Install : In Progress (0:03:33)
This phase can be restarted by running: playbooks/openshift-glusterfs/config.yml
Failure summary:
1. Hosts: mycluster-master-0
Play: Configure GlusterFS
Task: Load heketi topology
Message: Failed without returning a message.
Os erros mais comuns durante a instalação são:

1. Chave privada tem a frase secreta
2. O segredo do cofre da chave com chave privada não foi criado corretamente
3. As credenciais do principal de serviço foram inseridas incorretamente
4. A entidade de serviço não tem acesso de contribuidor ao grupo de recursos
Chave privada tem uma senha
Você verá um erro de que a permissão foi negada para SSH. SSH para o host do manual do Ansible para
verificar uma frase secreta na chave privada.
O segredo do cofre da chave com chave privada não foi criado corretamente
A chave privada é copiada para o host do guia estratégico Ansible-~/.ssh/id_rsa. Confirme se este arquivo está
correto. Teste abrindo uma sessão SSH em um dos nós do cluster a partir do ansible host do manual.
As credenciais do principal de serviço foram inseridas incorretamente
Ao fornecer a entrada para o modelo ou a oferta do Marketplace, as informações incorretas foram fornecidas.
Certifique-se de usar o appId (clientId) e a senha (clientSecret) corretos para o principal do serviço. Verifique
emitindo o seguinte comando azure cli.
az login --service-principal -u <client id> -p <client secret> -t <tenant id>
A entidade de serviço não tem acesso de contribuidor ao grupo de recursos

Se o provedor de nuvem do Azure estiver habilitado, o principal de serviço usado deverá ter acesso de
colaborador ao grupo de recursos. Verifique emitindo o seguinte comando azure cli.
az group update -g <openshift resource group> --set tags.sptest=test
Ferramentas adicionais
Para alguns erros, você também pode usar os seguintes comandos para obter mais informações:
1. status de systemctl <service>
2. journalctl -xe
Implantar o OKD no Azure
Você pode usar uma de duas maneiras para implantar o OKD (anteriormente conhecido como Origem do
OpenShift) no Azure:
Você pode implantar manualmente todos os componentes de infraestrutura do Azure necessários e, em
seguida, seguir a documentação do OKD.
Você também pode usar um modelo do Resource Manager existente que simplifica a implantação do cluster
do OKD.
Implantar usando o modelo OLD

Para implantar usando o modelo do Resource Manager, você usa um arquivo de parâmetros para fornecer os
parâmetros de entrada. Para personalizar ainda mais a implantação, bifurque o repositório do GitHub e altere os
itens apropriados.
O modelo OKD tem várias ramificações disponíveis para diferentes versões do OKD. Com base nas suas
necessidades, você pode implantar diretamente do repositório ou pode bifurcar o repositório e fazer alterações
personalizadas antes da implantação.
Use o valor appId da entidade de serviço que você criou anteriormente para o parâmetro aadClientId .
A seguir, um exemplo de um arquivo de parâmetros chamado azuredeploy.parameters.json com todas as
entradas necessárias.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"parameters": {
"masterVmSize": {
},
"infraVmSize": {
},
"nodeVmSize": {
},
"storageKind": {
"value": "managed"
},
"openshiftClusterPrefix": {
"value": "mycluster"
},
"masterInstanceCount": {
"value": 3
},
"infraInstanceCount": {
"value": 2
},
},
"nodeInstanceCount": {
"value": 2
},
"dataDiskSize": {
"value": 128
},
"adminUsername": {
"value": "clusteradmin"
},
"openshiftPassword": {
"value": "{Strong Password}"
},
"sshPublicKey": {
"value": "{SSH Public Key}"
},
"enableMetrics": {
"value": "true"
},
"enableLogging": {
"value": "false"
},
"keyVaultResourceGroup": {
"value": "keyvaultrg"
},
"keyVaultName": {
"value": "keyvault"
},
"keyVaultSecret": {
"value": "keysecret"
},
"enableAzure": {
"value": "true"
},
"aadClientId": {
"value": "11111111-abcd-1234-efgh-111111111111"
},
"aadClientSecret": {
"value": "{Strong Password}"
},
"defaultSubDomainType": {
"value": "nipio"
}
}
}
Substitua os parâmetros por suas informações específicas.

Versões diferentes podem ter parâmetros diferentes, portanto, verifique os parâmetros necessários para o ramo
que você usa.
Implantar usando a CLI do Azure
NOTE
O comando a seguir requer a CLI do Azure 2.0.8 ou posterior. Você pode verificar a versão CLI com o comando
az --version . Para atualizar a versão da CLI, consulte Instalar o Azure CLI.
O exemplo a seguir implanta o cluster OKD e todos os recursos relacionados em um grupo de recursos
denominado openshiftrg, com um nome de implantação myOpenShiftCluster. O modelo é referenciado
diretamente no repositório do GitHub ao usar um arquivo de parâmetros local chamado
azuredeploy.parameters.json.
az deployment group create -g openshiftrg --name myOpenShiftCluster \
--template-uri https://raw.githubusercontent.com/Microsoft/openshift-origin/master/azuredeploy.json \
--parameters @./azuredeploy.parameters.json
A implantação leva pelo menos 30 minutos para ser concluída, com base no número total de nós implantados. A
URL do console openShift e o nome DNS do mestre OpenShift são impressas no terminal quando a
implantação é concluída. Como alternativa, você pode exibir a seção de saídas da implantação no portal do
Azure.
{
"OpenShift Console Url": "http://openshiftlb.cloudapp.azure.com/console",
"OpenShift Master SSH": "ssh -p 2200 clusteradmin@myopenshiftmaster.cloudapp.azure.com"
}
Se você não quiser amarrar a linha de comando esperando a conclusão da implementação, inclua --no-wait
como uma das opções para a implementação do grupo. A saída da implantação pode ser recuperada do portal
do Azure na seção de implantação do grupo de recursos.
Conectar-se ao cluster do OKD

Quando a implementação terminar, conecte-se ao console do OpenShift com seu navegador usando o
OpenShift Console Url . Como alternativa, você pode SSH para o mestre de OKD. A seguir, um exemplo que usa
a saída da implementação:
$ ssh -p 2200 clusteradmin@myopenshiftmaster.cloudapp.azure.com
Limpar os recursos
Próximas etapas
Solução de problemas de implantação do OpenShift
Introdução ao OKD
Usar o Azure para hospedar e executar cenários de
carga de trabalho do SAP
Quando você usa o Microsoft Azure, pode executar de modo confiável seus cenários e cargas de trabalho
críticas do SAP em uma plataforma escalonável, em conformidade e de eficácia comprovada na empresa. Você
obtém a escalabilidade, a flexibilidade e a economia de custos do Azure. Com a parceria expandida entre a
Microsoft e a SAP, você pode executar aplicativos da SAP entre cenários de desenvolvimento e teste e produção
no Azure, com suporte total. Do SAP NetWeaver ao SAP S/4HANA, do SAP BI no Linux para Windows e do SAP
HANA para SQL, nós atendemos às suas necessidades.
Além de hospedar cenários do SAP NetWeaver com os diferentes DBMS no Azure, você pode hospedar outros
cenários de carga de trabalho do SAP, assim como SAP BI no Azure.
A exclusividade do Azure para SAP HANA é uma oferta exclusiva que diferencia o Azure. Para habilitar a
hospedagem de mais cenários SAP que exigem recursos de memória e CPU que envolvem SAP HANA, o Azure
oferece o uso de hardware bare-metal dedicado ao cliente. Use esta solução para executar implantações do SAP
HANA que exigem até 24 TB (expansão de 120 TB) de memória para S/4HANA ou outra carga de trabalho do
SAP HANA.
A hospedagem de cenários de carga de trabalho do SAP no Azure também pode criar requisitos de integração
de identidade e logon único. Essa situação pode ocorrer quando você usa o Azure AD (Azure Active Directory)
para conectar diferentes componentes SAP e ofertas de SaaS (software como serviço) ou PaaS (plataforma
como serviço) do SAP. Uma lista desses cenários de integração e logon único com o Azure AD e as entidades do
SAP é descrita e documentada na seção "integração de identidade do SAP do Azure AD e logon único".
Alterações à seção de carga de trabalho do SAP

Alterações a documentos na seção de carga de trabalho do SAP no Azure estão listadas no final deste artigo. As
entradas no log de alterações são mantidas por cerca de 180 dias.
Você quer saber

Se você tem tiver perguntas específicas, vamos encaminhá-lo a documentos ou fluxos específicos nesta seção
da página inicial. Você quer saber:
Quais VMs do Azure e as unidades de Instância Grande do HANA têm suporte para as versões de software
SAP e quais versões do sistema operacional. Leia o documento Qual software SAP tem suporte para a
implantação do Azure para obter respostas e o processo para encontrar as informações
Quais cenários de implantação do SAP têm suporte com VMs do Azure e Instâncias Grandes do HANA. As
informações sobre os cenários com suporte podem ser encontradas nos documentos:
Carga de trabalho do SAP em cenários compatíveis com a máquina virtual do Azure
Cenários com suporte para Instâncias Grandes do HANA
Quais Serviços do Azure, tipos de VM do Azure e serviços de armazenamento do Azure estão disponíveis nas
diferentes regiões do Azure, confira o site Produtos disponíveis por região
Os quadros de HA de terceiros funcionam, além do Windows e do pacemaker, com suporte? Verifique a
parte inferior da Nota de suporte da SAP #1928533
Qual armazenamento do Azure é melhor para o meu cenário? Ler tipos de armazenamento do Azure para
carga de trabalho do SAP
O kernel Red Hat no Oracle Enterprise Linux é compatível com o SAP? Leia #1565179 de observação de
suporte do SAP SAP
Por que as famílias de VMs de ea (s) v4 NS(s) do Azure / não são certificadas para SAP Hana? As famílias de
VM do Azure das/EAS são baseadas em hardware controlado por processador AMD. SAP HANA não dá
suporte a processadores AMD, nem mesmo em cenários virtualizados
Por que ainda estou recebendo a mensagem: ' os sinalizadores de CPU para a instrução RDTSCP ou os
sinalizadores de CPU para constant_tsc ou nonstop_tsc não estão definidos ou current_clocksource e
available_clocksource não estão configurados corretamente ' com SAP HANA, apesar do fato de que estou
executando os kernels Linux mais recentes. Para a resposta, verifique a Nota de suporte SAP #2791572
Onde posso encontrar arquiteturas para implantar o SAP Fiori no Azure? Confira o blog SAP no Azure:
instalação do firewall do aplicativo Web do gateway de aplicativo (WAF) V2 para aplicativos SAP Fiori para a
Internet
SAP HANA no Azure (Instâncias Grandes)

Uma série de documentos leva você por meio do SAP HANA no Azure (instâncias grandes) ou, para abreviar, em
Instâncias Grandes do HANA. Para obter informações sobre Instâncias Grandes do HANA, comece com o
documento Visão geral e arquitetura do SAP HANA no Azure (Instâncias Grandes) e percorra a documentação
relacionada na seção Instância Grande do HANA
SAP HANA em máquinas virtuais do Azure

Esta seção da documentação aborda diferentes aspectos do SAP HANA. Como pré-requisito, você deve estar
familiarizado com os principais serviços do Azure que fornecem serviços elementares de IaaS do Azure.
Portanto, você precisa de conhecimento da computação, do armazenamento e da rede do Azure. Muitos desses
assuntos são tratados no Guia de planejamento do Azure relacionado ao SAP NetWeaver.
SAP NetWeaver implantado em máquinas virtuais do Azure

Esta seção lista a documentação de planejamento e implantação do SAP NetWeaver, SAP LaMa e Business One
no Azure. A documentação se concentra nas noções básicas e no uso de bancos de dados não HANA com uma
carga de trabalho do SAP no Azure. Os documentos e artigos para alta disponibilidade também são a base para
SAP HANA alta disponibilidade no Azure
Alta disponibilidade do SAP NetWeaver e do S/4HANA

A alta disponibilidade da camada de aplicativo SAP e do DBMS está documentada nos detalhes a partir do
documento alta disponibilidade de máquinas virtuais do Azure para SAP NetWeaver
Integrar o Azure AD com os serviços SAP

Nesta seção, você pode encontrar informações sobre como configurar o SSO com a maioria dos serviços de
PaaS e SAP SaaS, NetWeaver e Fiori
Documentação sobre a integração dos serviços do Azure em

componentes SAP
Nesta seção, você encontrará documentos sobre a integração do Microsoft Power BI em fontes de dados SAP,
bem como Azure Data Factory integração ao SAP BW.
Log de Alterações
02/11/2021: alterações na alta disponibilidade do IBM DB2 LUW em VMs do Azure no Red Hat Enterprise
Linux Server para corrigir comandos de cluster pacemaker para RHEL 8. x
02/03/2021: alteração na configuração de pacemaker no RHEL no Azure para atualizar pcmk_host_map no
comando stonith Create
02/03/2021: alteração na configuração de pacemaker no SLES no Azure para adicionar pcmk_host_map no
comando stonith Create
02/03/2021: mais detalhes sobre as configurações do Agendador de e/s para o SUSE no artigo SAP Hana
configurações de armazenamento de máquina virtual do Azure
02/01/2021: alteração na ha para SAP Hana escalar verticalmente com seja no RHEL, SAP Hana escalar
horizontalmente HSR com pacemaker em VMs do Azure no RHEL, SAP Hana escalar horizontalmente com o
nó em espera em VMs do Azure com seja no SLES e SAP Hana escalar horizontalmente com o nó em espera
em VMs do Azure com seja no RHEL para adicionar um link aos volumes NFS v 4.1 em Azure NetApp Files
para SAP Hana
01/23/2021: apresente a funcionalidade do particionamento de volume de dados do HANA como
funcionalidade para distribuir operações de e/s em arquivos de dados do HANA em diferentes discos do
Azure ou compartilhamentos NFS sem usar um Gerenciador de volumes de disco em artigos SAP Hana
configurações de armazenamento de máquina virtual do Azure e volumes NFS v 4.1 no Azure NetApp Files
para SAP Hana
01/18/2021: suporte adicional de arquivos do Azure net apps baseado em NFS para Oracle em máquinas
virtuais do Azure implantação do Oracle DBMS para carga de trabalho do SAP e ajuste de decimais na tabela
em documentos NFS v 4.1 volumes em Azure NetApp Files para SAP Hana
01/11/2021: alterações secundárias na ha para SAP NW em VMs do Azure no RHEL for SAP Applications, ha
for SAP NW em VMs do Azure no RHEL com seja e ha para SAP NW em VMs do Azure no guia de vários SID
do RHEL para ajustar comandos para funcionar tanto para RHEL8 quanto para RHEL7, ENSA1 quanto ENSA2
01/05/2021: alterações no SAP Hana escalar horizontalmente com o nó em espera em VMs do Azure com
seja no SLES e SAP Hana escalar horizontalmente com o nó em espera em VMs do Azure com seja no RHEL,
revisando a configuração recomendada para permitir que o agente de host do SAP gerencie o intervalo de
portas locais
01/04/2021: adicionar novas regiões do Azure com suporte do HLI em o que é SAP Hana no Azure
(instâncias grandes)
12/29/2020: Adicionar recomendações de arquitetura para regiões específicas do Azure em configurações
de carga de trabalho do SAP com zonas de disponibilidade do Azure
12/21/2020: adicionar novas certificações a SKUs de instâncias grandes HANA em SKUs disponíveis para o
HLI
12/12/2020: ponteiro adicionado à nota SAP esclarecendo detalhes sobre o suporte do Oracle Enterprise
Linux pela SAP ao que há suporte para o software SAP para implantações do Azure
11/26/2020: adaptar SAP Hana configurações de armazenamento de máquina virtual do Azure e tipos de
armazenamento do Azure para carga de trabalho SAP para SLAs de VM única alterados
11/05/2020: alterando o link para a nova observação SAP sobre os tipos de sistema de arquivos com
suporte do HANA em SAP Hana configurações de armazenamento de máquina virtual do Azure
10/26/2020: alterando algumas tabelas para a configuração de armazenamento Premium do Azure para
esclarecer o provisionamento versus taxa de transferência de intermitência em SAP Hana configurações de
armazenamento de máquina virtual do Azure
10/22/2020: alteração na ha para SAP NW em VMs do Azure no SLES para aplicativos SAP, ha para SAP NW
em VMs do Azure no SLES com seja, ha para SAP NW em VMs do Azure no RHEL for SAP Applications e ha
para SAP NW em VMs do Azure no RHEL com seja para ajustar a recomendação para
net.IPv4.tcp_keepalive_time
10/16/2020: alteração na ha do IBM DB2 LUW em VMs do Azure no SLES com pacemaker, ha para SAP NW
em VMs do Azure no RHEL for SAP Applications, ha do IBM DB2 LUW em VMs do Azure no RHEL, ha para
SAP NW em VMs do Azure no RHEL multi-Sid, ha para SAP NW em VMs do Azure no RHEL com seja, ha para
SAP NW em VMs do Azure no SLES para aplicativos SAP, ha para SAP NNW em VMs do Azure no guia de
vários SID do SLES, ha para SAP NW em VMs do Azure no SLES com seja para aplicativos SAP, ha para NFS
em VMs doAzure em SLES, ha de SAP Hana em VMs do Azure no SLES, ha para SAP Hana escalar
verticalmente com seja no RHEL , Ha de SAP Hana em VMs do Azure no RHEL, SAP Hana escalar
horizontalmente HSR com pacemaker em VMs do Azure no RHEL, Prepare a infraestrutura do Azure para o
SAP ASCS/SCS com WSFC e disco compartilhado, Guia de alta disponibilidade multisid para SAP ASCS/SCS
com WSFC e disco compartilhado do Azure e Guia de alta disponibilidade de multisid para SAP ASCS/SCS
com WSFC e disco compartilhado para adicionar uma instrução que o IP flutuante não tem suporte em
cenários
10/16/2020: adicionando documentação para controlar instantâneos de armazenamento de instâncias
grandes do HANA no backup e na restauração de SAP Hana em instâncias grandes do Hana
10/15/2020: lançamento da plataforma de BI SAP BusinessObjects na documentação do Azure, Guia de
planejamento e implementação da plataforma de BI do SAP BusinessObjects no Azure e Guia de implantação
da plataforma BI do SAP BusinessObjects para Linux no Azure
10/05/2020: versão de SAP Hana escalar horizontalmente HSR com pacemaker no guia de configuração de
VMs do Azure no RHEL
09/30/2020: alterar a alta disponibilidade de SAP Hana em VMs do Azure no RHEL, ha para SAP Hana escalar
verticalmente com seja no RHEL e Configurando o pacemaker no RHEL no Azure para adaptar as instruções
para RHEL 8,1
09/29/2020: fazendo restrições e recomendações sobre o uso de PPG mais óbvio no artigo grupos de
posicionamento de proximidade do Azure para latência de rede ideal com aplicativos SAP
09/28/2020: adicionando um novo guia de operação de armazenamento para SAP HANA usando Azure
NetApp Files com os volumes do documento NFS v 4.1 no Azure NetApp Files para SAP Hana
09/23/2020: adicionar novos SKUs certificados para o HLI em SKUs disponíveis para o HLI
09/20/2020: alterações em documentos Considerações sobre implantação de DBMS de máquinas virtuais do
Azure para carga de trabalho do SAP, SQL Server implantação de DBMS de máquinas virtuais do Azure para
SAP NetWeaver, implantação de máquinas virtuais do Azure Oracle DBMS para a carga de trabalhodo SAP,
implantação de DBMS de máquinas virtuais do Azure DB2 para carga de trabalho do SAP em diferentes
discos do Azure. Além disso, adicionar recomendações de ultra Disk aos diferentes guias.
09/08/2020: alteração na alta disponibilidade de SAP Hana em VMs do Azure no SLES para esclarecer as
definições de stonith
09/03/2020: alterar em SAP Hana configurações de armazenamento de máquina virtual do Azure para
adaptar-se ao mínimo de 2 IOPS por capacidade de 1 GB com ultra Disk
09/02/2020: alteração nos SKUs disponíveis para o HLI para obter mais transparência em quais SKUs são
certificados pelo Hana
25 de agosto de 2020: alteração na ha para SAP NW em VMs do Azure no SLES com seja para corrigir erros
de digitação
25 de agosto de 2020: alteração no Guia de ha para SAP ASCS/SCS com WSFC e disco compartilhado,
Prepare a infraestrutura do Azure para SAP ASCS/SCS com WSFC e disco compartilhado e Instale o SAP NW
ha com o WSFC e o disco compartilhado para apresentar a opção de usar o disco compartilhado do Azure e
documentar a arquitetura SAP ERS2
25 de agosto de 2020: lançamento do Guia de alta disponibilidade de vários SIDs para SAP ASCS/SCS com
WSFC e disco compartilhado do Azure
25 de agosto de 2020: alteração no Guia de ha para SAP ASCS/SCS com WSFC e Azure NetApp Files (SMB),
preparar a infraestrutura do Azure para SAP ASCS/SCS com WSFC e compartilhamento de arquivos, Guia de
alta disponibilidade multisid para SAP ASCS/SCS com WSFC e disco compartilhado e Guia de alta
disponibilidade multisid para SAP ASCS/SCS com compartilhamento de arquivos WSFC e SOFS como
resultado das atualizações de conteúdo e da reestruturação nos guias de alta disponibilidade para SAP
ASCS/SCS com WFC e disco compartilhado
21 de agosto de 2020: adicionando nova versão do sistema operacional em sistemas operacionais
compatíveis para instâncias grandes do Hana como sistema operacional disponível para unidades de HLI do
tipo I e II
18 de agosto de 2020: versão do ha para SAP Hana escalar verticalmente com seja no RHEL
17 de agosto de 2020: adicionar informações sobre como usar Azure Site Recovery para mover sistemas
SAP NetWeaver do local para o Azure no artigo planejamento e implementação de máquinas virtuais do
Azure para SAP NetWeaver
08/14/2020: adicionando o aviso de configuração de disco para DB2 no artigo implantação de DBMS de
máquinas virtuais do Azure DB2 para carga de trabalho do SAP
11 de agosto de 2020: adicionando RHEL 7,6 a sistemas operacionais compatíveis para instâncias grandes do
Hana como sistema operacional disponível para unidades de HLI do tipo I
10 de agosto de 2020: introdução ao custo SAP HANA configuração de armazenamento em SAP Hana
configurações de armazenamento de máquina virtual do Azure e fazer algumas atualizações nas cargas de
trabalho do SAP no Azure: lista de verificação de planejamento e implantação
4 de agosto de 2020: alterar na configuração do pacemaker no SLES no Azure e Configurar o pacemaker no
RHEL no Azure para enfatizar a importância da resolução de nomes confiáveis para clusters do pacemaker
4 de agosto de 2020: alteração no SAP NW ha no WFCS com compartilhamento de arquivos, SAP NW ha no
WFCS com disco compartilhado, ha para SAP NW em VMs do Azure, ha para SAP NW em VMs do Azure no
SLES, ha para SAP NW em VMs do Azure no SLES com seja, ha para SAP NW em VMs do Azure no guia de
vários SID do SLES, alta disponibilidade para SAP NetWeaver em VMs do Azure no RHEL, ha para SAP NW
em VMs do Azure no RHEL com seja e ha para SAP NW em VMs do Azure no RHEL multi-Sid para esclarecer
o uso do parâmetro enque/encni/set_so_keepalive
23 de julho de 2020: adicionou o artigo salvar em SAP Hana em instâncias grandes com uma reserva do
Azure explicando o que você precisa saber antes de comprar uma reserva de SAP Hana em instâncias
grandes e como fazer a compra
16 de julho de 2020: descrever como usar Azure PowerShell para instalar a nova extensão de VM para SAP
no Guia de implantação
04 de julho de 2020: lançamento do Azure monitor para soluções SAP (versão prévia)
1º de julho de 2020: sugerindo configuração de armazenamento mais barata com base na funcionalidade de
intermitência de armazenamento Premium do Azure no documento SAP Hana configurações de
armazenamento de máquina virtual do Azure
24 de junho de 2020: alterar na configuração de pacemaker no SLES no Azure para liberar o novo agente de
isolamento do Azure aprimorado e uma configuração de STONITH mais resiliente para dispositivos, com
base no agente de limite do Azure
24 de junho de 2020: alterar na configuração do pacemaker no RHEL no Azure para liberar uma
configuração de STONITH mais resiliente
23 de junho de 2020: alterações no planejamento e implementação de máquinas virtuais do Azure para guia
do SAP NetWeaver e introdução de tipos de armazenamento do Azure para guia de carga de trabalho do
SAP
06/22/2020: adicionar etapas de instalação para a nova extensão de VM para SAP no Guia de implantação
16 de junho de 2020: alterar em conectividade de ponto de extremidade pública para VMs usando o ILB
padrão do Azure em cenários de ha do SAP para adicionar um link para a documentação da infraestrutura de
nuvem pública do SUSE 101
10 de junho de 2020: adicionando novas SKUs de HLI em SKUs disponíveis para a arquitetura de
armazenamento de HLI e SAP Hana (instâncias grandes)
21 de maio de 2020: alterar na configuração de pacemaker no SLES no Azure e Configurar o pacemaker no
RHEL no Azure para adicionar um link para conectividade de ponto de extremidade pública para VMs usando
o ILB padrão do Azure em cenários de ha do SAP
19 de maio de 2020: Adicione uma mensagem importante para não usar o grupo de volumes raiz ao usar o
LVM para volumes relacionados ao HANA em SAP Hana configurações de armazenamento de máquina
virtual do Azure
19 de maio de 2020: Adicionar novo sistema operacional com suporte para o HANA grande instância de tipo
II em [sistemas operacionais compatíveis para instâncias grandes do Hana](/- azure/virtual-
machines/workloads/sap/os-compatibility-matrix-hana-large-instance)
12 de maio de 2020: alteração na conectividade de ponto de extremidade pública para VMs usando o ILB
padrão do Azure em cenários de ha do SAP para atualizar links e adicionar informações para configuração de
firewall de terceiros
11 de maio de 2020: alteração na alta disponibilidade de SAP Hana em VMs do Azure no SLES para definir a
adesão de recursos como 0 para o recurso netcat, pois isso leva a um failover mais simplificado
05 de maio de 2020: alterações no planejamento e implementação de máquinas virtuais do Azure para SAP
NetWeaver para expressar que as implantações do Gen2 estão disponíveis para a família de VMs Mv1
24 de abril de 2020: alterações no SAP Hana escalar horizontalmente com o nó em espera em VMs do Azure
com seja no SLES, em SAP Hana escalar horizontalmente com o nó em espera em VMs do Azure com seja no
RHEL, alta disponibilidade para SAP NetWeaver em VMs do Azure no SLES com seja e alta disponibilidade
para o SAP NetWeaver em VMs do Azure no RHEL com seja para adicionar esclarecimento de que os
22 de abril de 2020: alterar em alta disponibilidade de SAP Hana em VMs do Azure no SLES para remover
is-managed o atributo meta das instruções, uma vez que ele entra em conflito ao colocar o cluster dentro ou
fora do modo de manutenção
21 de abril de 2020: adicionado SQL Azure DB como DBMS com suporte para a plataforma de comércio SAP
(Hybris) 1811 e posterior em artigos que software SAP tem suporte para implantações do Azure e as
configurações e certificações do SAP em execução no Microsoft Azure
16 de abril de 2020: adicionado SAP HANA como DBMS com suporte para plataforma de comércio SAP
(Hybris) em artigos o que é compatível com o software SAP para implantações do Azure e as configurações e
certificações do SAP em execução no Microsoft Azure
13 de abril de 2020: corrigir para os números de versão do SAP ASE exatos em implantação de DBMS de
máquinas virtuais do Azure ase SAP para carga de trabalho do SAP
07 de abril de 2020: alterar na configuração do pacemaker no SLES no Azure para esclarecer a Cloud-
netconfig-instruções do Azure
06 de abril de 2020: alterações na SAP Hana escalar horizontalmente com o nó em espera em VMs do Azure
com Azure NetApp files no SLES e no SAP Hana escalar horizontalmente com o nó em espera em VMs do
Azure com Azure NetApp files no RHEL para remover referências a NetApp TR-4435 (substituído por TR-
4746)
31 de março de 2020: alterar em alta disponibilidade de SAP Hana em VMs do Azure no SLES e alta
disponibilidade de SAP Hana em VMs do Azure no RHEL para adicionar instruções sobre como especificar o
tamanho da distribuição ao criar volumes distribuídos
27 de março de 2020: alterar em alta disponibilidade para SAP NW em VMs do Azure no SLES com seja para
aplicativos SAP para alinhar as opções de montagem do sistema de arquivos ao NetApp TR-4746 (remover a
opção de montagem de sincronização)
26 de março de 2020: alterar em alta disponibilidade para SAP NetWeaver em VMs do Azure no guia de
vários SID do SLES para Adicionar referência ao NetApp TR-4746
26 de março de 2020: alterar em alta disponibilidade para SAP NetWeaver em VMs do Azure no SLES para
aplicativos SAP, alta disponibilidade para SAP NetWeaver em VMs do Azure no SLES com Azure NetApp Files
para aplicativos SAP, alta disponibilidade para NFS em VMs do Azure no SLES, alta disponibilidade para SAP
NetWeaver em VMs do Azure no guia de vários SID do RHEL, alta disponibilidade para SAP NetWeaver em
VMs do Azure em RHEL para aplicativos SAP e alta disponibilidade para SAP NetWeaver em VMs do Azure
em RHEL com Azure NetApp Files para aplicações do Microsoft SAP para atualizar diagramas e esclarecer
instruções para a criação de pool de back-end Azure Load Balancer
19 de março de 2020: revisão principal do início rápido do documento: instalação manual de SAP Hana de
instância única em máquinas virtuais do Azure para instalação de SAP Hana em máquinas virtuais do Azure
17 de março de 2020: alterar na configuração de pacemaker em SuSE Linux Enterprise Server no Azure para
remover a configuração de SBD que não é mais necessária
Março de 16 2020: esclarecimento do cenário de certificação de coluna em SAP HANA plataforma certificada
IaaS em qual software SAP tem suporte para implantações do Azure
11/03/2020: alteração a Carga de trabalho do SAP em cenários com suporte de máquina virtual do Azure
para esclarecer vários bancos de dados por suporte de instância de DBMS
11 de março de 2020: alteração no planejamento e implementação de máquinas virtuais do Azure para SAP
NetWeaver explicando VMs de geração 1 e geração 2
10 de março de 2020: alterar em SAP Hana configurações de armazenamento de máquina virtual do Azure
para esclarecer os limites reais de taxa de transferência de seja
09 de março de 2020: alterar em alta disponibilidade para SAP NetWeaver em VMs do Azure em SuSE Linux
Enterprise Server para aplicativos SAP, alta disponibilidade para SAP NetWeaver em VMs do Azure em SuSE
Linux Enterprise Server com Azure NetApp Files para aplicativos SAP, alta disponibilidade para NFS em VMs
do Azure no SUSE Linux Enterprise Server, Configurando o pacemaker no SUSE Linux Enterprise Server no
Azure, alta disponibilidade do IBM DB2 LUW em VMs do azure no SUSE Linux Enterprise Server com
pacemaker, alta disponibilidade de SAP Hana em VMs do Azure no SUSE Linux Enterprise Server e alta
disponibilidade para SAP NetWeaver em VMs do Azure em um guia de vários SID do SLES para atualizar
recursos de cluster com o agente de recursos Azure-lb
5 de março de 2020: alterações de estrutura e alterações de conteúdo para regiões do Azure e máquinas
virtuais do Azure em planejamento e implementação de máquinas virtuais do Azure para SAP NetWeaver
03/03/2020: alteração a Alta disponibilidade para o SAP NW em VMs do Azure no SLES com ANF para
aplicativos SAP para alterar para um layout de volume ANF mais eficiente
1º de março de 2020: Guia de backup retrabalhado para SAP Hana em máquinas virtuais do Azure para
incluir o serviço de backup do Azure. Reduzido e condensado o conteúdo em Backup do Azure do SAP HANA
no nível de arquivo e excluído um terceiro documento que tratava do backup por meio de instantâneo de
disco. O conteúdo é tratado no guia de backup para SAP HANA em máquinas virtuais do Azure
27 de fevereiro de 2020: alterar em alta disponibilidade para o SAP NW em VMs do Azure no SLES para
aplicativos SAP, alta disponibilidade para SAP NW em VMs do Azure no SLES com seja para aplicativos SAP e
alta disponibilidade para SAP NetWeaver em VMs do Azure em clusters de SLES de vários SIDs para ajustar
o parâmetro de cluster "on Fail"
26 de fevereiro de 2020: alterar em SAP Hana configurações de armazenamento de máquina virtual do
Azure para esclarecer a opção do sistema de arquivos para o Hana no Azure
26 de fevereiro de 2020: alterar em arquitetura e cenários de alta disponibilidade para o SAP incluir o link
para a ha para SAP NetWeaver em VMs do Azure no guia de vários SID do RHEL
26 de fevereiro de 2020: alterar em alta disponibilidade para o SAP NW em VMs do Azure no SLES para
aplicativos SAP, alta disponibilidade para SAP NW em VMs do Azure no SLES com seja para aplicativos SAP,
alta disponibilidade de VMs do Azure para SAP NetWeaver no RHEL e a alta disponibilidade de VMs do azure
para SAP NetWeaver no RHEL com Azure NetApp files para remover a instrução que o cluster ASCS/ers de
vários SIDs
26 de fevereiro de 2020: lançamento de alta disponibilidade para SAP NetWeaver em VMs do Azure no guia
de vários SID do RHEL para adicionar um link ao guia de cluster do SUSE multi-Sid
25/02/2020: alteração a Arquitetura e cenários de alta disponibilidade para o SAP para adicionar links para
artigos mais recentes de HA
25 de fevereiro de 2020: alteração em alta disponibilidade do IBM DB2 LUW em VMs do Azure em SuSE
Linux Enterprise Server com pacemaker para apontar para o documento que descreve o acesso ao ponto de
extremidade público com o Azure Load Balancer padrão
21 de fevereiro de 2020: revisão completa do artigo implantação de DBMS de máquinas virtuais do Azure
ase do SAP para carga de trabalho do SAP
21 de fevereiro de 2020: alterar em SAP Hana configuração de armazenamento da máquina virtual do Azure
para representar uma nova recomendação no tamanho da distribuição para/Hana/data e adicionar a
configuração do Agendador de e/s
21 de fevereiro de 2020: alterações em documentos do SAP HANA em instâncias grandes para representar
SKUs recém certificados de S224 e S224m
21 de fevereiro de 2020: alteração em VMs do Azure alta disponibilidade para SAP NetWeaver em RHEL e a
alta disponibilidade de VMs do Azure para SAP NetWeaver no RHEL com Azure NetApp files para ajustar as
restrições de cluster para ENSA2 (arquitetura de replicação de servidor de enfileiramento 2)
20 de fevereiro de 2020: alterar em alta disponibilidade para SAP NetWeaver em VMs do Azure no guia de
vários SID do SLES para adicionar um link ao guia de cluster do SUSE multi-Sid
13 de fevereiro de 2020: alterações no planejamento e implementação de máquinas virtuais do Azure para o
SAP NetWeaver implementar links para novos documentos
13 de fevereiro de 2020: Adicionado novo documento carga de trabalho SAP no cenário com suporte da
máquina virtual do Azure
13 de fevereiro de 2020: Adicionado novo documento que software SAP tem suporte para a implantação do
Azure
13 de fevereiro de 2020: alteração em alta disponibilidade do IBM DB2 LUW em VMs do Azure no Red Hat
Enterprise Linux Server para apontar para o documento que descreve o acesso ao ponto de extremidade
público com o Azure Load Balancer padrão
13 de fevereiro de 2020: adicionar os novos tipos de VM a certificações SAP e configurações em execução no
Microsoft Azure
13 de fevereiro de 2020: adicionar novas notas de suporte SAP cargas de trabalho SAP no Azure: lista de
verificação de planejamento e implantação
13 de fevereiro de 2020: alteração nas VMs do Azure alta disponibilidade para SAP NetWeaver em RHEL e a
alta disponibilidade de VMs do Azure para SAP NetWeaver no RHEL com Azure NetApp files para alinhar os
tempos limite dos recursos de cluster às recomendações de tempo limite do Red Hat
11 de fevereiro de 2020: lançamento de SAP Hana na migração de instância grande do Azure para máquinas
virtuais do Azure
7 de fevereiro de 2020: alteração na conectividade de ponto de extremidade pública para VMs usando o ILB
padrão do Azure em cenários de ha do SAP para atualizar captura de tela de NSG de exemplo
Fevereiro de 03, 2020: alterar em alta disponibilidade para o SAP NW em VMs do Azure no SLES para
aplicativos SAP e alta disponibilidade para SAP NW em VMs do Azure no SLES com seja para aplicativos SAP
para remover o aviso sobre o uso de Dash nos nomes de host de nós de cluster no SLES
28 de janeiro de 2020: alterar em alta disponibilidade de SAP Hana em VMs do Azure no RHEL para alinhar
os SAP Hana de recursos de cluster para as recomendações de tempo limite do Red Hat
17 de janeiro de 2020: alteração nos grupos de posicionamento de proximidade do Azure para latência de
rede ideal com aplicativos SAP para alterar a seção da movimentação de VMs existentes para um grupo de
posicionamento de proximidade
17 de janeiro de 2020: alteração nas configurações de carga de trabalho do SAP com zonas de
disponibilidade do Azure para apontar para um procedimento que automatiza medidas de latência entre
zonas de disponibilidade
16 de janeiro de 2020: alterar em como instalar e configurar SAP Hana (instâncias grandes) no Azure para
adaptar as versões do sistema operacional ao diretório de hardware de IaaS do Hana
16 de janeiro de 2020: alterações em alta disponibilidade para SAP NetWeaver em VMs do Azure no guia de
vários SID do SLES para adicionar instruções para sistemas SAP, usando a arquitetura do enqueue Server 2
(ENSA2)
10 de janeiro de 2020: alterações no SAP Hana escalar horizontalmente com o nó em espera em VMs do
Azure com Azure NetApp files no SLES e no SAP Hana escalar horizontalmente com o nó em espera em VMs
do Azure com Azure NetApp files no RHEL para adicionar instruções sobre como fazer
nfs4_disable_idmapping alterações permanentes.
10 de janeiro de 2020: alterações na alta disponibilidade para SAP NetWeaver em VMs do Azure no SLES
com Azure NetApp Files para aplicativos SAP e em máquinas virtuais do Azure alta disponibilidade para SAP
NetWeaver no RHEL com Azure NetApp Files para aplicativos SAP para adicionar instruções sobre como
montar volumes Azure NetApp files NFSv4.
23 de dezembro de 2019: Lançamento de Alta disponibilidade para SAP NetWeaver em VMs do Azure no
guia de vários SID em SLES
18 de dezembro de 2019: Lançamento de Expansão do SAP HANA com nó em espera em VMs do Azure com
Azure NetApp Files em RHEL
Criar um Banco de Dados Oracle em uma VM do
Azure
Esse guia detalha como usar a CLI do Azure para implantar uma máquina virtual do Azure usando a imagem da
galeria do marketplace da Oracle a fim de criar um banco de dados Oracle 19c. Depois que o servidor for
implantado, conecte-se por meio de SSH para configurar o banco de dados Oracle.
Se você optar por instalar e usar a CLI localmente, este guia de início rápido exigirá a execução da CLI do Azure
versão 2.0.4 ou posterior. Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar,
consulte Instalar a CLI do Azure.

lógico no qual os recursos do Azure são implantados e gerenciados.
O exemplo a seguir cria um grupo de recursos denominado rg-oracle na localização eastus.
az group create --name rg-oracle --location eastus

Para criar uma VM (máquina virtual), use o comando az vm create.
O exemplo a seguir cria uma VM chamada vmoracle19c . Ele também criará chaves SSH, se elas ainda não
existirem em um local de chave padrão. Para usar um conjunto específico de chaves, use a opção
--ssh-key-value .
az vm create ^
--resource-group rg-oracle ^
--name vmoracle19c ^
--image Oracle:oracle-database-19-3:oracle-database-19-0904:latest ^
--size Standard_DS2_v2 ^
--admin-username azureuser ^
--generate-ssh-keys ^
--public-ip-address-allocation static ^
--public-ip-address-dns-name vmoracle19c
Depois de criar a VM, a CLI do Azure exibe informações semelhantes ao exemplo a seguir. Observe o valor de
publicIpAddress . Você pode usar esse endereço para acessar a VM.
{
"fqdns": "",
"id": "/subscriptions/{snip}/resourceGroups/rg-
oracle/providers/Microsoft.Compute/virtualMachines/vmoracle19c",
"macAddress": "00-0D-3A-36-2F-56",
"resourceGroup": "rg-oracle"
}
Criar um disco e anexá-lo a arquivos de dados da Oracle e ao FRA

az vm disk attach --name oradata01 --new --resource-group rg-oracle --size-gb 128 --sku StandardSSD_LRS --
vm-name vmoracle19c
Abrir as portas para conectividade

Nesta tarefa, você precisa configurar alguns pontos de extremidade externos para o ouvinte de banco de dados
e o EM Express a serem usados configurando o Grupo de Segurança de Rede do Azure que protege a VM.
1. Para abrir o ponto de extremidade que você usa para acessar o banco de dados Oracle remotamente, crie
uma regra de Grupo de Segurança de Rede da seguinte maneira:
az network nsg rule create ^

--nsg-name vmoracle19cNSG ^
--name allow-oracle ^
--protocol tcp ^
--priority 1001 ^
2. Para abrir o ponto de extremidade que você usa para acessar o Oracle EM Express remotamente, crie
uma regra de Grupo de Segurança de Rede com az network nsg rule create da seguinte maneira:
az network nsg rule create ^

--nsg-name vmoracle19cNSG ^
--name allow-oracle-EM ^
--protocol tcp ^
--priority 1002 ^
3. Se for necessário, obtenha o endereço IP público de sua VM com az network public-ip show da seguinte
maneira:
az network public-ip show ^

--name vmoracle19cPublicIP ^
--query [ipAddress] ^
--output tsv
Preparar o ambiente da VM
1. Conectar-se à VM
Para criar uma sessão SSH com a VM, use o comando a seguir. Substitua o endereço IP pelo valor
publicIpAddress para a sua VM.
ssh azureuser@<publicIpAddress>
2. Mudar para o usuário raiz
sudo su -
3. Verificar o último dispositivo de disco criado que formataremos para usar a retenção de arquivos de
dados da Oracle
ls -alt /dev/sd*|head -1
A saída será semelhante a:
brw-rw----. 1 root disk 8, 16 Dec 8 22:57 /dev/sdc
4. Formatar o dispositivo. Como o usuário raiz, executar o parted no dispositivo

Primeiro, crie um rótulo de disco:
parted /dev/sdc mklabel gpt
Em seguida, crie uma partição primária abrangendo todo o disco:
parted -a optimal /dev/sdc mkpart primary 0GB 64GB
Por fim, verifique os detalhes do dispositivo imprimindo os metadados dele:
parted /dev/sdc print
A saída deverá ser semelhante ao seguinte:
# parted /dev/sdc print

Model: Msft Virtual Disk (scsi)
Disk /dev/sdc: 68.7GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 64.0GB 64.0GB ext4 primary
5. Criar um sistema de arquivos na partição do dispositivo
mkfs -t ext4 /dev/sdc1
6. Criar um ponto de montagem

mkdir /u02
7. Monte o disco
mount /dev/sdc1 /u02
8. Alterar permissões no ponto de montagem
chmod 777 /u02
9. Adicionar a montagem ao arquivo /etc/fstab.
echo "/dev/sdc1 /u02 ext4 defaults 0 0" >> /etc/fstab
10. Atualizar o arquivo * /etc/hosts _ com o IP público e o nome do host.

Altere o IP público e VMname para refletir seus valores reais:
echo "<Public IP> <VMname>.eastus.cloudapp.azure.com <VMname>" >> /etc/hosts
11. Atualizar o arquivo do nome do host

Use o comando a seguir para adicionar o nome de domínio da VM ao arquivo _ */etc/hostname**. Isso
pressupõe que você criou o grupo de recursos e a VM na região eastus :
sed -i 's/$/\.eastus\.cloudapp\.azure\.com &/' /etc/hostname
12. Abrir portas de firewall

Como o SELinux é habilitado por padrão na imagem do Marketplace, precisamos abrir o firewall para
tráfego para a porta de escuta 1521 do banco de dados e a porta 5502 do Enterprise Manager Express.
Execute os seguintes comandos como usuário raiz:
firewall-cmd --zone=public --add-port=1521/tcp --permanent

firewall-cmd --zone=public --add-port=5502/tcp --permanent
firewall-cmd --reload
Criar o banco de dados

O software Oracle já está instalado na imagem do Marketplace. Crie um banco de dados de exemplo conforme
descrito a seguir.
1. Mude para o usuário oracle :
$ sudo su - oracle
2. Iniciar o ouvinte de banco de dados
$ lsnrctl start
A saída deverá ser semelhante a esta:
LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 20-OCT-2020 01:58:18
Copyright (c) 1991, 2019, Oracle. All rights reserved.
Starting /u01/app/oracle/product/19.0.0/dbhome_1/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 19.0.0.0.0 - Production

Log messages written to /u01/app/oracle/diag/tnslsnr/vmoracle19c/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmoracle19c.eastus.cloudapp.azure.com)
(PORT=1521)))
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date 20-OCT-2020 01:58:18
Uptime 0 days 0 hr. 0 min. 0 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Log File /u01/app/oracle/diag/tnslsnr/vmoracle19c/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=vmoracle19c.eastus.cloudapp.azure.com)(PORT=1521)))
The listener supports no services
The command completed successfully
3. Criar um diretório de dados para os arquivos de dados do Oracle:
mkdir /u02/oradata
4. Execute o Assistente de Criação de Banco de Dados:
dbca -silent \
-createDatabase \
-templateName General_Purpose.dbc \
-gdbname test \
-sid test \
-responseFile NO_VALUE \
-characterSet AL32UTF8 \
-sysPassword OraPasswd1 \
-systemPassword OraPasswd1 \
-createAsContainerDatabase false \
-databaseType MULTIPURPOSE \
-automaticMemoryManagement false \
-storageType FS \
-datafileDestination "/u02/oradata/" \
-ignorePreReqs
A criação do banco de dados demora alguns minutos.

Você verá uma saída com aparência semelhante à seguinte:
Prepare for db operation
10% complete
Copying database files
40% complete
Creating and starting Oracle instance
42% complete
46% complete
50% complete
54% complete
60% complete
Completing Database Creation
66% complete
69% complete
70% complete
Executing Post Configuration Actions
100% complete
Database creation complete. For details check the logfiles at:
/u01/app/oracle/cfgtoollogs/dbca/test.
Database Information:
Global Database Name:test
System Identifier(SID):test
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/test/test.log" for further details.
5. Definir variáveis do Oracle

Antes de se conectar, você precisa definir a variável de ambiente ORACLE_SID:
export ORACLE_SID=test
Você também deve adicionar a variável ORACLE_SID ao arquivo .bashrc dos usuários oracle para
entradas futuras usando o seguinte comando:
echo "export ORACLE_SID=test" >> ~oracle/.bashrc
Conectividade com o Oracle EM Express

Para ter uma ferramenta de gerenciamento de GUI que você pode usar para explorar o banco de dados,
configure o Oracle EM Express. Para se conectar ao Oracle EM Express, a porta deve ser configurada
primeiramente no Oracle.
1. Conecte-se ao seu banco de dados usando sqlplus:
sqlplus sys as sysdba
2. Após a conexão, defina a porta 5502 como EM Express
exec DBMS_XDB_CONFIG.SETHTTPSPORT(5502);
3. Conecte-se ao EM Express pelo navegador. Verifique se o seu navegador é compatível com EM Express (é
necessário ter Flash instalado):
https://<VM ip address or hostname>:5502/em
Você pode fazer logon usando a conta SYS e marcar a caixa de seleção como sysdba . Use a senha
OraPasswd1 que você definiu durante a instalação.
Automatizar a inicialização e o desligamento do banco de dados
Por padrão, o banco de dados Oracle não inicia automaticamente quando você reinicia a VM. Para configurar o
banco de dados Oracle para iniciar automaticamente, primeiro entre como raiz. Em seguida, crie e atualize
alguns arquivos do sistema.
1. Conectar-se como raiz
sudo su -
2. Execute o seguinte comando para alterar o sinalizador de inicialização automática de N para Y no

arquivo /etc/oratab :
sed -i 's/:N/:Y/' /etc/oratab
3. Crie um arquivo chamado /etc/init.d/dbora e cole o seguinte conteúdo:

#!/bin/sh
# chkconfig: 345 99 10
# Description: Oracle auto start-stop script.
#
# Set ORA_HOME to be equivalent to $ORACLE_HOME.
ORA_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
ORA_OWNER=oracle
case "$1" in
'start')
# Start the Oracle databases:
# The following command assumes that the Oracle sign-in
# will not prompt the user for any values.
# Remove "&" if you don't want startup as a background process.
su - $ORA_OWNER -c "$ORA_HOME/bin/dbstart $ORA_HOME" &
touch /var/lock/subsys/dbora
;;
'stop')
# Stop the Oracle databases:
# The following command assumes that the Oracle sign-in
# will not prompt the user for any values.
su - $ORA_OWNER -c "$ORA_HOME/bin/dbshut $ORA_HOME" &
rm -f /var/lock/subsys/dbora
;;
esac
4. Altere as permissões nos arquivos com chmod da seguinte maneira:
chgrp dba /etc/init.d/dbora

chmod 750 /etc/init.d/dbora
5. Crie links simbólicos para inicialização e desligamento, da seguinte maneira:
ln -s /etc/init.d/dbora /etc/rc.d/rc0.d/K01dbora
ln -s /etc/init.d/dbora /etc/rc.d/rc3.d/S99dbora
ln -s /etc/init.d/dbora /etc/rc.d/rc5.d/S99dbora
6. Para testar as alterações, reinicie a VM:
reboot
Limpar os recursos
Depois de terminar de explorar seu primeiro banco de dados Oracle no Azure e a VM não for mais necessária,
você poderá usar o comando az group delete para remover o grupo de recursos, a VM e todos os recursos
relacionados.
Próximas etapas
Saiba como proteger seu banco de dados no Azure com as Estratégias de Backup da Oracle
Saiba mais sobre outras Soluções Oracle no Azure.
Experimente o tutorial Instalar e configurar o Oracle Automated Storage Management.
Instalar o Elastic Stack em uma VM do Azure
Este artigo orienta como implantar Elasticsearch, Logstash e Kibana em uma VM Ubuntu no Azure. Para ver o
Elastic Stack em ação, opcionalmente você pode se conectar ao Kibana e trabalhar com alguns dados de log de
exemplo.
Neste tutorial, você aprenderá a:
Crie uma VM do Ubuntu em um grupo de recursos do Azure
Instale Elasticsearch, Logstash e Kibana na VM
Envie dados de exemplo para Elasticsearch com Logstash
Abra as portas e trabalhe com os dados no console do Kibana
Essa implantação é adequada para desenvolvimento básico com Elastic Stack. Para saber mais sobre Elastic
Stack, incluindo recomendações para um ambiente de produção, consulte a documentação do Elastic e o Azure
Architecture Center.
Pré-requisitos
Use o ambiente Bash no Azure Cloud Shell.
Se preferir, instale a CLI do Azure para executar comandos de referência da CLI.

Se estiver usando uma instalação local, entre com a CLI do Azure usando o comando az login. Para
concluir o processo de autenticação, siga as etapas exibidas no terminal. Para mais opções de
entrada, confira Entrar com a CLI do Azure.
Quando solicitado, instale as extensões da CLI do Azure no primeiro uso. Para obter mais
informações sobre extensões, confira Usar extensões com a CLI do Azure.
Execute az version para localizar a versão e as bibliotecas dependentes que estão instaladas. Para
fazer a atualização para a versão mais recente, execute az upgrade.
Este artigo exige a versão 2.0.4 ou posterior da CLI do Azure. Se você está usando o Azure Cloud Shell, a
versão mais recente já está instalada.

O exemplo a seguir cria um grupo de recursos chamado myResourceGroup no local eastus.

O exemplo a seguir cria uma VM denominada myVM e cria chaves SSH, se elas ainda não existirem em um local
de chave padrão. Para usar um conjunto específico de chaves, use a opção --ssh-key-value .
az vm create \
--name myVM \
--image UbuntuLTS \
--generate-ssh-keys
Quando a VM tiver sido criada, a CLI do Azure mostra informações semelhantes ao exemplo a seguir. Anote
publicIpAddress . Esse endereço é usado para acessar a VM.
{
"fqdns": "",
"id": "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",
"macAddress": "00-0D-3A-23-9A-49",
}
SSH em sua VM
Se você ainda não souber o endereço IP público de sua VM, execute o comando az network public-ip list:
az network public-ip list --resource-group myResourceGroup --query [].ipAddress
Use o seguinte comando para criar uma sessão SSH com a máquina virtual. Substitua o endereço IP público
correto de sua máquina virtual. Neste exemplo, o endereço IP é 40.68.254.142.
Instalar o Elastic Stack

Importe a chave de assinatura Elasticsearch e atualize sua lista de fontes APT para incluir o repositório do pacote
do Elastic:
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

echo "deb https://artifacts.elastic.co/packages/5.x/apt stable main" | sudo tee -a
/etc/apt/sources.list.d/elastic-5.x.list
Instale o Java Virtual na VM e configure a variável JAVA_HOME. Isso é necessário para que os componentes do
Elastic Stack sejam executados.
sudo apt update && sudo apt install openjdk-8-jre-headless

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
Execute os seguintes comandos para atualizar as fontes do pacote e instalar Elasticsearch, Kibana e Logstash.
sudo apt update && sudo apt install elasticsearch kibana logstash
NOTE
Instruções de instalação detalhadas, incluindo layouts de diretório e configuração inicial, são mantidas na documentação
do Elastic
Iniciar Elasticsearch
Inicie o Elasticsearch na sua VM com o seguinte comando:
sudo systemctl start elasticsearch.service
Este comando não produz resultados, portanto verifique se o Elasticsearch está em execução na VM com este
comando curl :
sudo curl -XGET 'localhost:9200/'
Se Elasticsearch estiver em execução, você verá a saída semelhante ao seguinte:
{
"name" : "w6Z4NwR",
"cluster_name" : "elasticsearch",
"cluster_uuid" : "SDzCajBoSK2EkXmHvJVaDQ",
"version" : {
"number" : "5.6.3",
"build_hash" : "1a2f265",
"build_date" : "2017-10-06T20:33:39.012Z",
"build_snapshot" : false,
"lucene_version" : "6.6.1"
},
"tagline" : "You Know, for Search"
}
Iniciar Logstash e adicionar dados ao Elasticsearch

Inicie o Logstash com o seguinte comando:
sudo systemctl start logstash.service
Teste o Logstash no modo interativo para garantir que eles esteja funcionando corretamente:
sudo /usr/share/logstash/bin/logstash -e 'input { stdin { } } output { stdout {} }'
Este é um pipeline do logstash básico que ecoa entrada padrão para saída padrão.
The stdin plugin is now waiting for input:

hello azure
2017-10-11T20:01:08.904Z myVM hello azure
Configure o Logstash para encaminhar mensagens de kernel dessa VM para Elasticsearch. Crie um novo
arquivo em um diretório vazio chamado vm-syslog-logstash.conf e cole a seguinte configuração Logstash:
input {
stdin {
type => "stdin-type"
}
file {
type => "syslog"
path => [ "/var/log/*.log", "/var/log/*/*.log", "/var/log/messages", "/var/log/syslog" ]
start_position => "beginning"
}
}
output {
stdout {
codec => rubydebug
}
elasticsearch {
hosts => "localhost:9200"
}
}
Teste esta configuração e envie os dados do syslog para Elasticsearch:
sudo /usr/share/logstash/bin/logstash -f vm-syslog-logstash.conf
Você pode ver as entradas do syslog em seu terminal ecoadas conforme elas são enviadas para Elasticsearch.
Use CTRL+C para sair do Logstash depois de enviar dados.
Inicie o Kibana e visualize os dados no Elasticsearch

Edite /etc/kibana/kibana.yml e altere o endereço IP que o Kibana escuta para que você pode acessá-lo do seu
navegador da Web.
server.host: "0.0.0.0"
Inicie o Kibana com o seguinte comando:
sudo systemctl start kibana.service
Abra porta 5601 da CLI do Azure para permitir o acesso remoto ao console Kibana:
Abra o console do Kibana e selecione Criar para gerar um índice padrão com base nos dados de syslog
enviados para o Elasticsearch anteriormente.
Selecione Descobrir no console do Kibana para pesquisar, procurar e filtrar os eventos de syslog.
Próximas etapas
Neste tutorial, você implantou o Elastic Stack em uma VM de desenvolvimento no Azure. Você aprendeu a:
Crie uma VM do Ubuntu em um grupo de recursos do Azure
Instale Elasticsearch, Logstash e Kibana na VM
Enviar dados de exemplo para Elasticsearch do Logstash
Abra as portas e trabalhe com os dados no console do Kibana
Hospedagem de mainframe em máquinas virtuais
do Azure
A migração de cargas de trabalho de ambientes de mainframe para a nuvem permite modernizar sua
infraestrutura e, muitas vezes, economizar em custos. Muitas cargas de trabalho podem ser transferidas para o
Azure com apenas pequenas alterações de código, como atualizar os nomes dos bancos de dados.
Em geral, o termo mainframe significa um sistema de computador grande. Especificamente, a grande maioria
atualmente em uso são os servidores IBM System Z ou OS sistemas compatíveis com IBM plug-and-compatible
que executam MVS, DOS, VSE, OS/390 ou Z/OS.
Uma VM (máquina virtual) do Azure é usada para isolar e gerenciar os recursos de um aplicativo específico em
uma única instância do. Mainframes como IBM z/OS usam partições lógicas (LPARs) para essa finalidade. Um
mainframe pode usar um LPAR para uma região CICS com programas COBOL associados e um LPAR separado
para o banco de dados IBM DB2. Um aplicativo típico de n camadas no Azure implanta VMs do Azure em uma
rede virtual que pode ser segmentada em sub-redes para cada camada.
As VMs do Azure podem executar ambientes de emulação de mainframe e compiladores que dão suporte a
cenários de comparação de precisão e deslocamento. O desenvolvimento e o teste geralmente estão entre as
primeiras cargas de trabalho para migrar de um mainframe para um ambiente de desenvolvimento/teste do
Azure. Os componentes comuns do servidor que você pode emular incluem OLTP (processo de transação
online), lote e sistemas de ingestão de dados como mostra a figura a seguir.
Algumas cargas de trabalho de mainframe podem ser migradas para o Azure com uma facilidade relativa,
enquanto outras podem ser rehospedadas no Azure usando uma solução de parceiro. Para obter diretrizes
detalhadas sobre como escolher uma solução de parceiro, o centro de migração de mainframe do Azure pode
ajudar.
Migração de mainframe
Rehospedar, recompilar, substituir ou desativar? IaaS ou PaaS? Para determinar a estratégia de migração certa
para seu aplicativo de mainframe, consulte o guia de migração do mainframe na centro de arquitetura do Azure.
Plataforma de rehospedagem micro Focus

O micro Focus Enterprise Server é uma das maiores plataformas de Hospedagem de mainframes disponíveis.
Você pode usá-lo para executar suas cargas de trabalho do z/OS em uma plataforma x86 menos dispendiosa no
Azure.
Introdução:
Instalar o Enterprise Server e o Enterprise Developer no Azure
Configurar o CICS BankDemo for Enterprise Developer no Azure
Executar o servidor corporativo em um contêiner do Docker no Azure
TmaxSoft OpenFrame no Azure

TmaxSoft OpenFrame é uma popular solução de rehospedagem de mainframe usada em cenários de
comparação de precisão e deslocamento. Um ambiente OpenFrame no Azure é adequado para
desenvolvimento, demonstrações, testes ou cargas de trabalho de produção.
Introdução:
Introdução ao TmaxSoft OpenFrame
Baixe o ebook
IBM zD&T 12,0

O IBM Z Development and Test Environment (IBM zD&T) configura um ambiente de não produção no Azure que
você pode usar para desenvolvimento, teste e demonstrações de aplicativos baseados em Z/OS.
O ambiente de emulação no Azure pode hospedar diferentes tipos de instâncias Z por meio de ADCDs
(distribuições controladas por desenvolvedores de aplicativos). Você pode executar o zD&T Personal Edition, o
zD&T Parallel Sysplex e o zD&T Enterprise Edition no Azure e Azure Stack.
Introdução:
Configurar o IBM zD&T 12,0 no Azure
Configurar ADCD em zD&T
IBM DB2 pureScale no Azure

O ambiente IBM DB2 pureScale fornece um cluster de banco de dados para o Azure. Ele não é idêntico ao
ambiente original, mas oferece disponibilidade e escala semelhantes à medida que o IBM DB2 para z/OS está
sendo executado em uma configuração de sysplex paralelo.
Para começar, consulte IBM DB2 pureScale no Azure.
Considerações
Ao migrar cargas de trabalho de mainframe para o IaaS (infraestrutura como serviço) do Azure, você pode
escolher entre vários tipos de recursos de computação escalonáveis e sob demanda, incluindo VMs do Azure. O
Azure oferece uma variedade de VMs Linux e Windows .
Computação
A potência de computação do Azure se compara favorável à capacidade de um mainframe. Se você estiver
pensando em mover uma carga de trabalho de mainframe para o Azure, compare a métrica de mainframe de 1
milhão instruções por segundo (MIPS) para CPUs virtuais.
Saiba como mover a computação do mainframe para o Azure.
Failover e alta disponibilidade
O Azure oferece SLAs (contratos de nível de serviço) baseados em compromisso. A disponibilidade de vários
noves é o padrão, e os SLAs podem ser otimizados com a replicação local ou baseada em geografia dos
serviços. O SLA completo do Azure explica a disponibilidade garantida do Azure como um todo.
Com o IaaS do Azure, como uma VM, as funções específicas do sistema fornecem suporte a failover — por
exemplo, instâncias de clustering de failover e conjuntos de disponibilidade. Quando você usa recursos de PaaS
(plataforma como serviço) do Azure, a plataforma manipula o failover automaticamente. Os exemplos incluem
banco de dados SQL do Azure e Azure Cosmos DB.
Escalabilidade
Os mainframes normalmente aumentam, enquanto os ambientes de nuvem são expandidos. O Azure oferece
uma variedade de tamanhos do Linux e do Windows para atender às suas necessidades. A nuvem também é
dimensionada para cima ou para baixo para corresponder às especificações exatas do usuário. A capacidade de
computação, o armazenamento e os serviços são dimensionados sob demanda em um modelo de cobrança
baseado em uso.
Armazenamento
Na nuvem, você tem uma variedade de opções de armazenamento flexíveis e escalonáveis e paga apenas pelo
que precisa. O Armazenamento do Azure oferece um armazenamento de objetos altamente escalonável para
objetos de dados, um serviço de sistema de arquivos para a nuvem, armazenamento de mensagens confiáveis e
armazenamento de NoSQL. Para VMs, discos gerenciados e discos não gerenciados fornecem armazenamento
em disco persistente e seguro.
Saiba como mover o armazenamento de mainframe para o Azure.
Backup e recuperação
Manter seu próprio site de recuperação de desastre pode ser uma proposta cara. O Azure tem opções fáceis de
implementar e econômicas para backup, recuperaçãoe redundância em níveis locais ou regionais, ou por meio
de redundância geográfica.
Azure governamental para migrações de mainframe

Muitas entidades do setor público adorariam mover seus aplicativos de mainframe para uma plataforma mais
moderna e flexível. Microsoft Azure Governamental é uma instância fisicamente separada da plataforma global
Microsoft Azure, empacotada para sistemas governamentais federais, estaduais e locais. Ele fornece segurança
de nível mundial, proteção e serviços de conformidade especificamente para Estados Unidos agências
governamentais e seus parceiros.
O Azure governamental ganhou uma autoridade provisória para operar (P-ATO) para um alto impacto
FedRAMP para sistemas que precisam desse tipo de ambiente.
Para começar, baixe Microsoft Azure governamental Cloud para aplicativos de mainframe.
Próximas etapas
Peça aos nossos parceiros para ajudá-lo a migrar ou rehospedar seus aplicativos de mainframe.
Consulte também:
White papers sobre tópicos de mainframe
Migração de mainframe
Desmistificando a migração do mainframe para o Azure
Tamanhos das máquinas virtuais no Azure
Este artigo descreve os tamanhos e as opções disponíveis para as máquinas virtuais do Azure que você pode
usar para executar seus aplicativos e cargas de trabalho. Ele também fornece considerações de implantação a
serem observadas ao planejar o uso desses recursos.
T IP O TA M A N H O S DESC RIÇ Ã O
Propósito geral B, Dsv3, Dv3, Dasv4, Dav4, DSv2, Dv2, Relação equilibrada de CPU/memória.
Av2, DC, DCv2, DV4, Dsv4, Ddv4, Ideal para teste e desenvolvimento,
Ddsv4 bancos de dados pequenos a médios e
servidores Web de tráfego baixo a
médio.
Computação otimizada F, FS, Fsv2 Alta relação de CPU/memória. Boa

para servidores web de tráfego médio,
dispositivos de rede, processos de lote
e servidores de aplicativo.
Memória otimizada Esv3, Ev3, Easv4, Eav4, Ev4, Esv4, Edv4, Alta relação de memória/CPU. Ótima
Edsv4, Mv2, M, DSv2, Dv2 para servidores de banco de dados
relacionais, caches médios a grandes e
análises na memória.
Armazenamento otimizado Lsv2 Taxa de transferência de disco alta e de

E/S são ideais para bancos de dados
Big Data, SQL, NoSQL,
armazenamento de dados e grandes
dados transacionais.
GPU NC, NCv2, NCv3, NCasT4_v3 Máquinas virtuais especializadas

(visualização), ND, NDv2 (versão direcionadas para edição de vídeo e
prévia), NV, NVv3, NVv4 renderização gráfica pesada, assim
como inferência e treinamento do
modelo (ND) com aprendizado
profundo. Disponível com uma ou
várias GPUs.
Computação de alto desempenho HB, HBv2, HC, H Nossas máquinas virtuais de CPU mais
rápidas e potentes com adaptadores
de rede de alta taxa de transferência
(RDMA) opcionais.
Para obter informações sobre os preços de vários tamanhos, consulte as páginas de preços para Linux ou
Windows.
Para ver a disponibilidade de tamanhos de VM nas regiões do Azure, confira Produtos disponíveis por região.
Para ver os limites gerais em VMs do Azure, consulte Limites de assinatura e serviços do Azure, cotas e
restrições.
Para obter mais informações sobre como o Azure nomeia suas VMs, consulte convenções de nomenclatura
de tamanhos de máquina virtual do Azure.
API REST
Para obter informações sobre como usar a API REST para consulta de tamanhos de VM, confira o seguinte:
Listar os tamanhos de máquina virtual disponíveis para redimensionamento
Listar os tamanhos de máquina virtual disponíveis para uma assinatura
Listar os tamanhos de máquina virtual disponíveis em um conjunto de disponibilidade
ACU
Saiba mais sobre como as ACUs (unidade de computação do Azure) podem ajudar você a comparar o
desempenho de computação entre SKUs do Azure.
Pontuações de parâmetro de comparação

Saiba mais sobre desempenho de computação para VMs do Linux usando as pontuações de parâmetro de
comparação CoreMark.
Saiba mais sobre o desempenho de computação para VMs do Windows usando as pontuações de parâmetro de
comparação SPECInt.
Gerenciar os custos
Os serviços do Azure custam dinheiro. O Gerenciamento de Custos do Azure ajuda você a definir orçamentos e
configurar alertas para manter os gastos sob controle. Analise, gerencie e otimize seus custos do Azure com o
Gerenciamento de Custos. Para saber mais, confira o guia de início rápido sobre como analisar seus custos.
Próximas etapas
Saiba mais sobre os diferentes tamanhos de VM que estão disponíveis:
Propósito geral
Computação otimizada
Memória otimizada
Armazenamento otimizado
GPU
Verifique a página Geração anterior para Standard A, Dv1 (D1-4 e D11-14 v1) e série A8-A11
Redimensionar uma máquina virtual do Linux
usando a CLI do Azure
Depois de provisionar uma VM (máquina virtual), é possível escalar ou reduzir verticalmente a VM alterando o
tamanho da VM. Em alguns casos, você deverá desalocar a VM primeiro. Você precisará desalocar a VM se o
tamanho desejado não estiver disponível no cluster de hardware que está hospedando a VM. Este artigo detalha
como redimensionar uma VM Linux com a CLI do Azure.
Para redimensionar uma VM, é preciso ter a CLI do Azure mais recente instalada e conectada a uma conta do
Azure usando az login.
1. Veja a lista de tamanhos de VM disponíveis no cluster de hardware onde a VM está hospedada com az
vm list-vm-resize-options. O exemplo a seguir lista tamanhos de VM para a VM chamada myVM na região
myResourceGroup do grupo de recursos:
az vm list-vm-resize-options --resource-group myResourceGroup --name myVM --output table
2. Se o tamanho desejado da VM estiver listado, redimensione a VM com az vm resize. O exemplo a seguir

redimensiona a VM chamada myVM para o tamanho Standard_DS3_v2 :
az vm resize --resource-group myResourceGroup --name myVM --size Standard_DS3_v2
A VM é reiniciada durante esse processo. Após a reinicialização, os discos existentes do sistema

operacional e de dados são remapeados. Tudo o que está no disco temporário é perdido.
3. Se o tamanho desejado da VM não estiver listado, você precisará primeiro desalocar a VM com az vm
deallocate. Esse processo permite que a VM seja redimensionada para qualquer tamanho disponível ao
qual a região dê suporte e então reiniciada. As etapas a seguir desalocam, redimensionam e iniciam a VM
denominada myVM no grupo de recursos chamado myResourceGroup :
az vm deallocate --resource-group myResourceGroup --name myVM

az vm resize --resource-group myResourceGroup --name myVM --size Standard_DS3_v2
az vm start --resource-group myResourceGroup --name myVM
WARNING
Desalocar a VM também libera os endereços IP dinâmicos atribuídos à VM. Os discos do sistema operacional e de
dados não são afetados.
Próximas etapas
Para obter escalabilidade adicional, execute várias instâncias de VM e expanda horizontalmente. Para obter mais
informações, consulte dimensionar automaticamente computadores Linux em um conjunto de
dimensionamento de máquinas virtuais.
Redimensionar uma VM do Windows
Este artigo mostra como mover uma VM para um tamanho de VMdiferente.

Depois de criar uma VM (máquina virtual), você pode expandir ou reduzir a VM, alterando o tamanho da VM.
Em alguns casos, você deverá desalocar a VM primeiro. Isso pode acontecer se o novo tamanho não estiver
disponível no cluster de hardware que hospeda atualmente a VM.
Se sua VM usa a Premium Storage - Armazenamento Premium, certifique-se de que você escolha um s versão
de tamanho para obter suporte de armazenamento Premium. Por exemplo, escolha Standard_E4s _v3 em vez de
Standard_E4_v3.
Usar o portal
1. Abra o Portal do Azure.
2. Abra a página da máquina virtual.
3. No menu à esquerda, selecione tamanho .
4. Escolha um novo tamanho na lista de tamanhos disponíveis e, em seguida, selecione redimensionar .
Se a máquina virtual estiver em execução no momento, alterar seu tamanho fará com que ela seja reiniciada.
Parar a máquina virtual pode revelar tamanhos adicionais.
Usar o PowerShell para redimensionar uma VM que não está em um

conjunto de disponibilidade
Defina algumas variáveis. Substitua os valores com suas próprias informações.
$vmName = "myVM"
Liste os tamanhos de VM que estão disponíveis no cluster do hardware onde a VM está hospedada.
Get-AzVMSize -ResourceGroupName $resourceGroup -VMName $vmName
Se o tamanho desejado estiver listado, execute os seguintes comandos para redimensionar a VM. Se o tamanho
desejado não estiver listado, vá para a etapa 3.
$vm = Get-AzVM -ResourceGroupName $resourceGroup -VMName $vmName

$vm.HardwareProfile.VmSize = "<newVMsize>"
Update-AzVM -VM $vm -ResourceGroupName $resourceGroup
Se o tamanho desejado não estiver listado, execute os seguintes comandos para desalocar a VM, redimensioná-
la e reiniciar a máquina virtual. Substitua <newVMsize> pelo tamanho desejado.
Stop-AzVM -ResourceGroupName $resourceGroup -Name $vmName -Force
$vm.HardwareProfile.VmSize = "<newVMSize>"
Start-AzVM -ResourceGroupName $resourceGroup -Name $vmName
WARNING
Desalocar a VM libera os endereços IP dinâmicos atribuídos à VM. Os discos do sistema operacional e de dados não são
afetados.
Usar o PowerShell para redimensionar uma VM em um conjunto de

disponibilidade
Se o novo tamanho de uma VM em um conjunto de disponibilidade não estiver disponível no cluster de
hardware que está hospedando atualmente a VM, todas as VMs no conjunto de disponibilidade precisarão ser
desalocadas para redimensionar a VM. Talvez também seja necessário atualizar o tamanho de outras VMs no
conjunto de disponibilidade depois que uma máquina virtual for redimensionada. Para redimensionar uma VM
em um conjunto de disponibilidade, execute as seguintes etapas.
$vmName = "myVM"
Liste os tamanhos de VM que estão disponíveis no cluster do hardware onde a VM está hospedada.
Get-AzVMSize -ResourceGroupName $resourceGroup -VMName $vmName
Se o tamanho desejado estiver listado, execute o comando a seguir para redimensionar a VM. Se não estiver
listado, vá para a próxima seção.

$vm.HardwareProfile.VmSize = "<newVmSize>"
Se o tamanho desejado não estiver listado, continue com as seguintes etapas para desalocar todas as VMs no
conjunto de disponibilidade, redimensionar VMs e reiniciá-los.
Pare todas as VMs no conjunto de disponibilidade.
$availabilitySetName = "<availabilitySetName>"
$as = Get-AzAvailabilitySet -ResourceGroupName $resourceGroup -Name $availabilitySetName
$virtualMachines = $as.VirtualMachinesReferences | Get-AzResource | Get-AzVM
$virtualMachines | Stop-AzVM -Force -NoWait
Redimensione e reinicie todas as VMs no conjunto de disponibilidade.

$availabilitySetName = "<availabilitySetName>"
$newSize = "<newVmSize>"
$as = Get-AzAvailabilitySet -ResourceGroupName $resourceGroup -Name $availabilitySetName
$virtualMachines = $as.VirtualMachinesReferences | Get-AzResource | Get-AzVM
$virtualMachines | Foreach-Object { $_.HardwareProfile.VmSize = $newSize }
$virtualMachines | Update-AzVM
$virtualMachines | Start-AzVM
Próximas etapas
Para obter escalabilidade adicional, execute várias instâncias de VM e expanda horizontalmente. Para obter mais
informações, consulte dimensionar automaticamente máquinas do Windows em um conjunto de
dimensionamento de máquinas virtuais.
Suporte para VMs de geração 2 no Azure
O suporte para VMs (máquinas virtuais) de geração 2 já está disponível no Azure. Você não pode alterar a
geração de uma máquina virtual depois de criá-la, portanto, examine as considerações nesta página antes de
escolher uma geração.
As VMs de geração 2 oferecem suporte a recursos principais que não têm suporte em VMs de geração 1. Esses
recursos incluem memória aumentada, Intel com Software Guard Extensions (Intel SGX) e memória persistente
virtualizada (vPMEM). As VMs de geração 2 em execução no local têm alguns recursos que ainda não têm
suporte no Azure. Para obter mais informações, consulte a seção Recursos e funcionalidades.
As VMs de geração 2 usam a nova arquitetura de inicialização baseada em UEFI, em vez da arquitetura baseada
em BIOS usada pelas VMs de geração 1. Em comparação com as VMs de geração 1, as VMs de geração 2 podem
ter tempos de inicialização e de instalação aprimorados. Para obter uma visão geral das VMs de geração 2 e
algumas das diferenças entre a geração 1 e a geração 2, consulte Devo criar uma máquina virtual de geração 1
ou 2 no Hyper-V?.
Tamanhos de máquinas virtuais de geração 2

As VMs de geração 1 têm suporte de todos os tamanhos de VM no Azure (exceto para VMs da série Mv2). O
Azure agora oferece suporte à geração 2 para a seguinte série de VMs selecionada:
Série B
Série DCsv2
Série DSv2
Dsv3-series
Série Dsv4
Série Dasv4
Série Ddsv4
Série Esv3
Série Esv4
Série Easv4
Série Edsv4
Série Fsv2
Série GS
Série HB
Série HC
Série ls
Lsv2-series
Série M
Série Mv21
Série NCv2
Série NCv3
Série ND
Série NVv3
Série NVv4
Série NCasT4_v3
1
1 A série Mv2
não dá suporte a imagens de VM de geração 1 e só oferece suporte a um subconjunto de
imagens de geração 2. Consulte a documentação da série Mv2 para obter detalhes.
As imagens de VM de geração 2 no Azure Marketplace

As VMs de geração 2 dão suporte às seguintes imagens do Marketplace:
Windows Server 2019, 2016, 2012 R2 e 2012
Windows 10 pro, Windows 10 Enterprise
SUSE Linux Enterprise Server 15 SP1
Ubuntu Server 16.04, 18.04, 19.04, 19.10
RHEL 8.1, 8.0, 7.7, 7.6, 7.5, 7.4, 7.0
CentOS 8.1, 8.0, 7.7, 7.6, 7.5, 7.4
Oracle Linux 7.7, 7.7-CI
NOTE
Tamanhos de máquina virtual específicos, como a série Mv2, podem dar suporte apenas a um subconjunto dessas
imagens – consulte a documentação de tamanho da máquina virtual relevante para obter detalhes completos.
Local em comparação a VMs do Azure geração 2

Atualmente, o Azure não dá suporte a alguns dos recursos que o Hyper-V local dá suporte para VMs de geração
2.
REC URSO DE GERA Ç Ã O 2 H Y P ER- V LO C A L A Z URE
Inicialização Segura ️
✔ Com inicialização confiável (versão
prévia)
VM blindada ️
✔ ❌
vTPM ️
prévia)
Segurança baseada em virtualização ️

(VBS) prévia)
Formato VHDX ️
✔ ❌
Para obter mais informações, consulte inicialização confiável (versão prévia).
Recursos e funcionalidades
Recursos da geração 1 versus geração 2
REC URSO GERA Ç Ã O 1 GERA Ç Ã O 2
Inicialização PCAT UEFI
Controladores de disco IDE SCSI
Tamanhos de VM Todos os tamanhos de VM Ver tamanhos disponíveis

Recursos da geração 1 versus geração 2
REC URSO GERA Ç Ã O 1 GERA Ç Ã O 2
Disco do sistema operacional > 2 TB ❌ ️

✔
Disco personalizado/imagem/troca de ️
✔ ️
✔
sistema operacional
Suporte ao conjunto de ️
✔ ️
✔
dimensionamento de máquinas
virtuais
Azure Site Recovery ️

✔ ️
✔
Backup/restauração ️
✔ ️
✔
Galeria de imagens compartilhadas ️

✔ ️
✔
Criptografia de disco do Azure ️

✔ ️
✔
Criptografia no servidor ️
✔ ️
✔
Criando uma VM de geração 2

Imagem do Marketplace
No portal do Azure ou CLI do Azure, você pode criar VMs de geração 2 de uma imagem do Marketplace que dá
suporte à inicialização de UEFI.
Portal do Azure
Veja abaixo as etapas para criar uma VM de geração 2 (Gen2) no portal do Azure.
1. Entre no Portal do Azure em https://portal.azure.com.
2. Selecione Criar um recurso .
3. Clique em ver tudo do Azure Marketplace à esquerda.
4. Selecione uma imagem que dê suporte a Gen2.
5. Clique em Criar .
6. Na guia Avançado , na seção Geração de VM , selecione a opção Gen 2 .
7. Na guia Noções básicas em Detalhes da instância vá para Tamanho e abra a folha Selecionar um
tamanho de VM .
8. Selecione uma VM com suporte à geração 2.
9. Percorra o restante das páginas para concluir a criação da VM.
PowerShell
Você também pode usar o PowerShell para criar uma VM referenciando diretamente a SKU de geração 1 ou
geração 2.
Por exemplo, use o seguinte cmdlet do PowerShell para obter uma lista das SKUs na oferta do WindowsServer .
Get-AzVMImageSku -Location westus2 -PublisherName MicrosoftWindowsServer -Offer WindowsServer
Se você estiver criando uma VM com o Windows Server 2012 como o sistema operacional, você selecionará a
SKU de VM de geração 1 (BIOS) ou de geração 2 (UEFI), que tem esta aparência:
2012-Datacenter
2012-datacenter-gensecond
Consulte a seção Recursos e funcionalidades para obter uma lista atual de imagens do Marketplace com
suporte.
CLI do Azure
Como alternativa, você pode usar o CLI do Azure para ver todas as imagens disponíveis da geração 2, que estão
listadas por Publicador .
az vm image list --publisher Canonical --sku gen2 --output table --all
Imagem gerenciada ou disco gerenciado

Você pode criar uma VM de geração 2 a partir de uma imagem gerenciada ou de um disco gerenciado da
mesma maneira que criaria uma VM de geração 1.
conjuntos de escala de máquina virtual
Você também pode criar VMs de geração 2 usando conjuntos de dimensionamento de máquinas virtuais. No
CLI do Azure, use conjuntos de dimensionamento do Azure para criar VMs de geração 2.
As VMs de geração 2 estão disponíveis em todas as regiões do Azure?
Sim. Mas nem todos os tamanhos de VM de geração 2 estão disponíveis em todas as regiões. A
disponibilidade da VM de geração 2 depende da disponibilidade do tamanho da VM.
Há uma diferença de preço entre as VMs de geração 1 e de geração 2?
Não.
Tenho um arquivo .vhd da minha VM de geração 2 local. Posso usar esse arquivo .vhd para
criar uma VM de geração 2 no Azure? Sim, você pode colocar seu arquivo .vhd de geração 2 no
Azure e usá-lo para criar uma VM de geração 2. Use as seguintes etapas para fazer isso:
1. Carregue o .vhd para uma conta de armazenamento na mesma região em que você gostaria de
criar sua VM.
2. Criar um disco gerenciado do .vhd. Defina a propriedade de geração do Hyper-V como V2. Os
comandos do PowerShell a seguir definem a propriedade de geração do Hyper-V ao criar um
disco gerenciado.
$sourceUri = 'https://xyzstorage.blob.core.windows.net/vhd/abcd.vhd'. #<Provide location to

your uploaded .vhd file>
$osDiskName = 'gen2Diskfrmgenvhd' #<Provide a name for your disk>
$diskconfig = New-AzDiskConfig -Location '<location>' -DiskSizeGB 127 -AccountType
Standard_LRS -OsType Windows -HyperVGeneration "V2" -SourceUri $sourceUri -CreateOption
'Import'
New-AzDisk -DiskName $osDiskName -ResourceGroupName '<Your Resource Group>' -Disk $diskconfig
3. Quando o disco estiver disponível, crie uma VM anexando esse disco. A VM criada será uma VM
de geração 2. Quando a VM de geração 2 é criada, você pode, opcionalmente, generalizar a
imagem dessa VM. Ao generalizar a imagem, você poderá usá-la para criar várias VMs.
Como fazer para aumentar o tamanho do disco do SO?
Discos do sistema operacional maiores que 2 TiB são novos para VMs de geração 2. Por padrão, OS
discos do sistema operacional são menores do que 2 TiB para VMs de geração 2. Você pode aumentar o
tamanho do disco até um máximo recomendado de 4 TiB. Use o CLI do Azure ou o portal do Azure para
aumentar o tamanho do disco do SO. Para obter informações sobre como expandir discos
programaticamente, consulte redimensionar um disco para Windows ou Linux.
Para aumentar o tamanho do disco do SO do portal do Azure:
1. No portal do Azure, vá até a página de propriedades da VM.
2. Para desligar e desalocar a VM, selecione o botão Parar .
3. Na seção Discos , selecione o disco do sistema operacional que você deseja aumentar.
4. Na seção Discos , selecione Configuração e atualize o Tamanho para o valor desejado.
5. Volte para a página de propriedades da VM para Iniciar a VM.
Você pode ver um aviso para discos do sistema operacional com mais de 2 TiB. O aviso não se aplica às
VMs de geração 2. No entanto, não há suporte para tamanhos de disco de so maiores que 4 TiB.
As VMs de geração 2 oferecem supor te à rede acelerada?
Sim. Para obter mais informações, consulte Criar uma VM com rede acelerada.
As VMs de geração 2 dão supor te à inicialização segura ou vTPM no Azure? Tanto o vTPM
quanto o Secure boot são recursos de inicialização confiável (versão prévia) para VMs de geração 2. Para
obter mais informações, consulte inicialização confiável.
Há supor te para VHDX na geração 2?
Não, as VMs de geração 2 dão suporte apenas a VHD.
As VMs de geração 2 dão supor te ao Armazenamento de Disco Ultra do Azure?
Sim.
Posso migrar uma VM de geração 1 para a geração 2?
Você não pode alterar a geração de uma VM depois de criá-la. Se você precisar alternar entre gerações de
VM, crie uma nova VM de uma geração diferente.
Por que o tamanho da minha VM não está habilitado no seletor de tamanho quando tento
criar uma VM Gen2?
Isso pode ser resolvido da seguinte maneira:
1. Verifique se a propriedade Geração de VM está definida como Gen 2 na guia Avançado .
2. Verifique se você está procurando um tamanho de VMs que dá suporte a VMs Gen2.
Próximas etapas
Saiba mais sobre a inicialização confiável (versão prévia) com VMs Gen 2.
Saiba mais sobre máquinas virtuais geração 2 no Hyper-V.
Tamanhos das Máquinas Virtuais de uso geral
Os tamanhos de VM para uso geral fornecem uma relação de CPU para memória equilibrada. Ideal para teste e
desenvolvimento, bancos de dados pequenos a médios e servidores Web de tráfego baixo a médio. Este artigo
fornece informações sobre as ofertas para computação de uso geral.
As VMs da série Av2 podem ser implantadas em uma variedade de tipos de hardware e processadores.
As VMs da série A possuem configurações de memória e de desempenho de CPU mais adequadas para
cargas de trabalho de entrada, como desenvolvimento e teste. O tamanho é limitado, com base no
hardware, para oferecer desempenho de processador consistente para a instância em execução,
independentemente do hardware em que é implantado. Para determinar o hardware físico no qual esse
tamanho é implantado, consulte o hardware virtual de dentro da Máquina Virtual. Os exemplos de casos
de uso incluem servidores de desenvolvimento e teste, servidores Web de tráfego baixo, bancos de
dados pequenos a médios, servidores para prova de conceito e repositórios de código.
NOTE
As VMs A8, A9, A10 a11 estão planejadas para aposentadoria em 3/2021. Para obter mais informações, confira o
Guia de migração de HPC. Esses tamanhos de VM estão na série "A_v1" original, não em "v2".
As VMs de intermitência da série B são ideais para cargas de trabalho que não precisam do desempenho
total da CPU continuamente, como servidores Web, bancos de dados pequenos e ambientes de
desenvolvimento e teste. Normalmente, essas cargas de trabalho têm requisitos de desempenho
expansíveis. A série B fornece esses clientes a possibilidade de comprar um tamanho VM com um preço
consciência da linha de base de desempenho que permite que a instância VM criar créditos quando a VM
é menor que o desempenho de base. Quando a VM tiver acumulado crédito, poderá disparar acima da
linha de base da VM usando até 100% da CPU quando seu aplicativo requer o maior desempenho de
CPU.
As séries Dav4 e Dasv4 são novos tamanhos que utilizam o processador 2,35 GHz EPYCTM 7452 da AMD
em uma configuração multi-thread com até 256 MB de cache L3, que dedica 8 MB desse cache L3 a cada
8 núcleos, aumentando as opções do cliente para executar as cargas de trabalho de uso geral. As séries
Dav4 e Dasv4 têm as mesmas configurações de memória e disco que as séries Dsv3 e D.
Dv4 e Dsv4-Series A dv4 e a série Dsv4 são executadas nos processadores Intel® Xeon® Platinum
8272CL (Cascadey Lake) em uma configuração de hiperthread, fornecendo uma proposta de valor
melhor para as cargas de trabalho de uso geral. Ele apresenta uma velocidade de clock de Turbo principal
de 3,4 GHz.
Ddv4 e Ddsv4-Series A Ddv4 e a série Ddsv4 são executadas nos ® processadores Intel Xeon ®
Platinum 8272CL (cascadey Lake) em uma configuração de hiperthread, fornecendo uma proposta de
valor melhor para as cargas de trabalho de uso geral. Ele apresenta uma velocidade de clock de Turbo
principal de 3,4 GHz , ® tecnologia Intel Turbo Boost 2,0, ® tecnologia Intel Hyper-Threading e
extensões de ® vetor avançadas Intel 512 (Intel ® AVX-512). Eles também dão suporte ao ® aumento
de aprendizado profundo da Intel. Esses novos tamanhos de VM terão um armazenamento local 50%
maior, bem como um melhor IOPS de disco local para leitura e gravação em comparação com os
tamanhos Dv3/Dsv3 com VMs Gen2.
Dv3 e Dsv3-Series As VMs são executadas em 2ª geração Intel® Xeon® Platinum 8272CL (cascade),
Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou os
processadores Intel® Xeon® E5-2673 v3 2,4 GHz (Haswell) em uma configuração de hiperthread,
fornecendo uma melhor proposta de valor para as cargas de trabalho de uso geral. A memória foi
expandida (de ~3.5 GiB/vCPU para 4 GiB/vCPU) enquanto os limites de rede e disco em uma base por
núcleo foram ajustados para alinhar com a mudança para o hyperthreading. A série Dv3 não tem mais os
tamanhos de VM de memória alta da série D/Dv2, que foram migrados para as séries Ev3 e Esv3
otimizadas para memória.
As VMs das séries Dv2 e Dsv2, continuação da série D original, apresentam uma CPU mais potente e a
configuração ideal de CPU/memória, tornando-as adequadas para a maioria das cargas de trabalho de
produção. A série Dv2 é aproximadamente 35% mais rápida do que a série D. A série Dv2 é executada em
2ª geração Intel® Xeon® Platinum 8272CL (Cascadey Lake), Intel® Xeon® 8171M 2.1 GHz
(Skylake), Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou os processadores Intel® Xeon® E5-
2673 v3 2,4 GHz (Haswell) com a tecnologia Intel Turbo Boost 2,0. A série Dv2 tem as mesmas
configurações de memória e disco que a série D.
A série DCv2 pode ajudar a proteger a confidencialidade e a integridade dos dados e do código enquanto
eles são processados na nuvem pública. Esses computadores têm o suporte da última geração do
processador Intel XEON E-2288G com a tecnologia SGX. Com a Tecnologia Intel Turbo Boost, esses
computadores podem chegar a 5,0 GHz. As instâncias da série DCv2 permitem que os clientes criem
aplicativos seguros baseados em enclave para proteger os códigos e os dados enquanto estiverem em
uso.
Outros tamanhos
Memória otimizada
GPU otimizada
Próximas etapas
Para obter mais informações sobre como o Azure nomeia suas VMs, consulte convenções de nomenclatura de
tamanhos de máquina virtual do Azure.
Série Av2
As VMs da série Av2 podem ser implantadas em uma variedade de tipos de hardware e processadores. As VMs
da série Av2 têm configurações de desempenho e memória de CPU mais adequadas para cargas de trabalho de
nível de entrada, como desenvolvimento e teste. O tamanho é limitado para oferecer desempenho de
processador consistente para a instância em execução, independentemente do hardware no qual ele está
implantado. Para determinar o hardware físico no qual esse tamanho é implantado, consulte o hardware virtual
de dentro da Máquina Virtual. Alguns casos de uso de exemplo incluem servidores de desenvolvimento e teste,
servidores Web de tráfego baixo, bancos de dados pequenos a médios, prova de conceitos e repositórios de
código.
ACU: 100
Armazenamento Premium: sem suporte
Armazenamento em cache Premium: sem suporte
Migração ao vivo: com suporte
Atualizações de preservação de memória: com suporte
Suporte à geração de VM: geração 1
Rede acelerada: sem suporte
Discos do sistema operacional efêmero: sem suporte
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
M EN TO
T EM P O RÁ R M Á XIM O
IO : DE DISC O S
A RM A Z EN A IO P S/ M B P S DE L A RGURA
M EN TO DE DA DO S/ TA DE B A N DA
T EM P O RÁ R L EIT URA / M XA DE DE REDE
M EM Ó RIA : IO ( SSD) B P S DE T RA N SF ERÊ M Á XIM O ESP ERA DA
TA M A N H O VC O RE GIB GIB GRAVA Ç Ã O N C IA : IO P S DE N IC S ( M B P S)
Standard_A 1 2 10 1000/20/1 2/2x500 2 250

1_v2 0
Standard_A 2 4 20 2000/40/2 4/4x500 2 500

2_v2 0
Standard_A 4 8 40 4000/80/4 8/8x500 4 1000

4_v2 0
Standard_A 8 16 80 8000/160/ 16/16x500 8 2000

8_v2 80
Standard_A 2 16 20 2000/40/2 4/4x500 2 500

2m_v2 0
Standard_A 4 32 40 4000/80/4 8/8x500 4 1000

4m_v2 0
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
M EN TO
IO : DE DISC O S
TA M A N H O VC O RE GIB GIB GRAVA Ç Ã O N C IA : IO P S DE N IC S ( M B P S)
Standard_A 8 64 80 8000/160/ 16/16x500 8 2000

8m_v2 80
Definições da tabela de tamanhos

A capacidade de armazenamento é mostrada em unidades de GiB ou de 1024^3 bytes. Quando você
compara os discos medidos em GB (1000 ^ 3 bytes) para os discos medidos em GiB (1024 ^ 3), lembre-
se de que os números de capacidade fornecidos em GiB podem parecer menores. Por exemplo, 1023 GiB
= 1098,4 GB.
A taxa de transferência do disco é medida em IOPS (operações de entrada/saída por segundo) e em
MBps, em que MBps = 10^6 bytes/s.
Os discos de dados podem operar nos modos em cache ou não armazenado em cache. Para a operação
do disco de dados armazenados em cache, o modo de cache do host é definido como ReadOnly ou
ReadWrite . Para as operação do disco de dados não armazenados em cache, o modo de cache do host é
definido como Nenhum .
Para saber como obter o melhor desempenho de armazenamento para suas VMs, consulte desempenho
de disco e máquina virtual.
Largura de banda de rede esperada é a largura de banda agregada máxima alocada por tipo de VM
em todas as NICs para todos os destinos. Para obter mais informações, consulte largura de banda de rede
da máquina virtual.
Os limites superiores não são garantidos. Os limites oferecem orientação para selecionar o tipo de VM
correto para o aplicativo pretendido. O desempenho real da rede dependerá de vários fatores, incluindo o
congestionamento da rede, cargas de aplicativos e configurações de rede. Para obter informações sobre
como otimizar a taxa de transferência de rede, consulte otimizar a taxa de transferência de rede para
máquinas virtuais do Azure. Para obter o desempenho de rede esperado no Linux ou no Windows, talvez
seja necessário selecionar uma versão específica ou otimizar sua VM. Para obter mais informações,
consulte NTTTCP (largura de banda/teste de taxa de transferência).
Outros tamanhos e informações

Propósito geral
Memória otimizada
GPU otimizada
Calculadora de preços: calculadora de preços
Mais informações sobre tipos de discos: tipos de disco
Próximas etapas
Tamanhos expansíveis da máquina virtual da série B
As VMs da série B são ideais para cargas de trabalho que não precisam do desempenho total da CPU
continuamente, como servidores Web, prova de conceitos, bancos de dados pequenos e ambientes de
compilação de desenvolvimento. Normalmente, essas cargas de trabalho têm requisitos de desempenho
expansíveis. A série B fornece a capacidade de comprar um tamanho de VM com desempenho de linha de base
que pode criar créditos quando ele estiver usando menos de sua linha de base. Quando a VM tiver acumulado
créditos, a VM poderá ultrapassar a linha de base usando até 100% do vCPU quando seu aplicativo exigir um
desempenho de CPU maior.
A série B vem nos seguintes tamanhos de VM:
ACU (unidade de computação do Azure): varia *
Armazenamento Premium: com suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: com suporte * *
Discos do sistema operacional efêmero: com suporte
* As VMs da série B são intermitentes e, portanto, os números do ACU variam dependendo das cargas de
trabalho e do uso do núcleo.
* * A rede acelerada só tem suporte para Standard_B12ms, Standard_B16ms e Standard_B20ms.
TA XA
DE
T RA
N SF E
RÊN C
IA
M Á XI TA XA
MA DE
DE T RA
A RM N SF E
A RM A Z EN RÊN C
AZE B A SE M Á XI M Á XI AME IA DE
NAM DE MO MO N TO DISC
EN T DESE DESE DE DISC T EM O
O MPE MPE C RÉD C RÉD OS POR SEM
T EM NHO NHO ITO S ITO S DE Á RIO CAC
POR DA DA C RÉD BAN A RM DA D : H E: M Á XI
TA M M EM Á RIO CPU CPU ITO S C Á RI A Z EN OS IO P S IO P S MO
ANH VC P Ó RIA ( SSD) DA DA IN IC I O S/ H A DO M Á XI /MBP /MBP DE
O U : GIB GIB VM VM A IS O RA S MOS S S N IC S
Stan 1 0,5 4 5% 100 30 3 72 2 200/ 160/ 2

dard % 10 10
_B1ls
1
Stan 1 1 4 10% 100 30 6 144 2 400/ 320/ 2

dard % 10 10
_B1s
TA XA
DE
T RA
N SF E
RÊN C
IA
M Á XI TA XA
MA DE
DE T RA
A RM N SF E
A RM A Z EN RÊN C
AZE B A SE M Á XI M Á XI AME IA DE
NAM DE MO MO N TO DISC
EN T DESE DESE DE DISC T EM O
O MPE MPE C RÉD C RÉD OS POR SEM
T EM NHO NHO ITO S ITO S DE Á RIO CAC
POR DA DA C RÉD BAN A RM DA D : H E: M Á XI
TA M M EM Á RIO CPU CPU ITO S C Á RI A Z EN OS IO P S IO P S MO
ANH VC P Ó RIA ( SSD) DA DA IN IC I O S/ H A DO M Á XI /MBP /MBP DE
O U : GIB GIB VM VM A IS O RA S MOS S S N IC S
Stan 1 2 4 20% 100 30 12 288 2 800/ 640/ 2

dard % 10 10
_B1
ms
Stan 2 4 8 40% 200 60 24 576 4 1600 1280 3

dard % /15 /15
_B2s
Stan 2 8 16 60% 200 60 36 864 4 2400 1920 3

dard % /22,5 /22,5
_B2
ms
Stan 4 16 32 90% 400 120 54 1296 8 3600 2880 4

dard % /35 /35
_B4
ms
Stan 8 32 64 135 800 240 81 1944 16 4320 4320 4

dard % % /50 /50
_B8
ms
Stan 12 48 96 202 1200 360 121 2909 16 6480 4320 6

dard % % /75 /50
_B12
ms
Stan 16 64 128 270 1600 480 162 3888 32 8640 4320 8

dard % % /100 /50
_B16
ms
Stan 20 80 160 337 2000 600 203 4860 32 1080 4320 8

dard % % 0/12 /50
_B20 5
ms
1 B1ls tem suporte apenas no Linux
Exemplo de carga de trabalho

Considere um aplicativo de check-in/saída do Office. O aplicativo precisa de picos de CPU durante o horário
comercial, mas não muito poder de computação fora do horário de expediente. Neste exemplo, a carga de
trabalho requer uma máquina virtual 16vCPU com 64GiB de RAM para trabalhar com eficiência.
A tabela mostra os dados de tráfego por hora e o gráfico é uma representação visual desse tráfego.
Características do B16:
Desempenho máximo da CPU: 16vCPU * 100% = 1600%
Linha de base: 270%
C RÉDITO S C RÉDITO S
C EN Á RIO H O RA USO DA C P U ( % ) A C UM UL A DO S 1 DISP O N ÍVEIS
Implantação do Implantação Implantação 480 (créditos iniciais) 480

B16ms
Nenhum tráfego 0:00 0 162 642
Baixo tráfego 6:00 270 0 1452
Os funcionários 7:00 1280 -606 846

chegam ao Office (o
aplicativo precisa de
80% vCPU)
Os funcionários 8:00 1280 -606 240

continuam chegando
ao Office (as
necessidades do
aplicativo são de 80%
vCPU)
C RÉDITO S C RÉDITO S
C EN Á RIO H O RA USO DA C P U ( % ) A C UM UL A DO S DISP O N ÍVEIS
Baixo tráfego 10:00 100 102 342
Baixo tráfego 12:00 100 102 576
Baixo tráfego 13:00 100 102 678
Baixo tráfego 15:00 100 102 912
Baixo tráfego 16:00 100 102 1014
Os funcionários estão 17:00 1600 -798 216

fazendo check-out (o
aplicativo precisa de
100% vCPU)
1 os créditos acumulados/créditos usados em uma hora são equivalentes a:

((Base CPU perf of VM - CPU Usage) / 100) * 60 minutes .
Para um D16s_v3 que tem 16 vCPUs e 64 GiB de memória, a taxa horária é $0.936 por hora (mensalmente
$673.92) e para B16ms com 16 vCPUs e 64 GiB de memória a taxa é $0.794 por hora (mensalmente $547.86).
Isso resulta em uma economia de 15%!
Perguntas e Respostas
P: o que acontece quando meus créditos acabam?
R : quando os créditos são esgotados, a VM retorna ao desempenho da linha de base.
P: como obter 135% da linha de base de desempenho de uma VM?
R : os 135% são compartilhados entre as 8 vCPUs que compõem o tamanho da VM. Por exemplo, se seu
aplicativo utiliza 4 dos 8 núcleos trabalhando em processamento de lotes e cada uma das 4 vCPUs estão sendo
executadas a 30% da utilização, o desempenho total da CPU da VM será de 120%. Isso significa que a VM estaria
criando créditos de tempo com base no delta de 15% da sua linha de base de desempenho. Mas isso também
significa que quando você tem créditos disponíveis, a mesma VM pode usar 100% de todas as 8 vCPUs, o que
daria à VM um desempenho máximo de CPU de 800%.
P: como posso monitorar meu saldo de crédito e consumo?
R : a métrica de crédito permite que você veja quantos créditos sua VM foi bancária e a métrica de
ConsumedCredit mostrará quantos créditos de CPU sua VM consumiu do banco. Você poderá exibir essas
métricas no painel de métricas no portal ou programaticamente pelas APIs do Azure Monitor.
Para saber mais sobre como acessar os dados de métrica do Azure, confira Visão geral das métricas no
Microsoft Azure.
P: como os créditos são acumulados e consumidos?
R : as taxas de consumo e acumulação da VM estão definidas de modo que uma VM em execução na sua linha
de base de desempenho não terá acúmulo ou consumo de créditos. Uma VM terá um aumento de créditos
sempre que estiver em execução abaixo da linha de base de desempenho e terá uma redução nos créditos
sempre que a VM estiver usando a CPU acima da sua linha de base de desempenho.
Exemplo : implantei uma VM usando o tamanho B1ms para meu aplicativo de banco de dados pequeno. Esse
tamanho permite que o meu aplicativo use até 20% de uma vCPU como minha linha de base, o que significa 0,2
de crédito por minuto que posso usar ou acumular.
Meu aplicativo está ocupado no início e no final do dia de trabalho dos meus funcionários, de 7h às 9h e de 16h
às 18h. Durante as outras 20 horas do dia, meu aplicativo está normalmente ocioso, usando apenas 10% da
vCPU. Para o horário fora do pico, eu recebi 0,2 créditos por minuto, mas consumindo apenas 0,1 créditos por
minuto, de modo que minha VM terá o banco 0,1 x 60 = 6 créditos por hora. Nas 20 horas em que estou fora de
pico, acumularei 120 créditos.
Durante o horário de pico, meu aplicativo aproveita 60% de utilização de vCPU, ainda acumulo 0,2 de crédito
por minuto, mas consumo 0,6 de crédito por minuto, com um custo líquido de 0,4 de crédito por minuto, ou 0,4
x 60 = 24 créditos por hora. Tenho 4 horas por dia de pico, ou seja, meu uso em hora de pico é de 4 x 24 = 96
créditos.
Se eu usar os 120 créditos acumulados fora de pico e subtrair os 96 créditos que usei para meu horário de pico,
acumulo mais 24 créditos por dia para usar em outras atividades.
P: como posso calcular os créditos acumulados e usados?
R : você pode usar a seguinte fórmula:
(Desempenho base da CPU da VM-uso da CPU)/100 = banco de créditos ou uso por minuto
por exemplo, na instância acima, sua linha de base é de 20% e se você usar 10% da CPU que está acumulando
(20%-10%)/100 = 0,1 crédito por minuto.
P: a série B dá suporte a discos de dados de Armazenamento Premium?
R : sim, todos os tamanhos da série B dão suporte a discos de dados de Armazenamento Premium.
P: Por que meu conjunto de créditos restantes está definido como 0 após uma reimplantação ou
parar/iniciar?
R : quando uma VM é reimplantada e a VM é movida para outro nó, o crédito acumulado é perdido. Se a VM for
iniciada/interrompida, mas permanecer no mesmo nó, a VM retém o crédito acumulado. Sempre que a VM
começa a ser atualizada em um nó, ela obtém um crédito inicial, por Standard_B8ms é 240.
P: o que acontecerá se eu implantar uma imagem de sistema operacional sem suporte no B1ls?
R: o B1ls só dá suporte a imagens do Linux e, se você implantar qualquer outra imagem do sistema
operacional, talvez não obtenha a melhor experiência do cliente.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série DCsv2
A série DCsv2 pode ajudar a proteger a confidencialidade e a integridade dos dados e do código enquanto eles
são processados na nuvem pública. Esses computadores têm o suporte da última geração do processador Intel
XEON E-2288G com a tecnologia SGX. Com a Tecnologia Intel Turbo Boost, esses computadores podem chegar a
5,0 GHz. As instâncias da série DCsv2 permitem que os clientes criem aplicativos seguros baseados em enclave
para proteger o código e os dados enquanto estiverem em uso.
Exemplos de casos de uso incluem: compartilhamento de dados confidenciais entre vários participantes,
detecção de fraudes, antilavagem de dinheiro, blockchain, análise de uso confidencial, análise de inteligência e
machine learning confidencial.
Armazenamento Premium:
cache de armazenamento Premiumcom suporte: migração ao vivo com suporte
:
atualizações de preservação de memóriasem suporte:
suporte à geração de VMsem suporte:
rede aceleradade geração 2: com suporte ( requer um mínimo de 4 vCPU *)
*Exceto para Standard_DC8_v2
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE N ÚM ERO
A RM A Z EN A M Á XIM O
M EN TO DE
T EM P O RÁ R N IC S/ L A RG
A RM A Z EN A IO : IO P S / URA DE
M EN TO MBPS B A N DA DE
T EM P O RÁ R DISC O S DE ( TA M A N H O REDE
M EM Ó RIA : IO ( SSD) DA DO S DO C A C H E ESP ERA DA M EM Ó RIA
TA M A N H O VC P U GIB GIB M Á XIM O S EM GIB ) ( M B P S) EP C ( M IB )
Standard_D 1 4 50 1 2.000/16 2 28
C1s_v2
Standard_D 2 8 100 2 4.000/32 2 56

C2s_v2
Standard_D 4 16 200 4 8.000/64 2 112

C4s_v2
Standard_D 8 32 400 8 16.000/128 2 168

C8_v2
As VMs da série DCsv2 são VMs de geração 2 e dão suporte apenas a imagens Gen2 .
Disponível atualmente nas regiões listadas aqui.
Geração anterior de VMs de computação confidencial: Série DC
Criar VMs DCsv2 usando o portal do Azure ou o Azure Marketplace
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Séries Dv2 e DSv2
A Dv2 e a série DSv2, um acompanhamento da série D original, apresentam uma CPU mais potente e
configuração ideal de CPU para memória, tornando-as adequadas para a maioria das cargas de trabalho de
produção. A série Dv2 é aproximadamente 35% mais rápida do que a série D. Dv2-série de execução no Intel®
Xeon® Platinum 8272CL (Cascadey Lake), Intel® Xeon® 8171M 2.1 GHz (Skylake), Intel® Xeon® E5-
2673 v4 2,3 GHz (Broadwell) ou os processadores Intel® Xeon® E5-2673 v3 2,4 GHz (Haswell) com a
tecnologia Intel Turbo Boost 2,0. A série Dv2 tem as mesmas configurações de memória e disco que a série D.
Série Dv2
Os tamanhos da série Dv2 são executados no Intel® Xeon® Platinum 8272CL (Cascadey Lake), no Intel®
Xeon® 8171M 2.1 GHz (Skylake) ou nos processadores Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou
Intel® Xeon® E5-2673 v3 2,4 GHz (Haswell) com a tecnologia Intel Turbo Boost 2,0.
ACU: 210-250
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O
T EM P O R
Á RIO :
A RM A Z E IO P S/ M B L A RGURA
N A M EN T P S DE DISC O S DE
O L EIT URA / DE TA XA DE B A N DA
T EM P O R M B P S DE DA DO S T RA N SF E DE REDE
TA M A N H M EM Ó RI Á RIO GRAVA Ç Ã M Á XIM O RÊN C IA : M Á XIM O ESP ERA D
O VC P U A : GIB ( SSD) GIB O S IO P S DE N IC S A ( M B P S)
Standard_ 1 3,5 50 3000/46/ 4 4x500 2 750

D1_v2 23
Standard_ 2 7 100 6000/93/ 8 8 x 500 2 1500

D2_v2 46
Standard_ 4 14 200 12000/18 16 16 x 500 4 3000

D3_v2 7/93
Standard_ 8 28 400 24000/37 32 32 x 500 8 6000

D4_v2 5/187
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O
T EM P O R
Á RIO :
A RM A Z E IO P S/ M B L A RGURA
N A M EN T P S DE DISC O S DE
O L EIT URA / DE TA XA DE B A N DA
T EM P O R M B P S DE DA DO S T RA N SF E DE REDE
TA M A N H M EM Ó RI Á RIO GRAVA Ç Ã M Á XIM O RÊN C IA : M Á XIM O ESP ERA D
O VC P U A : GIB ( SSD) GIB O S IO P S DE N IC S A ( M B P S)
Standard_ 16 56 800 48000/75 64 64x500 8 12000

D5_v2 0/375
Série DSv2
Os tamanhos da série DSv2 são executados no Intel® Xeon® Platinum 8272CL (Cascade, Lake), Intel®
Xeon® 8171M 2.1 GHz (Skylake) ou os processadores Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou
Intel® Xeon® E5-2673 v3 2,4 GHz (Haswell) com a tecnologia Intel Turbo Boost 2,0 e usam o armazenamento
Premium.
ACU: 210-250
Cache de armazenamento Premium: com suporte
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
Á RIA : T RA N SF E
A RM A Z E IO P S/ M B RÊN C IA L A RGURA
N A M EN T DISC O S PS DE DISC O DE
O DE ( TA M A N SEM B A N DA
T EM P O R DA DO S H O DO C A C H E: DE REDE
TA M A N H M EM Ó RI Á RIO M Á XIM O CACHE IO P S/ M B M Á XIM O ESP ERA D
O VC P U A : GIB ( SSD) GIB S EM GIB ) PS DE N IC S A ( M B P S)
Standard_ 1 3,5 7 4 4000/32 3200/48 2 750

DS1_v2 (43)
Standard_ 2 7 14 8 8000/64 6400/96 2 1500

DS2_v2 (86)
Standard_ 4 14 28 16 16000/12 12800/19 4 3000

DS3_v2 8 (172) 2
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
Standard_ 8 28 56 32 32000/25 25600/38 8 6000

DS4_v2 6 (344) 4
Standard_ 16 56 112 64 64000/51 51200/76 8 12000

DS5_v2 2 (688) 8

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Séries Dv3 e DSv3
A série Dv3 é executada no Intel® Xeon® Platinum 8272CL (Cascadey Lake), Intel® Xeon® 8171M 2.1 GHz
(Skylake), Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou os processadores Intel® Xeon® E5-2673 v3
2,4 GHz (Haswell) em uma configuração de Hyper-thread, fornecendo uma proposta de valor melhor para as
cargas de trabalho de uso geral. A memória foi expandida (de ~3.5 GiB/vCPU para 4 GiB/vCPU) enquanto os
limites de rede e disco em uma base por núcleo foram ajustados para alinhar com a mudança para o
hyperthreading. A série Dv3 não tem mais os tamanhos de VM de memória alta da série D/Dv2, que foram
migrados para as séries Ev3 e Esv3 otimizadas para memória.
Exemplos de casos de uso da série D incluem aplicativos de nível empresarial, bancos de dados relacionais,
cache na memória e análise.
Dv3-series
Os tamanhos da série Dv3 são executados no Intel® Xeon® Platinum 8272CL (Cascadey Lake), Intel®
Xeon® 8171M 2.1 GHz (Skylake), Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou os processadores
Intel® Xeon® E5-2673 v3 2,4 GHz (Haswell) com a ® tecnologia Intel Turbo Boost 2,0. Os tamanhos da série
Dv3 oferecem uma combinação de vCPU, memória e armazenamento temporário para a maioria das cargas de
trabalho de produção.
O armazenamento do disco de dados é faturado separadamente das máquinas virtuais. Para usar discos de
armazenamento premium, use os tamanhos Dsv3. Os medidores de cobrança e preço para os tamanhos Dsv3
são os mesmos que os da Dv3-series.
O recurso de VMs da série Dv3 Intel® Hyper-Threading tecnologia.
ACU: 160-190
TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
T EM P O RÁ RIO
: IO P S/ M B P S
A RM A Z EN A M DE L A RGURA DE
EN TO DISC O S DE L EIT URA / M B P B A N DA
M EM Ó RIA : T EM P O RÁ RIO DA DO S S DE M Á XIM A DE
TA M A N H O VC P U GIB ( SSD) GIB M Á XIM O S GRAVA Ç Ã O N IC S/ REDE
Standard_D2_ 2 8 50 4 3000/46/23 2/1000

v3
TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
T EM P O RÁ RIO
: IO P S/ M B P S
A RM A Z EN A M DE L A RGURA DE
EN TO DISC O S DE L EIT URA / M B P B A N DA
M EM Ó RIA : T EM P O RÁ RIO DA DO S S DE M Á XIM A DE
TA M A N H O VC P U GIB ( SSD) GIB M Á XIM O S GRAVA Ç Ã O N IC S/ REDE
Standard_D4_ 4 16 100 8 6000/93/46 2/2000

v3
Standard_D8_ 8 32 200 16 12000/187/9 4/4000

v3 3
Standard_D16 16 64 400 32 24000/375/1 8/8000

_v3 87
Standard_D32 32 128 800 32 48000/750/3 8/16000

_v3 75
Standard_D48 48 192 1200 32 96000/1000/ 8/24000

_v3 500
Standard_D64 64 256 1600 32 96000/1000/ 8/30000

_v3 500
Dsv3-series
Os tamanhos da série Dsv3 são executados no Intel® Xeon® Platinum 8272CL (Cascade, Lake), Intel®
Xeon® 8171M 2.1 GHz (Skylake), Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou os processadores
Intel® Xeon® E5-2673 v3 2,4 GHz (Haswell) com a ® tecnologia Intel Turbo Boost 2,0 e usam o
armazenamento Premium. Os tamanhos da série Dsv3 oferecem uma combinação de vCPU, memória e
armazenamento temporário para a maioria das cargas de trabalho de produção.
O recurso de VMs da série Dsv3 Intel® Hyper-Threading tecnologia.
ACU: 160-190
TA XA TA XA
DE DE
T RA N SF T RA N SF
ERÊN C I ERÊN C I
A A TA XA
M Á XIM M Á XIM DE
A DE A DE T RA N SF
A RM A Z A RM A Z ERÊN C I
EN A M E EN A M E A
N TO EM N TO EM M Á XIM
CACHE CACHE TA XA A DE M Á XIM
E E DE DISC O O DE
T EM P O T EM P O T RA N SF NÃO N IC S/ L A
A RM A Z RÁ RIA : RÁ RIA ERÊN C I CACHE RGURA
EN A M E IO P S/ M DE A DE DE DE
N TO DISC O S BPS IN T ERM DISC O IN T ERM B A N DA
T EM P O DE ( TA M A N IT ÊN C IA SEM IT ÊN C IA DE REDE
RÁ RIO DA DO S H O DO : C A C H E: : ESP ERA
TA M A N M EM Ó R ( SSD) M Á XIM CACHE IO P S/ M IO P S/ M IO P S/ M DA
HO VC P U IA : GIB GIB OS EM GIB ) B P S1 BPS B P S1 ( M B P S)
Standar 2 8 16 4 4000/3 4000/1 3200/4 4000/1 2/1000

d_D2s_v 2 (50) 00 8 00
3
Standar 4 16 32 8 8000/6 8000/2 6400/9 8000/2 2/2000

d_D4s_v 4 (100) 00 6 00
3
Standar 8 32 64 16 16000/ 16000/ 12800/ 16000/ 4/4000

d_D8s_v 128 400 192 400
3 (200)
Standar 16 64 128 32 32000/ 32000/ 25600/ 32000/ 8/8000

d_D16s_ 256 800 384 800
v3 (400)
Standar 32 128 256 32 64000/ 64000/ 51200/ 64000/ 8/1600

d_D32s_ 512 1600 768 1600 0
v3 (800)
Standar 48 192 384 32 96000/ 96000/ 76800/ 80000/ 8/2400

d_D48s_ 768 2000 1152 2000 0
v3 (1200)
Standar 64 256 512 32 128000 128000 80000/ 80000/ 8/3000

d_D64s_ /1024 /2000 1200 2000 0
v3 (1600)
1 as VMs da série Dsv3 podem estourar o desempenho do disco e chegar até o máximo de pico por até 30
minutos por vez.

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Para obter mais informações sobre tipos de disco, consulte quais tipos de disco estão disponíveis no Azure?
Próximas etapas
Séries Dav4 e Dasv4
As séries Dav4 e Dasv4 são novos tamanhos que utilizam o processador 2.35 GHz EPYCTM 7452 da AMD em
uma configuração multi-threaded com até 256 MB de cache L3, que dedica 8 MB desse cache L3 a cada 8
núcleos aumentando as opções do cliente para executar suas cargas de trabalho de uso geral. As séries Dav4 e
Dasv4 têm as mesmas configurações de memória e disco que as séries Dsv3 e D.
Série Dav4
ACU: 230-260
Os tamanhos da série Dav4 são baseados no processador AMD EPYCTM 7452 de 2.35 GHz que pode alcançar
uma frequência máxima aumentada de 3.35 GHz. Os tamanhos da série Dav4 oferecem uma combinação de
vCPU, memória e armazenamento temporário para a maioria das cargas de trabalho de produção. O
armazenamento do disco de dados é faturado separadamente das máquinas virtuais. Para usar o SSD Premium,
use os tamanhos de Dasv4. Os medidores de cobrança e preço para os tamanhos de Dasv4 são os mesmos que
os da série Dav4.
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
M EN TO
T EM P O RÁ R
A RM A Z EN A IO : IO P S / L A RGURA
M EN TO M B P S DE DE B A N DA
T EM P O RÁ R DISC O S DE L EIT URA / DE REDE
M EM Ó RIA : IO ( SSD) DA DO S M B P S DE M Á XIM O ESP ERA DA
TA M A N H O VC P U GIB GIB M Á XIM O S GRAVA Ç Ã O DE N IC S ( M B P S)
Standard_D 2 8 50 4 3000 / 46 / 2 800

2a_v4 23
Standard_D 4 16 100 8 6000 / 93 / 2 1600

4a_v4 46
Standard_D 8 32 200 16 12000 / 4 3200

8a_v4 187 / 93
Standard_D 16 64 400 32 24000 / 8 6400

16a_v4 375 / 187
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
M EN TO
T EM P O RÁ R
Standard_D 32 128 800 32 48000 / 8 12800

32a_v4 750 / 375
Standard_D 48 192 1200 32 96000/100 8 19200

48a_v4 0/500
Standard_D 64 256 1600 32 96000/100 8 25600

64a_v4 0/500
Standard_D 96 384 2400 32 96000/100 8 32000

96a_v4 0/500
Série Dasv4
ACU: 230-260
Os tamanhos da série Dasv4 são baseados no processador AMD EPYCTM 7452 de 2.35 GHz que pode alcançar
uma frequência máxima aumentada de 3.35 GHz e usar SSD Premium. Os tamanhos da série Dasv4 oferecem
uma combinação de vCPU, memória e armazenamento temporário para a maioria das cargas de trabalho de
produção.
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE TA XA DE
A RM A Z E T RA N SF E
N A M EN T RÊN C IA
O M Á XIM A
T EM P O R DO
Á RIO : DISC O
A RM A Z E IO P S / NÃO L A RGURA
N A M EN T DISC O S MBPS A RM A Z E DE
O DE ( TA M A N N A DO EM B A N DA
TA M A N H M EM Ó RI Á RIO M Á XIM O CACHE IO P S / M Á XIM O ESP ERA D
O VC P U A : GIB ( SSD) GIB S EM GIB ) MBPS DE N IC S A ( M B P S)
Standard_ 2 8 16 4 4000/32 3200/48 2 800

D2as_v4 (50)
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE TA XA DE
O M Á XIM A
T EM P O R DO
Á RIO : DISC O
Standard_ 4 16 32 8 8000/64 6400/96 2 1600

D4as_v4 (100)
Standard_ 8 32 64 16 16000/12 12800/19 4 3200

D8as_v4 8 (200) 2
Standard_ 16 64 128 32 32000/25 25600/38 8 6400

D16as_v4 5 (400) 4
Standard_ 32 128 256 32 64000/51 51200/76 8 12800

D32as_v4 0 (800) 8
Standard_ 48 192 384 32 96000/10 76800/11 8 19200

D48as_v4 20 (1200) 48
Standard_ 64 256 512 32 128000/1 80000/12 8 25600

D64as_v4 020 00
(1600)
Standard_ 96 384 768 32 192000/1 80000/12 8 32000

D96as_v4 020 00
(2400)

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Séries Ddv4 e Ddsv4
As séries Ddv4 e Ddsv4 são executadas nos processadores Intel® Xeon® Platinum 8272CL (Cascade Lake)
em uma configuração hyper-threaded, fornecendo uma proposta de valor melhor para as cargas de trabalho de
uso geral. Ele apresenta uma velocidade de clock de Turbo principal de 3,4 GHz , ® tecnologia Intel Turbo Boost
2,0, ® tecnologia Intel Hyper-Threading e extensões de ® vetor avançadas Intel 512 (Intel ® AVX-512). Eles
também dão suporte ao ® aumento de aprendizado profundo da Intel. Esses novos tamanhos de VM terão um
armazenamento local 50% maior, bem como um melhor IOPS de disco local para leitura e gravação em
comparação com os tamanhos Dv3/Dsv3 com VMs Gen2.
Os casos de uso da série D incluem aplicativos de nível empresarial, bancos de dados relacionais, cache em
memória e análises.
Série Ddv4
Os tamanhos da série Ddv4 são executados no Intel® Xeon® Platinum 8272CL (Cascade Lake). A série Ddv4
oferece uma combinação de vCPU, memória e disco temporário para a maioria das cargas de trabalho de
produção.
Os novos tamanhos de VM Ddv4 incluem um armazenamento SSD local mais rápido e maior (até 2.400 GiB) e
são projetados para aplicativos que se beneficiam de armazenamento local de alta velocidade e baixa latência,
como aplicativos que exigem leituras/gravações rápidas em armazenamento temporário ou que precisam de
armazenamento temporário para caches ou arquivos temporários. Você pode anexar armazenamento de SSDs
Standard e HDDs Standard às VMs Ddv4. O armazenamento em disco de dados remotos é cobrado
separadamente das máquinas virtuais.
ACU: 195-210
** TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
A RM A Z EN A M EN TO EM L A RGURA
M EN TO CACHE E DE B A N DA
T EM P O RÁ R DISC O S DE T EM P O RÁ R DE REDE
M EM Ó RIA : IO ( SSD) DA DO S IA : M Á XIM O ESP ERA DA
TA M A N H O VC P U GIB GIB M Á XIM O S IO P S/ M B P S DE N IC S ( M B P S)
Standard_D 2 8 75 4 19000/120 2 1000

2d_v4
Standard_D 4 16 150 8 38500/242 2 2000

4d_v4
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
Standard_D 8 32 300 16 77000/485 4 4000

8d_v4
Standard_D 16 64 600 32 154000/96 8 8000

16d_v4 8
Standard_D 32 128 1200 32 308000/19 8 16000

32d_v4 36
Standard_D 48 192 1800 32 462000/29 8 24.000

48d_v4 04
Standard_D 64 256 2400 32 615000/38 8 30000

64d_v4 72
** Esses valores de IOPs podem ser garantidos usando VMs Gen2
Série Ddsv4
A série Ddsv4 é executada no Intel® Xeon® Platinum 8272CL (Cascade Lake). A série Ddsv4 oferece uma
combinação de vCPU, memória e disco temporário para a maioria das cargas de trabalho de produção.
Os novos tamanhos de VM Ddsv4 incluem um armazenamento SSD local mais rápido e maior (até 2.400 GiB) e
são projetados para aplicativos que se beneficiam de armazenamento local de alta velocidade e baixa latência,
como aplicativos que exigem leituras/gravações rápidas em armazenamento temporário ou que precisam de
armazenamento temporário para caches ou arquivos temporários.
NOTE
Os medidores de cobrança e preço para os tamanhos da Ddsv4 são os mesmos que os da série Ddv4.
ACU: 195-210
** TA XA
DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
Standard_ 2 8 75 4 19000/12 3200/48 2 1000

D2ds_v4 0(50)
Standard_ 4 16 150 8 38500/24 6400/96 2 2000

D4ds_v4 2(100)
Standard_ 8 32 300 16 77000/48 12800/19 4 4000

D8ds_v4 5(200) 2
Standard_ 16 64 600 32 154000/9 25600/38 8 8000

D16ds_v 68(400) 4
4
Standard_ 32 128 1200 32 308000/1 51200/76 8 16000

D32ds_v 936(800) 8
4
Standard_ 48 192 1800 32 462000/2 76800/11 8 24.000

D48ds_v 904(1200 52
4 )
Standard_ 64 256 2400 32 615000/3 80000/12 8 30000

D64ds_v 872(1600 00
4 )

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Séries Dv4 e Dsv4
A dv4 e a série Dsv4 são executadas nos ® processadores Intel Xeon ® Platinum 8272CL (cascadey Lake) em
uma configuração de hiperthread, fornecendo uma proposta de valor melhor para as cargas de trabalho de uso
geral. Ele apresenta uma velocidade de clock de Turbo principal de 3,4 GHz.
NOTE
Para perguntas frequentes, consulte tamanhos de VM do Azure sem disco temporário local.
Série dv4
Os tamanhos da série dv4 são executados no Intel ® Xeon ® Platinum 8272CL (cascadey Lake). Os tamanhos
da série dv4 oferecem uma combinação de vCPU, memória e opções de armazenamento remoto para a maioria
das cargas de trabalho de produção. As VMs da série dv4 apresentam a ® tecnologia Intel Hyper-Threading.
O armazenamento em disco de dados remotos é cobrado separadamente das máquinas virtuais. Para usar
discos de armazenamento Premium, use os tamanhos de Dsv4. Os medidores de cobrança e preço para os
tamanhos de Dsv4 são os mesmos que os da série dv4.
ACU: 195-210
L A RGURA DE
A RM A Z EN A M B A N DA DE
EN TO DISC O S DE REDE
M EM Ó RIA : T EM P O RÁ RIO DA DO S M Á XIM O DE ESP ERA DA
TA M A N H O VC P U GIB ( SSD) GIB M Á XIM O S N IC S ( M B P S)
Standard_D2_ 2 8 Somente 4 2 1000

v4 armazenamen
to remoto

v4 armazenamen
to remoto

v4 armazenamen
to remoto
Standard_D16 16 64 Somente 32 8 8000

_v4 armazenamen
to remoto
L A RGURA DE

_v4 armazenamen
to remoto
Standard_D48 48 192 Somente 32 8 24.000

_v4 armazenamen
to remoto

_v4 armazenamen
to remoto
Série Dsv4
Os tamanhos da série Dsv4 são executados no Intel ® Xeon ® Platinum 8272CL (cascadey Lake). Os
tamanhos da série dv4 oferecem uma combinação de vCPU, memória e opções de armazenamento remoto para
a maioria das cargas de trabalho de produção. As VMs da série Dsv4 apresentam a ® tecnologia Intel Hyper-
Threading. O armazenamento em disco de dados remotos é cobrado separadamente das máquinas virtuais.
ACU: 195-210
TA XA DE
A RM A Z EN A T RA N SF ERÊ L A RGURA
M EN TO N C IA DE DE B A N DA
T EM P O RÁ R DISC O S DE DISC O SEM DE REDE
M EM Ó RIA : IO ( SSD) DA DO S C A C H E: M Á XIM O ESP ERA DA
Standard_D 2 8 Somente 4 3200/48 2 1000

2s_v4 armazenam
ento
remoto

4s_v4 armazenam
ento
remoto

8s_v4 armazenam
ento
remoto
TA XA DE

16s_v4 armazenam
ento
remoto

32s_v4 armazenam
ento
remoto
Standard_D 48 192 Somente 32 76800/115 8 24.000

48s_v4 armazenam 2
ento
remoto

64s_v4 armazenam 0
ento
remoto
Compute tamanhos de máquinas virtuais
otimizadas
Os tamanhos de VM otimizados para computação têm uma alta taxa de CPU para memória. Esses tamanhos são
bons para servidores Web de tráfego médio, dispositivos de rede, processos em lote e servidores de aplicativos.
Este artigo fornece informações sobre o número de vCPUs, discos de dados e NICs. Ele também inclui
informações sobre a taxa de transferência de armazenamento e a largura de banda de rede para cada tamanho
neste agrupamento.
A série Fsv2 é executada na 2ª geração de processadores Intel® Xeon® platina 8272CL (cascadey Lake) e
processadores Intel® Xeon® Platinum 8168 (Skylake). Ele apresenta uma velocidade de clock de Turbo
principal de 3,4 GHz e uma frequência máxima de Turbo de núcleo único de 3,7 GHz. As instruções Intel® AVX-
512 são novas em processadores escalonáveis da Intel. Essas instruções fornecem um aumento de desempenho
2X para cargas de trabalho de processamento de vetores em operações de ponto flutuante de precisão única e
dupla. Em outras palavras, eles são realmente rápidos para qualquer carga de trabalho computacional.
A um preço de lista por hora inferior, a série Fsv2 é o melhor valor de preço/desempenho no portfólio do Azure
com base na ACU (Unidade de Computação do Azure) por vCPU.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série Fsv2
A série Fsv2 é executada nos processadores Intel® Xeon® Platinum 8272CL (Cascadey Lake) e processadores
Intel® Xeon® Platinum 8168 (Skylake). Ele apresenta uma velocidade de clock de Turbo principal de 3,4 GHz
e uma frequência máxima de Turbo de núcleo único de 3,7 GHz. As instruções Intel® AVX-512 são novas em
processadores escalonáveis da Intel. Essas instruções fornecem um aumento de desempenho 2X para cargas de
trabalho de processamento de vetores em operações de ponto flutuante de precisão única e dupla. Em outras
palavras, eles são realmente rápidos para qualquer carga de trabalho computacional.
O recurso de VMs da série Fsv2 Intel® Hyper-Threading tecnologia.
ACU: 195-210
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
O DA VC P U A : GIB ( SSD) GIB S EM GIB ) PS DE N IC S A ( M B P S)
Standard_ 2 4 16 4 4000/31 3200/47 2 875

F2s_v2 (32)
Standard_ 4 8 32 8 8000/63 6400/95 2 1750

F4s_v2 (64)
Standard_ 8 16 64 16 16000/12 12800/19 4 3500

F8s_v2 7 (128) 0
Standard_ 16 32 128 32 32000/25 25600/38 4 7000

F16s_v2 5 (256) 0
Standard_ 32 64 256 32 64000/51 51200/75 8 14000

F32s_v2 2 (512) 0
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
O DA VC P U A : GIB ( SSD) GIB S EM GIB ) PS DE N IC S A ( M B P S)
Standard_ 48 96 384 32 96000/76 76800/11 8 21000

F48s_v2 8 (768) 00
Standard_ 64 128 512 32 128000/1 80000/11 8 28000

F64s_v2 024 00
(1024)
Standard_ 72 144 576 32 144000/1 80000/11 8 30000

F72s_v21, 152 00
2 (1520)
1 o uso de mais de 64 vCPU exige um destes sistemas operacionais convidados com suporte:
Windows Server 2016 ou posterior
Ubuntu 16, 4 LTS ou posterior, com kernel ajustado do Azure (kernel 4,15 ou posterior)
SLES 12 SP2 ou posterior
RHEL ou CentOS versão 6,7 até 6,10, com o pacote LIS fornecido pela Microsoft 4.3.1 (ou posterior) instalado
RHEL ou CentOS versão 7,3, com o pacote LIS fornecido pela Microsoft 4.2.1 (ou posterior) instalado
RHEL ou CentOS versão 7,6 ou posterior
Oracle Linux com UEK4 ou posterior
Debian 9 com o kernel de backports, Debian 10 ou posterior
CoreOS com um kernel 4,14 ou posterior
2 A instância é isolada em hardware dedicado a um único cliente.

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Tamanhos de máquinas virtuais com GPU
otimizadas para memória
Os tamanhos de VM com otimização de memória oferecem uma alta taxa de memória para CPU que é excelente
para servidores de banco de dados relacionais, caches médios a grandes e análise na memória. Este artigo
fornece informações sobre o número de vCPUs, discos de dados e NICs, bem como a taxa de transferência de
armazenamento e largura de banda de rede para cada tamanho neste agrupamento.
As séries Dv2 e DSv2, uma continuação da série D original, traz uma CPU com mais potência. A série Dv2
é aproximadamente 35% mais rápida do que a série D. Ela é executado nos processadores Intel®
Xeon® 8171M 2,1 GHz (Skylake) ou Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou Intel®
Xeon® E5-2673 v3 2,4 GHz (Haswell) e com a Tecnologia Intel Turbo Boost 2.0. A série Dv2 tem as
mesmas configurações de memória e disco que a série D.
As séries Dv2 e DSv2 são ideais para aplicativos que exigem vCPUs mais rápidas, melhor desempenho de
armazenamento temporário ou que tenham maior demanda de memória. Elas oferecem uma
combinação poderosa para vários aplicativos de nível empresarial.
As séries Eav4 e Easv4 utilizam o processador EPYCTM 7452 2,35 GHz da AMD em uma configuração
com multi-thread e um cache L3 de até 256 MB, aumentando as opções para executar a maioria das
cargas de trabalho otimizadas para memória. As séries Eav4 e Easv4 têm as mesmas configurações de
memória e disco que as séries Ev3 e Esv3.
O processador Intel® Xeon® 8171M 2,1 GHz (Skylake) ou Intel® Xeon® E5-2673 v4 2,3 GHz
(Broadwell) das séries Ev3 e Esv3 em uma configuração hyper-threaded, fornecendo uma melhor
proposta de valor para a maioria das cargas de trabalho de uso geral e levando a Ev3 para o alinhamento
com as VMs de uso geral da maioria das outras nuvens. A memória foi expandida (de 7 GiB/vCPU a 8
GiB/vCPU), enquanto os limites de rede e disco por núcleo para alinhamento com a migração para o
hyper-threading. A série Ev3 é o acompanhamento até os tamanhos de VM de memória alta das famílias
D/Dv2.
As Ev4 e a série Esv4 são executadas nos processadores da 2ª geração Intel ® Xeon ® Platinum
8272CL (cascadey Lake) em uma configuração de hiperthread, são ideais para vários aplicativos
empresariais com uso intensivo de memória e recursos até 504 GiB de RAM. Ele apresenta a tecnologia
Intel ® Turbo Boost 2,0, a ® tecnologia Intel Hyper-Threading e ® as extensões de vetor avançadas
Intel 512 (Intel AVX-512). As Ev4 e Esv4-Series não incluem um disco temporário local. Para obter mais
informações, consulte tamanhos de VM do Azure sem disco temporário local.
A Edv4 e a série Edsv4 são executadas em processadores de 2ª geração Intel ® Xeon ® Platinum
8272CL (Cascade, Lake), ideais para bancos de dados muito grandes ou outros aplicativos que se
beneficiam de contagens de vCPU altas e grandes quantidades de memória. Além disso, esses tamanhos
de VM incluem um armazenamento de SSD local rápido e maior para aplicativos que se beneficiam de
armazenamento local de alta velocidade e de baixa latência. Ele apresenta uma velocidade de clock de
Turbo principal de 3,4 GHz , ® tecnologia Intel Turbo Boost 2,0, ® tecnologia Intel Hyper-Threading e
extensões de ® vetor avançadas Intel 512 (Intel AVX-512).
A série M oferece uma alta contagem de vCPU (até 128 vCPUs) e uma grande quantidade de memória
(até 3,8 TiB). Ela também é ideal para bancos de dados extremamente grandes ou outros aplicativos que
se beneficiam de altas contagens de vCPU e de grandes quantidades de memória.
A série Mv2 oferece a mais alta contagem de vCPU (até 416 vCPUs) e a maior memória (até 11,4 TiB) de
qualquer VM na nuvem. Ela é ideal para bancos de dados extremamente grandes ou outros aplicativos
que se beneficiam de altas contagens de vCPU e de grandes quantidades de memória.
A Computação do Azure oferece tamanhos de máquina virtual Isolada, para um tipo de hardware específico e
dedicada a um único cliente. Esses tamanhos de máquina virtual são mais adequados para cargas de trabalho
que exigem um alto grau de isolamento de outros clientes, para cargas de trabalho que envolvem elementos
como requisitos normativos e de conformidade. Os clientes também podem optar por subdividir ainda mais os
recursos dessas máquinas virtuais Isoladas usando o Suporte do Azure para máquinas virtuais aninhadas.
Confira as páginas das famílias de máquina virtual abaixo para obter as opções de VM isoladas.
Outros tamanhos
Propósito geral
GPU otimizada
Próximas etapas
Dv2 com otimização de memória e série Dsv2
A Dv2 e a série Dsv2, uma continuação da série D original, apresenta uma CPU mais potente. Os tamanhos da
série DSv2 são executados no Intel® Xeon® Platinum 8272CL (Cascadey Lake), no Intel® Xeon® 8171M
2,1 GHz (Skylake) ou no Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou nos processadores Intel®
Xeon® E5-2673 v3 2,4 GHz (Haswell). A série Dv2 tem as mesmas configurações de memória e disco que a
série D.
Série Dv2 11-15

Os tamanhos da série Dv2 são executados no Intel® Xeon® Platinum 8272CL (Cascadey Lake), no Intel®
Xeon® 8171M 2,1 GHz (Skylake) ou no Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou nos
processadores Intel® Xeon® E5-2673 v3 2,4 GHz (Haswell).
ACU: 210-250
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
M EN TO
IO : DE DISC O S
TA M A N H O VC P U GIB GIB GRAVA Ç Ã O N C IA : IO P S DE N IC S ( M B P S)
Standard_D 2 14 100 6000/93/4 8/8x500 2 1500

11_v2 6
Standard_D 4 28 200 12000/187 16/16x500 4 3000

12_v2 /93
Standard_D 8 56 400 24000/375 32/32x500 8 6000

13_v2 /187
Standard_D 16 112 800 48000/750 64/64x500 8 12000

14_v2 /375
Standard_D 20 140 1000 60000/937 64/64x500 8 25000 2

15_v2 1 /468
1 2
1 A instância é isolada em hardware dedicado a um único cliente. 2 25000 Mbps com Rede Acelerada.
Série DSv2 11-15

Os tamanhos da série DSv2 são executados no Intel® Xeon® Platinum 8272CL (Cascadey Lake), no Intel®
Xeon® 8171M 2,1 GHz (Skylake) ou no Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou nos
processadores Intel® Xeon® E5-2673 v3 2,4 GHz (Haswell).
ACU: 210-250 1
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
Standard_ 2 14 28 8 8000/64 6400/96 2 1500

DS11_v2 (72)
3
Standard_ 4 28 56 16 16000/12 12800/19 4 3000

DS12_v2 8 (144) 2
3
Standard_ 8 56 112 32 32000/25 25600/38 8 6000

DS13_v2 6 (288) 4
3
Standard_ 16 112 224 64 64000/51 51200/76 8 12000

DS14_v2 2 (576) 8
3
Standard_ 20 140 280 64 80000/64 64000/96 8 25000 4

DS15_v2 0 (720) 0
2
1 A taxa de transferência máxima possível do disco (IOPS ou MBps) com uma VM da série DSv2 pode ser
limitada pelo número, tamanho e distribuição dos discos anexados. Para obter detalhes, confira o artigo Projetar
para um alto desempenho. 2 a instância é isolada para o hardware baseado em Intel Haswell e dedicada a um
único cliente.
3 Tamanhos limitados de núcleos disponíveis.
4
4 25000 Mbps com Rede Acelerada.

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Séries Ev3 e Esv3
A Ev3 e a série Esv3 são executadas no Intel® Xeon® Platinum 8272CL (Cascade Lake), ou o Intel® Xeon®
8171M 2,1 GHz (Skylake) ou o processador Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) em uma
configuração de hiperthread, fornecendo uma proposta de valor melhor para as cargas de trabalho de uso geral
e trazendo a Ev3 para o alinhamento com as VMs de uso geral da maioria das outras nuvens. A memória foi
expandida (de 7 GiB/vCPU para 8 GiB/vCPU) enquanto os limites de rede e disco foram ajustados em uma base
por núcleo para alinhar com a mudança para o hyperthreading. A série Ev3 é o acompanhamento até os
tamanhos de VM de memória alta das famílias D/Dv2.
Ev3-series
As instâncias da série Ev3 são executadas no Intel® Xeon® Platinum 8272CL (Cascadey Lake), no Intel®
Xeon® 8171M 2,1 GHz (Skylake) ou nos processadores Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) e no
recurso Intel Turbo Boost Technology 2,0. As instâncias Ev3-series são ideais para aplicativos empresariais com
uso intensivo de memória.
O armazenamento do disco de dados é faturado separadamente das máquinas virtuais. Para usar discos de
armazenamento premium, use os tamanhos ESv3. Os medidores de cobrança e preço para os tamanhos Esv3
são os mesmos da Ev3-series.
O recurso da VM da série Ev3 Intel® Hyper-Threading tecnologia.
ACU: 160-190
TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
T EM P O RÁ RIO N IC S
A RM A Z EN A M : IO P S / M B P S M Á XIM A S /
EN TO DISC O S DE DE L EIT URA / L A RGURA DE
M EM Ó RIA : T EM P O RÁ RIO DA DO S M B P S DE B A N DA DA
TA M A N H O VC P U GIB ( SSD) GIB M Á XIM O S GRAVA Ç Ã O REDE
Standard_E2_ 2 16 50 4 3000/46/23 2/1000

v3
Standard_E4_ 4 32 100 8 6000/93/46 2/2000

v3
Standard_E8_ 8 64 200 16 12000/187/9 4/4000

v3 3
TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
T EM P O RÁ RIO N IC S
A RM A Z EN A M : IO P S / M B P S M Á XIM A S /
EN TO DISC O S DE DE L EIT URA / L A RGURA DE
M EM Ó RIA : T EM P O RÁ RIO DA DO S M B P S DE B A N DA DA
TA M A N H O VC P U GIB ( SSD) GIB M Á XIM O S GRAVA Ç Ã O REDE
Standard_E16 16 128 400 32 24000/375/1 8/8000

_v3 87
Standard_E20 20 160 500 32 30000/469/2 8/10000

_v3 34
Standard_E32 32 256 800 32 48000/750/3 8/16000

_v3 75
Standard_E48 48 384 1200 32 96000/1000/ 8/24000

_v3 500
Standard_E64 64 432 1600 32 96000/1000/ 8/30000

_v3 500
Standard_E64i 64 432 1600 32 96000/1000/ 8/30000

_v3 1, 2 500
1 tamanhos de núcleos restritos disponíveis.
Série Esv3
As instâncias da série Esv3 são executadas no Intel® Xeon® Platinum 8272CL (Cascadey Lake), no Intel®
Xeon® 8171M 2,1 GHz (Skylake) ou no processador Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell), o
recurso Intel Turbo Boost Technology 2,0 e usa o armazenamento Premium. As instâncias da série Esv3 são
ideais para aplicativos empresariais com uso intensivo de memória.
O recurso da VM da série Esv3 Intel® Hyper-Threading tecnologia.
ACU: 160-190
TA XA
DE
T RA N SF TA XA
ERÊN C I DE TA XA
A T RA N SF DE
M Á XIM ERÊN C I T RA N SF
A DE A DE ERÊN C I
A RM A Z A RM A Z A DE
EN A M E EN A M E DISC O
N TO EM N TO NÃO
CACHE T EM P O TA XA A RM A Z M Á XIM
E RÁ RIO E DE EN A DO O DE
T EM P O EM T RA N SF EM N IC S/ L A
A RM A Z RÁ RIA : CACHE ERÊN C I CACHE RGURA
EN A M E IO P S/ M DE A DE DE DE
N TO DISC O S BPS IN T ERM DISC O IN T ERM B A N DA
T EM P O DE ( TA M A N IT ÊN C IA SEM IT ÊN C IA DE REDE
RÁ RIO DA DO S H O DO : C A C H E: : ESP ERA
TA M A N M EM Ó R ( SSD) M Á XIM CACHE IO P S/ M IO P S/ M IO P S/ M DA
HO VC P U IA : GIB GIB OS EM GIB ) B P S3 BPS B P S3 ( M B P S)
Standar 2 16 32 4 4000/3 4000/1 3200/4 4000/1 2/1000

d_E2s_v 2 (50) 00 8 00
3
Standar 4 32 64 8 8000/6 8000/2 6400/9 8000/2 2/2000

d_E4s_v 4 (100) 00 6 00
31
Standar 8 64 128 16 16000/ 16000/ 12800/ 16000/ 4/4000

d_E8s_v 128 400 192 400
31 (200)
Standar 16 128 256 32 32000/ 32000/ 25600/ 32000/ 8/8000

d_E16s_ 256 800 384 800
v3 1 (400)
Standar 20 160 320 32 40000/ 40000/ 32000/ 40000/ 8/1000

d_E20s_ 320 1000 480 1000 0
v3 (400)
Standar 32 256 512 32 64000/ 64000/ 51200/ 64000/ 8/1600

d_E32s_ 512 1600 768 1600 0
v3 1 (800)
Standar 48 384 768 32 96000/ 96000/ 76800/ 80000/ 8/2400

d_E48s_ 768 2000 1152 2000 0
v3 1 (1200)
Standar 64 432 864 32 128000 128000 80000/ 80000/ 8/3000

d_E64s_ /1024 /2000 1200 2000 0
v3 1 (1600)
Standar 64 432 864 32 128000 128000 80000/ 80000/ 8/3000

d_E64is_ /1024 /2000 1200 2000 0
v3 2 (1600)

3 as VMs da série Esv3 podem estourar o desempenho do disco e chegar até o máximo de pico por até 30
minutos por vez.
= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Para obter mais informações sobre tipos de disco, consulte quais tipos de disco estão disponíveis no Azure?
Próximas etapas
Séries Eav4 e Easv4
A série Eav4 e a Easv4 utilizam o processador de 2.35 GHz EPYCTM 7452 em uma configuração multi-threaded
com até 256 MB de cache L3, aumentando as opções para executar a maioria das cargas de trabalho com
otimização de memória. As séries Eav4 e Easv4 têm as mesmas configurações de memória e disco que as séries
Ev3 e Esv3.
Série Eav4
ACU: 230-260
Suporte à geração de VM: gerações 1 e 2
Os tamanhos da série Eav4 são baseados no processador AMD EPYCTM 7452 de 2.35 GHz que pode alcançar
uma frequência máxima aumentada de 3.35 GHz. Os tamanhos da série Eav4 são ideais para aplicativos
empresariais com uso intensivo de memória. O armazenamento do disco de dados é faturado separadamente
das máquinas virtuais. Para usar o SSD Premium, use os tamanhos da série Easv4. Os medidores de cobrança e
preço para os tamanhos de Easv4 são os mesmos que os da série Eav3.
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
M EN TO
T EM P O RÁ R
_E2a _ v4 2 16 50 4 3000 / 46 / 2 800

padrão 23
_E4a _ v4 4 32 100 8 6000 / 93 / 2 1600

padrão 46
_E8a _ v4 8 64 200 16 12000 / 4 3200

padrão 187 / 93
_E16a _ v4 16 128 400 32 24000 / 8 6400

padrão 375 / 187
_E20a _ v4 20 160 500 32 30000/468 8 8000

padrão /234
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
M EN TO
T EM P O RÁ R
_E32a _ v4 32 256 800 32 48000 / 8 12800

padrão 750 / 375
_E48a _ v4 48 384 1200 32 96000/100 8 19200

padrão 0 (500)
_E64a _ v4 64 512 1600 32 96000/100 8 25600

padrão 0 (500)
_E96a _ v4 96 672 2400 32 96000/100 8 32000

padrão 0 (500)
Série Easv4
ACU: 230-260
Suporte à geração de VM: gerações 1 e 2
Os tamanhos da série Easv4 são baseados no processador AMD EPYCTM 7452 de 2.35 GHz que pode alcançar
uma frequência máxima aumentada de 3.35 GHz e usar SSD Premium. Os tamanhos da série Easv4 são ideais
para aplicativos empresariais com uso intensivo de memória.
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE TA XA DE
O M Á XIM A
T EM P O R DO
Á RIO : DISC O
Standard_ 2 16 32 4 4000/32 3200/48 2 800

E2as_v4 (50)
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE TA XA DE
O M Á XIM A
T EM P O R DO
Á RIO : DISC O
Standard_ 4 32 64 8 8000/64 6400/96 2 1600

E4as_v4 (100)
Standard_ 8 64 128 16 16000/12 12800/19 4 3200

E8as_v4 8 (200) 2
Standard_ 16 128 256 32 32000/25 25600/38 8 6400

E16as_v4 5 (400) 4
Standard_ 20 160 320 32 40000/32 32000/48 8 8000

E20as_v4 0 (500) 0
Standard_ 32 256 512 32 64000/51 51200/76 8 12800

E32as_v4 0 (800) 8
Standard_ 48 384 768 32 96000/10 76800/11 8 19200

E48as_v4 20 (1200) 48
Standard_ 64 512 1024 32 128000/1 80000/12 8 25600

E64as_v4 020 00
(1600)
Standard_ 96 672 1344 32 192000/1 80000/12 8 32000

E96as_v4 020 00
1 (2400)

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Séries Edv4 e Edsv4
As séries Edv4 e Edsv4 são executadas nos processadores Intel® Xeon® Platinum 8272CL (Cascade Lake) em
uma configuração hyper-threaded e são ideais para vários aplicativos empresariais com uso intensivo de
memória e contam com até 504 GiB de RAM, com Tecnologia Intel® Turbo Boost 2.0, Tecnologia Intel®
Hyper-Threading e Intel® Advanced Vector Extensions 512 (Intel® AVX-512). Eles também dão suporte ao ®
aumento de aprendizado profundo da Intel. Esses novos tamanhos de VM terão 50% de armazenamento local
maior, bem como um IOPS de disco local melhor para leitura e gravação em comparação com os tamanhos de
Ev3/Esv3 com VMs Gen2. Ele apresenta uma velocidade de clock de Turbo principal de 3,4 GHz.
Série Edv4
Os tamanhos da série Edv4 são executados nos processadores Intel® Xeon® Platinum 8272CL (Cascade
Lake). Os tamanhos de máquina virtual Edv4 contam com até 504 GiB de RAM, além de um armazenamento
SSD local grande e rápido (de até 2.400 GiB). Essas máquinas virtuais são ideais para aplicativos empresariais
com uso intensivo de memória e aplicativos que se beneficiam de armazenamento local de alta velocidade e
baixa latência. Você pode anexar armazenamentos em disco SSDs Standard e HDDs Standard às VMs Edv4.
ACU: 195-210
** TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
Standard_E 2 16 75 4 19000/120 2 1000

2d_v4
Standard_E 4 32 150 8 38500/242 2 2000

4d_v4
Standard_E 8 64 300 16 77000/485 4 4000

8d_v4
Standard_E 16 128 600 32 154000/96 8 8000

16d_v4 8
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
Standard_E 20 160 750 32 193000/12 8 10000

20d_v4 11
Standard_E 32 256 1200 32 308000/19 8 16000

32d_v4 36
Standard_E 48 384 1800 32 462000/29 8 24.000

48d_v4 04
Standard_E 64 504 2400 32 615000/38 8 30000

64d_v4 72
Série Edsv4
Os tamanhos da série Edsv4 são executados nos processadores Intel® Xeon® Platinum 8272CL (Cascade
Lake). Os tamanhos de máquina virtual Edsv4 contam com até 504 GiB de RAM, além de um armazenamento
SSD local grande e rápido (de até 2.400 GiB). Essas máquinas virtuais são ideais para aplicativos empresariais
com uso intensivo de memória e aplicativos que se beneficiam de armazenamento local de alta velocidade e
baixa latência.
ACU: 195-210
** TA XA
DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
Standard_ 2 16 75 4 19000/12 3200/48 2 1000

E2ds_v4 0(50)
Standard_ 4 32 150 8 38500/24 6400/96 2 2000

E4ds_v4 2(100)
Standard_ 8 64 300 16 77000/48 12800/19 4 4000

E8ds_v4 5(200) 2
Standard_ 16 128 600 32 154000/9 25600/38 8 8000

E16ds_v4 68(400) 4
Standard_ 20 160 750 32 193000/1 32000/48 8 10000

E20ds_v4 211(500) 0
Standard_ 32 256 1200 32 308000/1 51200/76 8 16000

E32ds_v4 936(800) 8
Standard_ 48 384 1800 32 462000/2 76800/11 8 24.000

E48ds_v4 904(1200 52
)
Standard_ 64 504 2400 32 615000/3 80000/12 8 30000

E64ds_v4 872(1600 00
1 )
Standard_ 80 504 2400 32 615000/3 80000/12 8 30000

E80ids_v 872(1600 00
42 )
1 Tamanhos limitados de núcleos disponíveis).

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Séries Ev4 e Esv4
As Ev4 e a série Esv4 são executadas nos ® processadores Intel Xeon ® Platinum 8272CL (cascadey Lake) em
uma configuração de hiperthread, são ideais para vários aplicativos empresariais com uso intensivo de
memória e recursos até 504GIB de RAM. Ele apresenta uma velocidade de clock de Turbo principal de 3,4 GHz.
NOTE
Para perguntas frequentes, consulte tamanhos de VM do Azure sem disco temporário local.
Série Ev4
Os tamanhos da série Ev4 são executados no Intel Xeon ® Platinum 8272CL (cascadey Lake). As instâncias da
série Ev4 são ideais para aplicativos empresariais com uso intensivo de memória. As VMs da série Ev4
apresentam a ® tecnologia Intel Hyper-Threading.
O armazenamento em disco de dados remotos é cobrado separadamente das máquinas virtuais. Para usar
discos de armazenamento Premium, use os tamanhos de Esv4. Os medidores de cobrança e preço para os
tamanhos de Esv4 são os mesmos que os da série Ev4.
ACU: 195-210
L A RGURA DE
Standard_E2_ 2 16 Somente 4 2 1000

v4 armazenamen
to remoto

v4 armazenamen
to remoto

v4 armazenamen
to remoto
Standard_E16 16 128 Somente 32 8 8000

_v4 armazenamen
to remoto
L A RGURA DE

_v4 armazenamen
to remoto

_v4 armazenamen
to remoto
Standard_E48 48 384 Somente 32 8 24.000

_v4 armazenamen
to remoto

_v4 armazenamen
to remoto
Série Esv4
Os tamanhos da série Esv4 são executados no Intel ® Xeon ® Platinum 8272CL (cascadey Lake). As instâncias
da série Esv4 são ideais para aplicativos empresariais com uso intensivo de memória. As VMs da série Evs4
apresentam a ® tecnologia Intel Hyper-Threading. O armazenamento em disco de dados remotos é cobrado
separadamente das máquinas virtuais.
ACU: 195-210
TA XA DE
Standard_E 2 16 Somente 4 3200/48 2 1000

2s_v4 armazenam
ento
remoto

4s_v4 armazenam
ento
remoto
TA XA DE

8s_v4 armazenam
ento
remoto

16s_v4 armazenam
ento
remoto

20s_v4 armazenam
ento
remoto

32s_v4 armazenam
ento
remoto
Standard_E 48 384 Somente 32 76800/115 8 24.000

48s_v4 armazenam 2
ento
remoto

64s_v4 1 armazenam 0
ento
remoto

80is_v4 2 armazenam 0
ento
remoto
1 Tamanhos limitados de núcleos disponíveis).

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série M
A série M oferece uma alta contagem de vCPU (até 128 vCPUs) e uma grande quantidade de memória (até 3,8
TiB). Ela também é ideal para bancos de dados extremamente grandes ou outros aplicativos que se beneficiam
de altas contagens de vCPU e de grandes quantidades de memória. Os tamanhos da série M têm suporte no
Intel ® Xeon ® CPU E7-8890 v3 @ 2,50 GHz e no Intel ® Xeon ® Platinum 8280M (cascadey Lake).
O recurso da VM da série M tem a ® tecnologia Intel Hyper-Threading.
ACU: 160-180
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Acelerador de gravação: com suporte
Rede acelerada: com suporte
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
Standard_ 8 218,75 256 8 10000/10 5000/125 4 2000

M8ms 0 (793)
Standard_ 16 437,5 512 16 20000/20 10000/25 8 4000

M16ms 0 (1587) 0
Standard_ 32 192 1024 32 40000/40 20000/50 8 8000

M32ts 0 (3174) 0
Standard_ 32 256 1024 32 40000/40 20000/50 8 8000

M32ls 0 (3174) 0
Standard_ 32 875 1024 32 40000/40 20000/50 8 8000

M32ms 0 (3174) 0
Standard_ 64 1024 2.048 64 80000/80 40000/10 8 16000

M64s 1 0 (6348) 00
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE
A RM A Z E
N A M EN T
O EM
CACHE E
T EM P O R TA XA DE
Standard_ 64 512 2.048 64 80000/80 40000/10 8 16000

M64ls 1 0 (6348) 00
Standard_ 64 1792 2.048 64 80000/80 40000/10 8 16000

M64ms 1 0 (6348) 00
Standard_ 128 2.048 4096 64 160000/1 80000/20 8 30000

M128s 1 600 00
(12696)
Standard_ 128 3892 4096 64 160000/1 80000/20 8 30000

M128ms 600 00
1, 2 (12696)
Standard_ 64 1024 7168 64 80000/80 40000/10 8 16000

M64 1 0 (1228) 00
Standard_ 64 1792 7168 64 80000/80 40000/10 8 16000

M64m 1 0 (1228) 00
Standard_ 128 2.048 14336 64 250000/1 80000/20 8 32000

M128 1 600 00
(2456)
Standard_ 128 3892 14336 64 250000/1 80000/20 8 32000

M128m 1 600 00
(2456)
1 mais de 64 vCPU requer uma destas versões de convidado com suporte: Windows Server 2016, Ubuntu 16, 4
LTS, SLES 12 SP2 e Red Hat Enterprise Linux, CentOS 7,3 ou Oracle Linux 7,3 com Lis 4.2.1.

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série Mv2
A Mv2-Series apresenta alta taxa de transferência, plataforma de baixa latência em execução em um

processador Hyper-Threading Intel® Xeon® Platinum 8180M 2,5 GHz (Skylake) com uma frequência base
básica de 2,5 GHz e uma frequência máxima de Turbo de 3,8 GHz. Todos os tamanhos de máquina virtual da
série Mv2 podem usar discos persistentes Standard e Premium. As instâncias da série Mv2 são tamanhos de VM
com otimização de memória que fornecem desempenho computacional inigualável para dar suporte a grandes
bancos de dados na memória e cargas de trabalho, com uma alta taxa de memória para CPU, ideal para
servidores de banco de dados relacionais, caches grandes e análise na memória.
O recurso da VM Mv2-Series Intel® Hyper-Threading Technology
Acelerador de gravação: com suporte
TA XA DE
T RA N SF E
RÊN C IA
M Á XIM A
DE TA XA DE
O M Á XIM A
T EM P O R DO
Á RIO : DISC O
Standard_ 208 5700 4096 64 80000/80 40000/10 8 16000

M208ms 0 (7040) 00
_v21
Standard_ 208 2850 4096 64 80000/80 40000/10 8 16000

M208s_v 0 (7040) 00
21
Standard_ 416 11400 8192 64 250000/1 80000/20 8 32000

M416ms 600 00
_v21 (14080)
Standard_ 416 5700 8192 64 250000/1 80000/20 8 32000

M416s_v 600 00
21 (14080)
1 as VMs da série Mv2 são somente geração 2 e dão suporte a um subconjunto de imagens com suporte de
geração 2. Veja abaixo a lista completa de imagens com suporte para a série Mv2. Se você estiver usando o
Linux, consulte suporte para VMs de geração 2 no Azure para obter instruções sobre como localizar e selecionar
uma imagem. Se você estiver usando o Windows, consulte suporte para VMs de geração 2 no Azure para obter
instruções sobre como localizar e selecionar uma imagem.
SUSE Linux Enterprise Server 12 SP4 e posterior ou SUSE Linux Enterprise Server 15 SP1 e posterior
Red Hat Enterprise Linux 7,6, 7,7, 8,1 ou posterior
Oracle Enterprise Linux 7,7 ou posterior

= 1098,4 GB.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Tamanhos de VM compatíveis com vCPU restrita
Algumas cargas de trabalho de banco de dados como o SQL Server ou Oracle exigem alto de memória,
armazenamento e largura de banda I/O, mas não número alto de núcleos. Muitas cargas de trabalho do banco
de dados não são de uso intensivo de CPU. O Azure oferece determinados tamanhos de VM, onde você pode
restringir a contagem de vCPU VM para reduzir o custo de licenciamento de software, mantendo a mesma
memória, armazenamento e largura de banda I/O.
A contagem de vCPU pode ser restrita para a metade ou um quarto do tamanho da VM original. Esses novos
tamanhos VM têm um sufixo que especifica o número de vCPUs ativos para facilitar a identificação.
Por exemplo, o tamanho da VM atual Standard_GS5 acompanha 32 vCPUs, 448 GB de RAM, 64 discos (até 256
TB) e 80.000 IOPs ou 2 GB/s de largura de banda I/O. Os novos tamanhos de VM Standard_GS5-16 e 8
Standard_GS5 vêm com 8 e 16 vCPUs activas respectivamente, mantendo o restante das especificações de
Standard_GS5 para memória, armazenamento e largura de banda I/O.
Os valores de licenciamento cobrados para SQL Server ou Oracle são restritos à nova contagem de vCPU e
outros produtos devem ser cobrados com base na contagem de vCPU nova. Isso resulta em um aumento de
50% a 75% na razão entre as especificações VM para vCPUs ativas (Faturável). Esses novos tamanhos de VM
permitem que as cargas de trabalho dos clientes usem a mesma memória, armazenamento e largura de banda
de e/s ao mesmo tempo em que otimizam seu custo de licenciamento de software. Neste momento, o custo de
computação, que inclui o licenciamento do sistema operacional, permanece o mesmo com o tamanho original.
Para obter mais informações, consulte tamanhos de VM do Azure para cargas de trabalho do banco de dados
mais econômicos.
NAME VC P U ESP EC IF IC A Ç Õ ES
Standard_M8-2ms 2 Mesmo que M8ms
Standard_M64 32ms 32 O mesmo que M64ms
Standard_M64-16ms 16 O mesmo que M64ms
Standard_E4-2s_v3 2 O mesmo que E4s_v3

Standard_E32 16s_v3 16 O mesmo que E32s_v3
Standard_E4-2ds_v4 2 O mesmo que E4ds_v4

Standard_E4-2as_v4 2 O mesmo que E4as_v4
Standard_GS4-8 8 O mesmo que GS4
Standard_DS11-1_v2 1 O mesmo que DS11_v2
Standard_M416-208s_v2 208 O mesmo que M416s_v2
Standard_M416-208ms_v2 208 O mesmo que M416ms_v2

Outros tamanhos
Memória otimizada
GPU
Próximas etapas
Tamanhos de máquinas virtuais otimizados para
armazenamento
Os tamanhos de VM otimizados para armazenamento oferecem alta taxa de transferência e e/s de disco e são
ideais para Big data, SQL, bancos de dados NoSQL, data warehousing e grandes bancos de dados transacionais.
Os exemplos incluem Cassandra, MongoDB, Cloudera e Redis. Este artigo fornece informações sobre o número
de vCPUs, discos de dados e NICs, bem como taxa de transferência de armazenamento local e largura de banda
de rede para cada tamanho otimizado.
A Lsv2-Series apresenta alta taxa de transferência, baixa latência, armazenamento de NVMe local mapeado
diretamente em execução no processador AMD EPYCTM 7551 com um aumento principal de 2.55 GHz e um
aumento máximo de 3,0 GHz. As VMs da série Lsv2 vêm em tamanhos de 8 para vCPU 80 em uma configuração
de vários thread simultânea. Há 8 GiB de memória por vCPU e um dispositivo de NVMe SSD M.2 de 1,92 TB por
8 vCPUs, com até 19,2 TB (10x1.92TB) disponível no L80s v2.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Saiba como otimizar o desempenho nas máquinas virtuais da série Lsv2 para Windows ou Linux.
Série Lsv2
A série Lsv2 apresenta alta taxa de transferência, baixa latência, armazenamento NVMe no processador AMD
EPYCTM 7551 com um aumento core de 2,55GHz e aumento máximo de 3,0GHz. As VMs da série Lsv2 vêm em
tamanhos de 8 para vCPU 80 em uma configuração de vários thread simultânea. Há 8 GiB de memória por vCPU
e um dispositivo de NVMe SSD M.2 de 1,92 TB por 8 vCPUs, com até 19,2 TB (10x1.92TB) disponível no L80s v2.
NOTE
As VMs da série Lsv2 são otimizadas para usar o disco local no nó anexado diretamente à VM em vez de usar discos de
dados duráveis. Isso permite maior IOPs / taxa de transferência para suas cargas de trabalho. A Lsv2 e a série ls não dão
suporte à criação de um cache local para aumentar o IOPs atingível por discos de dados duráveis.
A alta taxa de transferência e o IOPs do disco local tornam as VMs da série Lsv2 ideais para os repositórios NoSQL, como
o Apache Cassandra e o MongoDB, que replicam dados em várias VMs para alcançar a persistência em caso de falha de
uma única VM.
Para saber mais, consulte otimizar o desempenho nas máquinas virtuais da série Lsv2 para Windows ou Linux.
ACU: 150-175
Intermitência: com suporte
TA XA
DE
TA XA T RA N S
DE F ERÊN
T RA N S C IA
TA XA F ERÊN M Á XIM
DE C IA DE A DE
T RA N S DISC O DISC O
F ERÊN DE DE
C IA DE DA DO S DA DO S
DISC O NÃO NÃO L A RGU
DE A RM A A RM A RA DE
N VM E 3 Z EN A D Z EN A D B A N DA
( IO P S O S EM O S EM DISC O DE
DISC O DE CACHE CACHE S DE REDE
M EM Ó T EM P O DISC O L EIT UR ( IO P S/ ( IO P S/ DA DO S M Á XIM ESP ER
TA M A RIA RÁ RIO 1 S A/MBP M B P S) M B P S) M Á XIM O DE A DA
NHO VC P U ( GIB ) ( GIB ) N VM E 2 S) 4 5 OS N IC S ( M B P S)
Standa 8 64 80 1x1.92 40000 8000/1 8000/1 16 2 3200

rd_L8s TB 0/2000 60 280
_v2
TA XA
DE
TA XA T RA N S
DE F ERÊN
T RA N S C IA
TA XA F ERÊN M Á XIM
DE C IA DE A DE
T RA N S DISC O DISC O
F ERÊN DE DE
C IA DE DA DO S DA DO S
DISC O NÃO NÃO L A RGU
DE A RM A A RM A RA DE
N VM E Z EN A D Z EN A D B A N DA
( IO P S O S EM O S EM DISC O DE
DISC O DE CACHE CACHE S DE REDE
M EM Ó T EM P O DISC O L EIT UR ( IO P S/ ( IO P S/ DA DO S M Á XIM ESP ER
TA M A RIA RÁ RIO S A/MBP M B P S) M B P S) M Á XIM O DE A DA
NHO VC P U ( GIB ) ( GIB ) N VM E S) OS N IC S ( M B P S)
Standa 16 128 160 2x1.92 80000 16000/ 16000/ 32 4 6400

rd_L16 TB 0/4000 320 1280
s_v2
Standa 32 256 320 4x1.92 1,5 32000/ 32000/ 32 8 12800

rd_L32 TB m/800 640 1280
s_v2 0
Standa 48 384 480 6 vezes 2.2 48000/ 48000/ 32 8 16000

rd_L48 1.92 m/140 960 2000 +
s_v2 TB 00
Standa 64 512 640 8x1.92 2.9 64000/ 64000/ 32 8 16000

rd_L64 TB m/160 1280 2000 +
s_v2 00
Standa 80 640 800 10x1.9 3,8 80000/ 80000/ 32 8 16000

rd_L80 2TB m/200 1400 2000 +
s_v26 00
1 As VMs da série Lsv2 têm um disco de recurso temporário baseado em SCSI padrão para uso de arquivo de
paginação/troca de sistema operacional (D: no Windows, /dev/sdb no Linux). Esse disco fornece 80 GiB de
armazenamento, 4.000 IOPS e taxa de transferência de 80 MBps a cada 8 VCPUs (por exemplo,
Standard_L80s_v2 fornece 800 GiB a 40.000 IOPS e 800 MBPS). Isso garante que as unidades de NVMe podem
ser totalmente dedicadas para uso do aplicativo. Esse disco é efêmero e todos os dados serão perdidos quando
ele for parado/desalocado.
2 Discos locais de NVMe são efêmeros, os dados serão perdidos nesses discos se você parar/desalocar a VM.
3 A tecnologia Hyper-V NVMe Direct fornece acesso limitado a unidades de NVMe locais mapeadas com
segurança no espaço VM de convidado. Alcançar o desempenho máximo requer ousar a compilação mais
recente do WS2019 ou Ubuntu 18.04 ou 16.04 do Azure Marketplace. O desempenho de gravação varia com
base no tamanho de E/S, carga de unidade e a utilização da capacidade.
4 VMs da série Lsv2 não fornecem o cache de host para o disco de dados uma vez que não beneficiam as cargas
de trabalho Lsv2.
5 as VMs da série Lsv2 podem aumentar o desempenho do disco por até 30 minutos por vez.
6 VMs com mais de 64 vCPUs exigem um destes sistemas operacionais convidados com suporte:
Ubuntu 16, 4 LTS ou posterior, com kernel ajustado do Azure (kernel 4,15 ou posterior)
SLES 12 SP2 ou posterior
RHEL ou CentOS versão 6,7 até 6,10, com o pacote LIS fornecido pela Microsoft 4.3.1 (ou posterior) instalado
RHEL ou CentOS versão 7,3, com o pacote LIS fornecido pela Microsoft 4.2.1 (ou posterior) instalado
RHEL ou CentOS versão 7,6 ou posterior
Oracle Linux com UEK4 ou posterior
Debian 9 com o kernel de backports, Debian 10 ou posterior
CoreOS com um kernel 4,14 ou posterior

A capacidade de armazenamento é mostrada em unidades de GiB ou de 1024^3 bytes. Ao comparar os
discos medidos em GB (1000^3 bytes) com os discos medidos em GiB (1024^3), lembre-se de que os
números de capacidade fornecidos em GiB poderão parecer menores. Por exemplo, 1023 GiB = 1098,4 GB
A taxa de transferência do disco é medida em IOPS (operações de entrada/saída por segundo) e em MBps,
em que MBps = 10^6 bytes/s.
Se você quiser obter o melhor desempenho para suas VMs, será necessário limitar o número de discos de
dados a 2 discos por vCPU.
Largura de banda de rede esperada é a largura de banda agregada máxima alocada por tipo de VM em
todas as NICs para todos os destinos. Os limites superiores não são garantidos, mas devem fornecer
diretrizes para selecionar o tipo de VM correto para o aplicativo desejado. O desempenho real da rede
dependerá de uma variedade de fatores, incluindo cargas de rede e aplicativos, bem como configurações de
rede. Para saber mais sobre como otimizar a taxa de transferência de rede, veja Otimização da taxa de
transferência de rede para Windows e Linux. Para obter o desempenho de rede esperado no Linux ou no
Windows, poderá necessário selecionar uma versão específica ou otimizar sua VM. Para saber mais, veja
Como testar a taxa de transferência da máquina virtual de forma confiável.

Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Otimizar o desempenho nas máquinas virtuais do
Linux da série Lsv2
As máquinas virtuais da série Lsv2 dão suporte a uma variedade de cargas de trabalho que precisam de alta E/S
e taxa de transferência no armazenamento local em uma ampla gama de aplicativos e setores. A série Lsv2 é
ideal para Big Data, SQL, bancos de dados NoSQL, data warehouse e grandes bancos de dados transacionais,
incluindo Cassandra, MongoDB, Cloudera e Redis.
O design das VMs (Máquinas Virtuais) da série Lsv2 maximiza o processador AMD EPYC™ 7551 para fornecer
o melhor desempenho entre o processador, a memória, os dispositivos NVMe e as VMs. Trabalhando com
parceiros no Linux, várias compilações estão disponíveis no Azure Marketplace que são otimizadas para o
desempenho da série Lsv2 e atualmente incluem:
Ubuntu 18.04
Ubuntu 16.04
RHEL 8,0
Debian 9
Debian 10
Este artigo fornece dicas e sugestões para garantir que suas cargas de trabalho e aplicativos alcancem o
desempenho máximo projetado para as VMs. As informações nesta página serão atualizadas continuamente à
medida que mais imagens otimizadas da série Lsv2 forem adicionadas ao Azure Marketplace.
Arquitetura de chipset AMD EYPC™

As VMs da série Lsv2 usam processadores de servidor AMD EYPC™ com base na microarquitetura do Zen. A
AMD desenvolveu a IF (Infinity Fabric) para EYPC™ como interconexão escalonável para seu modelo NUMA
que poderia ser usado para comunicações na matriz, no pacote e em vários pacotes. Em comparação com o QPI
(Quick-Path Interconnect) e o UPI (Ultra-Path Interconnect) usados em processadores em matriz monolítica
modernos da Intel, a arquitetura de matriz pequena de vários NUMA do AMD pode proporcionar benefícios de
desempenho, bem como desafios. O impacto real da largura de banda de memória e das restrições de latência
pode variar dependendo do tipo de cargas de trabalho em execução.
Dicas para maximizar o desempenho

Se você estiver carregando um GuestOS Linux personalizado para sua carga de trabalho, observe que a
rede acelerada estará desativada por padrão. Se você pretende habilitar a rede acelerada, habilite-a no
momento da criação da VM para obter o melhor desempenho.
O hardware que alimenta as VMs da série Lsv2 utiliza dispositivos NVMe com oito QPs (pares de fila) de
E/S. Cada fila de E/S do dispositivo NVMe é, na verdade, um par: uma fila de envio e uma fila de
conclusão. O driver NVMe é configurado para otimizar a utilização desses oito QPs de E/S distribuindo a
E/S em uma agenda round robin. Para obter o desempenho máximo, execute oito trabalhos por
dispositivo para correspondência.
Evite misturar comandos de administrador do NVMe (por exemplo, consulta de informações SMART do
NVMe etc.) com os comandos de E/S do NVMe durante as cargas de trabalho ativas. Os dispositivos
NVMe da série Lsv2 são apoiados pela tecnologia Hyper-V NVMe Direct, que muda para o "modo lento"
sempre que qualquer comando de administração do NVMe estiver pendente. Os usuários da série Lsv2
poderão ver uma queda significativa no desempenho de E/S do NVMe, se isso acontecer.
Os usuários da série Lsv2 não devem confiar nas informações NUMA do dispositivo (todas 0) relatadas
de dentro da VM para unidades de dados para decidir a afinidade NUMA para seus aplicativos. A maneira
recomendada para melhor desempenho é distribuir cargas de trabalho entre CPUs, se possível.
A profundidade máxima de fila com suporte por par de filas de E/S para o dispositivo NVMe da VM da
série Lsv2 é 1024 (em comparação com o limite de 32 do Amazon i3 QD). Os usuários da série Lsv2
devem limitar suas cargas de trabalho de parâmetro de comparação (sintéticas) para a profundidade de
fila de 1.024, ou inferior, para evitar o disparo de condições completas da fila, o que pode reduzir o
desempenho.
Como utilizar o armazenamento de NVMe local

O armazenamento local no disco NVMe de 1,92 TB em todas as VMs da série Lsv2 é efêmero. Durante uma
reinicialização padrão bem-sucedida da VM, os dados no disco NVMe local devem persistir. Os dados não serão
persistidos no NVMe se a VM for reimplantada, desalocada ou excluída. Os dados não serão persistidos se outro
problema fizer a VM, ou o hardware em que ela está sendo executada, se tornar não íntegra. Quando isso
acontece, todos os dados no host antigo são apagados com segurança.
Também haverá casos em que a VM precisará ser movida para um computador host diferente, por exemplo,
durante uma operação de manutenção planejada. As operações de manutenção planejada e algumas falhas de
hardware podem ser antecipadas com os Eventos Agendados. Os Eventos Agendados devem ser usados para
manter-se atualizado das operações previstas de manutenção e recuperação.
No caso de um evento de manutenção planejada exigir que a VM seja recriada em um novo host com discos
locais vazios, os dados precisarão ser ressincronizados (novamente, com todos os dados no host antigo sendo
apagados com segurança). Isso ocorre porque as VMs da série Lsv2 atualmente não dão suporte à migração ao
vivo no disco NVMe local.
Há dois modos de manutenção planejada.
Manutenção controlada pelo cliente da VM padrão
A VM é movida para um host atualizado durante uma janela de 30 dias.
Os dados de armazenamento local da série Lsv2 podem ser perdidos; portanto, é recomendável fazer backup
dos dados antes do evento.
Manutenção automática
Ocorre se o cliente não executa a manutenção controlada por ele ou no caso de procedimentos de
emergência, como um evento de dia zero de segurança.
Destina-se a preservar os dados do cliente, mas há um pequeno risco de um congelamento ou reinicialização
da VM.
Para qualquer evento de serviço futuro, use o processo de manutenção controlada para selecionar um horário
mais conveniente para a atualização. Antes do evento, você pode fazer backup de seus dados no
armazenamento Premium. Após a conclusão do evento de manutenção, você poderá retornar seus dados para o
armazenamento de NVMe local das VMs da série Lsv2 atualizadas.
Os cenários que mantêm dados em discos NVMe locais incluem:
A VM está em execução e é íntegra.
A VM é reinicializada no local (por você ou pelo Azure).
A VM está em pausa (parada sem desalocação).
A maioria das operações de serviço de manutenção planejada.
Os cenários que apagam dados com segurança para proteger o cliente incluem:
A VM é reimplantada, parada (desalocada) ou excluída (por você).
A VM se torna não íntegra e tem de reparar o serviço para outro nó devido a um problema de hardware.
Um pequeno número de operações de serviço de manutenção planejada que exige que a VM seja realocada
para outro host para manutenção.
Para saber mais sobre as opções de backup de dados no armazenamento local, consulte Backup e recuperação
de desastre para discos IaaS do Azure.
Como começo a implantação de VMs da série Lsv2?
Assim como qualquer outra VM, use o Portal, a CLI do Azure ou o PowerShell para criar uma VM.
Uma única falha de disco de NVMe fará com que todas as VMs no host falhem?
Se uma falha de disco for detectada no nó de hardware, o hardware estará em um estado de falha.
Quando isso ocorre, todas as VMs no nó são automaticamente desalocadas e movidas para um nó
íntegro. Para VMs da série Lsv2, isso significa que os dados do cliente no nó com falha também serão
apagados com segurança e precisarão ser recriados pelo cliente no novo nó. Conforme observado, antes
que a migração ao vivo se torne disponível no Lsv2, os dados no nó com falha serão movidos
proativamente com as VMs à medida que forem transferidas para outro nó.
É necessário fazer ajustes para rq_affinity o desempenho?
A configuração de rq_affinity é um ajuste secundário ao usar o máximo de operações de entrada/saída
absolutas por segundo (IOPS). Depois que tudo estiver funcionando bem, tente definir rq_affinity como 0
para ver se isso faz diferença.
Preciso alterar as configurações de blk_mq?
RHEL/CentOS 7. x usa o BLK-MQ automaticamente para os dispositivos NVMe. Não são necessárias
alterações de configuração ou configurações. A configuração scsi_mod. Use _blk_mq é somente para
SCSI e foi usada durante a versão prévia do Lsv2 porque os dispositivos NVMe estavam visíveis nas VMs
convidadas como dispositivos SCSI. Atualmente, os dispositivos NVMe são visíveis como dispositivos
NVMe, portanto, a configuração SCSI BLK-MQ é irrelevante.
Preciso alterar "fio"?
Para obter o máximo de IOPS com uma ferramenta de medição de desempenho como ' fio ' nos
tamanhos de VM L64v2 e L80v2, defina "rq_affinity" como 0 em cada dispositivo NVMe. Por exemplo,
essa linha de comando definirá "rq_affinity" como zero para todos os 10 dispositivos NVMe em uma VM
L80v2:
for i in `seq 0 9`; do echo 0 >/sys/block/nvme${i}n1/queue/rq_affinity; done
Observe também que o melhor desempenho é obtido quando a e/s é feita diretamente para cada um dos
dispositivos de NVMe brutos sem particionamento, nenhum sistema de arquivos, nenhuma configuração
de RAID 0, etc. Antes de iniciar uma sessão de teste, verifique se a configuração está em um estado
novo/limpo conhecido executando blkdiscard em cada um dos dispositivos NVMe.
Próximas etapas
Consulte as especificações para todas as VMs otimizadas para desempenho de armazenamento no Azure
Otimizar o desempenho nas máquinas virtuais do
Windows da série Lsv2
As máquinas virtuais da série Lsv2 dão suporte a uma variedade de cargas de trabalho que precisam de alta E/S
e taxa de transferência no armazenamento local em uma ampla gama de aplicativos e setores. A série Lsv2 é
ideal para Big Data, SQL, bancos de dados NoSQL, data warehouse e grandes bancos de dados transacionais,
incluindo Cassandra, MongoDB, Cloudera e Redis.
O design das VMs (Máquinas Virtuais) da série Lsv2 maximiza o processador AMD EPYC™ 7551 para fornecer
o melhor desempenho entre o processador, a memória, os dispositivos NVMe e as VMs. Além de maximizar o
desempenho do hardware, as VMs da série Lsv2 são projetadas para funcionar com as necessidades dos
sistemas operacionais Windows e Linux para melhorar o desempenho com o hardware e o software.
O ajuste do software e do hardware resultou na versão otimizada do Windows Server 2019 Datacenter, lançado
no início de dezembro de 2018 para o Azure Marketplace, que dá suporte ao desempenho máximo nos
dispositivos NVMe nas VMs da série Lsv2.
Este artigo fornece dicas e sugestões para garantir que suas cargas de trabalho e aplicativos alcancem o
desempenho máximo projetado para as VMs. As informações nesta página serão atualizadas continuamente à
medida que mais imagens otimizadas da série Lsv2 forem adicionadas ao Azure Marketplace.
Arquitetura de chipset AMD EYPC™

As VMs da série Lsv2 usam processadores de servidor AMD EYPC™ com base na microarquitetura do Zen. A
AMD desenvolveu a IF (Infinity Fabric) para EYPC™ como interconexão escalonável para seu modelo NUMA
que poderia ser usado para comunicações na matriz, no pacote e em vários pacotes. Em comparação com o QPI
(Quick-Path Interconnect) e o UPI (Ultra-Path Interconnect) usados em processadores em matriz monolítica
modernos da Intel, a arquitetura de matriz pequena de vários NUMA do AMD pode proporcionar benefícios de
desempenho, bem como desafios. O impacto real da largura de banda de memória e das restrições de latência
pode variar dependendo do tipo de cargas de trabalho em execução.
Dicas para maximizar o desempenho

O hardware que alimenta as VMs da série Lsv2 utiliza dispositivos NVMe com oito QPs (pares de fila) de
E/S. Cada fila de E/S do dispositivo NVMe é, na verdade, um par: uma fila de envio e uma fila de
conclusão. O driver NVMe é configurado para otimizar a utilização desses oito QPs de E/S distribuindo a
E/S em uma agenda round robin. Para obter o desempenho máximo, execute oito trabalhos por
dispositivo para correspondência.
Evite misturar comandos de administrador do NVMe (por exemplo, consulta de informações SMART do
NVMe etc.) com os comandos de E/S do NVMe durante as cargas de trabalho ativas. Os dispositivos
NVMe da série Lsv2 são apoiados pela tecnologia Hyper-V NVMe Direct, que muda para o "modo lento"
sempre que qualquer comando de administração do NVMe estiver pendente. Os usuários da série Lsv2
poderão ver uma queda significativa no desempenho de E/S do NVMe, se isso acontecer.
Os usuários da série Lsv2 não devem confiar nas informações NUMA do dispositivo (todas 0) relatadas
de dentro da VM para unidades de dados para decidir a afinidade NUMA para seus aplicativos. A maneira
recomendada para melhor desempenho é distribuir cargas de trabalho entre CPUs, se possível.
A profundidade máxima de fila com suporte por par de filas de E/S para o dispositivo NVMe da VM da
série Lsv2 é 1024 (em comparação com o limite de 32 do Amazon i3 QD). Os usuários da série Lsv2
devem limitar suas cargas de trabalho de parâmetro de comparação (sintéticas) para a profundidade de
fila de 1.024, ou inferior, para evitar o disparo de condições completas da fila, o que pode reduzir o
desempenho.
Como utilizar o armazenamento de NVMe local

O armazenamento local no disco NVMe de 1,92 TB em todas as VMs da série Lsv2 é efêmero. Durante uma
reinicialização padrão bem-sucedida da VM, os dados no disco NVMe local devem persistir. Os dados não serão
persistidos no NVMe se a VM for reimplantada, desalocada ou excluída. Os dados não serão persistidos se outro
problema fizer a VM, ou o hardware em que ela está sendo executada, se tornar não íntegra. Quando isso
acontece, todos os dados no host antigo são apagados com segurança.
Também haverá casos em que a VM precisará ser movida para um computador host diferente, por exemplo,
durante uma operação de manutenção planejada. As operações de manutenção planejada e algumas falhas de
hardware podem ser antecipadas com os Eventos Agendados. Os Eventos Agendados devem ser usados para
manter-se atualizado das operações previstas de manutenção e recuperação.
No caso de um evento de manutenção planejada exigir que a VM seja recriada em um novo host com discos
locais vazios, os dados precisarão ser ressincronizados (novamente, com todos os dados no host antigo sendo
apagados com segurança). Isso ocorre porque as VMs da série Lsv2 atualmente não dão suporte à migração ao
vivo no disco NVMe local.
Há dois modos de manutenção planejada.
Manutenção controlada pelo cliente da VM padrão
A VM é movida para um host atualizado durante uma janela de 30 dias.
Manutenção automática
Ocorre se o cliente não executa a manutenção controlada por ele ou no caso de procedimentos de
emergência, como um evento de dia zero de segurança.
Destina-se a preservar os dados do cliente, mas há um pequeno risco de um congelamento ou reinicialização
da VM.
Para qualquer evento de serviço futuro, use o processo de manutenção controlada para selecionar um horário
mais conveniente para a atualização. Antes do evento, você pode fazer backup de seus dados no
armazenamento Premium. Após a conclusão do evento de manutenção, você poderá retornar seus dados para o
armazenamento de NVMe local das VMs da série Lsv2 atualizadas.
Os cenários que mantêm dados em discos NVMe locais incluem:
A VM está em execução e é íntegra.
A VM é reinicializada no local (por você ou pelo Azure).
A VM está em pausa (parada sem desalocação).
A maioria das operações de serviço de manutenção planejada.
Os cenários que apagam dados com segurança para proteger o cliente incluem:
A VM é reimplantada, parada (desalocada) ou excluída (por você).
A VM se torna não íntegra e tem de reparar o serviço para outro nó devido a um problema de hardware.
Um pequeno número de operações de serviço de manutenção planejada que exige que a VM seja realocada
para outro host para manutenção.
Para saber mais sobre as opções de backup de dados no armazenamento local, consulte Backup e recuperação
de desastre para discos IaaS do Azure.
Como começo a implantação de VMs da série Lsv2?
Assim como qualquer outra VM, use o Portal, a CLI do Azure ou o PowerShell para criar uma VM.
Uma única falha de disco de NVMe fará com que todas as VMs no host falhem?
Se uma falha de disco for detectada no nó de hardware, o hardware estará em um estado de falha.
Quando isso ocorre, todas as VMs no nó são automaticamente desalocadas e movidas para um nó
íntegro. Para VMs da série Lsv2, isso significa que os dados do cliente no nó com falha também serão
apagados com segurança e precisarão ser recriados pelo cliente no novo nó. Conforme observado, antes
que a migração ao vivo se torne disponível no Lsv2, os dados no nó com falha serão movidos
proativamente com as VMs à medida que forem transferidas para outro nó.
É necessário fazer ajustes de sondagem no Windows Ser ver 2012 ou no Windows Ser ver
2016?
A sondagem do NVMe só está disponível no Windows Server 2019 no Azure.
Posso voltar para um modelo de ISR (rotina de ser viço de interrupção) tradicional?
As VMs da série Lsv2 são otimizadas para sondagem de NVMe. As atualizações são fornecidas
continuamente para melhorar o desempenho de sondagem.
Posso ajustar as configurações de sondagem no Windows Ser ver 2019?
As configurações de sondagem não são ajustáveis pelo usuário.
Próximas etapas
Consulte as especificações para todas as VMs otimizadas para desempenho de armazenamento no Azure
Tamanhos de máquinas virtuais com GPU
otimizadas
Os tamanhos de VM otimizadas para GPU são máquinas virtuais especializadas disponíveis com GPUs únicas,
múltiplas ou fracionárias. Esses tamanhos são projetados para cargas de trabalho de visualização e com muita
computação e muitos gráficos. Este artigo fornece informações sobre o número e o tipo de GPUs, vCPUs, discos
de dados e NICs. A taxa de transferência de armazenamento e a largura de banda de rede também são incluídos
para cada tamanho neste agrupamento.
Os tamanhos da série NCv3 e do NC T4_v3 são otimizados para aplicativos com aceleração de GPU com
uso intensivo de computação. Alguns exemplos são aplicativos baseados em CUDA e OpenCL e
simulações, ia e aprendizado profundo. O NC T4 v3-Series se concentra em cargas de trabalho de
inferência com a GPU Tesla T4 da NVIDIA e o processador AMD EPYC2 Roma. A série NCv3 está
concentrada em cargas de trabalho de computação e de ia de alto desempenho com a GPU Tesla V100 da
NVIDIA.
O tamanho da série NDv2 é voltado para aplicativos de treinamento de aprendizado profundo de
expansão e expansão. A série NDv2 usa o NVIDIA voltar V100 e o processador Intel Xeon Platinum 8168
(Skylake).
Os tamanhos da série NV e da série NVv3 são otimizados e desenvolvidos para cenários de visualização
remota, streaming, jogos, codificação e VDI usando estruturas como OpenGL e DirectX. Essas VMs são
apoiadas pela GPU Tesla M60 da NVIDIA.
Série NVv4 Tamanhos de VM otimizados e projetados para VDI e visualização remota. Com GPUs
particionadas, o NVv4 oferece o tamanho certo para cargas de trabalho que exigem recursos menores de
GPU. Essas VMs são apoiadas pela GPU AMD Radeon instinto MI25. Atualmente, as VMs NVv4 dão
suporte apenas ao sistema operacional convidado do Windows.
Sistemas operacionais e drivers com suporte

Para aproveitar os recursos de GPU das VMs da série N do Azure, os drivers NVIDIA ou AMD GPU devem ser
instalados.
Para VMs apoiadas por GPUs NVIDIA, a extensão de Driver Nvidia GPU instala drivers NVIDIA CUDA ou
Grid apropriados. Instale ou gerencie a extensão usando o portal do Azure ou ferramentas, como Azure
PowerShell ou modelos do Azure Resource Manager. Confira a documentação da Extensão de Driver de
GPU NVIDIA para saber quais são os sistemas operacionais compatíveis e as etapas de implantação. Para
obter informações gerais sobre extensões de VM, confira Recursos e extensões de máquina virtual do
Azure.
Como alternativa, você pode instalar os drivers NVIDIA GPU manualmente. Confira instalar drivers
NVIDIA GPU em VMs da série n executando o Windows ou instalar drivers NVIDIA GPU em VMs da série
n executando o Linux para sistemas operacionais, Drivers, instalação e etapas de verificação com suporte.
Para VMs apoiadas por GPUs AMD, consulte instalar drivers AMD GPU em VMs da série N executando o
Windows para sistemas operacionais, Drivers, instalação e etapas de verificação com suporte.
Considerações de implantação
Para ver a disponibilidade das VMs da Série N, veja Produtos disponíveis por região.
As VMs da Série N só podem ser implantadas no modelo de implantação do Resource Manager.
As VMs da série N diferem no tipo de Armazenamento do Microsoft Azure que dão suporte aos discos.
As VMs NC e NV dão suporte somente a discos de VM que executam backup em HDD (Armazenamento
em Disco Standard). As NCv2, NCv3, ND, NDv2, e’ NVv2são compatíveis apenas com discos de VM que
executam backup em SSD (Armazenamento em Disco Premium).
Se você quiser implantar mais do que algumas VMs da Série N, considere uma assinatura pré-paga ou
outras opções de compra. Se estiver usando uma conta gratuita do Azure, você poderá usar apenas um
número limitado de núcleos de computação do Azure.
Talvez seja necessário aumentar a cota de núcleos (por região) na sua assinatura do Azure, e aumentar a
cota separada para núcleos NC, NCv2, NCv3, ND, NDv2, NV, ou NVv2. Para solicitar um aumento de cota,
abra uma solicitação de atendimento ao cliente online gratuitamente. Os limites padrão podem variar
dependendo de sua categoria de assinatura.
Outros tamanhos
Propósito geral
Memória otimizada
Próximas etapas
Série NC
As VMs da série NC são alimentadas pela placa NVIDIA Tesla K80 e pelo processador Intel Xeon E5-2690 v3
(Haswell). Os usuários podem processar os dados mais rapidamente aproveitando o CUDA para aplicativos de
exploração de energia, simulações de falhas, renderização de traçados de raio, aprendizado profundo e muito
mais. A configuração NC24r fornece um adaptador de rede de alta taxa de transferência e baixa latência,
otimizado para cargas de trabalho de computação paralela firmemente acopladas.
Interconexão NVIDIA NVLink: sem suporte
A RM A Z EN A
M EN TO
T EM P O RÁ R M EM Ó RIA DISC O S DE
M EM Ó RIA : IO ( SSD) DA GP U: DA DO S M Á XIM O
TA M A N H O VC P U GIB GIB GP U GIB M Á XIM O S DE N IC S
Standard_N 6 56 340 1 12 24 1
C6
Standard_N 12 112 680 2 24 48 2

C12
Standard_N 24 224 1440 4 48 64 4

C24
Standard_N 24 224 1440 4 48 64 4

C24r*
1 GPU = metade de um cartão K80.

*Compatível com RDMA

= 1098,4 GB.

Para aproveitar os recursos de GPU das VMs da série N do Azure, os drivers NVIDIA GPU devem ser instalados.
A Extensão de Driver de GPU NVIDIA instala drivers CUDA ou GRID NVIDIA apropriados em VMs da série N.
Instale ou gerencie a extensão usando o portal do Azure ou ferramentas, como Azure PowerShell ou modelos
do Azure Resource Manager. Confira a documentação da Extensão de Driver de GPU NVIDIA para saber quais
são os sistemas operacionais compatíveis e as etapas de implantação. Para obter informações gerais sobre
extensões de VM, confira Recursos e extensões de máquina virtual do Azure.
Se você optar por instalar manualmente os drivers NVIDIA GPU, consulte configuração do driver GPU da série n
para Windows ou instalação do driver de GPU da série n para Linux para sistemas operacionais, Drivers,
instalação e etapas de verificação com suporte.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série NCv2
VMs da série NCv2 têm a tecnologia de GPUs NVIDIA Tesla P100. Essas GPUs podem fornecer desempenho
computacional 2 vezes maior que da série NC. Os clientes podem aproveitar essas GPUs atualizadas para cargas
de trabalho HPC tradicionais como modelagem de reservatório, sequenciamento de DNA, análise de proteína,
simulações de Monte Carlo, entre outros. Além das GPUs, as VMs da série NCv2 também são alimentadas por
CPUs Intel Xeon E5-2690 V4 (Broadwell).
A configuração NC24rs v2 fornece um adaptador de rede de alta taxa de transferência e baixa latência,
IMPORTANT
Para essa série de VMs, a cota de vCPU (núcleo) em sua assinatura é inicialmente definida como 0 em cada região. Solicite
um aumento de cota de vCPU para esta série em uma região disponível.
TA XA DE
T RA N SF E
A RM A Z E RÊN C IA
N A M EN T DISC O S DE DISC O
O DE SEM
T EM P O R M EM Ó RI DA DO S C A C H E:
TA M A N H M EM Ó RI Á RIO A DA M Á XIM O IO P S/ M B M Á XIM O
O VC P U A : GIB ( SSD) GIB GP U GP U: GIB S PS DE N IC S
Standard_ 6 112 736 1 16 12 20000/20 4

NC6s_v2 0
Standard_ 12 224 1474 2 32 24 40000/40 8

NC12s_v 0
2
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24s_v 0
2
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24rs_v 0
2*
1 GPU = um cartão P100.

= 1098,4 GB.

Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série NCv3
VMs da série NCv3 têm a tecnologia de GPUs NVIDIA Tesla V100. Essas GPUs podem fornecer desempenho
computacional 1,5 vezes maior da série NCv2. Os clientes podem aproveitar essas GPUs atualizadas para cargas
simulações de Monte Carlo, entre outros. A configuração NC24rs v3 fornece um adaptador de rede de alta taxa
de transferência e baixa latência, otimizado para cargas de trabalho de computação paralela firmemente
acopladas. Além das GPUs, as VMs da série NCv3 também são alimentadas por CPUs Intel Xeon E5-2690 V4
(Broadwell).
IMPORTANT
Para essa série de VMs, a cota de vCPU (núcleo) em sua assinatura é inicialmente definida como 0 em cada região. Solicite
um aumento de cota de vCPU para esta série em uma região disponível. Essas SKUs não estão disponíveis para avaliação
ou assinaturas do Azure do assinante do Visual Studio. Seu nível de assinatura pode não dar suporte à seleção ou
implantação dessas SKUs.
TA XA DE
T RA N SF E
O DE SEM
Standard_ 6 112 736 1 16 12 20000/20 4

NC6s_v3 0
Standard_ 12 224 1474 2 32 24 40000/40 8

NC12s_v 0
3
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24s_v 0
3
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24rs_v 0
3*
1 GPU = um cartão V100.


= 1098,4 GB.

Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série NCasT4_v3
As máquinas virtuais da série NCasT4_v3 são alimentadas por GPUs NVIDIA Tesla T4 e CPUs AMD EPYC 7V12
(Roma). O recurso de VMs tem até 4 GPUs NVIDIA T4 com 16 GB de memória cada, até 64 núcleos de
processador EPYC de 7V12 (Roma) não multithread e 440 GiB de memória do sistema. Essas máquinas virtuais
são ideais para a implantação de serviços de ia, como inferência em tempo real de solicitações geradas pelo
usuário ou para gráficos interativos e cargas de trabalho de visualização usando o driver de grade da NVIDIA e a
tecnologia de GPU virtual. As cargas de trabalho de computação de GPU padrão baseadas em CUDA, TensorRT,
Caffe, ONNX e outras estruturas, ou aplicativos gráficos com aceleração de GPU com base em OpenGL e DirectX
podem ser implantadas de forma econômica, com proximidade aos usuários, na série de NCasT4_v3.
ACU: 230-260
M Á XIM O
DE
N IC S/ L A RG
A RM A Z EN A URA DE
M EN TO B A N DA DE
T EM P O RÁ R M EM Ó RIA DISC O S DE REDE
M EM Ó RIA : IO ( SSD) DA GP U: DA DO S ESP ERA DO
TA M A N H O VC P U GIB GIB GP U GIB M Á XIM O S ( M B P S)
Standard_N 4 28 180 1 16 8 2 / 8000

C4as_T4_v3
Standard_N 8 56 360 1 16 16 4 / 8000

C8as_T4_v3
Standard_N 16 110 360 1 16 32 8 / 8000

C16as_T4_v
3
Standard_N 64 440 2880 4 64 32 8 / 32000

C64as_T4_v
3

= 1098,4 GB.

Para aproveitar os recursos de GPU das VMs da série NCasT4_v3 do Azure que executam Windows ou Linux, os
drivers NVIDIA GPU devem ser instalados.
Para instalar os drivers NVIDIA GPU manualmente, consulte instalação do driver de GPU da série N para
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série ND
As máquinas virtuais da série ND são uma nova adição à família de GPU projetada para cargas de trabalho AI e
Deep Learning. Elas oferecem um desempenho excelente para treinamento e Inferência. As instâncias do ND são
alimentadas por NVIDIA Tesla P40 GPUs e CPUs Intel Xeon E5-2690 V4 (Broadwell). Essas instâncias oferecem
um desempenho excelente para operações de ponto flutuante de precisão simples, para cargas de trabalho de
AI que utilizam o Cognitive Toolkit, o TensorFlow, o Caffe e outras estruturas. A série ND também oferece um
tamanho de memória de GPU muito maior (24 GB), permitindo usar modelos de rede neural muito maiores.
Como a série NC, a série ND oferece uma configuração com uma baixa latência secundária, uma rede com alta
taxa de transferência por meio de RDMA e a conectividade InfiniBand, permitindo executar trabalhos de grande
escala que abrangem várias GPUs.
IMPORTANT
Para essa série de VMs, a cota de vCPU (núcleo) por região em sua assinatura é definida inicialmente como 0. Solicite um
aumento de cota de vCPU para esta série em uma região disponível.
TA XA DE
T RA N SF E
O DE SEM
Standard_ 6 112 736 1 24 12 20000/20 4

ND6s 0
Standard_ 12 224 1474 2 48 24 40000/40 8

ND12s 0
Standard_ 24 448 2948 4 24 32 80000/80 8

ND24s 0
Standard_ 24 448 2948 4 96 32 80000/80 8

ND24rs* 0
1 GPU = um cartão de P40.

= 1098,4 GB.

Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série NDv2 atualizada
A máquina virtual da série NDv2 é uma nova adição à família de GPU projetada para as necessidades das cargas
de trabalho mais exigentes do ia, do aprendizado de máquina, da simulação e do HPC com maior rapidez.
A NDv2 é alimentada por oito GPUs NVIDIA Tesla V100 NVLINK conectadas, cada uma com 32 GB de memória
de GPU. Cada VM NDv2 também tem 40 núcleos não hiperthreads Intel Xeon Platinum 8168 (Skylake) e 672
GiB de memória do sistema.
As instâncias de NDv2 fornecem excelente desempenho para cargas de trabalho do HPC e do AI utilizando
kernels de computação otimizados para GPU CUDA e as muitas ferramentas de ia, ML e análise que dão suporte
à aceleração de GPU "pronta para uso", como TensorFlow, Pytorch, Caffe, RAPIDS e outras estruturas.
De forma crucial, o NDv2 é criado para expansão computacionalmente intensa (aproveitando 8 GPUs por VM) e
escalar horizontalmente (aproveitando várias VMs trabalhando juntas) cargas de trabalho. A série NDv2 agora
dá suporte à rede de back-end InfiniBand EDR de 100-Gigabit, semelhante àquela disponível na série HB da VM
HPC, para permitir o clustering de alto desempenho para cenários paralelos, incluindo treinamento distribuído
para ia e ML. Essa rede de back-end dá suporte a todos os principais protocolos InfiniBand, incluindo aqueles
empregados pelas bibliotecas NCCL2 da NVIDIA, permitindo um clustering contínuo de GPUs.
IMPORTANT
Ao habilitar a InfiniBand na VM ND40rs_v2, use o driver 4.7-1.0.0.1 Mellanox ofed.
Devido à maior memória da GPU, o novo ND40rs_v2 VM requer o uso de VMs de geração 2 e imagens do Marketplace.
Observação: o ND40s_v2 incluindo 16 GB de memória por GPU não está mais disponível para visualização e foi
substituído pelo ND40rs_v2 atualizado.

InfiniBand: com suporte
Interconexão NVIDIA NVLink: com suporte
TA XA
DE
T RA N SF
ERÊN C I
A
M Á XIM
A DO
DISC O
A RM A Z NÃO
EN A M E A RM A Z L A RGUR
N TO DISC O S EN A DO A DE
T EM P O M EM Ó R DE EM B A N DA
RÁ RIO IA DA DA DO S C A C H E: DE REDE M Á XIM
TA M A N M EM Ó R ( SSD) : GP U: M Á XIM IO P S / M Á XIM O DE
HO VC P U IA : GIB GIB GP U GIB OS MBPS A N IC S
Standar 40 672 2948 8 V100 32 32 80000/ 24000 8

d_ND40 32 GB 800 Mbps
rs_v2 (NVLink)

= 1098,4 GB.

do Azure Resource Manager. Para obter informações gerais sobre extensões de VM, confira Recursos e
extensões de máquina virtual do Azure.
Se você optar por instalar os drivers NVIDIA GPU manualmente, consulte instalação do driver de GPU da série N
para Linux.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série NV
As máquinas virtuais da série NV têm a tecnologia das GPUs Tesla M60 da NVIDIA e NVIDIA GRID para
aplicativos acelerados de área de trabalho e áreas de trabalho virtuais, em que os clientes podem visualizar seus
dados ou simulações. Os usuários podem visualizar seus fluxos de trabalho com uso intensivo de gráficos em
instâncias NV para obter capacidade gráfica superior, além de executar cargas de trabalho de precisão única,
como codificação e renderização. As VMs da série NV também são alimentadas por CPUs do Intel Xeon E5-2690
v3 (Haswell).
Cada GPU em instâncias NV vem com uma licença GRID. Esta licença oferece flexibilidade para usar uma
instância NV como uma estação de trabalho virtual para um único usuário ou 25 usuários simultâneos podem
se conectar à VM para um cenário de aplicativo virtual.
A RM A Z
EN A M E ESTA Ç Õ
N TO DISC O S ES DE
T EM P O M EM Ó R DE T RA B A L A P L IC A
RÁ RIO IA DA DA DO S M Á XIM HO T IVO S
TA M A N M EM Ó R ( SSD) GP U: M Á XIM O DE VIRT UA I VIRT UA I
HO VC P U IA : GIB GIB GP U GIB OS N IC S S S
Standar 6 56 340 1 8 24 1 1 25
d_NV6
Standar 12 112 680 2 16 48 2 2 50

d_NV12
Standar 24 224 1440 4 32 64 4 4 100

d_NV24
1 GPU = metade de um cartão M60.

= 1098,4 GB.

Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série NVv3
As máquinas virtuais da série NVv3 são da plataforma NVIDIA Tesla M60 GPUs e da tecnologia NVIDIA Grid
com as CPUs Intel E5-2690 V4 (Broadwell) e a tecnologia Intel Hyper-Threading. Essas máquinas virtuais são
direcionadas para aplicativos com gráficos acelerados por GPU e áreas de trabalho virtuais em que os clientes
querem visualizar dados, simular resultados para exibição, trabalhar no CAD ou renderizar e transmitir
conteúdo por streaming. Além disso, essas máquinas virtuais podem executar cargas de trabalho de precisão
simples, como codificação e renderização. As máquinas virtuais NVv3 dão suporte ao armazenamento Premium
e vêm com duas vezes a RAM (memória do sistema) quando comparadas com sua série NV do antecessor.
Cada GPU em instâncias de NVv3 vem com uma licença de grade. Esta licença oferece flexibilidade para usar
uma instância NV como uma estação de trabalho virtual para um único usuário ou 25 usuários simultâneos
podem se conectar à VM para um cenário de aplicativo virtual.
TA XA M Á XIM
DE O DE
T RA N S N IC S/ L
A RM A F ERÊN A RGUR
Z EN A C IA DE A DE
M EN T DISC O B A N DA ESTA Ç
O DISC O SEM DE Õ ES DE
T EM P O M EM Ó S DE CACHE REDE T RA B A A P L IC
M EM Ó RÁ RIO RIA DA DA DO S : ESP ER LHO AT IVO S
TA M A RIA : ( SSD) GP U: M Á XIM IO P S/ A DO VIRT U VIRT U
NHO VC P U GIB GIB GP U GIB OS MBPS ( M B P S) A IS A IS
Standa 12 112 320 1 8 12 20000/ 4/ 1 25

rd_NV 200 6000
12s_v3
Standa 24 224 640 2 16 24 40000/ 8/ 2 50

rd_NV 400 12000
24s_v3
Standa 48 448 1280 4 32 32 80000/ 8/ 4 100

rd_NV 800 24000
48s_v3
11 GPU = placa M60 de uma metade.

= 1098,4 GB.

Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série NVv4
As máquinas virtuais da série NVv4 são alimentadas por GPUs AMD Radeon instinto MI25 e CPUs AMD EPYC
7V12 (Roma). Com o NVv4-Series, o Azure está introduzindo máquinas virtuais com GPUs parciais. Escolha a
máquina virtual de tamanho certo para aplicativos gráficos acelerados de GPU e áreas de trabalho virtuais
começando em 1/8 de uma GPU com 2 buffer de quadros GiB para uma GPU completa com 16 buffer de
quadros GiB. Atualmente, as máquinas virtuais NVv4 dão suporte apenas ao sistema operacional convidado do
Windows.
ACU: 230-260
N ÚM ERO
M Á XIM O
DE
N IC S/ L A RG
M EN TO B A N DA DE
T EM P O RÁ R M EM Ó RIA DISC O S DE REDE
M EM Ó RIA : IO ( SSD) DA GP U: DA DO S ESP ERA DA
TA M A N H O VC P U GIB GIB GP U GIB M Á XIM O S ( M B P S)
Standard_N 4 14 88 1/8 2 4 2 / 1000

V4as_v4
Standard_N 8 28 176 1/4 4 8 4 / 2000

V8as_v4
Standard_N 16 56 352 1/2 8 16 8 / 4000

V16as_v4
Standard_N 32 112 704 1 16 32 8 / 8000

V32as_v4
1 as VMs da série NVv4 apresentam a tecnologia de vários threads simultâneos da AMD

= 1098,4 GB.

Para aproveitar os recursos de GPU das VMs da série NVv4 do Azure que executam o Windows, os drivers de
GPU AMD devem ser instalados.
Para instalar os drivers do AMD GPU manualmente, consulte instalação do driver da GPU AMD da série N para
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Instalar drivers NVIDIA GPU em VMs da série N
que executam o Linux
Para aproveitar as funcionalidades de GPU das VMs da série N do Azure que contam com GPUs da NVIDIA, é
preciso instalar os drivers para GPU NVIDIA. A Extensão de Driver de GPU NVIDIA instala drivers CUDA ou GRID
NVIDIA apropriados em VMs da série N. Instale ou gerencie a extensão usando o portal do Azure ou
ferramentas, como a CLI do Azure ou os modelos do Azure Resource Manager. Confira a documentação da
Extensão de Driver de GPU NVIDIA para saber quais são as distribuições compatíveis e as etapas de
implantação.
Se você optar por instalar os drivers de GPU da NVIDIA manualmente, este artigo fornecerá as distribuições
compatíveis, os drivers e as etapas de instalação e verificação. Também há informações de As informações de
instalação manual de driver também estão disponíveis para VMs do Windows.
Para obter as especificações de VMs da série N, as capacidades de armazenamento e os detalhes de disco,
consulte Tamanhos de VM Linux para GPU.
Distribuições e drivers com suporte

Drivers NVIDIA CUDA
Os drivers NVIDIA CUDA para VMs das séries NC, NCv2, NCv3, ND e NDv2 (opcional para a série NV) são
suportados apenas nas distribuições Linux listadas na tabela a seguir. As informações sobre o driver CUDA são
atuais no momento da publicação. Para obter os drivers CUDA e os sistemas operacionais com suporte mais
recentes, visite o site do NVIDIA . Certifique-se de instalar ou atualizar para os drivers mais recentes do CUDA
para a sua distribuição.
TIP
Como alternativa à instalação manual do driver CUDA em uma VM do Linux, você pode implantar uma imagem de
Máquina Virtual de Ciência de Dados do Azure. As edições DSVM para Ubuntu 16.04 LTS ou CentOS 7.4 vem com drivers
NVIDIA CUDA pré-instalados, a Biblioteca de Rede Neural Avançada CUDA Neural e outras ferramentas.
Drivers NVIDIA GRID

A Microsoft redistribui os instaladores de driver de grade NVIDIA para VMs de série NVv3 e NV usadas como
estações de trabalho virtuais ou para aplicativos virtuais. Instale somente esses drivers de grade em VMs do
Azure NV, apenas em sistemas operacionais listados na tabela a seguir. Esses drivers incluem o licenciamento de
Software de GPU Virtual de GRID no Azure. Você não precisa configurar um servidor de licença de software de
vGPU NVIDIA.
Os drivers de grade redistribuídos pelo Azure não funcionam em VMs da série não NV, como as VMs NC, NCv2,
NCv3, ND e série NDv2.
DIST RIB UIÇ Ã O DRIVER
Ubuntu 18.04 LTS NVIDIA GRID 12,0, ramificação do driver R460(. exe)
Ubuntu 16.04 LTS
Red Hat Enterprise Linux 7,7 a 7,9, 8,0, 8,1
Visite o GitHub para obter a lista completa de todos os links de driver de grade NVIDIA anteriores.
WARNING
A instalação de software de terceiros em produtos do Red Hat pode afetar os termos de suporte do Red Hat. Consulte o
artigo da Base de conhecimento do Red Hat.
Instalar drivers de CUDA em VMs série N

Aqui estão as etapas para instalar os drivers CUDA a partir do NVIDIA CUDA Toolkit em VMs série N.
Os desenvolvedores de C e C++ podem opcionalmente instalar o Kit de ferramentas completo para criar
aplicativos com aceleração de GPU. Para obter mais informações, consulte o Guia de instalação do CUDA.
Para instalar os drivers de CUDA, realize uma conexão SSH para cada VM. Para verificar se o sistema tem uma
GPU compatível com CUDA, execute o seguinte comando:
lspci | grep -i NVIDIA
Você verá uma saída semelhante ao seguinte exemplo (mostrando uma placa NVIDIA Tesla K80):
Em seguida, execute os comandos de instalação específicos para a sua distribuição.

Ubuntu
1. Baixe e instale os drivers CUDA do site da NVIDIA. Por exemplo, para Ubuntu 16.04 LTS:
CUDA_REPO_PKG=cuda-repo-ubuntu1604_10.0.130-1_amd64.deb
wget -O /tmp/${CUDA_REPO_PKG}
https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/${CUDA_REPO_PKG}
sudo dpkg -i /tmp/${CUDA_REPO_PKG}
sudo apt-key adv --fetch-keys

https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/7fa2af80.pub
rm -f /tmp/${CUDA_REPO_PKG}
sudo apt-get update
sudo apt-get install cuda-drivers

A instalação poderá levar vários minutos.
2. Para opcionalmente instalar o Kit de ferramentas CUDA completo, digite:
sudo apt-get install cuda
3. Reinicie a VM e prossiga para verificar a instalação.

Atualizações de driver CUDA
É recomendável que você atualize periodicamente os drivers CUDA após a implantação.
sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get dist-upgrade -y
sudo apt-get install cuda-drivers
sudo reboot
CentOS ou Red Hat Enterprise Linux

1. Atualize o kernel (recomendado). Se você optar por não atualizar o kernel, verifique se as versões
kernel-devel e dkms são apropriadas para seu kernel.
sudo yum install kernel kernel-tools kernel-headers kernel-devel
sudo reboot
2. Install the latest Linux Integration Services for Hyper-V and Azure. Check if LIS is required by verifying the
results of lspci. If all GPU devices are listed as expected, installing LIS is not required.
Skip this step if you plan to use CentOS 7.8(or higher) as LIS is no longer required for these versions.
Please note that LIS is applicable to Red Hat Enterprise Linux, CentOS, and the Oracle Linux Red Hat Compatible
Kernel 5.2-5.11, 6.0-6.10, and 7.0-7.7. Please refer to the [Linux Integration Services documentation]
(https://www.microsoft.com/en-us/download/details.aspx?id=55106) for more details.
Skip this step if you are not using the Kernel versions listed above.
wget https://aka.ms/lis
tar xvzf lis
cd LISISO
sudo ./install.sh
sudo reboot
3. Reconecte-se à VM e continue a instalação com os seguintes comandos:

sudo rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum install dkms
CUDA_REPO_PKG=cuda-repo-rhel7-10.0.130-1.x86_64.rpm
wget https://developer.download.nvidia.com/compute/cuda/repos/rhel7/x86_64/${CUDA_REPO_PKG} -O
/tmp/${CUDA_REPO_PKG}
sudo rpm -ivh /tmp/${CUDA_REPO_PKG}
rm -f /tmp/${CUDA_REPO_PKG}
sudo yum install cuda-drivers
A instalação poderá levar vários minutos.

4. Para opcionalmente instalar o Kit de ferramentas CUDA completo, digite:
sudo yum install cuda
NOTE
Se você vir uma mensagem de erro relacionada a pacotes ausentes, como Vulkan-FileSystem, talvez seja
necessário editar/etc/yum.repos.d/RH-Cloud, procurar por optional-RPMs e definir Enabled como 1

Verificar a instalação de drivers
Para consultar o estado do dispositivo GPU, conecte-se à VM por SSH e execute o utilitário de linha de comando
nvidia-smi instalado com o driver.
Se o driver estiver instalado, você verá uma saída parecida com a mostrada a seguir. Observe que GPU-Util
mostrará 0%, a menos que você esteja executando uma carga de trabalho da GPU na VM. Sua versão de driver e
os detalhes GPU podem ser diferentes daqueles mostrados.
Conectividade de rede RDMA

A conectividade de rede RDMA pode ser habilitada em VMs da série N compatíveis com RDMA, como o NC24r
implantado no mesmo conjunto de disponibilidade ou em um grupo de posicionamento único em um conjunto
de dimensionamento de máquina virtual (VM). A rede RDMA dá suporte ao tráfego da Interface de transmissão
de mensagens (MPI) para aplicativos executados com Intel MPI 5.x ou uma versão posterior. Requisitos
adicionais são listados a seguir:
Distribuições
Implante VMs da série N habilitadas para RDMA de uma das imagens no Azure Marketplace que é compatível
com a conectividade RDMA nas VMs da série N:
Ubuntu 16.04 LTS – Configure os drivers RDMA na VM e registre-se na Intel para baixar a MPI da Intel:
1. Instalar dapl, rdmacm, ibverbs e mlx4
sudo apt-get update
sudo apt-get install libdapl2 libmlx4-1
2. Em /etc/waagent.conf, habilite o RDMA removendo as marcas de comentários das seguintes linhas

de configuração. Você precisa de acesso à raiz para editar esse arquivo.
OS.EnableRDMA=y
OS.UpdateRdmaDriver=y
3. Adicione ou altere as seguintes configurações de memória em KB no arquivo

/etc/security/limits.conf. Você precisa de acesso à raiz para editar esse arquivo. Para fins de teste, é
possível definir memlock como ilimitado. Por exemplo:
<User or group name> hard memlock unlimited .
<User or group name> hard memlock <memory required for your application in KB>
<User or group name> soft memlock <memory required for your application in KB>
4. Instalar a Intel MPI Library. Comprar e baixe a biblioteca da Intel ou baixe a versão de avaliação
gratuita.
wget http://registrationcenter-download.intel.com/akdlm/irc_nas/tec/9278/l_mpi_p_5.1.3.223.tgz
Há suporte apenas para runtimes MPI Intel 5.x.

Para saber as etapas de instalação, consulte o Guia de instalação da Intel MPI Library.
5. Habilite ptrace para os processos que não são de depuração e não são da raiz (necessária para as
versões mais recentes da Intel MPI).
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
CentOS-based 7.4 HPC - Os drivers RDMA e o Intel MPI 5.1 são instalados na VM.
HPC baseado em CentOS -CentOS-HPC 7,6 e posterior (para SKUs em que a InfiniBand tem suporte
em relação a Sr-IOV). Essas imagens têm bibliotecas Mellanox OFED e MPI pré-instaladas.
NOTE
CX3-Pro cartões têm suporte apenas por meio de versões LTS do Mellanox OFED. Use LTS Mellanox OFED Version (4.9-
0.1.7.0) nas VMs da série N com cartões de ConnectX3-Pro. Para obter mais informações, consulte drivers do Linux.
Além disso, algumas das mais recentes imagens do HPC do Azure Marketplace têm o Mellanox OFED 5,1 e posterior, que
não dá suporte a cartões ConnectX3-Pro. Verifique a versão do Mellanox OFED na imagem do HPC antes de usá-la em
VMs com cartões de ConnectX3-Pro.
As imagens a seguir são as mais recentes imagens do CentOS-HPC que dão suporte a cartões de ConnectX3-Pro:
OpenLogic: CentOS-HPC: 7.6:7.6.2020062900
OpenLogic: CentOS-HPC: 7_6gen2:7.6.2020062901
OpenLogic: CentOS-HPC: 7.7:7.7.2020062600
OpenLogic: CentOS-HPC: 7_7-Gen2:7.7.2020062601
OpenLogic: CentOS-HPC: 8_1:8.1.2020062400
OpenLogic: CentOS-HPC: 8_1-Gen2:8.1.2020062401
Instalar drivers de GRID em VMs da série NVv3 ou NV

Para instalar drivers NVIDIA GRID em VMs da série NVv3 ou NV, faça uma conexão SSH para cada VM e siga as
etapas para a sua distribuição do Linux.
Ubuntu
1. Execute o comando lspci . Verifique se a placa ou placas NVIDIA M60 estão visíveis como dispositivos
PCI.
2. Instale as atualizações.
sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get dist-upgrade -y
sudo apt-get install build-essential ubuntu-desktop -y
sudo apt-get install linux-azure -y
3. Desabilite o driver de kernel Nouveau, que é incompatível com o driver NVIDIA. (Apenas use o driver
NVIDIA em VMs NVv2 ou NV.) Para fazer isso, crie um arquivo em /etc/modprobe.d chamado
nouveau.conf com o conteúdo a seguir:
blacklist nouveau
blacklist lbm-nouveau
4. Reinicie a VM e reconecte. Saia do servidor X:
sudo systemctl stop lightdm.service
5. Baixe e instale o driver GRID:

wget -O NVIDIA-Linux-x86_64-grid.run https://go.microsoft.com/fwlink/?linkid=874272
chmod +x NVIDIA-Linux-x86_64-grid.run
sudo ./NVIDIA-Linux-x86_64-grid.run
6. Quando você for questionado se deseja executar o utilitário nvidia-xconfig para atualizar seu arquivo de
configuração X, selecione Sim .
7. Após a conclusão da instalação, copie /etc/nvidia/gridd.conf.template para um novo arquivo gridd.conf
no local /etc/hosts nvidia/
sudo cp /etc/nvidia/gridd.conf.template /etc/nvidia/gridd.conf
8. Adicione o seguinte a /etc/nvidia/gridd.conf :
IgnoreSP=FALSE
EnableUI=FALSE
9. Remova o seguinte de /etc/nvidia/gridd.conf se estiver presente:
FeatureType=0

CentOS ou Red Hat Enterprise Linux
1. Atualize o kernel e o DKMS (recomendado). Se você optar por não atualizar o kernel, verifique se as
versões kernel-devel e dkms são apropriadas para seu kernel.
sudo yum update
sudo yum install kernel-devel
sudo rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum install dkms
sudo yum install hyperv-daemons
2. Desabilite o driver de kernel Nouveau, que é incompatível com o driver NVIDIA. (Use apenas o driver
NVIDIA em VMs NV ou NV3.) Para fazer isso, crie um arquivo em /etc/modprobe.d nome nouveau.conf
com o seguinte conteúdo:
blacklist nouveau
blacklist lbm-nouveau
3. Reinicie a VM, reconecte e instale o último Integration Services do Linux para Hyper-V e Azure. Verifique
se LIS é necessário verificando os resultados de lspci. Se todos os dispositivos GPU estiverem listados
como esperado, a instalação de LIS não será necessária.
Ignore esta etapa é usar o CentOS/RHEL 7,8 e superior.
tar xvzf lis
cd LISISO
sudo ./install.sh
sudo reboot
4. Reconecte-se à VM e execute o comando lspci . Verifique se a placa ou placas NVIDIA M60 estão visíveis
como dispositivos PCI.
5. Baixe e instale o driver GRID:
wget -O NVIDIA-Linux-x86_64-grid.run https://go.microsoft.com/fwlink/?linkid=874272
chmod +x NVIDIA-Linux-x86_64-grid.run
sudo ./NVIDIA-Linux-x86_64-grid.run
6. Quando você for questionado se deseja executar o utilitário nvidia-xconfig para atualizar seu arquivo de
configuração X, selecione Sim .
7. Após a conclusão da instalação, copie /etc/nvidia/gridd.conf.template para um novo arquivo gridd.conf
no local /etc/hosts nvidia/
sudo cp /etc/nvidia/gridd.conf.template /etc/nvidia/gridd.conf
8. Adicione o seguinte a /etc/nvidia/gridd.conf :
IgnoreSP=FALSE
EnableUI=FALSE
9. Remova o seguinte de /etc/nvidia/gridd.conf se estiver presente:
FeatureType=0

Para consultar o estado do dispositivo GPU, conecte-se à VM por SSH e execute o utilitário de linha de comando
nvidia-smi instalado com o driver.
Se o driver estiver instalado, você verá uma saída parecida com a mostrada a seguir. Observe que GPU-Util
mostrará 0%, a menos que você esteja executando uma carga de trabalho da GPU na VM. Sua versão de driver e
os detalhes GPU podem ser diferentes daqueles mostrados.
Servidor X11
Se você precisa de um servidor X11 para conexões remotas com uma VM NVv2 ou NV, o x11vnc é
recomendado porque ele permite a aceleração de hardware para gráfico. A BusID do dispositivo M60 precisa ser
adicionada manualmente ao arquivo de configuração X11 (normalmente, etc/X11/xorg.conf ). Adicione uma
seção "Device" semelhante à seguinte:
Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "Tesla M60"
BusID "PCI:0@your-BusID:0:0"
EndSection
Além disso, atualize sua seção "Screen" para usar este dispositivo.
A BusID decimal pode ser encontrada executando
nvidia-xconfig --query-gpu-info | awk '/PCI BusID/{print $4}'
A BusID pode mudar quando uma VM é realocada ou reinicializada. Portanto, convém criar um script para
atualizar a BusID na configuração do X11 quando uma VM é reiniciada. Por exemplo, crie um script chamado
busidupdate.sh (ou outro nome que desejar) com um conteúdo semelhante ao seguinte:
#!/bin/bash
XCONFIG="/etc/X11/xorg.conf"
OLDBUSID=àwk '/BusID/{gsub(/"/, "", $2); print $2}' ${XCONFIG}`
NEWBUSID=`nvidia-xconfig --query-gpu-info | awk '/PCI BusID/{print $4}'`
if [[ "${OLDBUSID}" == "${NEWBUSID}" ]] ; then

echo "NVIDIA BUSID not changed - nothing to do"
else
echo "NVIDIA BUSID changed from \"${OLDBUSID}\" to \"${NEWBUSID}\": Updating ${XCONFIG}"
sed -e 's|BusID.*|BusID '\"${NEWBUSID}\"'|' -i ${XCONFIG}
fi
Em seguida, crie uma entrada para o seu script de atualização em /etc/rc.d/rc3.d para que o script seja
invocado como raiz na inicialização.
Você pode definir o modo de persistência usando nvidia-smi , de modo que o resultado do comando seja
mais rápido quando você precisar consultar cartões. Para definir o modo de persistência, execute
nvidia-smi -pm 1 . Observe que, se a VM for reiniciada, a configuração do modo desaparecerá. Você sempre
pode gerar um script da configuração de modo para ser executada na inicialização.
Se você atualizou os drivers NVIDIA CUDA para a versão mais recente e descobrir que a conectividade RDMA
não está mais funcionando, reinstale os drivers RDMA para restabelecer essa conectividade.
Se uma determinada versão do sistema operacional CentOS/RHEL (ou kernel) não tiver suporte para LIS, um
erro "versão do kernel sem suporte" será gerado. Relate esse erro junto com as versões do sistema
operacional e do kernel.
Próximas etapas
Para capturar uma imagem de VM do Linux na qual você tenha instalado drivers NVIDIA, consulte Como
generalizar e capturar uma máquina virtual Linux.
Instalar drivers de GPU NVIDIA em VMs da série N
que executam o Windows
Para aproveitar as funcionalidades de GPU das VMs da série N do Azure que contam com GPUs da NVIDIA, é
preciso instalar os drivers para GPU NVIDIA. A Extensão de Driver de GPU NVIDIA instala drivers CUDA ou GRID
NVIDIA apropriados em VMs da série N. Instale ou gerencie a extensão usando o portal do Azure ou
ferramentas, como Azure PowerShell ou modelos do Azure Resource Manager. Confira a documentação da
Extensão de Driver de GPU NVIDIA para saber quais são os sistemas operacionais compatíveis e as etapas de
implantação.
Se você optar por instalar os drivers NVIDIA GPU manualmente, este artigo fornecerá os sistemas operacionais,
drivers e etapas de instalação e verificação com suporte. As informações de instalação manual de driver
também estão disponíveis para VMs do Linux.
Para especificações básicas, capacidades de armazenamento e detalhes de disco, consulte tamanhos de VM
Windows da GPU.

Drivers NVIDIA Tesla (CUDA )
Os drivers NVIDIA Tesla (CUDA) para as VMs NC, NCv2, NCv3, NCasT4_v3, ND e NDv2 Series (opcional para a
série NV) têm suporte apenas nos sistemas operacionais listados na tabela a seguir. Os links de download do
driver Tesla são atuais no momento da publicação. Para os drivers mais recentes, visite o site da NVIDIA.
TIP
Como alternativa à instalação manual do driver CUDA em uma VM do Windows Server, você pode implantar uma
imagem da Máquina Virtual de Ciência de Dados do Azure. As edições DSVM do Windows Server 2016 instalam
previamente os drivers NVIDIA CUDA, a Biblioteca de Rede Neural Profunda CUDA e outras ferramentas.
SIST EM A O P ERA C IO N A L DRIVER
Windows Server 2019 451,82 (. exe)
Windows Server 2016 451,82 (. exe)
Drivers NVIDIA GRID

A Microsoft redistribui os instaladores de driver de grade NVIDIA para VMs de série NVv3 e NV usadas como
estações de trabalho virtuais ou para aplicativos virtuais. Instale somente esses drivers de grade nas VMs da
série NV do Azure, somente nos sistemas operacionais listados na tabela a seguir. Esses drivers incluem o
licenciamento de Software de GPU Virtual de GRID no Azure. Você não precisa configurar um servidor de
licença de software de vGPU NVIDIA.
Os drivers de grade redistribuídos pelo Azure não funcionam em VMs da série não NV, como as VMs NCv2,
NCv3, ND e NDv2-Series. A única exceção é a série de VM NCas_T4_V3, em que os drivers de grade habilitarão
as funcionalidades de gráficos semelhantes à série NV.
O NC-Series com GPUs NVIDIA K80 não oferece suporte a aplicativos de grade/gráficos.
Observe que a extensão NVIDIA sempre instalará o driver mais recente. Fornecemos links para a versão anterior
aqui para os clientes que têm dependência em uma versão mais antiga.
Para o Windows Server 2019, Windows Server 2016 1607, 1709 e Windows 10 (até o Build 20H2):
Grade 12,0 (461, 9) (. exe)
Grade 11,3 (452,77) (. exe)
Para o Windows Server 2012 R2:
Grade 12,0 (461, 9) (. exe)
Grade 11,3 (452,77) (. exe)
Para obter a lista completa de todos os links de driver de grade NVIDIA anteriores, visite GitHub
Instalação do driver
1. Conecte-se pela Área de Trabalho Remota a cada VM da série N.
2. Baixe, extraia e instale o driver com suporte para o sistema operacional Windows.
Uma reinicialização é necessária após a instalação do driver de GRID em uma VM. Uma reinicialização não é
necessária após a instalação do driver de CUDA.

Observe que o painel de controle NVIDIA só está acessível com a instalação do driver de grade. Se você tiver
instalado drivers CUDA, o painel de controle nvidia não estará visível.
É possível verificar a instalação de drivers no Gerenciador de Dispositivos. O exemplo a seguir mostra uma
configuração bem-sucedida da placa Tesla K80 em uma VM NC do Azure.
Para consultar o estado do dispositivo GPU, execute o utilitário de linha de comando nvidia-smi instalado com o
driver.
1. Abra um prompt de comando e mude para o diretório C:\Program Files\NVIDIA
Corporation\NVSMI .
2. Execute nvidia-smi . Se o driver estiver instalado, você verá uma saída parecida com a mostrada a seguir.
O GPU-Util mostra 0% , a menos que você esteja atualmente executando uma carga de trabalho de GPU
na VM. Sua versão de driver e os detalhes GPU podem ser diferentes daqueles mostrados.
Conectividade de rede RDMA

A conectividade de rede RDMA pode ser ativada em VMs da série N com capacidade de RDMA, como o NC24r
implementado no mesmo conjunto de disponibilidade ou em um único grupo de posicionamento em um
conjunto de dimensionamento de máquina virtual. A extensão HpcVmDrivers deve ser adicionada para instalar
drivers de dispositivo de rede do Windows que habilitam a conectividade RDMA. Para adicionar a extensão de
VM a uma VM da série N habilitada para RDMA, use cmdlets do Azure PowerShell para o Azure Resource
Manager.
Para instalar a última extensão HpcVMDrivers versão 1.1 em uma VM compatível com RDMA existente chamada
myVM na região Oeste dos EUA:
Set-AzVMExtension -ResourceGroupName "myResourceGroup" -Location "westus" -VMName "myVM" -ExtensionName

"HpcVmDrivers" -Publisher "Microsoft.HpcCompute" -Type "HpcVmDrivers" -TypeHandlerVersion "1.1"
Para obter mais informações, consulte Recursos e extensões da máquina virtual para Windows.
A rede RDMA dá suporte ao tráfego da Interface de transmissão de mensagens (MPI) para aplicativos
executados com Microsoft MPI ou Intel MPI 5.x.
Próximas etapas
Desenvolvedores compilando aplicativos acelerados por GPU para GPUs NVIDIA Tesla também podem baixar
e instalar o CUDA Toolkit. Para obter mais informações, consulte o Guia de instalação do CUDA.
Instalação de drivers de GPU AMD em VMs da
série N executando Windows
Para aproveitar as funcionalidades da GPU das VMs da série NVv4 do Azure executando Windows, é necessário
instalar os drivers de GPU AMD. A Extensão de Driver de GPU AMD instala drivers de GPU AMD em uma VM da
série NVv4. Instale ou gerencie a extensão usando o portal do Azure ou ferramentas, como Azure PowerShell ou
modelos do Azure Resource Manager. Veja a documentação da Extensão de Driver de GPU AMD para saber
quais são os sistemas operacionais suportados e as etapas de implantação.
Se optar por instalar os drivers de GPU AMD manualmente, este artigo fornece os sistemas operacionais
suportados, os drivers e as etapas de instalação e verificação.
Apenas os drivers de GPU publicados pela Microsoft são suportados em VMs da série NVv4. NÃO INSTALE
drivers de GPU de nenhuma outra fonte.
Para especificações básicas, capacidades de armazenamento e detalhes de disco, consulte tamanhos de VM
Windows da GPU.

SIST EM A O P ERA C IO N A L DRIVER
Windows 10 Enterprise Multi-Session-compilação 1909 20. Q4 (. exe)
Windows 10-Build 1909
Windows Server 2016
Windows Server 2019
NOTE
Se você usar o Build 1903/1909, talvez seja necessário atualizar a seguinte política de grupo para obter um desempenho
ideal. Essas alterações não são necessárias para qualquer outra compilação do Windows.
[Configuração do computador-políticas de >->configurações do Windows->Modelos Administrativos->componentes do
Windows->Serviços de Área de Trabalho Remota->Host da Sessão da Área de Trabalho Remota->ambiente de sessão
remota], defina a política [usar driver de exibição de gráficos do WDDM para conexões Área de Trabalho Remota] como
desabilitado.
Instalação do driver
1. Conecte-se pela Área de Trabalho Remota a cada VM da série NVv4.
2. Se você precisar desinstalar a versão anterior do driver, baixe o utilitário de limpeza AMD aqui , não use o
utilitário fornecido com a versão anterior do driver.
3. Baixe e instale o driver mais recente.
4. Reinicialize a VM.
É possível verificar a instalação de drivers no Gerenciador de Dispositivos. O exemplo a seguir mostra uma
configuração bem-sucedida da placa Radeon Instinct MI25 em uma VM da série NVv4 do Azure.
Use dxdiag para verificar as propriedades de exibição da GPU, incluindo a RAM de vídeo. O exemplo a seguir
mostra a metade de uma partição placa Radeon Instinct MI25 em uma VM da série NVv4 do Azure.
Se estiver executando o Windows 10 build 1903 ou superior, então dxdiag não mostrará nenhuma informação
na guia “Exibição”. Use a opção “Salvar todas as informações” na parte inferior e o arquivo de saída mostrará as
informações relacionadas à GPU AMD MI25.
Tamanhos de máquina virtual FPGA otimizados
Os tamanhos de VM otimizados para FPGA são máquinas virtuais especializadas disponíveis com um ou vários
FPGAs. Esses tamanhos são projetados para cargas de trabalho de computação intensiva. Este artigo fornece
informações sobre o número e tipo de FPGAs, vCPUs, discos de dados e NICs. A taxa de transferência de
armazenamento e a largura de banda de rede também são incluídos para cada tamanho neste agrupamento.
Os tamanhos da série NP são otimizados para cargas de trabalho, incluindo inferência de aprendizado de
máquina, transcodificação de vídeo e pesquisa de banco de dados & análise. A série NP é alimentada por
Xilinx U250 Accelerators.
Para ver a disponibilidade das VMs da Série N, veja Produtos disponíveis por região.
As VMs da Série N só podem ser implantadas no modelo de implantação do Resource Manager.
Se você quiser implantar mais do que algumas VMs da Série N, considere uma assinatura pré-paga ou
outras opções de compra. Se estiver usando uma conta gratuita do Azure, você poderá usar apenas um
número limitado de núcleos de computação do Azure.
Talvez seja necessário aumentar a cota de núcleos (por região) em sua assinatura do Azure e aumentar a
cota separada para os núcleos de NP. Para solicitar um aumento de cota, abra uma solicitação de
atendimento ao cliente online gratuitamente. Os limites padrão podem variar dependendo de sua
categoria de assinatura.
Outros tamanhos
Propósito geral
Computação acelerada por GPU
Memória otimizada
Próximas etapas
Série NP (versão prévia)
As máquinas virtuais da série NP são alimentadas por Xilinx U250 FPGAs para acelerar cargas de trabalho,
incluindo inferência de aprendizado de máquina, transcodificação de vídeo e pesquisa de & de banco de dados.
As VMs da série NP também são alimentadas por CPUs do Intel Xeon 8171M (Skylake) com toda a velocidade
do clock de Turbo principal de 3,2 GHz.
M Á XIM O
DE
N IC S/ L A RG
M EN TO B A N DA DE
T EM P O RÁ R DISC O S DE REDE
M EM Ó RIA : IO ( SSD) M EM Ó RIA DA DO S ESP ERA DA
TA M A N H O VC P U GIB GIB F P GA F P GA : GIB M Á XIM O S ( M B P S)
Standard_N 10 168 736 1 64 8 1 / 7500

P10s
Standard_N 20 336 1474 2 128 16 2 / 15000

P20s
Standard_N 40 672 2948 4 256 32 4 / 30000

P40s

= 1098,4 GB.

Visite notas de versão do Xilinx Runtime (XRT) para obter a lista completa de sistemas operacionais com
suporte.
Durante o programa de visualização Microsoft Azure as equipes de engenharia compartilharão instruções
específicas para a instalação do driver.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Tamanhos de VM de computação de alto
desempenho
As VMs (máquinas virtuais) da série H do Azure foram projetadas para fornecer desempenho, escalabilidade e
eficiência de custo da classe de liderança para uma variedade de cargas de trabalho do HPC do mundo real.
Série HBv2 As VMs são otimizadas para aplicativos orientados pela largura de banda da memória, como
dinâmica de fluidos, análise de elemento finito e simulação de reservatório. HBv2 VMs Feature 120 AMD EPYC
7742 núcleos de processador, 4 GB de RAM por núcleo de CPU e nenhum multithread simultâneo. Cada VM
HBv2 fornece até 340 GB/s de largura de banda de memória e até 4 teraFLOPS de computação FP64.
O recurso de VMs HBv2 de 200 GB/s Mellanox HDR InfiniBand, enquanto as VMs da série HB e HC apresentam
100 GB/s Mellanox EDR InfiniBand. Cada um desses tipos de VM é conectado em uma árvore Fat sem bloqueio
para desempenho de RDMA otimizado e consistente. As VMs HBv2 dão suporte ao roteamento adaptável e ao
transporte conectado dinâmico (DCT, em outros transportes Standard RC e UD). Esses recursos aprimoram o
desempenho, a escalabilidade e a consistência do aplicativo e o uso deles é altamente recomendável.
Série HB As VMs são otimizadas para aplicativos orientados por largura de banda de memória, como dinâmica
de fluidos, análise de elemento finito explícito e modelagem de clima. As VMs HB apresentam 60 AMD EPYC
7551 núcleos de processador, 4 GB de RAM por núcleo de CPU e nenhum hyperthreading. A plataforma AMD
EPYC fornece mais de 260 GB/s de largura de banda de memória.
Série HC As VMs são otimizadas para aplicativos orientados por computação densa, como análise implícita de
elemento finito, Molecular Dynamics e química computacional. O HC VMs Feature 44 Intel Xeon Platinum 8168
núcleos de processador, 8 GB de RAM por núcleo de CPU e nenhum hyperthreading. A plataforma Intel Xeon
Platinum dá suporte ao ecossistema avançado de ferramentas de software da Intel, como a biblioteca de kernels
matemáticos da Intel.
Série H As VMs são otimizadas para aplicativos orientados por altas frequências de CPU ou grandes requisitos
de memória por núcleo. As VMs da série H apresentam 8 ou 16 núcleos de processador Intel Xeon E5 2667 v3, 7
ou 14 GB de RAM por núcleo de CPU e nenhum hyperthreading. A série H apresenta 56 GB/s Mellanox FDR
InfiniBand em uma configuração de árvore de Fat sem bloqueio para desempenho consistente de RDMA. As
VMs da série H dão suporte ao Intel MPI 5. x e ao MS-MPI.
NOTE
Todas as VMs da série HBv2, HB e HC têm acesso exclusivo aos servidores físicos. Há apenas 1 VM por servidor físico e
não há multilocação compartilhada com outras VMs para esses tamanhos de VM.
NOTE
As VMs A8 – a11 estão planejadas para aposentadoria em 3/2021. Para obter mais informações, confira o Guia de
migração de HPC.
Instâncias compatíveis com RDMA

A maioria dos tamanhos de VM HPC (HBv2, HB, HC, H16r, H16mr, A8 e A9) tem um recurso de interface de rede
para conectividade RDMA (acesso remoto direto à memória). Os tamanhos de série N selecionados designados
com ' r ' (ND40rs_v2, ND24rs, NC24rs_v3, NC24rs_v2 e NC24r) também são compatíveis com RDMA. Essa
interface é além da interface de rede Ethernet padrão do Azure disponível nos outros tamanhos de VM.
Essa interface permite que as instâncias compatíveis com RDMA comuniquem-se por uma rede InfiniBand (IB),
operando com tarifas HDR para HBv2, taxas de EDR para HB, HC, NDv2, taxas de FDR para H16r, H16mr e outras
máquinas virtuais da série N compatíveis com RDMA e taxas de QDR para VMs A8 e A9. Esses recursos RDMA
podem melhorar a escalabilidade e o desempenho de determinados aplicativos MPI (Interface de Transmissão
de Mensagens).
NOTE
No Azure HPC, há duas classes de VMs, dependendo se elas estão habilitadas para a InfiniBand. Atualmente, quase todas
as VMs habilitadas para RDMA ou de geração mais recentes no Azure são SR-IOV habilitado, exceto para H16r, H16mr,
NC24r, A8, A9. O RDMA só é habilitado pela rede InfiniBand (IB) e tem suporte para todas as VMs compatíveis com
RDMA. Só há suporte para IP sobre IB em VMs habilitadas para SR-IOV. O RDMA não está habilitado pela rede Ethernet.
Sistema operacional -o Linux tem suporte muito bem para VMs HPC; distribuições como CentOS,
RHEL, Ubuntu, SUSE são usados com frequência. Em relação ao suporte do Windows, o Windows Server
2016 e versões mais recentes têm suporte em todas as VMs da série HPC. O Windows Server 2012 R2,
Windows Server 2012 também tem suporte em VMs não habilitadas para SR-IOV (H16r, H16mr, A8 e
A9). Observe que o Windows Server 2012 R2 não tem suporte no HBv2 e em outras VMs com mais de
64 núcleos (virtuais ou físicos). Consulte imagens de VM para obter uma lista de imagens de VM com
suporte no Marketplace e como elas podem ser configuradas adequadamente.
InfiniBand e drivers -em VMs habilitadas para InfiniBand, os drivers apropriados são necessários para
habilitar o RDMA. No Linux, para VMs de SR-IOV e não habilitadas para SR-IOV, as imagens de VM do
CentOS-HPC no Marketplace são pré-configuradas com os drivers apropriados. As imagens de VM
Ubuntu podem ser configuradas com os drivers corretos usando as instruções aqui. Consulte configurar
e otimizar VMs para o sistema operacional Linux para obter mais detalhes sobre imagens de SO Linux de
VM prontas para uso.
No Linux, a extensão de VM InfiniBandDriverLinux pode ser usada para instalar os drivers Mellanox ofed
e habilitar o InfiniBand nas VMs das séries H e N habilitadas para Sr-iov. Saiba mais sobre como habilitar
o InfiniBand em VMs compatíveis com RDMA em cargas de trabalho de HPC.
No Windows, a extensão de VM InfiniBandDriverWindows instala drivers diretos de rede do Windows
(em VMs que não são de Sr-IOV) ou drivers Mellanox ofed (em VMs Sr-IOV) para conectividade RDMA.
Em determinadas implantações de instâncias A8 e A9, a extensão HpcVmDrivers é adicionada
automaticamente. Observe que a extensão de VM HpcVmDrivers está sendo preterida; Ele não será
atualizado.
Para adicionar a extensão de VM a uma VM, use cmdlets do Azure PowerShell. Para obter mais
informações, consulte Recursos e extensões da máquina virtual. Também é possível trabalhar com
extensões de VMs implantadas no modelo de implantação clássico.
MPI -os tamanhos de VM habilitados para Sr-IOV no Azure permitem que quase qualquer tipo de MPI
seja usado com o Mellanox ofed. Em VMs não habilitadas para SR-IOV, as implementações MPI com
suporte usam a interface do Microsoft Network Direct (ND) para se comunicar entre as VMs. Portanto,
somente as versões do Microsoft MPI (MS-MPI) 2012 R2 ou posterior e do Intel MPI 5. x têm suporte.
Versões posteriores (2017, 2018) da biblioteca de tempo de execução do Intel MPI podem ou não ser
compatíveis com os drivers RDMA do Azure. Consulte Setup MPI for HPC para obter mais detalhes sobre
como configurar MPI em VMs do HPC no Azure.
Espaço de endereço de rede RDMA - A rede RDMA no Azure reserva o espaço de endereço
172.16.0.0/16. Para executar aplicativos MPI em instâncias implantadas em uma rede virtual do Azure,
verifique se o espaço do endereço de rede virtual não se sobrepõe à rede RDMA.
Opções de configuração de cluster

O Azure fornece várias opções para criar clusters de VMs do Windows HPC que podem se comunicar usando a
rede RDMA, incluindo:
Máquinas vir tuais – implante as VMs HPC compatíveis com RDMA no mesmo conjunto de
dimensionamento ou conjunto de disponibilidade (ao usar o modelo de implantação Azure Resource
Manager). Se você usar o modelo de implantação clássico, implante as VMs no mesmo serviço de nuvem.
Conjuntos de dimensionamento de máquinas vir tuais – em um conjunto de dimensionamento de
máquinas virtuais, certifique-se de limitar a implantação a um único grupo de posicionamento para
comunicação InfiniBand dentro do conjunto de dimensionamento. Por exemplo, em um modelo do
Resource Manager, defina a singlePlacementGroup propriedade como true . Observe que o tamanho
máximo do conjunto de dimensionamento que pode ser girado com a singlePlacementGroup propriedade
para true é limitado às VMs 100 por padrão. Se suas necessidades de escala de trabalho do HPC forem
maiores que 100 VMs em um único locatário, você poderá solicitar um aumento, abrir uma solicitação de
atendimento ao cliente online sem encargos. O limite do número de VMs em um único conjunto de
dimensionamento pode ser aumentado para 300. Observe que, ao implantar VMs usando conjuntos de
disponibilidade, o limite máximo é de 200 VMs por conjunto de disponibilidade.
MPI entre máquinas vir tuais – se RDMA (por exemplo, usando a comunicação MPI) for necessário
entre VMs (máquinas virtuais), verifique se as VMs estão no mesmo conjunto de dimensionamento de
máquinas virtuais ou conjunto de disponibilidade.
Azure CycleCloud -criar um cluster HPC no Azure CycleCloud para executar trabalhos MPI.
Lote do Azure -crie um pool do lote do Azure para executar cargas de trabalho MPI. Para usar instâncias
de computação intensiva para executar aplicativos MPI com o Lote do Azure, consulte Usar tarefas de
várias instâncias para executar aplicativos MPI (Interface de Transmissão de Mensagens) no Lote do
Azure.
Microsoft HPC Pack - O HPC Pack inclui um ambiente de tempo de execução para MS-MPI que usa a
rede RDMA do Azure quando implantado em VMs do Linux compatíveis com RDMA. Por exemplo, para
implantações, consulte configurar um cluster de RDMA do Linux com o HPC Pack para executar
aplicativos MPI.
Assinatura do Azure – Para implantar um número maior de instâncias de computação intensiva,
considere uma assinatura pré-paga ou outras opções de compra. Se estiver usando uma conta gratuita
do Azure, você poderá usar apenas um número limitado de núcleos de computação do Azure.
Preço e disponibilidade – esses tamanhos de VM são oferecidos apenas no tipo de preço Standard.
Confira Produtos disponíveis por região para ver a disponibilidade nas regiões do Azure.
Cota de núcleos – Talvez seja preciso aumentar a cota de núcleos em sua assinatura do Azure, saindo
do valor padrão. Sua assinatura também pode limitar o número de núcleos que você pode implantar em
determinadas famílias de tamanho de VM, incluindo a série de H. Para solicitar um aumento de cota, abra
uma solicitação de atendimento ao cliente online gratuitamente. (Os limites padrão podem variar
dependendo de sua categoria de assinatura.)
NOTE
Entre em contato com o Suporte do Azure se precisar de capacidade em larga escala. Cotas do Azure são limites
de crédito, não garantias de capacidade. Independentemente de sua cota, você é cobrado apenas pelo núcleos
utilizados.
Rede vir tual – Não é necessário ter uma rede virtual do Azure para usar instâncias de computação
intensiva. No entanto, para muitas implantações, é necessária pelo menos uma rede virtual do Azure
baseada em nuvem ou uma conexão site a site se você precisar acessar recursos locais. Quando
necessário, você precisará criar uma nova rede virtual para implantar as instâncias. Não há suporte para
a adição de VMs de computação intensiva a uma rede virtual em um grupo de afinidades.
Redimensionamento – devido ao seu hardware especializado, você só pode redimensionar instâncias
de computação intensiva dentro da mesma família de tamanho (série H ou série N). Por exemplo,
somente é possível redimensionar uma VM da série H de um tamanho da série H para outro.
Considerações adicionais sobre o suporte do driver InfiniBand e discos de NVMe podem precisar ser
consideradas para determinadas VMs.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Saiba mais sobre como configurar suas VMs, habilitar a INFINIBAND, Configurar MPI e otimizar aplicativos
HPC para o Azure em cargas de trabalho do HPC.
Leia os comunicados mais recentes e alguns exemplos e resultados da HPC nos Blogs da Tech Community da
Computação do Azure.
Para obter uma visão de nível superior da arquitetura de execução de cargas de trabalho de HPC, confira HPC
(computação de alto desempenho) no Azure.
Série H
As VMs da série H são otimizadas para aplicativos orientados por altas frequências de CPU ou grandes
requisitos de memória por núcleo. As VMs da série H apresentam 8 ou 16 núcleos de processador Intel Xeon E5
2667 v3, até 14 GB de RAM por núcleo de CPU e sem hyperthreading. A série H apresenta 56 GB/s Mellanox
FDR InfiniBand em uma configuração de árvore de Fat sem bloqueio para desempenho consistente de RDMA.
As VMs da série H não são habilitadas para o SR-IOV atualmente e dão suporte ao Intel MPI 5. x e ao MS-MPI.
ACU: 290-300
F RE
Q UÊ TA X
NCI F RE A DE
LAR A DE Q UÊ A RM T RA
GUR TO D NCI AZE N SF
A DE F RE OS A DE DES NA ERÊ
BAN Q UÊ OS N ÚC EM P M EN DISC NCI
DA NCI N ÚC L EO EN H TO OS A VN I
DE A DE L EO ÚN I O T EM DE MÁX CS
ME ME CPU S CO DE POR DA D IM A ET H
P RO MÓ MÓ BAS ( GH ( GH RDM SUP Á RI OS DO ERN
TA M C ES RIA RIA E Z, Z, A O RT O MÁX DISC ET
ANH VC P SA D ( GIB GB / ( GH P IC P IC ( GB / EA ( GIB IM O O: MÁX
O U OR ) S Z) O) O) S) MPI ) S IO P S .
Stan 8 Intel 56 40 3.2 3.3 3,6 - Intel 100 32 32 x 2

dard Xeo 5. x, 0 500
_H8 n E5 MS-
266 MPI
7 v3

_H1 n E5 MS-
6 266 MPI
7 v3

_H8 n E5 MS-
m 266 MPI
7 v3
F RE
Q UÊ TA X
NCI F RE A DE
LAR A DE Q UÊ A RM T RA
GUR TO D NCI AZE N SF
A DE F RE OS A DE DES NA ERÊ
BAN Q UÊ OS N ÚC EM P M EN DISC NCI
DA NCI N ÚC L EO EN H TO OS A VN I
DE A DE L EO ÚN I O T EM DE MÁX CS
ME ME CPU S CO DE POR DA D IM A ET H
P RO MÓ MÓ BAS ( GH ( GH RDM SUP Á RI OS DO ERN
TA M C ES RIA RIA E Z, Z, A O RT O MÁX DISC ET
ANH VC P SA D ( GIB GB / ( GH P IC P IC ( GB / EA ( GIB IM O O: MÁX
O U OR ) S Z) O) O) S) MPI ) S IO P S .

_H1 n E5 MS-
6m 266 MPI
7 v3
Stan 16 Intel 112 80 3.2 3.3 3,6 56 Intel 200 64 64 x 4

_H1 n E5 MS-
6r 1 266 MPI
7 v3
Stan 16 Intel 224 80 3.2 3.3 3,6 56 Intel 200 64 64 x 4

_H1 n E5 MS-
6mr 266 MPI
1 7 v3
1 para aplicativos MPI, a rede de back-end RDMA dedicada é habilitada pela rede InfiniBand FDR.

= 1098,4 GB.
NOTE
Entre as VMs compatíveis com RDMA, a série H não é habilitada para Sr-iov. Portanto, as imagens de VMcom suporte, os
requisitos de Driver InfiniBand e as bibliotecas MPI com suporte são diferentes das VMs habilitadas para Sr-iov.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série HB
As VMs da série HB são otimizadas para aplicativos orientados por largura de banda de memória, como
dinâmica de fluidos, análise de elemento finito explícito e modelagem de clima. HB VMs Feature 60 AMD EPYC
7551 núcleos de processador, 4 GB de RAM por núcleo de CPU e nenhum multithread simultâneo. Uma VM HB
fornece até 260 GB/s de largura de banda de memória.
As VMs da série HB apresentam 100 GB/s Mellanox EDR InfiniBand. Essas VMs são conectadas em uma árvore
Fat sem bloqueio para desempenho de RDMA otimizado e consistente. Essas VMs dão suporte ao roteamento
adaptável e ao transporte conectado dinâmico (DCT, em outros transportes Standard RC e UD). Esses recursos
aprimoram o desempenho, a escalabilidade e a consistência do aplicativo e o uso deles é altamente
recomendável.
ACU: 199-216
F REQ
UÊN F REQ
C IA UÊN
DE C IA
L A RG TO D DE
URA F REQ OS N ÚC DESE A RM
DE UÊN OS L EO MPE A Z EN DISC
BAN C IA N ÚC ÚN IC NHO AME OS
DA DE L EO S O DE N TO DE VN IC
P RO DE CPU ( GH Z ( GH Z RDM SUP O T EM DA D S
TA M C ESS M EM M EM B A SE , , A RT E POR OS ET H E
ANH VC P A DO Ó RIA Ó RIA ( GH Z P IC O P IC O ( GB / A Á RIO M Á XI RN ET
O U R ( GIB ) GB / S ) ) ) S) MPI ( GIB ) MOS M Á X.
Stan 60 AMD 240 263 2,0 2.55 2.55 100 Todo 700 4 8
dard EPYC s
_HB6 7551
0rs

= 1098,4 GB.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Saiba mais sobre como configurar suas VMs, habilitar a InfiniBand, configurar a MPIe otimizar os aplicativos
Série HBv2
As VMs da série HBv2 são otimizadas para aplicativos orientados por largura de banda de memória, como
dinâmica de fluidos, análise de elemento finito e simulação de reservatório. HBv2 VMs Feature 120 AMD EPYC
7742 núcleos de processador, 4 GB de RAM por núcleo de CPU e nenhum multithread simultâneo. Cada VM
HBv2 fornece até 340 GB/s de largura de banda de memória e até 4 teraFLOPS de computação FP64.
As VMs HBv2-Series apresentam 200 GB/s Mellanox HDR InfiniBand. Essas VMs são conectadas em uma árvore
aprimoram o desempenho, a escalabilidade e a consistência do aplicativo e o uso deles é altamente
recomendável.
F REQ
UÊN F REQ
C IA UÊN
DE C IA
L A RG TO D DE
Stan 120 AMD 480 350 2.45 3.1 3.3 200 Todo 480 8 8
dard EPYC s +
_HB1 7V12 960
20rs_
v2

= 1098,4 GB.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Série HC
As VMs da série HC são otimizadas para aplicativos orientados por computação densa, como análise implícita
de elemento finito, Molecular Dynamics e química computacional. O HC VMs Feature 44 Intel Xeon Platinum
8168 núcleos de processador, 8 GB de RAM por núcleo de CPU e nenhum hyperthreading. A plataforma Intel
Xeon Platinum dá suporte ao ecossistema avançado da Intel de ferramentas de software, como a biblioteca de
kernels matemáticas da Intel e recursos de processamento de vetor avançado, como AVX-512.
As VMs da série HC apresentam 100 GB/s Mellanox EDR InfiniBand. Essas VMs são conectadas em uma árvore
aprimoram o desempenho, a escalabilidade e a consistência do aplicativo e o uso deles é recomendado.
ACU: 297-315
F REQ
UÊN F REQ
C IA UÊN
DE C IA
L A RG TO D DE
Stan 44 Intel 352 191 2.7 3.4 3.7 100 Todo 700 4 8
dard Xeon s
_HC4 Plati
4rs num
8168

= 1098,4 GB.
Outros tamanhos
Propósito geral
Memória otimizada
GPU otimizada
Próximas etapas
Saiba mais sobre como configurar suas VMs, habilitar a InfiniBand, configurar a MPIe otimizar os aplicativos
Para uma exibição arquitetônica de alto nível da execução de cargas de trabalho do HPC, consulte
computação de alto desempenho (HPC) no Azure.
Verifique as cotas do vCPU usando o CLI do Azure
As cotas de vCPU para máquinas virtuais e conjuntos de escala de máquinas virtuais são organizadas em duas
camadas para cada assinatura, em cada região. A primeira camada é a vCPUs Total Regional e a segunda
camada são os vários núcleos da família de tamanho da VM, como as vCPUs da série D. Sempre que uma nova
VM é implantada a vCPUs para a máquina virtual não deve exceder a cota de vCPU para a família de tamanho
VM ou a cota total vCPU regional. Se qualquer uma das cotas é excedida, a implantação de VM não será
permitida. Também há uma cota para o número total de máquinas virtuais na região. Os detalhes sobre cada
uma dessas cotas podem ser vistos no uso + cotas seção o assinatura página o portal do Azure, ou você
pode consultar os valores usando o Azure CLI.
NOTE
A cota é calculada com base no número total de núcleos em alocados e desalocados. Se precisar de núcleos adicionais,
solicite um aumento de cota ou exclua VMs desnecessárias.
Verificar o uso
Você pode verificar o uso de cotas usando az vm list-usage.
az vm list-usage --location "East US" -o table
A saída deve parecer com esta:
Name CurrentValue Limit

-------------------------------- -------------- -------
Availability Sets 0 2000
Total Regional vCPUs 29 100
Virtual Machines 7 10000
Virtual Machine Scale Sets 0 2000
Standard DSv3 Family vCPUs 8 100
Standard DSv2 Family vCPUs 3 100
Standard Dv3 Family vCPUs 2 100
Standard D Family vCPUs 8 100
Standard Dv2 Family vCPUs 8 100
Basic A Family vCPUs 0 100
Standard A0-A7 Family vCPUs 0 100
Standard A8-A11 Family vCPUs 0 100
Standard DS Family vCPUs 0 100
Standard G Family vCPUs 0 100
Standard GS Family vCPUs 0 100
Standard F Family vCPUs 0 100
Standard FS Family vCPUs 0 100
Standard Storage Managed Disks 5 10000
Premium Storage Managed Disks 5 10000
Instâncias de máquina virtual reservada

Instâncias de máquina virtual reservada, que têm o escopo voltado para uma assinatura única sem flexibilidade
para o tamanho da VM, adicionarão um novo aspecto às cotas de vCPU. Esses valores descrevem o número de
instâncias de tamanho indicado que devem ser implantadas na assinatura. Eles funcionam como um espaço
reservado no sistema de cotas para garantir que a cota seja reservada para garantir que as reservas do Azure
sejam implantadas na assinatura. Por exemplo, se uma assinatura específica tiver 10 reservas Standard_D1, o
limite de uso para as reservas Standard_D1 será 10. Isso fará com que o Azure garanta que haja sempre pelo
menos 10 vCPUs disponíveis na cota de vCPUs Regionais Totais para serem usados para instâncias Standard_D1
e pelo menos 10 VCPUs disponíveis na cota de vCPU Família D padrão para serem usados para as instâncias
Standard_D1.
Se um aumento de cota for necessário para adquirir um RI assinatura única, você pode solicitar um aumento de
cota na sua assinatura.
Próximas etapas
Para obter mais informações sobre cobrança e cotas, confira Assinatura do Azure e limite de serviços, cotas e
restrições.
Verifique as cotas do vCPU usando Azure
PowerShell
As cotas de vCPU para máquinas virtuais e conjuntos de escala de máquinas virtuais são organizadas em duas
camadas para cada assinatura, em cada região. A primeira camada é a vCPUs Total Regional e a segunda
camada são os vários núcleos da família de tamanho da VM, como as vCPUs da série D. Sempre que uma nova
VM é implantada a vCPUs para a máquina virtual não deve exceder a cota de vCPU para a família de tamanho
VM ou a cota total vCPU regional. Se qualquer uma das cotas é excedida, a implantação de VM não será
permitida. Também há uma cota para o número total de máquinas virtuais na região. Os detalhes sobre cada
uma dessas cotas podem ser vistos na seção uso + cotas da página de assinatura no portal do Azure, ou você
pode consultar os valores usando o PowerShell.
NOTE
A cota é calculada com base no número total de núcleos em alocados e desalocados. Se precisar de núcleos adicionais,
solicite um aumento de cota ou exclua VMs desnecessárias.
Verificar o uso
Você pode usar o cmdlet Get-AzVMUsage para verificar o seu uso de cotas.
Get-AzVMUsage -Location "East US"
A saída parecerá com o seguinte:

Name Current Value Limit Unit
---- ------------- ----- ----
Availability Sets 0 2000 Count
Total Regional vCPUs 4 260 Count
Virtual Machines 4 10000 Count
Virtual Machine Scale Sets 1 2000 Count
Standard B Family vCPUs 1 10 Count
Standard DSv2 Family vCPUs 1 100 Count
Standard Dv2 Family vCPUs 2 100 Count
Basic A Family vCPUs 0 100 Count
Standard A0-A7 Family vCPUs 0 250 Count
Standard A8-A11 Family vCPUs 0 100 Count
Standard D Family vCPUs 0 100 Count
Standard G Family vCPUs 0 100 Count
Standard DS Family vCPUs 0 100 Count
Standard GS Family vCPUs 0 100 Count
Standard F Family vCPUs 0 100 Count
Standard FS Family vCPUs 0 100 Count
Standard NV Family vCPUs 0 24 Count
Standard NC Family vCPUs 0 48 Count
Standard H Family vCPUs 0 8 Count
Standard Av2 Family vCPUs 0 100 Count
Standard LS Family vCPUs 0 100 Count
Standard Dv2 Promo Family vCPUs 0 100 Count
Standard DSv2 Promo Family vCPUs 0 100 Count
Standard MS Family vCPUs 0 0 Count
Standard Dv3 Family vCPUs 0 100 Count
Standard DSv3 Family vCPUs 0 100 Count
Standard Ev3 Family vCPUs 0 100 Count
Standard ESv3 Family vCPUs 0 100 Count
Standard FSv2 Family vCPUs 0 100 Count
Standard ND Family vCPUs 0 0 Count
Standard NCv2 Family vCPUs 0 0 Count
Standard NCv3 Family vCPUs 0 0 Count
Standard LSv2 Family vCPUs 0 0 Count
Standard Storage Managed Disks 2 10000 Count
Premium Storage Managed Disks 1 10000 Count
Instâncias de máquina virtual reservada

Instâncias de máquina virtual reservada, que têm o escopo voltado para uma assinatura única sem flexibilidade
para o tamanho da VM, adicionarão um novo aspecto às cotas de vCPU. Esses valores descrevem o número de
instâncias de tamanho indicado que devem ser implantadas na assinatura. Eles funcionam como um espaço
reservado no sistema de cotas para garantir que a cota seja reservada para garantir que instâncias de VMs
reservadas sejam implantadas na assinatura. Por exemplo, se uma assinatura específica tiver 10 instâncias de
VM reservadas Standard_D1, o limite de uso para instâncias de VMs reservadas Standard_D1 será 10. Isso fará
com que o Azure garanta que haja sempre pelo menos 10 vCPUs disponíveis na cota de vCPUs Regionais Totais
para serem usados para instâncias Standard_D1 e pelo menos 10 VCPUs disponíveis na cota de vCPU Família D
padrão para serem usados para as instâncias Standard_D1.
Se um aumento de cota for necessário para comprar uma RI de Assinatura Única, você poderá solicitar um
aumento de cota na sua assinatura.
Próximas etapas
Para obter mais informações sobre cobrança e cotas, confira Assinatura do Azure e limite de serviços, cotas e
restrições.
Tamanhos de VM do Azure sem disco temporário
local
Este artigo fornece respostas para perguntas frequentes sobre os tamanhos de VM do Azure que não têm um
disco temporário local (ou seja, nenhum disco Temp local). Para obter mais informações sobre esses tamanhos
de VM, consulte especificações para dv4 e Dsv4 (cargas de trabalho uso geral) ou especificações para as séries
Ev4 e Esv4 (cargas de trabalho com otimização de memória).
O que não significa disco temporário local?

Tradicionalmente, tivemos tamanhos de VM (por exemplo, Standard_D2s_v3, Standard_E48_v3) que incluem um
pequeno disco local (ou seja, uma unidade D:). Agora com esses novos tamanhos de VM, esse pequeno disco
local não existe mais; no entanto, você ainda pode anexar HDD Standard, SSD Premium ou SSD Ultra.
E se eu ainda quiser um disco temporário local?

Se sua carga de trabalho exigir um disco temporário local, também temos novos tamanhos de VM Ddv4 e
Ddsv4 ou Edv4 e Edsv4 disponíveis. Esses tamanhos oferecem 50% de disco temporário maior em comparação
com os tamanhos v3 anteriores.
NOTE
O disco temporário local não é persistente; para garantir que seus dados sejam persistentes, use as opções HDD
Standard, SSD Premium ou SSD Ultra.
Quais são as diferenças entre esses novos tamanhos de VM e o Uso

Geral Dv3/Dsv3 ou os tamanhos de VM Ev3/Esv3 com otimização de
memória com os quais estou acostumado?
FA M ÍL IA S DE VM S V3 C O M DISC O N O VA S FA M ÍL IA S V4 C O M DISC O N O VA S FA M ÍL IA S V4 SEM DISC O
T EM P O RÁ RIO LO C A L T EM P O RÁ RIO LO C A L T EM P O RÁ RIO LO C A L
Dv3 Ddv4 Dv4
Dsv3 Ddsv4 Dsv4
Ev3 Edv4 Ev4
Esv3 Edsv4 Esv4
Posso redimensionar um tamanho de VM que tem um disco

temporário local para um tamanho de VM sem disco temporário
local?
Não. As únicas combinações permitidas para redimensionamento são:
1. VM (com disco temporário local)-> VM (com disco temporário local); e
2. VM (sem disco temporário local)-> VM (sem disco temporário local).
NOTE
Se uma imagem depender do disco de recurso ou se existir um arquivo de paginação ou permuta no disco temporário
local, as imagens sem disco não funcionarão — em vez disso, use a alternativa ' com disco '.
Esses tamanhos de VM dão suporte a sistemas operacionais Linux e

Windows (SO)?
Sim.
Isso interromperá meus scripts personalizados, imagens

personalizadas ou imagens do sistema operacional que têm arquivos
ou arquivos de paginação em um disco temporário local?
Se a imagem personalizada do sistema operacional apontar para o disco temporário local, a imagem poderá
não funcionar corretamente com esse tamanho sem disco.
Dúvidas ou comentários?
Preencha o formulário de comentários.
Próximas etapas
Neste documento, você aprendeu mais sobre as perguntas mais frequentes relacionadas às VMs do Azure sem
disco temporário local. Para obter mais informações sobre esses tamanhos de VM, consulte os seguintes
artigos:
Especificações para dv4 e Dsv4 (carga de trabalho de Uso Geral)
Especificações para Ev4 e Esv4 (carga de trabalho com otimização de memória)
Convenções de nomenclatura de tamanhos de
máquina virtual do Azure
Esta página descreve as convenções de nomenclatura usadas para VMs do Azure. As VMs usam essas
convenções de nomenclatura para indicar diferentes recursos e especificações.
Explicação da Convenção de nomenclatura

[Família] + *[Sub-família ] + [n º de vCPUs] + [Recursos aditivos] + *[Tipo de acelerador ] + [Versão]
VA LO R EXP L IC A Ç Ã O
Family Indica a série da família de VMs
* Sub-família Usado somente para diferenciações de VM especializadas
n º de vCPUs Denota o número de vCPUs da VM
Recursos aditivos Uma ou mais letras minúsculas denotam recursos aditivos,

como:
a = processador baseado em AMD
d = disco (o disco temporário local está presente); Isso é
para VMs do Azure mais novas, consulte Ddv4 e Ddsv4-
Series
h = capacidade de hibernação
i = tamanho isolado
l = memória insuficiente; uma quantidade menor de
memória do que o tamanho intensivo de memória
m = uso intensivo de memória; a maior quantidade de
memória em um determinado tamanho
t = memória mínima; a menor quantidade de memória em
um determinado tamanho
r = compatível com RDMA
s = capacidade de armazenamento Premium, incluindo o uso
possível de SSD ultra (Observação: alguns tamanhos mais
recentes Sem o atributo de s ainda podem dar suporte ao
armazenamento Premium, por exemplo, m128, m64, etc.)
* Tipo de acelerador Denota o tipo de acelerador de hardware nas SKUs

especializadas/GPU. Somente os novos SKUs
especializados/GPU iniciados do T3 2020 terão o acelerador
de hardware no nome.
Versão Denota a versão da série da família de VMs
Análise de exemplo
[Família] + *[Sub-família ] + [n º de vCPUs] + [Recursos aditivos] + *[Tipo de acelerador ] + [Versão]
Exemplo 1: M416ms_v2
Family M
n º de vCPUs 416
Recursos aditivos m = uso intensivo de memória

s = capacidade de armazenamento Premium
Versão v2
Exemplo 2: NV16as_v4
Family N
Sub-família V
n º de vCPUs 16
Recursos aditivos a = processador baseado em AMD

Versão v4
Exemplo 3: NC4as_T4_v3
Family N
Sub-família C
n º de vCPUs 4
Recursos aditivos a = processador baseado em AMD

Tipo de acelerador T4
Versão v3
Próximas etapas
Saiba mais sobre os tamanhos de VM disponíveis no Azure.
Gerações anteriores de tamanhos de máquinas
virtuais
Esta seção fornece informações sobre gerações anteriores de tamanhos de máquinas virtuais. Esses tamanhos
ainda podem ser usados, mas as gerações mais recentes estão disponíveis.
Série F
A série F é baseada no processador 2.4 GHz Intel Xeon® E5-2673 v3 (Haswell), que pode obter velocidades de
relógio tão altas quanto 3.1 GHz com o Intel Turbo Boost Technology 2.0. Esse é o mesmo desempenho de CPU
que o das VMs da série Dv2.
As VMs da série F são uma ótima opção para as cargas de trabalho que exigem CPUs mais rápidas, mas não
precisam de tanta memória ou armazenamento temporário por vCPU. Cargas de trabalho como análise,
servidores de jogos, servidores Web e de processamento em lote serão beneficiados com o valor da série F.
ACU: 210 - 250
Armazenamento Premium: Sem suporte
Cache de Armazenamento Premium: Sem suporte
TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
T EM P O RÁ RIO M Á XIM O DE M Á XIM O DE
: IO P S/ M B P S DISC O S DE N IC S/ L A RGUR
A RM A Z EN A M DE DA DO S/ TA XA A DE B A N DA
EN TO L EIT URA / M B P DE DE REDE
M EM Ó RIA : T EM P O RÁ RIO S DE T RA N SF ERÊN ESP ERA DA
TA M A N H O VC P U GIB ( SSD) GIB GRAVA Ç Ã O C IA : IO P S ( M B P S)
Standard_F1 1 2 16 3000/46/23 4/4x500 2/750
Standard_F2 2 4 32 6000/93/46 8/8x500 2/1500
Standard_F4 4 8 64 12000/187/9 16/16x500 4/3000

3
Standard_F8 8 16 128 24000/375/1 32/32x500 8/6000

87
Standard_F16 16 32 256 48000/750/3 64/64x500 8/12000

75
FS-series 1
A série Fs fornece todas as vantagens da série F, além do armazenamento Premium.
ACU: 210 - 250
Armazenamento Premium: Com suporte
Cache de Armazenamento Premium: Com suporte
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
M EN TO EM M Á XIM O
CACHE E DE
T EM P O RÁ R TA XA DE N IC S/ L A RG
A RM A Z EN A IA : T RA N SF ERÊ URA DE
M EN TO IO P S/ M B P S N C IA DE B A N DA DE
T EM P O RÁ R DISC O S DE ( TA M A N H O DISC O SEM REDE
M EM Ó RIA : IO ( SSD) DA DO S DO C A C H E C A C H E: ESP ERA DA
TA M A N H O VC P U GIB GIB M Á XIM O S EM GIB ) IO P S/ M B P S ( M B P S)
Standard_F 1 2 4 4 4000/32 3200/48 2/750

1s (12)
Standard_F 2 4 8 8 8000/64 6400/96 2/1500

2s (24)
Standard_F 4 8 16 16 16000/128 12800/192 4/3000

4s (48)
Standard_F 8 16 32 32 32000/256 25600/384 8/6000

8s (96)
Standard_F 16 32 64 64 64000/512 51200/768 8/12000

16s (192)
MBps = 10^6 bytes por segundo e GiB = 1024^3 bytes.

1 a taxa de transferência máxima possível do disco (IOPS
ou Mbps) com uma VM da série FS pode ser limitada
pelo número, tamanho e distribuição dos discos anexados. Para obter detalhes, consulte design para alto
desempenho.
Série NVv2
Recomendação de tamanho mais recente : série NVv3
As máquinas virtuais da série NVv2 contam com as GPUs Tesla M60 NVIDIA e a tecnologia NVIDIA GRID com
CPUs Intel Broadwell. Essas máquinas virtuais são direcionadas para aplicativos com gráficos acelerados por
GPU e áreas de trabalho virtuais em que os clientes querem visualizar dados, simular resultados para exibição,
trabalhar no CAD ou renderizar e transmitir conteúdo por streaming. Além disso, essas máquinas virtuais
podem executar cargas de trabalho de precisão simples, como codificação e renderização. As máquinas virtuais
NVv2 são compatíveis com o Armazenamento Premium e oferecem duas vezes mais memória (RAM) em
comparação com a Série NV anterior.
Cada GPU em instâncias da NVv2 vem com uma licença GRID. Esta licença oferece flexibilidade para usar uma
A RM A Z
EN A M E ESTA Ç Õ
N TO DISC O S ES DE
Standar 6 112 320 1 8 12 4 1 25

d_NV6s
_v2
Standar 12 224 640 2 16 24 8 2 50

d_NV12
s_v2
Standar 24 448 1280 4 32 32 8 4 100

d_NV24
s_v2
Gerações mais antigas de tamanhos de máquina virtual

Esta seção fornece informações sobre gerações mais antigas de tamanhos de máquina virtual. Esses tamanhos
ainda têm suporte, mas não receberão capacidade adicional. Há tamanhos mais novos ou alternativos que estão
geralmente disponíveis. Consulte tamanhos de máquinas virtuais no Azure para escolher os tamanhos de VM
que melhor se ajustarão às suas necessidades.
Para obter mais informações sobre o redimensionamento de uma VM do Linux, consulte redimensionar uma
VM do Linux.
A Básico
Recomendação de tamanho mais recente : série Av2
Os tamanhos da camada básicos são principalmente para as cargas de trabalho de desenvolvimento e outros
aplicativos que não requerem o balanceamento de carga, dimensionamento automático ou máquinas virtuais
que consomem muita memória.
TA M A N H O M Á X. DE
TA M A N H O – M Á XIM O DO DISC O S DE M Á X. IO P S
TA M A N H O \ N DISC O DA DO S ( 1023 ( 300 P O R
OME VC P U M EM Ó RIA N IC S ( M Á X. ) T EM P O RÁ RIO GB C A DA ) DISC O )
A0\Basic_A0 1 768 MB 2 20 GB 1 1 x 300
A1\Basic_A1 1 1,75 GB 2 40 GB 2 2 x 300
A2\Basic_A2 2 3,5 GB 2 60 GB 4 4 x 300
A3\Basic_A3 4 7 GB 2 120 GB 8 8 x 300
A4\Basic_A4 8 14 GB 2 240 GB 16 16 x 300

Standard A0 - A4 usando CLI e PowerShell
No modelo de implantação clássica, alguns nomes de tamanhos de VM são ligeiramente diferentes na CLI e no
PowerShell:
Standard_A0 é ExtraSmall
Standard_A1 é pequeno
Standard_A2 é médio
Standard_A3 é grande
Standard_A4 é ExtraLarge
Séria A
ACU: 50-100
M Á XIM O DE
TA XA DE N IC S/ L A RGUR
A RM A Z EN A M T RA N SF ERÊN A DE B A N DA
EN TO DISC O S DE C IA M Á XIM A DE REDE
M EM Ó RIA : T EM P O RÁ RIO DA DO S DO DISC O DE ESP ERA DA
TA M A N H O VC P U GIB ( H DD) : GIB M Á XIM O S DA DO S: IO P S ( M B P S)
Standard_A0 1 0,768 20 1 1 x 500 2/100

1
Standard_A1 1 1,75 70 2 2x500 2/500
Standard_A2 2 3,5 135 4 4x500 2/500
Standard_A3 4 7 285 8 8 x 500 2/1000
Standard_A4 8 14 605 16 16 x 500 4/2000
Standard_A5 2 14 135 4 4x500 2/500
Standard_A6 4 28 285 8 8 x 500 2/1000
Standard_A7 8 56 605 16 16 x 500 4/2000
1 O tamanho A0 está assinado em excesso no hardware físico. Para este tamanho específico somente, outras
implantações de clientes podem afetar o desempenho da carga de trabalho em execução. O desempenho
relativo é descrito a seguir como a linha de base esperada, sujeito a uma variação aproximada de 15%.
Série A – Instâncias de computação intensiva

ACU: 225
Os tamanhos A8-A11 e série H também são conhecidos como instâncias de computação intensiva. O hardware
de datacenter do Azure que executa esses tamanhos é projetado e otimizado para aplicativos de uso intensivo
de computação e rede, incluindo aplicativos, modelagem e simulações de cluster HPC (computação de alto
desempenho). A série de A8-A11 usa Intel Xeon E5-2670 a 2,6 GHz e a série H usa Intel Xeon E5-2667 v3 a 3,2
GHz.
TA XA DE
A RM A Z EN A M T RA N SF ERÊN
EN TO DISC O S DE C IA M Á XIM A
M EM Ó RIA : T EM P O RÁ RIO DA DO S DO DISC O DE M Á XIM O DE
TA M A N H O VC P U GIB ( H DD) : GIB M Á XIM O S DA DO S: IO P S N IC S
Standard_A8 8 56 382 32 32 x 500 2

1
Standard_A9 16 112 382 64 64x500 4

1
Standard_A10 8 56 382 32 32 x 500 2
Standard_A11 16 112 382 64 64x500 4
1Para os aplicativos MPI, a rede de back-end RDMA dedicada é habilitada pela rede InfiniBand FDR, que fornece
latência ultrabaixa e largura de banda alta.
NOTE
As VMs A8 – a11 estão planejadas para aposentadoria em 3/2021. É altamente recomendável não criar novas VMs A8 –
a11. Migre quaisquer VMs A8-a11 existentes para tamanhos de VM de computação de alto desempenho mais novos e
eficientes, como H, HB, HC, HBv2, bem como tamanhos de VM de computação de uso geral, como D, E e F para melhor
desempenho-preço. Para obter mais informações, confira o Guia de migração de HPC.
Série D
Recomendação de tamanho mais recente : série Dav4, série dv4 e série Ddv4
ACU: 160-250 1
TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
Standard_D1 1 3,5 50 3000/46/23 4/4x500 2/500
Standard_D2 2 7 100 6000/93/46 8/8x500 2/1000

TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
Standard_D3 4 14 200 12000/187/9 16/16x500 4/2000

3
Standard_D4 8 28 400 24000/375/1 32/32x500 8/4000

87
1 a família de VMs pode ser

executada em uma das seguintes cpus: 2,2 GHz intel xeon® E5-2660 v2, 2,4 GHz
intel xeon® E5-2673 v3 (Haswell) ou 2,3 GHz intel xeon® E5-2673 V4 (Broadwell)
Série D - otimizado para memória

Recomendação de tamanho mais recente : série Dav4, série dv4 e série Ddv4
ACU: 160-250 1
TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
Standard_D11 2 14 100 6000/93/46 8/8x500 2/1000
Standard_D12 4 28 200 12000/187/9 16/16x500 4/2000

3
Standard_D13 8 56 400 24000/375/1 32/32x500 8/4000

87
Standard_D14 16 112 800 48000/750/3 64/64x500 8/8000

75

Visualização: série CC
Recomendação de tamanho mais recente : série DCsv2
A série DC usa a última geração de processador E-2176G Intel XEON de 3.7 GHz com tecnologia de SGX e, com
a tecnologia Intel Turbo Boost, pode chegar a até 4,7 GHz.
TA XA DE
T RA N SF ERÊ
N C IA TA XA DE
M Á XIM A T RA N SF ERÊ
DE N C IA
A RM A Z EN A M Á XIM A M Á XIM O
M EN TO DO DISC O DE
T EM P O RÁ R NÃO N IC S/ L A RG
A RM A Z EN A IO : IO P S / A RM A Z EN A URA DE
M EN TO MBPS DO EM B A N DA DE
T EM P O RÁ R DISC O S DE ( TA M A N H O C A C H E: REDE
M EM Ó RIA : IO ( SSD) DA DO S DO C A C H E IO P S / ESP ERA DO
TA M A N H O VC P U GIB GIB M Á XIM O S EM GIB ) MBPS ( M B P S)
Standard_D 2 8 100 2 4000 / 32 3200 /48 2 / 1500

C2s (43)
Standard_D 4 16 200 4 8000 / 64 6400 /96 2 / 3000

C4s (86)
IMPORTANT
As VMs da série DC são VMs de geração 2 e só oferecem suporte a Gen2 imagens.
Série DS
Recomendação de tamanho mais recente : série Dasv4, série Dsv4 e série Ddsv4
ACU: 160-250 1
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
CACHE E DE
Standard_D 1 3,5 7 4 4000/32 3200/32 2/500

S1 (43)
Standard_D 2 7 14 8 8000/64 6400/64 2/1000

S2 (86)
Standard_D 4 14 28 16 16000/128 12800/128 4/2000

S3 (172)
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
CACHE E DE
Standard_D 8 28 56 32 32000/256 25600/256 8/4000

S4 (344)

Série DS - otimizado para memória

Recomendação de tamanho mais recente : série Dasv4, série Dsv4 e série Ddsv4
ACU: 160-250 1, 2
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A
CACHE E DE
Standard_D 2 14 28 8 8000/64 6400/64 2/1000

S11 (72)
Standard_D 4 28 56 16 16000/128 12800/128 4/2000

S12 (144)
Standard_D 8 56 112 32 32000/256 25600/256 8/4000

S13 (288)
Standard_D 16 112 224 64 64000/512 51200/512 8/8000

S14 (576)
1 A taxa de transferência máxima possível do disco (IOPS

ou MBps) com uma VM da série DS pode ser limitada
desempenho. 2 a família de VMs pode ser executada em uma das seguintes cpus: 2,2 GHz intel xeon® E5-2660
v2, 2,4 GHz intel xeon® E5-2673 v3 (Haswell) ou 2,3 GHz intel xeon® E5-2673 V4 (Broadwell)
Série Ls
Recomendação de tamanho mais recente : série Lsv2
A série Ls oferece até 32 vCPUs, usando a família de processadores Intel® Xeon® E5 v3. A série Ls obtém o
mesmo desempenho de CPU da série G/GS e vem com 8 GiB de memória por vCPU.
A série Ls não é compatível com a criação de um cache local para aumentar o IOPS que pode ser obtido por
discos de dados duráveis. A alta taxa de transferência e o IOPS do disco local tornam as VMs da série ls ideais
para repositórios NoSQL, como o Apache Cassandra e o MongoDB, que replicam dados em várias VMs para
alcançar a persistência no caso de falha de uma única VM.
ACU: 180-240
TA XA DE TA XA DE
T RA N SF ERÊ T RA N SF ERÊ
N C IA N C IA
M Á XIM A M Á XIM A M Á XIM O
DO DO DISC O DE
A RM A Z EN A NÃO N IC S/ L A RG
M EN TO A RM A Z EN A URA DE
A RM A Z EN A T EM P O RÁ R DO EM B A N DA DE
M EN TO DISC O S DE IO CACHE REDE
M EM Ó RIA T EM P O RÁ R DA DO S ( IO P S/ M B P ( IO P S/ M B P ESP ERA DA
TA M A N H O VC P U ( GIB ) IO ( GIB ) M Á XIM O S S) S) ( M B P S)
Standard_L 4 32 678 16 20000/200 5000/125 2/4000

4s
Standard_L 8 64 1388 32 40000/400 10000/250 4/8000

8s
Standard_L 16 128 2807 64 80000/800 20000/500 8/16000

16s
Standard_L 32 256 5630 64 160000/16 40000/100 8/20000

32s 1 00 0
A taxa de transferência máxima possível do disco com VMs da série Ls pode ser limitada pelo número, tamanho
e divisão dos discos anexados. Para obter detalhes, consulte design para alto desempenho.
Série GS
Recomendação de tamanho mais recente : série Easv4, série Esv4, Edsv4 e série M
ACU: 180 - 240 1
TA XA DE
T RA N SF ERÊ
N C IA
M Á XIM A
DE
A RM A Z EN A M Á XIM O
M EN TO DE
A RM A Z EN A IO : IO P S / T RA N SF ERÊ URA DE
M EN TO MBPS N C IA DE B A N DA DE
Standard_G 2 28 56 8 10000/100 5000/ 125 2/2000

S1 (264)
Standard_G 4 56 112 16 20000/200 10000/ 2/4000

S2 (528) 250
Standard_G 8 112 224 32 40000/400 20000/ 4/8000

S3 (1056) 500
Standard_G 16 224 448 64 80000/800 40000/100 8/16000

S4 3 (2112) 0
Standard_G 32 448 896 64 160000/16 80000/200 8/20000

S5 2, 3 00 (4224) 0
1 A taxa de transferência máxima possível do disco (IOPS

ou MBps) com uma VM da série GS pode ser limitada
desempenho.
3 Tamanhos limitados de núcleos disponíveis.
Série G
Recomendação de tamanho mais recente : Eav4, série Ev4 e série Edv4 e série M
ACU: 180 - 240
TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
Standard_G1 2 28 384 6000/93/46 8/8x500 2/2000

TA XA DE
T RA N SF ERÊN
C IA M Á XIM A
DE
A RM A Z EN A M
EN TO
Standard_G2 4 56 768 12000/187/9 16/16x500 2/4000

3
Standard_G3 8 112 1536 24000/375/1 32/32x500 4/8000

87
Standard_G4 16 224 3072 48000/750/3 64/64x500 8/16000

75
Standard_G5 32 448 6144 96000/1500/ 64/64x500 8/20000

1 750

Série NV
Recomendação de tamanho mais recente : série NVv3 e série NVv4
As máquinas virtuais da série NV têm a tecnologia das GPUs Tesla M60 da NVIDIA e NVIDIA GRID para
aplicativos acelerados de área de trabalho e áreas de trabalho virtuais, em que os clientes podem visualizar seus
dados ou simulações. Os usuários podem visualizar seus fluxos de trabalho com uso intensivo de gráficos em
instâncias NV para obter capacidade gráfica superior, além de executar cargas de trabalho de precisão única,
como codificação e renderização. As VMs da série NV também são alimentadas por CPUs do Intel Xeon E5-2690
v3 (Haswell).
Cada GPU em instâncias NV vem com uma licença GRID. Esta licença oferece flexibilidade para usar uma
Migração ao Vivo: Sem suporte
Atualizações de preservação de memória: Sem suporte
A RM A Z
EN A M E ESTA Ç Õ
N TO DISC O S ES DE
Standar 6 56 340 1 8 24 1 1 25
d_NV6
Standar 12 112 680 2 16 48 2 2 50

d_NV12
A RM A Z
EN A M E ESTA Ç Õ
N TO DISC O S ES DE
Standar 24 224 1440 4 32 64 4 4 100

d_NV24
1 GPU = metade de um cartão M60.

Série NC
Recomendação de tamanho mais recente : NC T4 v3-Series
As VMs da série NC são alimentadas pela placa NVIDIA Tesla K80 e pelo processador Intel Xeon E5-2690 v3
(Haswell). Os usuários podem processar os dados mais rapidamente aproveitando o CUDA para aplicativos de
exploração de energia, simulações de falhas, renderização de traçados de raio, aprendizado profundo e muito
mais. A configuração NC24r fornece um adaptador de rede de alta taxa de transferência e baixa latência,
A RM A Z EN A
M EN TO
T EM P O RÁ R M EM Ó RIA DISC O S DE
M EM Ó RIA : IO ( SSD) DA GP U: DA DO S M Á XIM O
TA M A N H O VC P U GIB GIB GP U GIB M Á XIM O S DE N IC S
Standard_N 6 56 340 1 12 24 1
C6
Standard_N 12 112 680 2 24 48 2

C12
Standard_N 24 224 1440 4 48 64 4

C24
Standard_N 24 224 1440 4 48 64 4

C24r*
1 GPU = metade de um cartão K80.

Série NCv2
Recomendação de tamanho mais recente : NC T4 v3-Series e NC V100 v3-Series
VMs da série NCv2 têm a tecnologia de GPUs NVIDIA Tesla P100. Essas GPUs podem fornecer desempenho
computacional 2 vezes maior que da série NC. Os clientes podem aproveitar essas GPUs atualizadas para cargas
simulações de Monte Carlo, entre outros. Além das GPUs, as VMs da série NCv2 também são alimentadas por
CPUs Intel Xeon E5-2690 V4 (Broadwell).
A configuração NC24rs v2 fornece um adaptador de rede de alta taxa de transferência e baixa latência,
Para essa série de VMs, a cota de vCPU (núcleo) em sua assinatura é inicialmente definida como 0 em cada
região. Solicite um aumento de cota de vCPU para esta série em uma região disponível.
TA XA DE
T RA N SF E
O DE SEM
Standard_ 6 112 736 1 16 12 20000/20 4

NC6s_v2 0
Standard_ 12 224 1474 2 32 24 40000/40 8

NC12s_v 0
2
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24s_v 0
2
Standard_ 24 448 2948 4 64 32 80000/80 8

NC24rs_v 0
2*
1 GPU = um cartão P100.

Série ND
Recomendação de tamanho mais recente : NDv2-Series e NC V100 v3-Series
As máquinas virtuais da série ND são uma nova adição à família de GPU projetada para cargas de trabalho AI e
Deep Learning. Elas oferecem um desempenho excelente para treinamento e Inferência. As instâncias do ND são
alimentadas por NVIDIA Tesla P40 GPUs e CPUs Intel Xeon E5-2690 V4 (Broadwell). Essas instâncias oferecem
um desempenho excelente para operações de ponto flutuante de precisão simples, para cargas de trabalho de
AI que utilizam o Cognitive Toolkit, o TensorFlow, o Caffe e outras estruturas. A série ND também oferece um
tamanho de memória de GPU muito maior (24 GB), permitindo usar modelos de rede neural muito maiores.
Como a série NC, a série ND oferece uma configuração com uma baixa latência secundária, uma rede com alta
taxa de transferência por meio de RDMA e a conectividade InfiniBand, permitindo executar trabalhos de grande
escala que abrangem várias GPUs.
Para essa série de VMs, a cota de vCPU (núcleo) por região em sua assinatura é definida inicialmente como
0. Solicite um aumento de cota de vCPU para esta série em uma região disponível.
TA XA DE
T RA N SF E
O DE SEM
Standard_ 6 112 736 1 24 12 20000/20 4

ND6s 0
Standard_ 12 224 1474 2 48 24 40000/40 8

ND12s 0
Standard_ 24 448 2948 4 24 32 80000/80 8

ND24s 0
Standard_ 24 448 2948 4 96 32 80000/80 8

ND24rs* 0
1 GPU = um cartão de P40.

Próximas etapas
Isolamento de máquina virtual no Azure
A Computação do Azure oferece tamanhos de máquina virtual Isolada, para um tipo de hardware específico e
dedicada a um único cliente. Os tamanhos isolados residem e operam em uma geração de hardware específica
e serão preteridos quando a geração de hardware for desativada.
Os tamanhos de máquinas virtuais isoladas são mais adequados para cargas de trabalho que exigem um alto
grau de isolamento de cargas de trabalho de outros clientes por motivos que incluem requisitos de
conformidade e regulamentação de atendimento. Utilizar um tamanho isolado garante que sua máquina virtual
será apenas sendo executada na instância de servidor específico.
Além disso, como as VMs de tamanho isolado são grandes, os clientes podem optar por subdividir os recursos
dessas VMs usando o suporte do Azure para máquinas virtuais aninhadas.
As ofertas atuais da máquina virtual isolada incluem:
Standard_E80ids_v4
Standard_E80is_v4
Standard_F72s_v2
Standard_E64is_v3
Standard_E64i_v3
Standard_M128ms
Standard_GS5
Standard_G5
NOTE
Os tamanhos de VM isolados têm um ciclo de vida limitado por hardware. Consulte abaixo para obter detalhes
Substituição de tamanhos de VM isoladas

Os tamanhos de VM isolados têm um ciclo de vida limitado por hardware. O Azure emitirá lembretes 12 meses
antes da data oficial de substituição dos tamanhos e fornecerá uma oferta de isolamento atualizada para sua
consideração.
TA M A N H O DATA DE RET IRA DA DO ISO L A M EN TO
Standard_DS15_v21 15 de maio de 2020
Standard_D15_v21 15 de maio de 2020
1 para obterdetalhes sobre o Standard_DS15_v2 e Standard_D15_v2 programa de desativação de isolamento,

consulte FAQs
P: o tamanho será desativado ou apenas seu recurso de "isolamento"?
R : se o tamanho da máquina virtual não tiver o subscript "i", somente o recurso "isolamento" será desativado.
Se o isolamento não for necessário, não haverá nenhuma ação a ser tomada e a VM continuará funcionando
conforme o esperado. Os exemplos incluem Standard_DS15_v2, Standard_D15_v2, Standard_M128ms etc. Se o
tamanho da máquina virtual incluir o subscript "i", o tamanho será desativado.
P: há um tempo de inatividade quando minha VM chega em um hardware não isolado?
R : se não houver necessidade de isolamento, nenhuma ação será necessária e não haverá nenhum tempo de
inatividade.
P: há algum Delta de custo para mover para uma máquina virtual não isolada?
R : não
P: quando os outros tamanhos isolados serão desativados?
R : forneceremos lembretes 12 meses antes da reprovação oficial do tamanho isolado.
P: sou um cliente do Azure Service Fabric contando com as camadas de durabilidade prata ou ouro. Essa
alteração me afeta?
R : não. As garantias fornecidas pelas camadas de durabilidade de Service Fabric continuarão a funcionar mesmo
após essa alteração. Se você precisar de isolamento de hardware físico por outros motivos, talvez ainda precise
executar uma das ações descritas acima.
P: quais são as etapas para D15_v2 ou desativação de isolamento de DS15_v2?
A:
DATA AÇÃO
18 de novembro de 2019 Disponibilidade de D/DS15i_v2 (PAYG, RI de 1 ano)
14 de maio de 2020 Último dia para comprar D/DS15i_v2 RI de 1 ano
15 de maio de 2020 Garantia de isolamento D/DS15_v2 removida
15 de maio de 2021 Desativar D/DS15i_v2 (todos os clientes exceto quem

comprou a RI de 3 anos de D/DS15_v2 antes de 18 de
novembro de 2019)
17 de novembro de 2022 Desativar D/DS15i_v2 quando o RIs de 3 anos for concluído

(para clientes que compraram uma RI de 3 anos de
D/DS15_v2 antes de 18 de novembro de 2019)
Próximas etapas
Os clientes também podem optar por subdividir ainda mais os recursos dessas máquinas virtuais Isoladas
usando o Suporte do Azure para máquinas virtuais aninhadas.
ACU (unidade de computação do Azure)
O conceito da ACU (Unidade de Computação do Azure) fornece uma maneira de comparar o desempenho de
computação (CPU) em SKUs do Azure. Isso ajudará você a identificar facilmente qual SKU é tem maior
probabilidade de satisfazer suas necessidades de desempenho. O ACU está atualmente padronizado em uma
VM pequena (Standard_A1) sendo 100 e todos os outros SKUs representam aproximadamente quanto tempo a
SKU pode executar um benchmark padrão
* ACUs usam a tecnologia Intel® Turbo para aumentar a frequência da CPU e fornecer um aumento de
desempenho. A quantidade do aumento de desempenho pode variar com base no tamanho da VM, na carga de
trabalho e em outras cargas de trabalho em execução no mesmo host.
** ACUs usam tecnologia AMD® Boost para aumentar a frequência da CPU e fornecer um aumento de
desempenho. A quantidade do aumento de desempenho pode variar com base no tamanho da VM, na carga de
trabalho e em outras cargas de trabalho em execução no mesmo host.
**Com Hyper-threading e capacidade de executar virtualização aninhada
IMPORTANT
A ACU é apenas uma diretriz. Os resultados para sua carga de trabalho podem variar.
FA M ÍL IA DE SK U A C U \ VC P U VC P U: C O RE
A0 50 1:1
A1 - A4 100 1:1
A5 - A7 100 1:1
A1_v2 - A8_v2 100 1:1
A2m_v2 - A8m_v2 100 1:1
A8 - A11 225* 1:1
B Varia Varia
D1 - D14 160-250 1:1
D1_v2 - D15_v2 210 - 250* 1:1
DS1 - DS14 160-250 1:1
DS1_v2 - DS15_v2 210 - 250* 1:1
D_v3 160 - 190* 2:1***
Ds_v3 160 - 190* 2:1***
Dav4 230-260 * * 2:1
Dasv4 230-260 * * 2:1
Dv4 195 - 210 2:1***
Dsv4 195 - 210 2:1***
Ddv4 195-210 * 2:1***

FA M ÍL IA DE SK U A C U \ VC P U VC P U: C O RE
Ddsv4 195-210 * 2:1***
E_v3 160 - 190* 2:1***
Es_v3 160 - 190* 2:1***
Eav4 230-260 * * 2:1
Easv4 230-260 * * 2:1
Ev4 195 - 210 2:1***
Esv4 195 - 210 2:1***
Edv4 195-210 * 2:1***
Edsv4 195-210 * 2:1***
F2s_v2 - F72s_v2 195-210 * 2:1***
F1 - F16 210 - 250* 1:1
F1s - F16s 210 - 250* 1:1
G1 - G5 180 - 240* 1:1
GS1 - GS5 180 - 240* 1:1
H 290 – 300* 1:1
HB 199-216 * * 1:1
HC 297-315 * 1:1
L4s - L32s 180 - 240* 1:1
L8s_v2 - L80s_v2 150 - 175** 2:1
M 160-180 2:1***
NVv4 230-260 * * 2:1
Nos links abaixo, você obtém mais informações sobre os diferentes tamanhos:
Uso geral
Memória otimizada
GPU otimizada
Pontuações de parâmetro de comparação de
computação de VMs do Linux
As pontuações de parâmetro de comparação CoreMark a seguir mostram o desempenho de computação de

uma lista organizada de VMs de alto desempenho do Azure que executam o Ubuntu. As pontuações de
parâmetro de comparação de computação também estão disponíveis para VMs do Windows.
Standard_Das_v4
(12/11/2019 2:28:52 AM PBI 5851281)
% DE
DESEN VO
P O N T UA LVIM EN T
TA M A N H NÓS M EM Ó RI ÇÃO DESVIO O #EXEC UÇ
O DA VM CPU VC P US N UM A A ( GIB ) M ÉDIA PA DRÃ O PA DRÃ O Õ ES
Standard_ Processad 2 1 7.8 29.726 693 2,33% 42

D2as_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 4 1 15.7 59.224 1.595 2,69% 42

D4as_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 8 1 31,4 116.412 3.613 3,10% 42

D8as_v4 or AMD
EPYC
7452 32-
Core

D16as_v4 or AMD
EPYC
7452 32-
Core

D32as_v4 or AMD
EPYC
7452 32-
Core
Standard_Da_v4
(12/12/2019 12:01:48 AM PBI 5851281)
% DE
DESEN VO

D2a_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 4 1 15.7 59.685 1.141 1,91% 77

D4a_v4 or AMD
EPYC
7452 32-
Core

D8a_v4 or AMD
EPYC
7452 32-
Core

D16a_v4 or AMD
EPYC
7452 32-
Core

D32a_v4 or AMD
EPYC
7452 32-
Core

D48a_v4 or AMD
EPYC
7452 32-
Core

D64a_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 96 12 377,9 1.290.45 13.640 1, 6% 35

D96a_v4 or AMD 5
EPYC
7452 32-
Core
Standard_Eas_v4
(12/11/2019 2:28:50 AM PBI 5851281)
% DE
DESEN VO

E2as_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 4 1 31,4 58.356 480 0,82% 42

E4as_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 8 1 62,9 115.943 3.526 3, 4% 35

E8as_v4 or AMD
EPYC
7452 32-
Core

E16as_v4 or AMD
EPYC
7452 32-
Core

E32as_v4 or AMD
EPYC
7452 32-
Core

E48as_v4 or AMD
EPYC
7452 32-
Core

E64as_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 96 12 661,4 1.299.23 14.997 1,15% 70

E96as_v4 or AMD 3
EPYC
7452 32-
Core
Standard_Ea_v4
(12/11/2019 2:29:06 AM PBI 5851281)
% DE
DESEN VO

E2a_v4 or AMD
EPYC
7452 32-
Core

E4a_v4 or AMD
EPYC
7452 32-
Core

E8a_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 16 2 125,9 226.947 4.661 2, 5% 35

E16a_v4 or AMD
EPYC
7452 32-
Core

E32a_v4 or AMD
EPYC
7452 32-
Core

E48a_v4 or AMD
EPYC
7452 32-
Core

E64a_v4 or AMD
EPYC
7452 32-
Core
Standard_ Processad 96 12 661,4 1.298.07 15.948 1,23% 35

E96a_v4 or AMD 4
EPYC
7452 32-
Core
Av2 - Computação Geral

(3/15/2019 12:06:55 AM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 1 1 1,9 6.483 120 1,85% 273

A1_v2 Xeon(R)
CPU E5-
2660 0 @
2,20 GHz
Standard_ Intel(R) 1 1 1,9 6.059 208 3,43% 217

A1_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 1,9 6.367 453 7,12% 217

A1_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 3.9 13.161 194 1,48% 266

A2_v2 Xeon(R)
CPU E5-
2660 0 @
2,20 GHz
Standard_ Intel(R) 2 1 3.9 12.067 401 3,32% 203

A2_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 3.9 12.527 797 6,37% 238

A2_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 15.7 13.167 179 1,36% 273

A2m_v2 Xeon(R)
CPU E5-
2660 0 @
2,20 GHz
Standard_ Intel(R) 2 1 15.7 12.133 336 2,77% 210

A2m_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
% DE
DESEN VO
Standard_ Intel(R) 2 1 15.7 12.401 656 5,29% 224

A2m_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 7.8 26.307 231 0,88% 231

A4_v2 Xeon(R)
CPU E5-
2660 0 @
2,20 GHz
Standard_ Intel(R) 4 1 7.8 24.552 720 2,93% 224

A4_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 7.8 24.963 1.625 6,51% 252

A4_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 31,4 26.238 292 1,11% 259

A4m_v2 Xeon(R)
CPU E5-
2660 0 @
2,20 GHz
Standard_ Intel(R) 4 1 31,4 24.250 491 2,02% 189

A4m_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 31,4 24.725 1.553 6,28% 259

A4m_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 15.7 53.237 687 1,29% 266

A8_v2 Xeon(R)
CPU E5-
2660 0 @
2,20 GHz
% DE
DESEN VO
Standard_ Intel(R) 8 1 15.7 49.655 585 1,18% 147

A8_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 15.7 49.005 2.162 4,41% 294

A8_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 2 62,9 52.627 902 1,71% 266

A8m_v2 Xeon(R)
CPU E5-
2660 0 @
2,20 GHz
Standard_ Intel(R) 8 1 62,9 49.838 633 1,27% 182

A8m_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 62,9 49.123 2.483 5.05% 259

A8m_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
NOTE
As VMs da série Av2 podem ser implantadas em uma variedade de tipos de hardware e processadores (como visto
acima). As VMs da série Av2 têm configurações de desempenho e memória de CPU mais adequadas para cargas de
trabalho de nível de entrada, como desenvolvimento e teste. O tamanho é limitado para oferecer desempenho de
processador relativamente consistente para a instância em execução, independentemente do hardware no qual ele está
implantado; no entanto, o software que aproveita as mais novas otimizações de processador podem ver uma variação
mais significativa nos tipos de processador.
B-expansível
(3/15/2019 12:27:08 AM PBI 3897709) (atualizado 6/14/2019 7:09:29 AM PBI 4777081)
% DE
DESEN VO
Standard_ Intel(R) 1 1 1,9 13.593 307 2,26% 28

B1ms Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 1,9 14.069 495 3,52% 672

B1ms Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 1 1 0,9 13.736 211 1,54% 28

B1s Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 0,9 13.965 457 3,27% 672

B1s Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 7.8 27.361 1.110 4,06% 28

B2ms Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 7.8 27.432 771 2,81% 672

B2ms Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 3.9 27.488 822 2,99% 28

B2s Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 3.9 27.548 864 3,14% 672

B2s Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 4 1 15.7 54.951 1.868 3,40% 28

B4ms Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 15.7 54.051 1.260 2,33% 672

B4ms Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 31,4 111.929 1.562 1,40% 35

B8ms Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 31,4 109.537 1.354 1,24% 665

B8ms Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 12 1 47.1 170.777 3.421 2,00% 70

B12ms Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 12 1 47.1 166.676 1.368 0,82% 70

B12ms Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 1 62,9 208.373 30.383 14,58% 63

B16ms Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 62,9 223.203 1.232 0,55% 70

B16ms Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 20 1 78,6 269.561 25.095 9,31% 77

B20ms Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 20 1 78,6 274.007 3.669 1,34% 70

B20ms Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
NOTE
As VMs da série B são para cargas de trabalho com requisitos de desempenho intermitentes. As instâncias de VM
acumulam créditos ao usar menos de sua linha de base. Quando a VM acumula o crédito, a VM pode ultrapassar a linha
de base usando até 100% para atender aos requisitos curtos de intermitência de CPU. O tempo de intermitência depende
dos créditos disponíveis, que é uma função de tamanho e tempo da VM.
O Comark é um teste de execução curta que normalmente é concluído nos créditos de intermitência disponíveis. Portanto,
os números acima normalmente representam o desempenho de intermitência da VM, refletindo o que a curta, a
intermitência, as cargas de trabalho (típicas no desempenho da série B) normalmente verão.
DSv3 - Computação Geral + Armazenamento Premium

(3/12/2019 6:52:03 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 2 1 7.8 20.153 838 4,16% 147

D2s_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 7.8 20.903 1.324 6,33% 553

D2s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 4 1 15.7 39.502 1.257 3,18% 189

D4s_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 15.7 40.547 1.935 4,77% 511

D4s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 31,4 80.191 1.054 1,31% 168

D8s_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 31,4 79.884 3.073 3,85% 532

D8s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 1 62,9 160.319 1.213 0,76% 105

D16s_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 62,9 156.325 2.176 1,39% 588

D16s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 32 2 125,9 315.457 2.647 0,84% 105

D32s_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 32 1 125,9 312.058 1.661 0.53% 595

D32s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 64 2 251,9 627.378 4.447 0,71% 700

D64s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Dv3 - Computação Geral

(3/12/2019 6:54:27 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 2 1 7.8 20.359 799 3,93% 154

D2_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 7.8 20.737 1.422 6,86% 546

D2_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 15.7 40.095 1.501 3,74% 147

D4_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 15.7 41.147 2.706 6,58% 546

D4_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 31,4 80.383 1.486 1,85% 133

D8_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
% DE
DESEN VO
Standard_ Intel(R) 8 1 31,4 80.511 3.916 4,86% 560

D8_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 1 62,9 160.932 2.200 1,37% 140

D16_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 62,9 158.679 4.550 2,87% 560

D16_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 32 2 125,9 314.208 4.250 1,35% 189

D32_v3 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 32 1 125,9 312.472 3.173 1, 2% 511

D32_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 64 2 251,9 627.470 9.651 1,54% 700

D64_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
DSv2 - Otimizado para Armazenamento

(3/15/2019 12:53:13 AM PBI 3897709)
% DE
DESEN VO
% DE
DESEN VO
Standard_ Intel(R) 1 1 3.4 14.642 600 4,10% 259

DS1_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 3.4 14.808 904 6,10% 434

DS1_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 6,8 28.654 877 3, 6% 301

DS2_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 6,8 29.089 1.421 4,89% 406

DS2_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 13,7 57.255 1.633 2,85% 238

DS3_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 13,7 57.255 2.265 3,96% 462

DS3_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 27,5 116.681 1.097 0,94% 231

DS4_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 27,5 112.512 1.261 1,12% 462

DS4_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 16 1 55,0 225.661 2.370 1, 5% 189

DS5_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 2 55,0 229.145 2.878 1,26% 21

DS5_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 55,0 226.818 1.797 0,79% 497

DS5_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 13,7 28.571 920 3,22% 238

DS11_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 13,7 29.049 1.614 5,56% 469

DS11_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 1 1 13,7 14.594 617 4,23% 287

DS11- Xeon(R)
1_v2 CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 13,7 14.951 852 5,70% 413

DS11- Xeon(R)
1_v2 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 27,5 57.503 1.398 2,43% 217

DS12_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
% DE
DESEN VO
Standard_ Intel(R) 4 1 27,5 57.082 2.372 4,16% 483

DS12_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 1 1 27,5 14.698 564 3,84% 238

DS12- Xeon(R)
1_v2 CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 27,5 15.127 941 6,22% 462

DS12- Xeon(R)
1_v2 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 27,5 28.711 981 3,42% 259

DS12- Xeon(R)
2_v2 CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 27,5 29.305 1.241 4,24% 441

DS12- Xeon(R)
2_v2 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 55,0 116.875 1.286 1,10% 203

DS13_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 55,0 112.318 1.356 1,21% 504

DS13_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 55,0 29.105 1.154 3,97% 224

DS13- Xeon(R)
2_v2 CPU E5-
2673 v3
@ 2,40
GHz
% DE
DESEN VO
Standard_ Intel(R) 2 1 55,0 29.936 1.720 5,75% 483

DS13- Xeon(R)
2_v2 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 55,0 56.992 1.814 3,18% 280

DS13- Xeon(R)
4_v2 CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 55,0 57.781 2.122 3,67% 427

DS13- Xeon(R)
4_v2 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 2 110,2 224.149 3.450 1,54% 196

DS14_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 110,2 227.108 1.267 0,56% 504

DS14_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 2 110,2 56.211 2.154 3,83% 189

DS14- Xeon(R)
4_v2 CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 110,2 59.651 2.560 4,29% 518

DS14- Xeon(R)
4_v2 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 2 110,2 112.280 4.430 3,95% 196

DS14- Xeon(R)
8_v2 CPU E5-
2673 v3
@ 2,40
GHz
% DE
DESEN VO
Standard_ Intel(R) 8 1 110,2 113.375 1.442 1,27% 511

DS14- Xeon(R)
8_v2 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 20 2 137,7 279.359 4.032 1,44% 665

DS15_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz

(3/12/2019 6:53:48 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 1 1 3.4 14.730 663 4,50% 385

D1_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 3.4 15.057 1.319 8,76% 322

D1_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 6,8 29.395 1.073 3,65% 329

D2_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 6,8 29.564 2.145 7,26% 378

D2_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 4 1 13,7 58.150 1.340 2,30% 343

D3_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 13,7 57.820 2.944 5,09% 364

D3_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 27,5 117.448 1.612 1,37% 308

D4_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 27,5 114.082 3.369 2,95% 399

D4_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 1 55,0 226.370 4.722 2, 9% 147

D5_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 2 55,0 225.035 5.026 2,23% 119

D5_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 55,0 227.883 3.259 1,43% 441

D5_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 13,7 29.260 1.012 3,46% 308

D11_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
% DE
DESEN VO
Standard_ Intel(R) 2 1 13,7 29.306 1.763 6, 2% 399

D11_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 27,5 58.322 1.391 2,39% 329

D12_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 27,5 57.999 3.533 6, 9% 371

D12_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 55,0 117.218 1.514 1,29% 329

D13_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 55,0 114.344 3.307 2,89% 378

D13_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 2 110,2 224.348 5.477 2,44% 280

D14_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 110,2 228.221 2.733 1,20% 427

D14_v2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 20 2 137,7 281.494 7.976 2,83% 672

D15_v2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Esv3 - Otimizado para Memória + Armazenamento Premium
(3/12/2019 7:17:33 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 2 1 15.7 20.957 1.200 5,73% 672

E2s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 31,4 40.420 1.993 4,93% 672

E4s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 31,4 20.774 1.133 5,45% 672

E4-2s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 62,9 80.153 3.308 4,13% 665

E8s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 62,9 21.178 1.334 6,30% 665

E8-2s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 62,9 40.614 2.216 5,46% 672

E8-4s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 1 125,9 156.137 2.160 1,38% 672

E16s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 4 1 125,9 41.950 2.309 5,50% 637

E16- Xeon(R)
4s_v3 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 125,9 81.196 3.179 3,91% 658

E16- Xeon(R)
8s_v3 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 20 1 157,4 196.619 1.325 0,67% 672

E20s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 32 2 251,9 304.707 5.719 1,88% 672

E32s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 2 251,9 83.576 3.693 4,42% 672

E32- Xeon(R)
8s_v3 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 2 251,9 158.023 4.317 2,73% 672

E32 Xeon(R)
16s_v3 CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 64 2 425,2 628.540 3.982 0,63% 49

E64s_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 2 425,2 169.611 3.265 1,92% 42

E64- Xeon(R)
16s_v3 CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 32 2 425,2 307.584 3.569 1,16% 56

E64- Xeon(R)
32s_v3 CPU E5-
2673 v4
@ 2,30
GHz
Eisv3-memória opcional + armazenamento Premium (isolado)

(4/11/2019 10:07:29 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 64 2 425,2 627.745 4.062 0,65% 196

E64is_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Ev3 - Otimizado para Memória

(3/12/2019 6:52:13 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 2 1 15.7 21.171 1.772 8,37% 693

E2_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 31,4 41.181 3.148 7,64% 700

E4_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 62,9 81.211 5.055 6,22% 700

E8_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 16 1 125,9 158.152 4.033 2,55% 700

E16_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 20 1 157,4 197.739 2.731 1,38% 693

E20_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 32 2 251,9 307.286 8.353 2,72% 700

E32_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 64 2 425,2 628.451 9.235 1,47% 707

E64_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Eiv3-otimizado para memória (isolado)

(3/12/2019 6:57:51 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 64 2 425,2 625.855 4.881 0,78% 7

E64i_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 64 2 425,2 629.151 9.756 1,55% 217

E64i_v3 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Fsv2 - Computação + Otimizado para Armazenamento

(3/12/2019 6:51:35 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 2 1 3.9 28.219 1.843 6,53% 700

F2s_v2 Xeon(R)
Platinum
8168
CPU @
2,70 GHz
Standard_ Intel(R) 4 1 7.8 53.911 1.002 1,86% 707

F4s_v2 Xeon(R)
Platinum
8168
CPU @
2,70 GHz
Standard_ Intel(R) 8 1 15.7 106.467 1.101 1,03% 707

F8s_v2 Xeon(R)
Platinum
8168
CPU @
2,70 GHz
Standard_ Intel(R) 16 1 31,4 211.311 1.724 0,82% 707

F16s_v2 Xeon(R)
Platinum
8168
CPU @
2,70 GHz
Standard_ Intel(R) 32 1 62,9 423.175 4.346 1,03% 707

F32s_v2 Xeon(R)
Platinum
8168
CPU @
2,70 GHz
Standard_ Intel(R) 64 2 125,9 829.537 21.574 2,60% 707

F64s_v2 Xeon(R)
Platinum
8168
CPU @
2,70 GHz
Standard_ Intel(R) 72 2 141,7 933.800 26.783 2,87% 707

F72s_v2 Xeon(R)
Platinum
8168
CPU @
2,70 GHz
Fs - Computação e Otimizado para Armazenamento

(3/15/2019 12:12:51 AM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 1 1 1,9 14.552 504 3,46% 350

F1s Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 1,9 14.784 858 5,80% 357

F1s Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 3.9 28.664 895 3,12% 245

F2s Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 2 1 3.9 29.188 1.228 4,21% 455

F2s Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 7.8 57.192 1.700 2,97% 259

F4s Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 7.8 57.412 2.215 3,86% 448

F4s Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 15.7 117.008 1.139 0,97% 259

F8s Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 15.7 112.610 1.595 1,42% 441

F8s Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
% DE
DESEN VO
Standard_ Intel(R) 16 1 31,4 225.444 2.328 1,03% 210

F16s Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 2 31,4 228.919 3.380 1,48% 28

F16s Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 31,4 227.015 1.543 0,68% 462

F16s Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
F - Otimizado para Computação

(3/12/2019 6:53:59 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 1 1 1,9 14.937 593 3,97% 350

F1 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 1 1 1,9 15.460 1.326 8,58% 350

F1 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 2 1 3.9 29.324 1.196 4, 8% 343

F2 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
% DE
DESEN VO
Standard_ Intel(R) 2 1 3.9 29.299 1.908 6,51% 364

F2 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 4 1 7.8 58.314 1.245 2,14% 364

F4 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 4 1 7.8 58.280 3.581 6,14% 336

F4 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 8 1 15.7 117.516 1.460 1,24% 308

F8 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 8 1 15.7 114.361 3.868 3,38% 399

F8 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
Standard_ Intel(R) 16 1 31,4 226.487 4.140 1,83% 154

F16 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 2 31,4 226.683 4.723 2, 8% 133

F16 Xeon(R)
CPU E5-
2673 v3
@ 2,40
GHz
Standard_ Intel(R) 16 1 31,4 228.592 2.371 1,04% 392

F16 Xeon(R)
CPU E5-
2673 v4
@ 2,30
GHz
GS - Otimizado para Armazenamento
(3/12/2019 10:22:33 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 2 1 27,5 28.835 2.222 7,71% 287

GS1 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 4 1 55,0 55.568 3.139 5,65% 287

GS2 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 8 1 110,2 106.567 2.188 2, 5% 287

GS3 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 16 1 220,4 210.586 4.130 1,96% 287

GS4 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 4 1 220,4 58.598 2.670 4,56% 287

GS4-4 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 8 1 220,4 108.234 2.392 2,21% 287

GS4-8 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 32 2 440,9 399.835 8.694 2,17% 287

GS5 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
% DE
DESEN VO
Standard_ Intel(R) 8 2 440,9 116.643 2.354 2,02% 287

GS5-8 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 16 2 440,9 210.984 2.995 1,42% 287

GS5-16 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
G - Otimizado para Computação

(3/12/2019 10:23:51 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 2 1 27,5 32.808 2.679 8,17% 287

G1 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 4 1 55,0 62.907 4.465 7,10% 287

G2 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 8 1 110,2 113.471 4.346 3,83% 287

G3 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 16 1 220,4 212.092 2.857 1,35% 287

G4 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
% DE
DESEN VO
Standard_ Intel(R) 32 2 440,9 403.315 6.947 1,72% 273

G5 Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
H - Computação de Alto Desempenho (HPC)

(3/12/2019 10:50:51 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 8 1 55,0 149.859 734 0,49% 175

H8 Xeon(R)
CPU E5-
2667 v3
@ 3,20
GHz
Standard_ Intel(R) 8 1 110,2 149.931 657 0,44% 147

H8m Xeon(R)
CPU E5-
2667 v3
@ 3,20
GHz
Standard_ Intel(R) 16 2 110,2 282.083 6.738 2,39% 84

H16 Xeon(R)
CPU E5-
2667 v3
@ 3,20
GHz
Standard_ Intel(R) 16 2 220,4 282.106 7.013 2,49% 84

H16m Xeon(R)
CPU E5-
2667 v3
@ 3,20
GHz
Standard_ Intel(R) 16 2 220,4 282.167 6.889 2,44% 84

H16mr Xeon(R)
CPU E5-
2667 v3
@ 3,20
GHz
% DE
DESEN VO
Standard_ Intel(R) 16 2 110,2 280.837 6.587 2,35% 84

H16r Xeon(R)
CPU E5-
2667 v3
@ 3,20
GHz
Lv2-otimizado para armazenamento

(3/14/2019 5:49:04 PM PBI 3897709)
% DE
DESEN VO
Standard_ Processad 8 1 62,9 80.528 404 0,50% 119

L8s_v2 or AMD
EPYC
7551 32-
Core

L16s_v2 or AMD
EPYC
7551 32-
Core

L32s_v2 or AMD
EPYC
7551 32-
Core

L64s_v2 or AMD
EPYC
7551 32-
Core

L80s_v2 or AMD
EPYC
7551 32-
Core
Ls - Otimizado para Armazenamento

(3/12/2019 10:22:29 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 4 1 31,4 56.488 2.916 5,16% 287

L4s Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 8 1 62,9 107.017 2.323 2,17% 287

L8s Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 16 1 125,9 210.865 3.653 1,73% 280

L16s Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
Standard_ Intel(R) 32 2 251,9 399.963 9.254 2,31% 287

L32s Xeon(R)
CPU E5-
2698B v3
@ 2,00
GHz
M - Otimizado para Memória

(4/11/2019 7:30:39 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel(R) 2 1 215,2 22.605 29 0.13% 42

M8-2ms Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 4 1 215,2 44.488 183 0,41% 42

M8-4ms Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
% DE
DESEN VO
Standard_ Intel(R) 4 1 430,6 44.451 269 0,61% 42

M16- Xeon(R)
4ms CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 8 1 430,6 88.238 1.243 1,41% 42

M16- Xeon(R)
8ms CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 8 1 861,2 88.521 1.353 1,53% 42

M32- Xeon(R)
8ms CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 16 1 861,2 174.674 3.104 1,78% 42

M32- Xeon(R)
16ms CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 64 2 1007,9 683.022 11.929 1,75% 42

M64 Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 16 2 1763,9 169.386 4.737 2,80% 42

M64- Xeon(R)
16ms CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 32 2 1763,9 337.599 4.738 1,40% 42

M64 Xeon(R)
32ms CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 64 2 1763,9 677.466 14.478 2,14% 42

M64m Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
% DE
DESEN VO
Standard_ Intel(R) 64 2 1763,9 675.342 16.577 2,45% 42

M64ms Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 64 2 1007,9 674.785 15.983 2,37% 42

M64s Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 128 4 2015,9 1.334.21 21.126 1,58% 42

M128 Xeon(R) 8
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 32 4 3831,1 334.873 5.005 1,49% 42

M128- Xeon(R)
32ms CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 64 4 3831,1 667.808 18.145 2,72% 42

M128- Xeon(R)
64ms CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 128 4 3831,1 1.335.87 19.642 1,47% 42

M128m Xeon(R) 3
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 128 4 3831,1 1.329.15 24.295 1,83% 42

M128ms Xeon(R) 1
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 128 4 2015,9 1.329.92 20.117 1,51% 42

M128s Xeon(R) 3
CPU E7-
8890 v3
@ 2,50
GHz
% DE
DESEN VO
Standard_ Intel(R) 16 1 430,6 174.686 2.704 1,55% 35

M16ms Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 32 1 251,9 344.069 3.372 0,98% 42

M32ls Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 32 1 861,2 343.226 4.884 1,42% 84

M32ms Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 32 2 861,2 336.526 4.396 1,31% 7

M32ms Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 32 1 188,9 341.112 5.491 1,61% 35

M32ts Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 64 2 503,9 676.026 18.078 2,67% 42

M64ls Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
Standard_ Intel(R) 8 1 215,2 88.066 1.391 1,58% 42

M8ms Xeon(R)
CPU E7-
8890 v3
@ 2,50
GHz
NCSv3-GPU habilitada
(3/21/2019 5:48:37 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel (R) 6 1 110,2 106.929 353 0,33% 49

NC6s_v3 Xeon (R)
CPU E5-
2690 v4
@ 2,60
GHz
Standard_ Intel (R) 12 1 220,4 213.585 875 0,41% 42

NC12s_v Xeon (R)
3 CPU E5-
2690 v4
@ 2,60
GHz
Standard_ Intel (R) 24 2 440,9 403.554 6.705 1,66% 42

NC24rs_v Xeon (R)
3 CPU E5-
2690 v4
@ 2,60
GHz
Standard_ Intel (R) 24 2 440,9 403.874 7.603 1,88% 42

NC24s_v Xeon (R)
3 CPU E5-
2690 v4
@ 2,60
GHz
(3/12/2019 11:19:19 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel (R) 6 1 110,2 107.115 321 0,30% 63

NC6s_v2 Xeon (R)
CPU E5-
2690 v4
@ 2,60
GHz
Standard_ Intel (R) 12 1 220,4 213.814 656 0,31% 63

NC12s_v Xeon (R)
2 CPU E5-
2690 v4
@ 2,60
GHz
% DE
DESEN VO
Standard_ Intel (R) 24 2 440,9 401.728 6.995 1,74% 63

NC24rs_v Xeon (R)
2 CPU E5-
2690 v4
@ 2,60
GHz
Standard_ Intel (R) 24 2 440,9 402.808 7.923 1,97% 63

NC24s_v Xeon (R)
2 CPU E5-
2690 v4
@ 2,60
GHz
NC-GPU habilitada
(3/12/2019 11:08:03 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel (R) 6 1 55,0 102.211 658 0,64% 259

NC6 Xeon (R)
CPU E5-
2690 v3
@ 2,60
GHz
Standard_ Intel (R) 12 1 110,2 203.523 2.293 1,13% 259

NC12 Xeon (R)
CPU E5-
2690 v3
@ 2,60
GHz
Standard_ Intel (R) 24 2 220,4 382.897 8.712 2,28% 259

NC24 Xeon (R)
CPU E5-
2690 v3
@ 2,60
GHz
Standard_ Intel (R) 24 2 220,4 383.171 9.166 2,39% 259

NC24r Xeon (R)
CPU E5-
2690 v3
@ 2,60
GHz
NDs-GPU habilitada
(3/12/2019 11:19:10 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel (R) 6 1 110,2 107.095 353 0,33% 63

ND6s Xeon (R)
CPU E5-
2690 v4
@ 2,60
GHz
Standard_ Intel (R) 12 1 220,4 212.298 3.457 1,63% 63

ND12s Xeon (R)
CPU E5-
2690 v4
@ 2,60
GHz
Standard_ Intel (R) 24 2 440,9 402.749 7.838 1,95% 56

ND24rs Xeon (R)
CPU E5-
2690 v4
@ 2,60
GHz
Standard_ Intel (R) 24 2 440,9 401.822 7.776 1,94% 63

ND24s Xeon (R)
CPU E5-
2690 v4
@ 2,60
GHz
NV-GPU habilitada
(3/12/2019 11:08:13 PM PBI 3897709)
% DE
DESEN VO
Standard_ Intel (R) 6 1 55,0 101.728 2.094 2,06% 259

NV6 Xeon (R)
CPU E5-
2690 v3
@ 2,60
GHz
Standard_ Intel (R) 12 1 110,2 203.903 1.724 0,85% 252

NV12 Xeon (R)
CPU E5-
2690 v3
@ 2,60
GHz
% DE
DESEN VO
Standard_ Intel (R) 24 2 220,4 379.879 8.737 2,30% 259

NV24 Xeon (R)
CPU E5-
2690 v3
@ 2,60
GHz
Sobre o CoreMark
Os números do Linux foram calculados com a execução do CoreMark no Ubuntu. O CoreMark foi configurado
com o número de threads definidos como o número de CPUs virtuais e a simultaneidade definida como
PThreads. O número de iterações de destino foi ajustado com base no desempenho esperado para fornecer um
runtime de pelo menos 20 segundos (normalmente muito mais). A pontuação final representa o número de
iterações concluídas dividido pelo número de segundos necessário para executar o teste. Cada teste foi
executado, no mínimo, sete vezes em cada VM. Datas de execuções de teste mostradas acima. Execução de teste
em várias VMs em regiões públicas do Azure tinham suporte na execução da data. Séries básicas A e B
(expansíveis) não mostradas porque o desempenho é variável. Séries N não mostrada, pois elas centralizadas
em GPU e a Coremark não mede o desempenho de GPU.
Próximas etapas
Para obter capacidades de armazenamento, detalhes do disco e considerações adicionais sobre como
escolher um dos diferentes tamanhos de VM, veja Tamanhos das máquinas virtuais.
Para executar os scripts do CoreMark nas VMs do Linux, baixe o pacote de scripts do CoreMark.
Pontuações de parâmetro de comparação de
computação de VMs do Windows
As pontuações de benchmark SPECInt a seguir mostram o desempenho de computação para selecionar VMs do
Azure executando o Windows Server. As pontuações de parâmetro de comparação de computação também
estão disponíveis para VMs do Linux.
Av2 - Computação Geral

TA XA B A SE
TA M A N H O VC P US N Ó S N UM A CPU EXEC UÇ Õ ES M ÉDIA ST DDEV
Standard_A1_ 1 1 Intel(R) 12 14,2 0.3

v2 Xeon(R) CPU
E5-2660 0 @
2,20 GHz
Standard_A1_ 1 1 Intel(R) 9 13.2 0,6

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
Standard_A1_ 1 1 Intel(R) 10 14,1 0,7

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

v2 Xeon(R) CPU
E5-2660 0 @
2,20 GHz

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_A2 2 1 Intel(R) 14 29,0 0,5

m_v2 Xeon(R) CPU
E5-2660 0 @
2,20 GHz

m_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
TA XA B A SE
Standard_A2 2 1 Intel(R) 21 28,4 1.0

m_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

v2 Xeon(R) CPU
E5-2660 0 @
2,20 GHz

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

m_v2 Xeon(R) CPU
E5-2660 0 @
2,20 GHz

m_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

m_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

v2 Xeon(R) CPU
E5-2660 0 @
2,20 GHz

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

m_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
TA XA B A SE

m_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

m_v2 Xeon(R) CPU
E5-2660 0 @
2,20 GHz
NOTE
As VMs da série Av2 podem ser implantadas em uma variedade de tipos de hardware e processadores (como visto
acima). As VMs da série Av2 têm configurações de desempenho e memória de CPU mais adequadas para cargas de
trabalho de nível de entrada, como desenvolvimento e teste. O tamanho é limitado para oferecer desempenho de
processador relativamente consistente para a instância em execução, independentemente do hardware no qual ele está
implantado; no entanto, o software que aproveita as mais novas otimizações de processador podem ver uma variação
mais significativa nos tipos de processador.
B-expansível
(Atualizado 2019-10-23 para 2019-11-03 PBI: 5604451)
TA XA B A SE
Standard_B1 1 1 Intel(R) 9 6.3 0,2

ms Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
Standard_B1 1 1 Intel(R) 47 6.4 0,2

ms Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_B2 2 1 Intel(R) 36 19,8 0,8

ms Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_B2s 2 1 Intel(R) 2 13,0 0.0

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
Standard_B2s 2 1 Intel(R) 29 13,0 0,5

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
TA XA B A SE
Standard_B4 4 1 Intel(R) 6 27,1 1.0

ms Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

ms Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_B8 8 1 Intel(R) 3 42,0 0.0

ms Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

ms Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_B12 12 1 Intel (R) Xeon 19 58,9 2.3

ms (R) CPU E5-
2673 V3 ou
v4
Standard_B16 16 1 Intel (R) Xeon 18 75,4 2.1

ms (R) CPU E5-
2673 V3 ou
v4
Standard_B20 20 1 Intel (R) Xeon 2 90,6 1,3

ms (R) CPU E5-
2673 V3 ou
v4
NOTE
As VMs da série B são para cargas de trabalho com requisitos de desempenho intermitentes. As instâncias de VM
acumulam créditos ao usar menos de sua linha de base. Quando a VM acumula o crédito, a VM pode ultrapassar a linha
de base usando até 100% para atender aos requisitos curtos de intermitência de CPU. O tempo de intermitência depende
dos créditos disponíveis, que é uma função de tamanho e tempo da VM.
A SPEC int é um teste de execução bastante demorado que normalmente esgota os créditos de intermitência disponíveis.
Portanto, os números acima estão mais próximos do desempenho de linha de base da VM (embora possam refletir algum
tempo de intermitência acumulado entre as execuções). Para cargas de trabalho curtas, intensas (típicas na série B),
normalmente será mais próxima do que a série DS v3.
DSv3 - Computação Geral + Armazenamento Premium

(atualizado 2019-10-23 para 2019-11-03 PBI: 5604451)
TA XA B A SE
Standard_D2s 2 1 Intel(R) 10 40,8 2.3

_v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_D8s 8 1 Intel(R) 7 148,3 1,9

_v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_D16 16 1 Intel(R) 3 275,7 5.1

s_v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_D32 32 2 Intel(R) 9 535,6 12,6

s_v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
Standard_D32 8 Intel (R) Xeon 6 166,0 8.8

-8s_v3 (R) CPU E5-
2673 V3 ou
v4
TA XA B A SE

-16s_v3 (R) CPU E5-
2673 V3 ou
v4
Standard_D48 48 2 Intel (R) Xeon 1 838,0 0.0

s_v3 (R) CPU E5-
2673 V3 ou
v4

s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_D64 16 Intel (R) Xeon 4 340,0 21,4

-16s_v3 (R) CPU E5-
2673 V3 ou
v4

-32s_v3 (R) CPU E5-
2673 V3 ou
v4

(atualizado 2019-10-23 para 2019-11-03 PBI: 5604451)
TA XA B A SE
Standard_D2_ 2 1 Intel(R) 10 38,6 1.8

v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_D4_ 4 1 Intel(R) 17 77,8 1,3

v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
TA XA B A SE

v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
Standard_D48 48 Intel (R) Xeon 3 839,7 14,4

_v3 (R) CPU E5-
2673 V3 ou
v4

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
DSv2 - Otimizado para Armazenamento

TA XA B A SE
Standard_DS1 1 1 Intel(R) 12 33,0 1,1

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
Standard_DS1 1 1 Intel(R) 37 33,8 2.5

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
TA XA B A SE

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

1_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

1_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

1-1_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
TA XA B A SE

1-1_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

2_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

2_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

2-1_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

2-1_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

2-2_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

2-2_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

3_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

3_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

3-2_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

3-2_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
TA XA B A SE

3-4_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

3-4_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

4_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

4_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

4-4_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

4-4_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

4-8_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_DS1 8 2 Intel(R) 14 247,4 10,2

4-8_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

5_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

TA XA B A SE

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
TA XA B A SE

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
Standard_D3_ 4 1 Intel(R) 27 133.4 9.1

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_D5_ 16 1 Intel(R) 9 413,9 14,1

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
TA XA B A SE

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

_v2 Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
Esv3 - Otimizado para Memória + Armazenamento Premium

TA XA B A SE
Standard_E2s 2 1 Intel(R) 39 42,5 2.2

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
TA XA B A SE

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_E8- 2 1 Intel(R) 57 41,8 2.6

2s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_E8- 4 1 Intel(R) 45 82,9 3.0

4s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_E16 16 1 Intel(R) 31 295,7 4.5

s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

-4s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

-8s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_E32 32 2 Intel(R) 31 577,9 9,4

s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

-8s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

16s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_E4- 2 1 Intel(R) 65 41.9 2.4

2s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
TA XA B A SE

s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

-16s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

-32s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Eisv3-memória opcional + armazenamento Premium (isolado)

TA XA B A SE
Standard_E64i 64 2 Intel(R) 28 1073,9 5.7

s_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Ev3 - Otimizado para Memória

TA XA B A SE
Standard_E2_ 2 1 Intel(R) 41 41,2 2.4

v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_E4_ 4 1 Intel(R) 43 81,4 5,3

v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Standard_E8_ 8 1 Intel(R) 39 157,4 8.1

v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
TA XA B A SE

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Eiv3-otimizado para memória (isolado)

TA XA B A SE
Standard_E64i 64 2 Intel(R) 28 1081,4 11,1

_v3 Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
Fsv2 - Computação + Otimizado para Armazenamento

TA XA B A SE
Standard_F2s 2 1 Intel(R) 46 56,5 2.4

_v2 Xeon(R)
Platinum
8168 CPU @
2,70 GHz

_v2 Xeon(R)
Platinum
8168 CPU @
2,70 GHz
Standard_F8s 8 1 Intel(R) 36 215,2 5,3

_v2 Xeon(R)
Platinum
8168 CPU @
2,70 GHz
Standard_F16 16 1 Intel(R) 36 409,3 15.5

s_v2 Xeon(R)
Platinum
8168 CPU @
2,70 GHz
Standard_F32 32 1 Intel(R) 31 760,9 16,9

s_v2 Xeon(R)
Platinum
8168 CPU @
2,70 GHz
TA XA B A SE

s_v2 Xeon(R)
Platinum
8168 CPU @
2,70 GHz

s_v2 Xeon(R)
Platinum
8168 CPU @
2,70 GHz
Fs - Computação e Otimizado para Armazenamento

TA XA B A SE

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
TA XA B A SE

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

s Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

s Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz
F - Otimizado para Computação

TA XA B A SE

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
TA XA B A SE

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz

Xeon(R) CPU
E5-2673 v4
@ 2,30 GHz

Xeon(R) CPU
E5-2673 v3
@ 2,40 GHz
GS - Otimizado para Armazenamento

TA XA B A SE
Standard_GS1 2 1 Intel(R) 29 63,6 4.7

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
Standard_GS4 16 1 Intel(R) 31 391,4 28,6

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz

-4 Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz

-8 Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
TA XA B A SE

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz

-8 Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz

-16 Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
G - Otimizado para Computação

TA XA B A SE
Standard_G1 2 1 Intel(R) 29 64,7 9.2

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
Standard_G2 4 1 Intel(R) 30 127,9 12,2

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
Standard_G3 8 1 Intel(R) 30 231,7 12,6

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
H - Computação de Alto Desempenho (HPC)

TA XA B A SE
Standard_H8 8 1 Intel(R) 31 296,1 1.4

Xeon(R) CPU
E5-2667 v3
@ 3,20 GHz
TA XA B A SE

m Xeon(R) CPU
E5-2667 v3
@ 3,20 GHz

Xeon(R) CPU
E5-2667 v3
@ 3,20 GHz

m Xeon(R) CPU
E5-2667 v3
@ 3,20 GHz

mr Xeon(R) CPU
E5-2667 v3
@ 3,20 GHz

r Xeon(R) CPU
E5-2667 v3
@ 3,20 GHz
Ls - Otimizado para Armazenamento

TA XA B A SE
Standard_L4s 4 1 Intel(R) 29 122,7 6.6

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
Standard_L8s 8 1 Intel(R) 30 223,3 7,5

Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
Standard_L16 16 1 Intel(R) 31 397,3 2.5

s Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
Standard_L32 32 2 Intel(R) 31 766,1 3,5

s Xeon(R) CPU
E5-2698B v3
@ 2,00 GHz
M - Otimizado para Memória

TA XA B A SE
Standard_M8 2 1 Intel(R) 15 42.1 2.1

-2ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz
Standard_M8 4 1 Intel(R) 13 81,6 2,9

-4ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz
Standard_M1 4 1 Intel(R) 14 82,5 2.5

6-4ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

6-8ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

2-8ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

2-16ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

4 Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

4-16ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

4 32ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

4m Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

4ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz
TA XA B A SE

4s Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

28 Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

28-32ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

28-64ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

28m Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

28ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

28s Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

6ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

2ls Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

2ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

2ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz
TA XA B A SE

2ts Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

4ls Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz

ms Xeon(R) CPU
E7-8890 v3
@ 2,50 GHz
TA XA B A SE
Standard_NC 6 1 Intel (R) Xeon 6 230,2 1.6

6s_v3 (R) CPU E5-
2690 v4 @
2,60 GHz
Standard_NC 12 1 Intel (R) Xeon 7 425,0 3,6

12s_v3 (R) CPU E5-
2690 v4 @
2,60 GHz

24rs_v3 (R) CPU E5-
2690 v4 @
2,60 GHz

24s_v3 (R) CPU E5-
2690 v4 @
2,60 GHz
TA XA B A SE

6s_v2 (R) CPU E5-
2690 v4 @
2,60 GHz

12s_v2 (R) CPU E5-
2690 v4 @
2,60 GHz
TA XA B A SE

24rs_v2 (R) CPU E5-
2690 v4 @
2,60 GHz

24s_v2 (R) CPU E5-
2690 v4 @
2,60 GHz
NC-GPU habilitada
TA XA B A SE

6 (R) CPU E5-
2690 v3 @
2,60 GHz

12 (R) CPU E5-
2690 v3 @
2,60 GHz

24 (R) CPU E5-
2690 v3 @
2,60 GHz

24r (R) CPU E5-
2690 v3 @
2,60 GHz
NDs-GPU habilitada
TA XA B A SE
Standard_ND 6 1 Intel (R) Xeon 8 230,1 1.2

6s (R) CPU E5-
2690 v4 @
2,60 GHz

12s (R) CPU E5-
2690 v4 @
2,60 GHz
Standard_ND 24 2 Intel (R) Xeon 10 811,4 3,5

24rs (R) CPU E5-
2690 v4 @
2,60 GHz
TA XA B A SE

24s (R) CPU E5-
2690 v4 @
2,60 GHz
NV-GPU habilitada
TA XA B A SE
Standard_NV 6 1 Intel (R) Xeon 28 210,5 6.1

6 (R) CPU E5-
2690 v3 @
2,60 GHz

12 (R) CPU E5-
2690 v3 @
2,60 GHz

24 (R) CPU E5-
2690 v3 @
2,60 GHz
Sobre o SPECint
Os números do Windows foram calculados executando o SPECint 2006 no Windows Server. O SPECint foi
executado usando a opção de taxa base (SPECint_rate2006), com uma cópia por vCPU. O SPECint consiste em
12 testes separados, cada um deles executado três vezes, usando o valor mediano de cada teste e ponderando-
os para formar uma pontuação composta. Em seguida, eles foram executados em várias VMs para fornecer as
pontuações médias mostradas.
Próximas etapas
Para obter capacidades de armazenamento, detalhes do disco e considerações adicionais sobre como
escolher um dos diferentes tamanhos de VM, veja Tamanhos das máquinas virtuais.
Implantar em hosts dedicados usando o CLI do
Azure
Este artigo orienta como criar um host dedicado do Azure para hospedar suas máquinas virtuais (VMs).
Certifique-se de ter instalado CLI do Azure versão 2.16.0 ou posterior e conectado a uma conta do Azure usando
az login .
Limitações
Os tamanhos e tipos de hardware disponíveis para hosts dedicados variam de acordo com a região. Consulte
a página de preços do host para saber mais.

gerenciados. Crie o grupo de recursos com az group create. O exemplo a seguir cria um grupo de recursos
chamado myDHResourceGroup na localização Leste dos EUA.
az group create --name myDHResourceGroup --location eastus
Listar SKUs de host disponíveis em uma região

Nem todas as SKUs de host estão disponíveis em todas as regiões e zonas de disponibilidade.
Liste a disponibilidade do host e quaisquer restrições de oferta antes de iniciar o provisionamento de hosts
dedicados.
az vm list-skus -l eastus2 -r hostGroups/hosts -o table
Criar um grupo de hosts

Um grupo de hosts é um recurso que representa uma coleção de hosts dedicados. Você cria um grupo de
hosts em uma região e uma zona de disponibilidade e adiciona hosts a ele. Ao planejar a alta disponibilidade, há
opções adicionais. Você pode usar uma ou ambas as opções a seguir com hosts dedicados:
Alcance de várias zonas de disponibilidade. Nesse caso, é necessário ter um grupo de hosts em cada uma das
zonas que você quer usar.
Alcance de vários domínios de falha que são mapeados para racks físicos.
Em ambos os casos, você precisa fornecer a contagem de domínios de falha ao seu grupo de hosts. Se você não
quiser abranger domínios de falha no seu grupo, use uma contagem de domínio de falha de 1.
Você também pode optar por usar tanto zonas de disponibilidade quanto domínios de falha.
Neste exemplo, usaremos az vm host group create para criar um grupo de hosts usando zonas de
disponibilidade e domínios de falha.
az vm host group create \
--name myHostGroup \
-g myDHResourceGroup \
-z 1 \
--platform-fault-domain-count 2
Adicione o --automatic-placement true parâmetro para que suas VMs e instâncias do conjunto de
dimensionamento sejam colocadas automaticamente nos hosts, dentro de um grupo de hosts. Para obter mais
informações, consulte manual versus posicionamento automático .
Outros exemplos
Você também pode usar az vm host group create para criar um grupo de hosts na zona de disponibilidade 1 (e
sem domínios de falha).

--name myAZHostGroup \
-z 1 \
O exemplo a seguir usa az vm host group create para criar um grupo de hosts usando apenas domínios de falha
(para uso em regiões onde as zonas de disponibilidades não têm suporte).

--name myFDHostGroup \
Criar um host
Agora, vamos criar um host dedicado no grupo de hosts. Além de um nome para o host, você deve fornecer o
SKU para o host. O SKU do host captura a série de VMs com suporte, bem como a geração de hardware para o
host dedicado.
Para mais informações sobre preços e SKUs do host, consulte Preços do Host Dedicado do Azure.
Use az vm host create para criar um host. Ao definir uma contagem de domínios de falha para seu grupo de
hosts, você será solicitado a especificar o domínio de falha para o host.
az vm host create \
--host-group myHostGroup \
--name myHost \
--sku DSv3-Type1 \
--platform-fault-domain 1 \
-g myDHResourceGroup

Crie uma máquina virtual em um host dedicado usando az vm create. Se você especificou uma zona de
disponibilidade ao criar o grupo de hosts, será necessário usar a mesma zona ao criar a máquina virtual.
az vm create \
-n myVM \
--image debian \
--size Standard_D4s_v3 \
--zone 1
Para posicionar a VM em um host específico, use --host em vez de especificar o grupo de hosts com
--host-group .
WARNING
A máquina virtual será criada em estado de falha em um host que não tenha recursos suficientes.

Ao implantar um conjunto de dimensionamento, você especifica o grupo de hosts.
az vmss create \
--name myScaleSet \
--image UbuntuLTS \
--size Standard_D4s_v3 \
--zone 1
Se você quiser escolher manualmente a qual host será implantado o conjunto de dimensionamento, adicione
--host e o nome do host.
Verifique o status do host

Você pode verificar o status da integridade do host e quantas máquinas virtuais ainda poderá implantar no host
com az vm host get-instance-view.
az vm host get-instance-view \
--name myHost
{
"autoReplaceOnFailure": true,
"hostId": "6de80643-0f45-4e94-9a4c-c49d5c777b62",
"id": "/subscriptions/10101010-1010-1010-1010-
101010101010/resourceGroups/myDHResourceGroup/providers/Microsoft.Compute/hostGroups/myHostGroup/hosts/myHos
t",
"instanceView": {
"assetId": "12345678-1234-1234-abcd-abc123456789",
"availableCapacity": {
"allocatableVms": [
{
{
"count": 31.0,
"vmSize": "Standard_D2s_v3"
},
{
"count": 15.0,
},
{
"count": 7.0,
},
{
"count": 3.0,
},
{
"count": 1.0,
"vmSize": "Standard_D32-8s_v3"
},
{
"count": 1.0,
},
{
"count": 1.0,
},
{
"count": 1.0,
},
{
"count": 0.0,
},
{
"count": 0.0,
},
{
"count": 0.0,
}
]
},
"statuses": [
{
"code": "ProvisioningState/succeeded",
"displayStatus": "Provisioning succeeded",
"level": "Info",
"message": null,
"time": "2019-07-24T21:22:40.604754+00:00"
},
{
"code": "HealthState/available",
"displayStatus": "Host available",
"level": "Info",
"message": null,
"time": null
}
]
},
"licenseType": null,
"location": "eastus2",
"name": "myHost",
"platformFaultDomain": 1,
"provisioningState": "Succeeded",
"provisioningTime": "2019-07-24T21:22:40.604754+00:00",
"resourceGroup": "myDHResourceGroup",
"resourceGroup": "myDHResourceGroup",
"sku": {
"capacity": null,
"name": "DSv3-Type1",
"tier": null
},
"tags": null,
"type": null,
"virtualMachines": [
{
101010101010/resourceGroups/MYDHRESOURCEGROUP/providers/Microsoft.Compute/virtualMachines/MYVM",
"resourceGroup": "MYDHRESOURCEGROUP"
}
]
}
Exportar como um modelo

Você pode exportar um modelo se quiser criar um ambiente de desenvolvimento adicional usando os mesmos
parâmetros ou um ambiente de produção corresponde. O Gerenciador de Recursos usa modelos JSON que
definem todos os parâmetros para seu ambiente. Crie ambientes inteiros fazendo referência a esse modelo
JSON. Você pode criar modelos JSON manualmente ou exportar um ambiente existente para criar o modelo
JSON para você. Use az group export para exportar seu grupo de recursos.
az group export --name myDHResourceGroup > myDHResourceGroup.json
Esse comando cria o arquivo myDHResourceGroup.json no diretório de trabalho atual. Quando você cria um
ambiente com base neste modelo, será solicitado que você informe todos os nomes de recursos. Você pode
popular esses nomes em seu arquivo de modelo adicionando o parâmetro --include-parameter-default-value
ao comando az group export . Edite seu modelo JSON para especificar os nomes dos recursos, ou crie um
arquivo parameters.json que especifica os nomes dos recursos.
Para criar um ambiente a partir de seu modelo, use AZ Deployment Group Create.
az deployment group create \

--resource-group myNewResourceGroup \
--template-file myDHResourceGroup.json
Limpar
Você é cobrado por hosts dedicados, mesmo se não houver máquinas virtuais implantadas. Você deve excluir os
hosts que não está usando atualmente para economizar custos.
Você só pode excluir um host quando não houver mais máquinas virtuais que o utilizem. Exclua as VMs com az
vm delete.
az vm delete -n myVM -g myDHResourceGroup
Depois de excluir as VMs, você pode excluir o host com az vm host delete.
az vm host delete -g myDHResourceGroup --host-group myHostGroup --name myHost
Depois de excluir todos os hosts, você pode excluir os grupos de hosts com az vm host group delete.
az vm host group delete -g myDHResourceGroup --host-group myHostGroup
Você também pode excluir o grupo de recursos inteiro com um único comando. Isso excluirá todos os recursos
criados no grupo, incluindo todas as VMs, hosts e grupos de hosts.
az group delete -n myDHResourceGroup
Próximas etapas
Para mais informações, consulte a visão geral de hosts dedicados.
Você também pode criar hosts dedicados usando o portal do Azure.
Há um exemplo de modelo, aqui, que usa zonas e domínios de falha para obter resiliência máxima em
uma região.
Implantar VMs e conjuntos de dimensionamento
para hosts dedicados usando o portal
Limitações

Você também pode optar por usar tanto zonas de disponibilidade quanto domínios de falha.
Neste exemplo, criaremos um grupo de hosts usando 1 zona de disponibilidade e 2 domínios de falha.
1. Abra o portaldo Azure.
2. Selecione criar um recurso no canto superior esquerdo.
3. Procure por grupo de hosts e, em seguida, selecione grupos de hosts nos resultados.
4. Na página grupos de hosts , selecione criar .
5. Selecione a assinatura que você deseja usar e, em seguida, selecione criar nova para criar um novo grupo
de recursos.
6. Digite myDedicatedHostsRG como o nome e, em seguida, selecione OK .
7. Para nome do grupo de hosts , digite myhost Group.
8. Em Localização , selecione Leste dos EUA .
9. Para zona de disponibilidade , selecione 1 .
10. Para contagem de domínios de falha , selecione 2 .
11. Selecione posicionamento automático para atribuir automaticamente as VMs e as instâncias do conjunto
de dimensionamento a um host disponível neste grupo.
12. Selecione revisar + criar e aguarde a validação.
13. Depois de ver a mensagem validação aprovada , selecione criar para criar o grupo de hosts.
Só deve levar alguns minutos para criar o grupo de hosts.
Criar um host dedicado

Agora, crie um host dedicado no grupo de hosts. Além de um nome para o host, você deve fornecer o SKU para
o host. O SKU do host captura a série de VMs com suporte, bem como a geração de hardware para o host
dedicado.
Ao definir uma contagem de domínios de falha para seu grupo de hosts, você será solicitado a especificar o
domínio de falha para o host.
1. Selecione criar um recurso no canto superior esquerdo.
2. Pesquise host dedicado e, em seguida, selecione hosts dedicados nos resultados.
3. Na página hosts dedicados , selecione criar .
4. Selecione a assinatura que você deseja usar.
5. Selecione myDedicatedHostsRG como o grupo de recursos .
6. Em detalhes da instância , digite myhost para o nome e selecione leste dos EUA para o local.
7. Em perfil de hardware , selecione família de Es3 padrão-tipo 1 para a família de tamanho , selecione
myhost Group para o grupo de hosts e, em seguida, selecione 1 para o domínio de falha . Deixe os
padrões para o restante dos campos.
8. Quando terminar, selecione revisar + criar e aguarde a validação.
9. Depois de ver a mensagem validação aprovada , selecione criar para criar o host.

1. Escolha Criar um recurso no canto superior esquerdo do portal do Azure.
2. Na caixa de pesquisa acima da lista de recursos do Azure Marketplace, procure e selecione a imagem que
deseja usar e escolha Criar .
3. Na guia noções básicas , em detalhes do projeto , verifique se a assinatura correta está selecionada e, em
seguida, selecione MyDedicatedHostsRG como o grupo de recursos .
4. Em Detalhes da instância , digite myVM para o Nome da máquina vir tual e escolha Leste dos EUA para
Localização .
5. Em Opções de disponibilidade selecionar zona de disponibilidade , selecione 1 na lista suspensa.
6. Para o tamanho, selecione alterar tamanho . Na lista de tamanhos disponíveis, escolha um da série Esv3,
como Standard E2 v3 . Talvez seja necessário limpar o filtro para ver todos os tamanhos disponíveis.
7. Conclua o restante dos campos na guia noções básicas , conforme necessário.
8. Se você quiser especificar qual host deve ser usado para sua VM, na parte superior da página, selecione a
guia avançado e, na seção host , selecione myhost Group para o grupo de hosts e myhost para o host .
Caso contrário, sua VM será automaticamente colocada em um host com capacidade.
9. Deixe os padrões restantes e, em seguida, selecione o botão Examinar + criar na parte inferior da página.
10. Quando você receber a mensagem informando que a validação foi aprovada, selecione Criar .
Levará alguns minutos para que sua VM seja implantada.

1. Procure por conjunto de dimensionamento e selecione conjuntos de dimensionamento de máquinas
vir tuais na lista.
2. Selecione Adicionar para criar um novo conjunto de dimensionamento.
3. Preencha os campos na guia noções básicas como faria normalmente, mas certifique-se de selecionar um
tamanho de VM que seja da série escolhida para o host dedicado, como o Standard E2 v3 .
4. Na guia avançado , para algoritmo de difusão , selecione distribuição máxima .
5. Em grupo de hosts , selecione o grupo de hosts na lista suspensa. Se você criou recentemente o grupo,
pode levar um minuto para ser adicionado à lista.
Adicionar uma VM existente

Você pode adicionar uma VM existente a um host dedicado, mas a VM deve primeiro ser Stop\Deallocated.
Antes de mover uma VM para um host dedicado, verifique se a configuração da VM tem suporte:
O tamanho da VM deve estar na mesma família de tamanho que o host dedicado. Por exemplo, se o host
dedicado for DSv3, o tamanho da VM poderá ser Standard_D4s_v3, mas não poderá ser um Standard_A4_v2.
A VM precisa estar localizada na mesma região que o host dedicado.
A VM não pode fazer parte de um grupo de posicionamento de proximidade. Remova a VM do grupo de
posicionamento de proximidade antes de movê-la para um host dedicado. Para obter mais informações,
consulte mover uma VM para fora de um grupo de posicionamento de proximidade
A VM não pode estar em um conjunto de disponibilidade.
Se a VM estiver em uma zona de disponibilidade, ela deverá ser a mesma zona de disponibilidade que o
grupo de hosts. As configurações de zona de disponibilidade para a VM e o grupo de hosts devem
corresponder.
Mova a VM para um host dedicado usando o portal.
1. Abra a página da VM.
2. Selecione parar para STOP\DEALLOCATE a VM.
3. Selecione configuração no menu à esquerda.
4. Selecione um grupo de hosts e um host nos menus suspensos.
5. Quando terminar, selecione salvar na parte superior da página.
6. Depois que a VM tiver sido adicionada ao host, selecione visão geral no menu à esquerda.
7. Na parte superior da página, selecione Iniciar para reiniciar a VM.
Próximas etapas
Para mais informações, consulte a visão geral de hosts dedicados.
uma região.
Você também pode implantar um host dedicado usando o CLI do Azure ou o PowerShell.
Implantar VMs em hosts dedicados usando o Azure
PowerShell
Verifique se você instalou Azure PowerShell versão 2.8.0 ou posterior e se está conectado a uma conta do Azure
no com Connect-AzAccount .
Limitações
Atualmente, não há suporte para conjuntos de dimensionamento de máquinas virtuais em hosts dedicados.

Você também pode optar por usar tanto zonas de disponibilidade quanto domínios de falha. Este exemplo cria
um grupo de hosts na zona 1, com 2 domínios de falha.
$rgName = "myDHResourceGroup"
$location = "EastUS"
New-AzResourceGroup -Location $location -Name $rgName

$hostGroup = New-AzHostGroup `
-Location $location `
-Name myHostGroup `
-PlatformFaultDomain 2 `
-ResourceGroupName $rgName `
-Zone 1
Adicione o -SupportAutomaticPlacement true parâmetro para que suas VMs e instâncias do conjunto de
dimensionamento sejam colocadas automaticamente nos hosts, dentro de um grupo de hosts. Para obter mais
informações, consulte manual versus posicionamento automático .
Criar um host
Agora, vamos criar um host dedicado no grupo de hosts. Além de um nome para o host, você deve fornecer o
SKU para o host. O SKU do host captura a série de VMs com suporte, bem como a geração de hardware para o
host dedicado.
Ao definir uma contagem de domínios de falha para seu grupo de hosts, você será solicitado a especificar o
domínio de falha para o host. Neste exemplo, definimos o domínio de falha para o host como 1.
$dHost = New-AzHost `
-HostGroupName $hostGroup.Name `
-Location $location -Name myHost `
-Sku DSv3-Type1 `
-AutoReplaceOnFailure 1 `
-PlatformFaultDomain 1

Crie uma máquina virtual no host dedicado.
Se você especificou uma zona de disponibilidade ao criar o grupo de hosts, será necessário usar a mesma zona
ao criar a máquina virtual. Para este exemplo, como nosso grupo de hosts está na zona 1, precisamos criar a VM
na zona 1.
New-AzVM `
-Credential $cred `
-Name myVM `
-HostId $dhost.Id `
-Image Win2016Datacenter `
-Zone 1 `
-Size Standard_D4s_v3
WARNING
A máquina virtual será criada em estado de falha em um host que não tenha recursos suficientes.
Verifique o status do host

Você pode verificar o status de integridade do host e quantas máquinas virtuais você ainda pode implantar no
host usando GetAzHost com o -InstanceView parâmetro.
Get-AzHost `
-Name myHost `
-HostGroupName $hostGroup.Name `
-InstanceView

ResourceGroupName : myDHResourceGroup
PlatformFaultDomain : 1
AutoReplaceOnFailure : True
HostId : 12345678-1234-1234-abcd-abc123456789
ProvisioningTime : 7/28/2019 5:31:01 PM
ProvisioningState : Succeeded
InstanceView :
AssetId : abc45678-abcd-1234-abcd-123456789abc
AvailableCapacity :
AllocatableVMs[0] :
VmSize : Standard_D2s_v3
Count : 32
AllocatableVMs[1] :
Count : 16
AllocatableVMs[2] :
Count : 8
AllocatableVMs[3] :
Count : 4
AllocatableVMs[4] :
VmSize : Standard_D32-8s_v3
Count : 2
AllocatableVMs[5] :
Count : 2
AllocatableVMs[6] :
Count : 2
AllocatableVMs[7] :
Count : 1
AllocatableVMs[8] :
Count : 1
AllocatableVMs[9] :
Count : 1
Statuses[0] :
Code : ProvisioningState/succeeded
Level : Info
DisplayStatus : Provisioning succeeded
Time : 7/28/2019 5:31:01 PM
Statuses[1] :
Code : HealthState/available
Level : Info
DisplayStatus : Host available
Sku :
Name : DSv3-Type1
Id : /subscriptions/10101010-1010-1010-1010-101010101010/re
sourceGroups/myDHResourceGroup/providers/Microsoft.Compute/hostGroups/myHostGroup/hosts
/myHost
Name : myHost
Location : eastus
Tags : {}

New-AzVmss `
-VMScaleSetName "myDHScaleSet" `
-PublicIpAddressName "myPublicIPAddress" `
-LoadBalancerName "myLoadBalancer" `
-UpgradePolicyMode "Automatic"`
-HostGroupId $hostGroup.Id
Se você quiser escolher manualmente a qual host será implantado o conjunto de dimensionamento, adicione
--host e o nome do host.
Adicionar uma VM existente

Você pode adicionar uma VM existente a um host dedicado, mas a VM deve primeiro ser Stop\Deallocated.
Antes de mover uma VM para um host dedicado, verifique se a configuração da VM tem suporte:
O tamanho da VM deve estar na mesma família de tamanho que o host dedicado. Por exemplo, se o host
dedicado for DSv3, o tamanho da VM poderá ser Standard_D4s_v3, mas não poderá ser um Standard_A4_v2.
A VM precisa estar localizada na mesma região que o host dedicado.
A VM não pode fazer parte de um grupo de posicionamento de proximidade. Remova a VM do grupo de
posicionamento de proximidade antes de movê-la para um host dedicado. Para obter mais informações,
consulte mover uma VM para fora de um grupo de posicionamento de proximidade
A VM não pode estar em um conjunto de disponibilidade.
Se a VM estiver em uma zona de disponibilidade, ela deverá ser a mesma zona de disponibilidade que o
grupo de hosts. As configurações de zona de disponibilidade para a VM e o grupo de hosts devem
corresponder.
Substitua os valores das variáveis pelas suas próprias informações.
$vmRGName = "movetohost"
$vmName = "myVMtoHost"
$dhRGName = "myDHResourceGroup"
$dhGroupName = "myHostGroup"
$dhName = "myHost"
$myDH = Get-AzHost `
-HostGroupName $dhGroupName `
-ResourceGroupName $dhRGName `
-Name $dhName
$myVM = Get-AzVM `
-ResourceGroupName $vmRGName `
-Name $vmName
$myVM.Host = New-Object Microsoft.Azure.Management.Compute.Models.SubResource
$myVM.Host.Id = "$myDH.Id"
Stop-AzVM `
-Name $vmName -Force
Update-AzVM `
-VM $myVM -Debug
Start-AzVM `
-Name $vmName
Limpar
Você é cobrado por hosts dedicados, mesmo se não houver máquinas virtuais implantadas. Você deve excluir os
hosts que não está usando atualmente para economizar custos.
Você só pode excluir um host quando não houver mais máquinas virtuais que o utilizem. Exclua as VMs usando
Remove-AzVM.
Remove-AzVM -ResourceGroupName $rgName -Name myVM
Depois de excluir as VMs, você pode excluir o host usando Remove-AzHost.
Remove-AzHost -ResourceGroupName $rgName -Name myHost
Depois de excluir todos os hosts, você poderá excluir o grupo de hosts usando Remove-AzHostGroup.
Remove-AzHost -ResourceGroupName $rgName -Name myHost
Você também pode excluir o grupo de recursos inteiro em um único comando usando Remove-
AzResourceGroup. Isso excluirá todos os recursos criados no grupo, incluindo todas as VMs, hosts e grupos de
hosts.
Remove-AzResourceGroup -Name $rgName
Próximas etapas
uma região.
Você também pode implantar hosts dedicados usando o portal do Azure.
Usar máquinas virtuais do Azure Spot
O uso de máquinas virtuais do Azure Spot permite que você aproveite a capacidade não utilizada a uma
economia de custo significativa. A qualquer momento, quando o Azure precisar da capacidade de volta, a
infraestrutura do Azure removerá as máquinas virtuais do Azure Spot. Portanto, as máquinas virtuais de ponto
do Azure são ótimas para cargas de trabalho que podem lidar com interrupções como trabalhos de
processamento em lotes, ambientes de desenvolvimento/teste, cargas de trabalho de computação grande e
muito mais.
A quantidade de capacidade disponível pode variar com base no tamanho, região, hora do dia e etc. Ao
implantar máquinas virtuais do Azure Spot, o Azure irá alocar as VMs se houver capacidade disponível, mas não
há SLA para essas VMs. Uma máquina virtual do Azure Spot não oferece nenhuma garantia de alta
disponibilidade. A qualquer momento, quando o Azure precisar da capacidade de volta, a infraestrutura do
Azure removerá as máquinas virtuais do Azure spot com 30 segundos de aviso.
Política de remoção
As VMs podem ser removidas com base na capacidade ou no preço máximo definido. Ao criar uma máquina
virtual de ponto do Azure, você pode definir a política de remoção como desalocar (padrão) ou excluir.
A política de desalocação move a VM para o estado parado e desalocada, permitindo que você a implante
novamente mais tarde. No entanto, não há nenhuma garantia de que a alocação terá êxito. As VMs desalocadas
serão contadas em relação à sua cota e você será cobrado pelos custos de armazenamento para os discos
subjacentes.
Se você quiser que sua VM seja excluída quando ela for removida, você poderá definir a política de remoção a
ser excluída. As VMs removidas são excluídas junto com seus discos subjacentes, portanto, você não continuará
a ser cobrado pelo armazenamento.
Você pode optar por receber notificações na VM por meio do Azure eventos agendados. Isso notificará você se
suas VMs estiverem sendo removidas e você terá 30 segundos para concluir todos os trabalhos e realizar
tarefas de desligamento antes da remoção.
OPÇ ÃO RESULTA DO
O preço máximo é definido como >= o preço atual. A VM será implantada se a capacidade e a cota estiverem
disponíveis.
O preço máximo é definido para < o preço atual. A VM não está implantada. Você receberá uma mensagem
de erro informando que o preço máximo precisa ser >=
preço atual.
Reiniciar uma VM de parar/desalocar se o preço máximo for Se houver capacidade e cota, a VM será implantada.
>= o preço atual
Reiniciar uma VM de parar/desalocar se o preço máximo for Você receberá uma mensagem de erro informando que o
< o preço atual preço máximo precisa ser >= preço atual.
O preço da VM foi concluído e agora está > o preço A VM é removida. Você Obtém uma notificação de 30s antes
máximo. da remoção real.
OPÇ ÃO RESULTA DO
Após a remoção, o preço da VM volta a ser < o preço A VM não será reiniciada automaticamente. Você pode
máximo. reiniciar a VM por conta própria e ela será cobrada com o
preço atual.
Se o preço máximo for definido como -1 A VM não será removida por motivos de preço. O preço
máximo será o preço atual, até o preço das VMs padrão.
Você nunca será cobrado acima do preço padrão.
Alterando o preço máximo Você precisa desalocar a VM para alterar o preço máximo.
Desaloque a VM, defina um novo preço máximo e, em
seguida, atualize a VM.
Limitações
Não há suporte para os seguintes tamanhos de VM em máquinas virtuais do Azure spot:
Série B
Versões promocionais de qualquer tamanho (como Dv2, NV, NC, tamanhos promocionais de H)
As máquinas virtuais do Azure Spot podem ser implantadas em qualquer região, exceto Microsoft Azure a
21Vianet da China.
Atualmente, há suporte para os seguintes tipos de oferta :
Contrato Enterprise
Código de oferta pago conforme o uso 003P
Patrocinado
Para provedor de serviços de nuvem (CSP), entre em contato com seu parceiro
Preços
Os preços para as máquinas virtuais do Azure Spot são variáveis, com base na região e no SKU. Para obter mais
informações, consulte preços de VM para Linux e Windows.
Você também pode consultar informações de preços usando a API de preços de varejo do Azure para consultar
informações sobre preços especiais. O meterName e skuName os dois conterão Spot .
Como o preço é variável, você tem a opção de definir um preço máximo, em dólares americanos (USD), usando
até 5 casas decimais. Por exemplo, o valor 0.98765 seria um preço máximo de $0,98765 USD por hora. Se você
definir o preço máximo como -1 , a VM não será removida com base no preço. O preço da VM será o preço
atual para o ponto ou o preço de uma VM padrão, o que nunca é menor, desde que haja capacidade e cota
disponível.
Histórico de preços e remoções

Você pode ver os preços históricos e as taxas de remoção por tamanho em uma região no Portal. Selecione
Exibir histórico de preços e comparar preços em regiões próximas para ver uma tabela ou gráfico de
preços para um tamanho específico. As taxas de preço e remoção nas imagens a seguir são apenas exemplos.
Gráfico :
Tabela :
P: Uma vez criado, é uma máquina virtual de ponto do Azure igual à VM normal padrão?
R: Sim, exceto que não há SLA para máquinas virtuais do Azure Spot e elas podem ser removidas a qualquer
momento.
P: O que fazer quando você é removido, mas ainda precisa de capacidade?
R: Recomendamos que você use VMs padrão em vez de máquinas virtuais do Azure Spot se precisar de
capacidade imediatamente.
P: Como a cota é gerenciada para máquinas virtuais do Azure Spot?
R: As máquinas virtuais do Azure Spot terão um pool de cotas separado. A cota do Spot será compartilhada
entre as VMs e as instâncias do conjunto de dimensionamento. Para saber mais, confira Assinatura e limites de
serviço, cotas e restrições do Azure.
P: Posso solicitar cota adicional para máquinas virtuais do Azure Spot?
R: Sim, você poderá enviar a solicitação para aumentar sua cota para máquinas virtuais do Azure Spot por meio
do processo de solicitação de cota padrão.
P: Onde posso postar perguntas?
R: Você pode postar e marcar sua pergunta com azure-spot em Perguntas e respostas.
P: Como posso alterar o preço máximo de uma VM Spot?
R: Para poder alterar o preço máximo, você precisa desalocar a VM. Em seguida, você pode alterar o preço
máximo no portal, na seção de configuração da VM.
Próximas etapas
Use a CLI, o portal, o modelo ARMou o PowerShell para implantar máquinas virtuais do Azure Spot.
Você também pode implantar um conjunto de dimensionamento com instâncias de máquina virtual do Azure
Spot.
Se você encontrar um erro, consulte códigos de erro.
Implantar máquinas virtuais do Azure Spot usando
o CLI do Azure
muito mais.
Você tem a opção de definir um preço máximo que está disposto a pagar, por hora, para a VM. O preço máximo
de uma máquina virtual de ponto do Azure pode ser definido em dólares americanos (USD), usando até 5 casas
decimais. Por exemplo, o valor 0.98765 seria um preço máximo de $0,98765 USD por hora. Se você definir o
preço máximo como -1 , a VM não será removida com base no preço. O preço da VM será o preço atual para a
máquina virtual do Azure spot ou o preço de uma VM padrão, o que nunca é menor, desde que haja capacidade
e cota disponível. Para obter mais informações sobre como definir o preço máximo, consulte máquinas virtuais
do Azure Spot – preços.
O processo para criar uma máquina virtual do Azure Spot usando o CLI do Azure é o mesmo detalhado no
artigo de início rápido. Basta adicionar o parâmetro '--priority spot ', definir --eviction-policy como desalocar
(esse é o padrão) ou Delete e fornecer um preço máximo ou -1 .

Para criar máquinas virtuais do Azure Spot, você precisa estar executando o CLI do Azure versão 2.0.74 ou
posterior. Execute az --version para descobrir a versão. Se você precisar instalar ou atualizar, confira Instalar a
CLI do Azure.
Entrar no Azure usando login az.
az login
Criar uma máquina virtual do Azure Spot

Este exemplo mostra como implantar uma máquina virtual de ponto do Linux Azure que não será removida
com base no preço. A política de remoção é definida para desalocar a VM, para que ela possa ser reiniciada
posteriormente. Se você quiser excluir a VM e o disco subjacente quando a VM for removida, defina
--eviction-policy como Delete .
az group create -n mySpotGroup -l eastus
az vm create \
--resource-group mySpotGroup \
--name myVM \
--image UbuntuLTS \
--priority Spot \
--max-price -1 \
--eviction-policy Deallocate
Depois que a VM for criada, você poderá consultar para ver o preço máximo de cobrança de todas as VMs no
grupo de recursos.
az vm list \
-g mySpotGroup \
--query '[].{Name:name, MaxPrice:billingProfile.maxPrice}' \
--output table
Simular uma remoção

Você pode simular uma remoção de uma máquina virtual de ponto do Azure, para testar como seu aplicativo
responderá a uma remoção repentina.
Substitua o seguinte pelas suas informações:
subscriptionId
resourceGroupName
vmName
POST
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Mic
rosoft.Compute/virtualMachines/{vmName}/simulateEviction?api-version=2020-06-01
Próximas etapas
Você também pode criar uma máquina virtual do Azure Spot usando Azure PowerShell, portalou um modelo.
Consulte as informações de preços atuais usando a API de preços de varejo do Azure para obter informações
sobre a máquina virtual do Azure Spot. O meterName e skuName os dois conterão Spot .
o portal do Azure
muito mais.
informações, consulte preços de VM para Linux e Windows. Para obter mais informações sobre como definir o
preço máximo, consulte máquinas virtuais do Azure Spot – preços.
para uma máquina virtual de ponto do Azure pode ser definido em dólares americanos (USD), usando até 5
casas decimais. Por exemplo, o valor 0.05701 seria um preço máximo de $0.5701 USD por hora. Se você definir
o preço máximo como -1 , a VM não será removida com base no preço. O preço da VM será o preço atual para
o ponto ou o preço de uma VM padrão, o que nunca é menor, desde que haja capacidade e cota disponível.
Quando a VM é removida, você tem a opção de excluir a VM e o disco subjacente ou desalocar a VM para que
ela possa ser reiniciada mais tarde.
Criar a VM
Ao implantar uma VM, você pode optar por usar uma instância de spot do Azure.
Na guia noções básicas , na seção detalhes da instância , não é o padrão para usar uma instância de spot
do Azure.
Se você selecionar Sim , a seção será expandida e você poderá escolher o tipo de remoção e a política de
remoção.
Você também pode comparar as taxas de preço e remoção com outras regiões semelhantes selecionando Exibir
histórico de preços e comparar preços em regiões próximas .
Neste exemplo, a região central do Canadá é mais barata e tem uma taxa de remoção mais baixa do que a
região leste dos EUA.
Você pode alterar a região selecionando a opção que funciona melhor para você e, em seguida, selecionando
OK .

subscriptionId
resourceGroupName
vmName
POST
Próximas etapas
Você também pode criar máquinas virtuais do Azure Spot usando o PowerShell, a CLIou um modelo.
o Azure PowerShell
muito mais.
informações, consulte preços de VM para Linux e Windows. Para obter mais informações sobre como definir o
preço máximo, consulte máquinas virtuais do Azure Spot – preços.
de uma máquina virtual de ponto do Azure pode ser definido em dólares americanos (USD), usando até 5 casas
decimais. Por exemplo, o valor 0.98765 seria um preço máximo de $0,98765 USD por hora. Se você definir o
preço máximo como -1 , a VM não será removida com base no preço. O preço da VM será o preço atual para o
ponto ou o preço de uma VM padrão, o que nunca é menor, desde que haja capacidade e cota disponível.
Criar a VM
Crie um spotVM usando New-AzVmConfig para criar a configuração. Incluir -Priority Spot e definir
-MaxPrice como:
-1 Portanto, a VM não é removida com base no preço.

um valor de dólar, até 5 dígitos. Por exemplo, -MaxPrice .98765 significa que a VM será desalocada quando o
preço de um spotVM vai cerca de US $98765 por hora.
Este exemplo cria um spotVM que não será desalocado com base no preço (somente quando o Azure precisar
da capacidade de volta). A política de remoção é definida para desalocar a VM, para que ela possa ser reiniciada
posteriormente. Se você quiser excluir a VM e o disco subjacente quando a VM for removida, defina
-EvictionPolicy como Delete em New-AzVMConfig .
$resourceGroup = "mySpotRG"
$location = "eastus"
$vmName = "mySpotVM"
$cred = Get-Credential -Message "Enter a username and password for the virtual machine."
-Name mySubnet -AddressPrefix 192.168.1.0/24
$vnet = New-AzVirtualNetwork -ResourceGroupName $resourceGroup `
-Location $location -Name MYvNET -AddressPrefix 192.168.0.0/16 `
$nic = New-AzNetworkInterface -Name myNic -ResourceGroupName $resourceGroup -Location $location `
# Create a virtual machine configuration and set this to be an Azure Spot Virtual Machine
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize Standard_D1 -Priority "Spot" -MaxPrice -1 -EvictionPolicy
Deallocate | `
Set-AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred | `
Set-AzVMSourceImage -PublisherName MicrosoftWindowsServer -Offer WindowsServer -Skus 2016-Datacenter -
Version latest | `
Depois que a VM for criada, você poderá consultar para ver o preço máximo de todas as VMs no grupo de
recursos.
Get-AzVM -ResourceGroupName $resourceGroup | `

Select-Object Name,@{Name="maxPrice"; Expression={$_.BillingProfile.MaxPrice}}

subscriptionId
resourceGroupName
vmName
POST
Próximas etapas
Você também pode criar uma máquina virtual do Azure Spot usando o CLI do Azure, o portal ou um modelo.
sobre os preços de máquina virtual do Azure Spot. O meterName e skuName os dois conterão Spot .
um modelo do Resource Manager
muito mais.
para uma máquina virtual de ponto do Azure pode ser definido em dólares americanos (USD), usando até 5
casas decimais. Por exemplo, o valor 0.98765 seria um preço máximo de $0,98765 USD por hora. Se você
definir o preço máximo como -1 , a VM não será removida com base no preço. O preço da VM será o preço
atual para as máquinas virtuais do Azure spot ou o preço de uma VM padrão, o que nunca é menor, desde que
haja capacidade e cota disponível. Para obter mais informações sobre como definir o preço máximo, consulte
máquinas virtuais do Azure Spot – preços.
Como usar um modelo

Para implantações de modelo de máquina virtual do Azure Spot, use "apiVersion": "2019-03-01" ou posterior.
Adicione as priority evictionPolicy Propriedades e billingProfile ao no seu modelo:
"priority": "Spot",
"evictionPolicy": "Deallocate",
"billingProfile": {
"maxPrice": -1
}
Aqui está um modelo de exemplo com as propriedades adicionadas para uma máquina virtual de ponto do
Azure. Substitua os nomes de recursos pelos seus próprios e <password> por uma senha para a conta de
administrador local na VM.
{
"$schema": "http://schema.management.azure.com/schemas/2019-03-01/deploymentTemplate.json#",
"parameters": {
},
"variables": {
"vnetId": "/subscriptions/ec9fcd04-e188-48b9-abfc-
abcd515f1836/resourceGroups/spotVM/providers/Microsoft.Network/virtualNetworks/spotVM",
"subnetName": "default",
"networkInterfaceName": "spotVMNIC",
"publicIpAddressName": "spotVM-ip",
"publicIpAddressType": "Dynamic",
"publicIpAddressSku": "Basic",
"virtualMachineName": "spotVM",
"osDiskType": "Premium_LRS",
"virtualMachineSize": "Standard_D2s_v3",
"adminUsername": "azureuser",
"adminPassword": "<password>",
"diagnosticsStorageAccountName": "diagstoragespot2019",
"diagnosticsStorageAccountId": "Microsoft.Storage/storageAccounts/diagstoragespot2019",
"diagnosticsStorageAccountType": "Standard_LRS",
"diagnosticsStorageAccountKind": "Storage",
"subnetRef": "[concat(variables('vnetId'), '/subnets/', variables('subnetName'))]"
},
"resources": [
{
"name": "spotVM",
"apiVersion": "2019-03-01",
"dependsOn": [
"[concat('Microsoft.Network/publicIpAddresses/', variables('publicIpAddressName'))]"
],
"properties": {
{
"properties": {
"subnet": {
},
"id": "[resourceId(resourceGroup().name,
'Microsoft.Network/publicIpAddresses', variables('publicIpAddressName'))]"
}
}
}
]
}
},
{
"name": "[variables('publicIpAddressName')]",
"type": "Microsoft.Network/publicIpAddresses",
"apiVersion": "2019-02-01",
"properties": {
"publicIpAllocationMethod": "[variables('publicIpAddressType')]"
},
"sku": {
"name": "[variables('publicIpAddressSku')]"
}
},
{
"name": "[variables('virtualMachineName')]",
"apiVersion": "2019-03-01",
"dependsOn": [
"[concat('Microsoft.Network/networkInterfaces/', variables('networkInterfaceName'))]",
"[concat('Microsoft.Storage/storageAccounts/', variables('diagnosticsStorageAccountName'))]"
],
"properties": {
"vmSize": "[variables('virtualMachineSize')]"
},
"storageProfile": {
"osDisk": {
"createOption": "fromImage",
"managedDisk": {
"storageAccountType": "[variables('osDiskType')]"
}
},
"imageReference": {
"sku": "18.04-LTS",
"version": "latest"
}
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',
variables('networkInterfaceName'))]"
}
]
},
"osProfile": {
"computerName": "[variables('virtualMachineName')]",
"adminUsername": "[variables('adminUsername')]",
"adminPassword": "[variables('adminPassword')]"
},
"enabled": true,
"storageUri": "[concat('https://', variables('diagnosticsStorageAccountName'),
'.blob.core.windows.net/')]"
}
},
"priority": "Spot",
"evictionPolicy": "Deallocate",
"billingProfile": {
"maxPrice": -1
}
}
},
{
"name": "[variables('diagnosticsStorageAccountName')]",
"apiVersion": "2019-04-01",
"properties": {},
"kind": "[variables('diagnosticsStorageAccountKind')]",
"sku": {
"name": "[variables('diagnosticsStorageAccountType')]"
}
}
],
"outputs": {
"adminUsername": {
"type": "string",
"value": "[variables('adminUsername')]"
}
}
}

subscriptionId
resourceGroupName
vmName
POST
Próximas etapas
Você também pode criar uma máquina virtual do Azure Spot usando Azure PowerShell ou a CLI do Azure.
sobre os preços de máquina virtual do Azure Spot. O meterName e skuName os dois conterão Spot .
Mensagens de erro para máquinas virtuais do
Azure Spot e conjuntos de dimensionamento
Aqui estão alguns códigos de erro possíveis que você pode receber ao usar as máquinas virtuais e os conjuntos
de dimensionamento do Azure Spot.
C H AVE M EN SA GEM DESC RIÇ Ã O
SkuNotAvailable A camada solicitada para o recurso ' Não há capacidade suficiente de

<resource> ' não está disponível máquina virtual do Azure Spot neste
atualmente no local ' <location> ' para local para criar sua instância de VM ou
a assinatura ' <subscriptionID> '. Tente conjunto de dimensionamento.
outra camada ou implante em um local
diferente.
EvictionPolicyCanBeSetOnlyOnAzureSp A política de remoção pode ser Essa VM não é uma máquina virtual
otVirtualMachines definida somente em máquinas de ponto do Azure, portanto, você não
virtuais de ponto do Azure. pode definir a política de remoção.
AzureSpotVMNotSupportedInAvailabili Não há suporte para a máquina virtual Você precisa optar por usar uma
tySet do Azure spot no conjunto de máquina virtual de ponto do Azure ou
disponibilidade. usar uma VM em um conjunto de
disponibilidade, não pode escolher
ambas.
AzureSpotFeatureNotEnabledForSubsc Assinatura não habilitada com o Use uma assinatura que dê suporte a
ription recurso de máquina virtual do Azure máquinas virtuais do Azure Spot.
Spot.
VMPriorityCannotBeApplied O valor de prioridade especificado ' {0} Especifique a prioridade quando a VM

' não pode ser aplicado à máquina for criada.
virtual ' {1} ', pois nenhuma prioridade
foi especificada quando a máquina
virtual foi criada.
SpotPriceGreaterThanProvidedMaxPric Não é possível executar a operação ' Selecione um preço máximo mais alto.
e {0} ', pois o preço máximo fornecido ' Para obter mais informações, consulte
{1} USD ' é inferior ao preço spot atual informações de preço para Linux ou
' {2} USD ' para o tamanho da máquina Windows.
virtual do Azure spot ' {3} '.
MaxPriceValueInvalid Valor de preço máximo inválido. Os Insira um preço máximo válido. Para
únicos valores com suporte para o obter mais informações, consulte
preço máximo são-1 ou um decimal preços para Linux ou Windows.
maior que zero. O valor de preço
máximo de-1 indica que a máquina
virtual do Azure Spot não será
removida por motivos de preço.
MaxPriceChangeNotAllowedForAllocat A alteração máxima de preço não é Stop\Deallocate a VM para que você

edVMs permitida quando a VM ' {0} ' está possa alterar o preço máximo.
alocada no momento. Desaloque e
tente novamente.
C H AVE M EN SA GEM DESC RIÇ Ã O
MaxPriceChangeNotAllowed A alteração máxima de preço não é Você não pode alterar o preço máximo
permitida. desta VM.
AzureSpotIsNotSupportedForThisAPIV Não há suporte para a máquina virtual A versão da API precisa ser 2019-03-
ersion de ponto do Azure nesta versão de 01.
API.
AzureSpotIsNotSupportedForThisVMSi A máquina virtual do Azure Spot não Selecione outro tamanho de VM. Para
ze tem suporte para esse tamanho de obter mais informações, consulte
VM {0} . máquinas virtuais do Azure Spot.
MaxPriceIsSupportedOnlyForAzureSpo O preço máximo tem suporte apenas Para obter mais informações, consulte
tVirtualMachines para máquinas virtuais do Azure Spot. máquinas virtuais do Azure Spot.
MoveResourcesWithAzureSpotVMNot A solicitação mover recursos contém Não é possível mover as máquinas

Supported uma máquina virtual de ponto do virtuais do Azure Spot.
Azure. Sem suporte. Verifique os
detalhes do erro para IDs de máquina
virtual.
MoveResourcesWithAzureSpotVmssNo A solicitação mover recursos contém Não é possível mover as instâncias do

tSupported um conjunto de dimensionamento de conjunto de dimensionamento de
máquinas virtuais do Azure Spot. Sem máquinas virtuais do Azure Spot.
suporte. Verifique os detalhes do erro
para as IDs do conjunto de
virtuais.
AzureSpotVMNotSupportedInVmssWit Não há suporte para a máquina virtual Defina o modo de orquestração como
hVMOrchestrationMode de ponto do Azure no conjunto de conjunto de dimensionamento de
dimensionamento de máquinas máquinas virtuais para usar as
virtuais com o modo de orquestração instâncias de máquina virtual do Azure
de VM. Spot.
Próximas etapas Para obter mais informações, consulte máquinas virtuais Spot.
Como Benefício Híbrido do Azure se aplica a
máquinas virtuais Linux
Benefício Híbrido do Azure é um benefício de licenciamento que ajuda a reduzir significativamente os custos de
execução de suas VMs (máquinas virtuais) Red Hat Enterprise Linux (RHEL) e SUSE Linux Enterprise Server
(SLES) na nuvem. Com esse benefício, você paga apenas pelos custos de infraestrutura da sua VM, pois sua
assinatura RHEL ou SLES cobre a taxa de software. O benefício está disponível para todas as imagens RHEL e
SLES Marketplace PAYG (pré-pago).
O Benefício Híbrido do Azure para VMs do Linux agora está disponível publicamente.
Descrição do benefício
Por meio do Benefício Híbrido do Azure, você pode migrar seus servidores RHEL e SLES locais para o Azure
convertendo VMs RHEL e SLES PAYG existentes no Azure para cobrança BYOS (traga sua própria assinatura).
Normalmente, as VMs implantadas de imagens PAYG no Azure cobrarão uma taxa de infraestrutura e uma taxa
de software. Com Benefício Híbrido do Azure, as VMs PAYG podem ser convertidas em um modelo de cobrança
BYOS sem uma reimplantação, para que você possa evitar qualquer risco de tempo de inatividade.
Depois de habilitar o benefício na VM RHEL ou SLES, você não será mais cobrado pela taxa de software
adicional normalmente incorrida em uma VM PAYG. Em vez disso, sua VM começará a acumular um encargo de
BYOS, que inclui apenas a taxa de hardware de computação e nenhuma taxa de software.
Você também pode optar por converter uma VM que teve o benefício habilitado nele de volta para um modelo
de cobrança PAYG.
Escopo da elegibilidade Benefício Híbrido do Azure para VMs Linux

Benefício Híbrido do Azure está disponível para todas as imagens RHEL e SLES PAYG do Azure Marketplace. O
benefício ainda não está disponível para imagens RHEL ou SLES BYOS ou para imagens personalizadas do
Azure Marketplace.
As instâncias reservadas, as instâncias de host dedicadas do Azure e os benefícios híbridos do SQL não são
elegíveis para Benefício Híbrido do Azure se você já estiver usando o benefício com VMs do Linux.
Introdução
Clientes do Red Hat
Benefício Híbrido do Azure para RHEL está disponível para clientes Red Hat que atendem a esses dois critérios:
Ter assinaturas RHEL ativas ou não usadas qualificadas para uso no Azure
Habilitou uma ou mais dessas assinaturas para uso no Azure com o programa de acesso à nuvem do Red
Hat
IMPORTANT
Verifique se a assinatura correta foi habilitada no programa de acesso à nuvem .
Para começar a usar o benefício do Red Hat:

1. Habilite uma ou mais de suas assinaturas RHEL qualificadas para uso no Azure usando a interface do
cliente do Red Hat Cloud Access.
As assinaturas do Azure que você fornecer durante o processo de habilitação de acesso à nuvem do Red
Hat terão permissão para usar o recurso Benefício Híbrido do Azure.
2. Aplique Benefício Híbrido do Azure a qualquer uma das suas VMs PAYG do RHEL existentes e a novas
VMs RHEL que você implantar de imagens do Azure Marketplace PAYG. Você pode usar portal do Azure
ou CLI do Azure para habilitar o benefício.
3. Siga as próximas etapas recomendadas para configurar fontes de atualização para suas VMs RHEL e para
obter diretrizes de conformidade de assinatura do RHEL.
Clientes do SUSE
Para começar a usar o benefício do SUSE:
1. Registre-se no programa de nuvem pública SUSE.
2. Aplique o benefício às suas VMs recém-criadas ou existentes por meio do portal do Azure ou CLI do Azure.
3. Registre suas VMs que estão recebendo o benefício com uma fonte separada de atualizações.
Habilitar e desabilitar o benefício no portal do Azure

Você pode habilitar o benefício em VMs existentes visitando a opção de configuração à esquerda e seguindo
as etapas ali. Você pode habilitar o benefício em novas VMs durante a experiência de criação da VM.
Portal do Azure exemplo para habilitar o benefício para uma VM existente:
1. Visite portal do Microsoft Azure
2. Vá para a página ' criar uma máquina virtual ' no Portal.
3. Clique na caixa de seleção para habilitar a conversão de AHB e usar licenças de acesso à nuvem.
4. Criar uma máquina virtual seguindo o próximo conjunto de instruções

5. Verifique a folha de configuração e você verá a opção habilitada.
Portal do Azure exemplo para habilitar o benefício durante a criação da VM:
1. Visite portal do Microsoft Azure
2. Abra a página da máquina virtual na qual você deseja aplicar a conversão.
3. Vá para a opção de configuração à esquerda. Você verá a seção licenciamento. Para habilitar a conversão de
AHB, marque o botão de opção ' Sim ' e marque a caixa de seleção de confirmação.
NOTE
Se você tiver criado um instantâneo personalizado ou uma imagem compar tilhada (SIG) de uma imagem RHEL ou
SLES PAYG Marketplace, você só poderá usar CLI do Azure para habilitar benefício híbrido do Azure. Essa é uma limitação
conhecida e, no momento, não há nenhum cronograma para fornecer esse recurso no portal do Azure também.
Habilitar e desabilitar o benefício no CLI do Azure

Você pode usar o az vm update comando para atualizar as VMs existentes. Para VMs RHEL, execute o comando
com um --license-type parâmetro de RHEL_BYOS . Para VMs SLES, execute o comando com um
--license-type parâmetro de SLES_BYOS .
Exemplo da CLI para habilitar o benefício
# This will enable the benefit on a RHEL VM

az vm update -g myResourceGroup -n myVmName --license-type RHEL_BYOS
# This will enable the benefit on a SLES VM

az vm update -g myResourceGroup -n myVmName --license-type SLES_BYOS
Exemplo da CLI para desabilitar o benefício

Para desabilitar o benefício, use um --license-type valor de None :
# This will disable the benefit on a VM

az vm update -g myResourceGroup -n myVmName --license-type None
Exemplo de CLI para habilitar o benefício em um grande número de VMs

Para habilitar o benefício em um grande número de VMs, você pode usar o --ids parâmetro no CLI do Azure:
# This will enable the benefit on a RHEL VM. In this example, ids.txt is an
# existing text file that contains a delimited list of resource IDs corresponding
# to the VMs using the benefit
az vm update -g myResourceGroup -n myVmName --license-type RHEL_BYOS --ids $(cat ids.txt)
Os exemplos a seguir mostram dois métodos para obter uma lista de IDs de recurso: um no nível do grupo de
recursos e outro no nível da assinatura.
# To get a list of all the resource IDs in a resource group:

$(az vm list -g MyResourceGroup --query "[].id" -o tsv)
# To get a list of all the resource IDs of VMs in a subscription:

az vm list -o json | jq '.[] | {VMName: .name, ResourceID: .id}'
Aplicar o Benefício Híbrido do Azure em tempo de criação da VM

Além de aplicar as Benefício Híbrido do Azure às VMs pagas conforme o uso existentes, você pode chamá-las no
momento da criação da VM. Os benefícios disso são threefold:
Você pode provisionar VMs PAYG e BYOS usando a mesma imagem e processo.
Ele permite alterações futuras no modo de licenciamento, algo não disponível com uma imagem somente
BYOS ou se você colocar sua própria VM.
A VM será conectada à RHUI (infraestrutura de atualização do Red Hat) por padrão, para garantir que ela
permaneça atualizada e segura. Você pode alterar o mecanismo atualizado após a implantação a qualquer
momento.
Verificar o status de Benefício Híbrido do Azure de uma VM

Você pode exibir o status de Benefício Híbrido do Azure de uma VM usando o CLI do Azure ou usando o serviço
de metadados de instância do Azure.
CLI do Azure
Você pode usar o az vm get-instance-view comando para essa finalidade. Procure um licenseType campo na
resposta. Se o licenseType campo existir e o valor for RHEL_BYOS ou SLES_BYOS , sua VM terá o benefício
habilitado.
az vm get-instance-view -g MyResourceGroup -n MyVm
Serviço de metadados de instância do Azure

De dentro da própria VM, você pode consultar os metadados atestados no serviço de metadados de instância
do Azure para determinar o valor da VM licenseType . Um licenseType valor RHEL_BYOS ou SLES_BYOS
indicará que sua VM tem o benefício habilitado. Saiba mais sobre os metadados atestados.
Conformidade
Red Hat
Os clientes que usam o Benefício Híbrido do Azure para RHEL concordam com os termos legais padrão e a
política de privacidade associada às ofertas do Azure Marketplace RHEL.
Os clientes que usam o Benefício Híbrido do Azure para RHEL têm três opções para fornecer atualizações de
software e patches para essas VMs:
Infraestrutura de atualização do Red Hat (opção padrão)
Servidor de satélite Red Hat
Gerenciador de assinaturas do Red Hat
Os clientes que escolhem a opção RHUI podem continuar a usar o RHUI como a principal origem de atualização
para suas VMs Benefício Híbrido do Azure RHEL sem anexar assinaturas de RHEL a essas VMs. Os clientes que
escolhem a opção RHUI são responsáveis por garantir a conformidade da assinatura do RHEL.
Os clientes que escolhem o servidor de satélite Red Hat ou o Gerenciador de assinaturas do Red Hat devem
remover a configuração RHUI e anexar uma assinatura RHEL habilitada para acesso à nuvem às suas VMs
Benefício Híbrido do Azure RHEL.
Para obter mais informações sobre conformidade de assinatura do Red Hat, atualizações de software e fontes
para Benefício Híbrido do Azure VMs RHEL, consulte o artigo sobre o Red Hat sobre como usar assinaturas do
RHEL com benefício híbrido do Azure.
SUSE
Para usar Benefício Híbrido do Azure para suas VMs SLES e obter informações sobre como migrar do SLES PAYG
para o BYOS ou migrar do SLES BYOS para o PAYG, consulte SuSE Linux Enterprise e benefício híbrido do Azure.
P: posso usar um tipo de licença RHEL_BYOS com uma imagem SLES ou vice-versa?
R: não, você não pode. A tentativa de inserir um tipo de licença que corresponda incorretamente à distribuição
em execução em sua VM não atualizará nenhum metadado de cobrança. Mas se você inserir acidentalmente o
tipo de licença errado, atualizar sua VM novamente para o tipo de licença correto ainda habilitará o benefício.
P: Eu me registrei com o acesso à nuvem Red Hat, mas ainda não posso habilitar o benefício em minhas VMs
RHEL. O que devo fazer?
R: pode levar algum tempo para que o registro da assinatura do Red Hat Cloud Access se propague do Red Hat
para o Azure. Se você ainda vir o erro após um dia útil, entre em contato com o suporte da Microsoft.
P: implantei uma VM usando o RHEL BYOS "imagem dourada". Posso converter a cobrança nessas imagens de
BYOS para PAYG?
R: não, você não pode. Benefício Híbrido do Azure dá suporte à conversão somente em imagens pagas
conforme o uso.
P: Eu carreguei minha própria imagem RHEL do local (por meio de migrações para Azure, Azure Site Recovery
ou de outra forma) para o Azure. Posso converter a cobrança nessas imagens de BYOS para PAYG?
R: não, você não pode. No momento, o recurso Benefício Híbrido do Azure está disponível apenas para imagens
RHEL e SLES no Azure Marketplace.
P: Eu carreguei minha própria imagem RHEL do local (por meio de migrações para Azure, Azure Site Recovery
ou de outra forma) para o Azure. Preciso fazer algo para se beneficiar do Benefício Híbrido do Azure?
R: não, você não tem. As imagens RHEL que você carrega já são consideradas BYOS, e você é cobrado apenas
pelos custos de infraestrutura do Azure. Você é responsável pelos custos de assinatura do RHEL, assim como
você é para seus ambientes locais.
P: posso usar Benefício Híbrido do Azure em VMs implantadas de imagens do Azure Marketplace RHEL e do
SLES SAP?
R: Sim, você pode. Você pode usar o tipo de licença do RHEL_BYOS para VMs RHEL e SLES_BYOS para conversões
de VMs implantadas de imagens do Azure Marketplace RHEL e SLES SAP.
P: posso usar Benefício Híbrido do Azure em conjuntos de dimensionamento de máquinas virtuais para RHEL e
SLES?
R: não, você não pode. Atualmente, os conjuntos de dimensionamento de máquinas virtuais estão no escopo de
Benefício Híbrido do Azure para RHEL e SLES.
P: posso usar Benefício Híbrido do Azure em instâncias reservadas para RHEL e SLES?
R: não, você não pode. Atualmente, as instâncias reservadas não estão no escopo de Benefício Híbrido do Azure
para RHEL e SLES.
P: posso usar Benefício Híbrido do Azure em uma máquina virtual implantada para SQL Server em imagens
RHEL?
R: não, você não pode. Não há nenhum plano para dar suporte a essas máquinas virtuais.
P: posso usar Benefício Híbrido do Azure na minha assinatura do RHEL virtual Data Center?
R: não, você não pode. O VDC não tem suporte no Azure, incluindo AHB.
Problemas comuns
Esta seção lista os problemas comuns que você pode encontrar e as etapas de mitigação.
ERRO AT EN UA Ç Ã O
"A ação não pôde ser concluída porque nossos registros Para usar o benefício com VMs RHEL, você deve primeiro
mostram que você não habilitou com êxito o acesso à registrar suas assinaturas do Azure com o Red Hat Cloud
nuvem Red Hat em sua assinatura do Azure...." Access.
Próximas etapas
Saiba como criar e atualizar VMs e adicionar tipos de licença (RHEL_BYOS, SLES_BYOS) para Benefício
Híbrido do Azure usando o CLI do Azure
Benefício Híbrido do Azure para Windows Server
Para clientes com o Software Assurance, o Benefício Híbrido do Azure para Windows Server permite usar as
licenças locais do Windows Server e executar máquinas virtuais do Windows no Azure por um custo reduzido.
Você pode usa o Benefício Híbrido do Azure para Windows Server para implantar novas máquinas virtuais com
Windows OS. Este artigo percorre as etapas sobre como implantar novas VMs com o Benefício Híbrido do Azure
para Windows Server e como você pode atualizar VMs existentes e em execução. Para saber mais sobre
licenciamento e economia de custo do Benefício Híbrido do Azure para Windows Server, consulte a página de
licenciamento do Benefício Híbrido do Azure para Windows Server.
Cada licença de 2 processadores ou cada conjunto de licenças de 16 núcleos tem direito a duas instâncias de até
8 núcleos ou uma instância de até 16 núcleos. O Benefício Híbrido do Azure para licenças Standard Edition só
pode ser usado uma vez localmente ou no Azure. Os benefícios da Datacenter Edition permitem o uso
simultâneo localmente e no Azure.
Usar o Benefício Híbrido do Azure para Windows Server com quaisquer VMs executando Windows Server OS
agora têm suporte em todas as regiões, incluindo VMs com software adicional como SQL Server ou software do
marketplace de terceiros.
VMs clássicas
Para VMs clássicas, há suporte apenas para implantar uma nova VM a partir de imagens personalizadas locais.
Para aproveitar os recursos com suporte neste artigo, você deve primeiro migrar as VMs clássicas para o
modelo do Resource Manager.
IMPORTANT
As VMs clássicas serão desativadas em 1º de março de 2023.
Se você usa os recursos de IaaS do ASM, realize a migração até 1º de março de 2023. Recomendamos que faça a
migração o quanto antes para aproveitar as inúmeras melhorias feitas no Azure Resource Manager.
Para mais informações, confira Migrar os recursos de IaaS para o Azure Resource Manager até 1º de março de 2023.
Formas de usar o Benefício Híbrido do Azure para Windows Server

Há algumas maneiras de usar as máquinas virtuais do Windows com o Benefício Híbrido do Azure:
1. Você pode implantar VMs de uma das imagens do Windows Server fornecidos no Azure Marketplace
2. Você pode carregar uma VM personalizada e implantar usando um modelo do Gerenciador de Recursos ou
do Azure PowerShell
3. Você pode alternar e converter uma VM existente entre executar com o Benefício Híbrido do Azure ou pagar
o custo sob demanda para Windows Server
4. Você também pode implantar o Benefício Híbrido do Azure para Windows Server em conjunto de
dimensionamento de máquina virtual também
Crie uma VM com Benefício Híbrido do Azure para Windows Server

Todas as imagens baseadas em Windows Server OS têm suporte para Benefício Híbrido do Azure para
Windows Server. Você pode usar imagens de suporte da plataforma do Azure ou carregar as suas próprias
imagens personalizadas do Windows Server.
Portal
Para criar uma VM com o Benefício Híbrido do Azure para Windows Server, role até a parte inferior da guia
noções básicas durante o processo de criação e, em Licenciamento , marque a caixa para usar uma licença
existente do Windows Server.
PowerShell
New-AzVm `
-Name "myVM" `
-ImageName "Win2016Datacenter" `
-LicenseType "Windows_Server"
CLI
az vm create \
--name myVM \
--location eastus \
--license-type Windows_Server
Modelo
Nos modelos do Resource Manager, um parâmetro adicional para licenseType deve ser especificado. Você
pode ler mais sobre a criação de modelos do Azure Resource Manager
"properties": {
"licenseType": "Windows_Server",
"vmSize": "[variables('vmSize')]"
}
Converter uma VM existente usando o Benefício Híbrido do Azure

para Windows Server
Se houver uma VM existente que você deseja converter para aproveitar o Benefício Híbrido do Azure para
Windows Server, atualize o tipo de licença da VM seguindo as instruções abaixo.
NOTE
A alteração do tipo de licença na VM não faz com que o sistema seja reinicializado e não causa interrupção no serviço. Ele
é simplesmente uma atualização de um sinalizador de metadados.
Portal
Na folha VM do portal, você pode atualizar a VM para usar o Benefício Híbrido do Azure selecionando a opção
de “Configuração” e alternar a opção “Benefício Híbrido do Azure”
PowerShell
Converter VMs do Windows Server existentes para o Benefício Híbrido do Azure para Windows Server
$vm = Get-AzVM -ResourceGroup "rg-name" -Name "vm-name"
$vm.LicenseType = "Windows_Server"
Update-AzVM -ResourceGroupName rg-name -VM $vm
Converter VMs do Windows Server com o benefício pré-pago
$vm = Get-AzVM -ResourceGroup "rg-name" -Name "vm-name"

$vm.LicenseType = "None"
Update-AzVM -ResourceGroupName rg-name -VM $vm
CLI
Converter VMs do Windows Server existentes para o Benefício Híbrido do Azure para Windows Server
az vm update --resource-group myResourceGroup --name myVM --set licenseType=Windows_Server
Como verificar se sua VM está utilizando o benefício de licenciamento

Depois de implantar sua VM por meio do PowerShell, modelo do Gerenciador de Recursos ou Portal, verifique a
configuração nos métodos seguintes.
Portal
No portal de folha de VM, você pode ver a alternância para o Benefício Híbrido do Azure para Windows Server,
selecionando a guia "Configuração".
PowerShell
O exemplo a seguir mostra o tipo de licença para uma única VM
Get-AzVM -ResourceGroup "myResourceGroup" -Name "myVM"
Saída:
Type : Microsoft.Compute/virtualMachines
Location : westus
LicenseType : Windows_Server
Esta saída contrasta com a seguinte VM implantada sem licenciamento do Benefício Híbrido do Azure para
Windows Server:
Location : westus
LicenseType :
CLI
az vm get-instance-view -g MyResourceGroup -n MyVM --query "[?licenseType=='Windows_Server']" -o table
NOTE
A alteração do tipo de licença na VM não faz com que o sistema seja reinicializado e não causa interrupção no serviço.
Trata-se apenas de um sinalizador de licenciamento de metadados.
Listar todas as VMs com Benefício Híbrido do Azure para Windows
Server em uma assinatura
Para ver e contar todas as máquinas virtuais implantadas com o Benefício Híbrido do Azure para Windows
Server, execute o comando a seguir em sua assinatura:
Portal
Na folha de recursos de conjuntos de dimensionamento de máquina Virtual ou Máquina Virtual, você pode
exibir uma lista de todas as VMs e tipo de licenciamento, configurando a coluna da tabela para incluir o
"Benefício Híbrido do Azure". A configuração da VM pode ser "Habilitado", "Não habilitado" ou "Sem suporte".
PowerShell
$vms = Get-AzVM
$vms | ?{$_.LicenseType -like "Windows_Server"} | select ResourceGroupName, Name, LicenseType
CLI
az vm list --query "[?licenseType=='Windows_Server']" -o table
Implantar um Conjunto de Dimensionamento de Máquinas Virtuais

com o Benefício Híbrido do Azure para Windows Server
Nos modelos do Gerenciador de Recursos de seu conjunto de dimensionamento de máquinas virtuais, um
parâmetro adicional licenseType deve ser especificado dentro da sua propriedade VirtualMachineProfile. Você
pode fazer isso durante criar ou atualizar para seu conjunto de dimensionamento por meio do modelo ARM,
PowerShell, CLI do Azure ou REST.
O exemplo a seguir usa um modelo ARM com uma imagem do Windows Server 2016 Datacenter:
"virtualMachineProfile": {
"storageProfile": {
"osDisk": {
"createOption": "FromImage"
},
"imageReference": {
"sku": "2016-Datacenter",
"version": "latest"
}
},
"licenseType": "Windows_Server",
"osProfile": {
"computerNamePrefix": "[parameters('vmssName')]",
}
Você também pode aprender mais sobre como Modificar um conjunto de escala de máquinas virtuais para
outras maneiras de atualizar sua escala definida.
Próximas etapas
Leia mais sobre como economizar dinheiro com o benefício híbrido do Azure
Leia sobre as Perguntas frequentes sobre Benefício Híbrido do Azure
Leia mais sobre Orientação detalhada sobre licenciamento do Benefício Híbrido do Azure para Windows
Server
Saiba mais sobre como o Benefício Híbrido do Azure para Windows Server e o Azure Site Recovery tornam a
migração de aplicativos para o Azure ainda mais econômica
Saiba mais sobre o Windows 10 no Azure com Direitos de Hospedagem Multilocatário
Saiba mais sobre como usar modelos do Resource Manager
Como implantar o Windows 10 no Azure com
direitos de hospedagem multilocatário
Para clientes com Windows 10 Enterprise E3/E5 por usuário ou por Acesso de Área de Trabalho Virtual do
Windows por usuário (licenças de assinatura do usuário ou licenças complementares de assinatura do usuário),
os direitos de hospedagem multilocatário para Windows 10 permitem que você coloque suas licenças do
Windows 10 na nuvem e execute máquinas virtuais do Windows 10 no Azure sem necessidade de pagar por
outra licença. Os direitos de hospedagem multilocatário estão disponíveis somente para Windows 10 (versão
1703 ou posterior).
Para obter mais informações, consulte hospedagem multilocatário para Windows 10.
NOTE
Para usar o Windows 7, 8,1 e 10 imagens para desenvolvimento ou teste, consulte Windows Client no Azure para
cenários de desenvolvimento/teste
Para conhecer os benefícios de licenciamento do Windows Server, veja Benefícios do uso híbrido do Azure para
imagens do Windows Server.
Licenças de assinatura que se qualificam para direitos de hospedagem

multilocatário
Usando o centro de administração da Microsoft, você pode confirmar se uma licença com suporte do Windows
10 foi atribuída a um usuário.
IMPORTANT
Os usuários devem ter uma das licenças de assinatura abaixo para usar as imagens do Windows 10 no Azure. Se você não
tiver uma dessas licenças de assinatura, elas poderão ser adquiridas por meio de seu parceiro de serviço de nuvem ou
diretamente pela Microsoft.
Licenças de assinatura qualificadas:

Microsoft 365 E3/e5
Microsoft 365 F3
Microsoft 365 a3/a5
Windows 10 Enterprise E3/e5
Educação do Windows 10 a3/a5
Windows VDA E3/e5
Implantando a imagem do Windows 10 do Azure Marketplace

Para implantações de modelo do PowerShell, CLI e Azure Resource Manager, as imagens do Windows 10 podem
ser encontradas usando o PublisherName: MicrosoftWindowsDesktop e o Offer: Windows-10 . A atualização dos
criadores de versão do Windows 10 (1809) ou posterior tem suporte para direitos de hospedagem
multilocatário.
Get-AzVmImageSku -Location '$location' -PublisherName 'MicrosoftWindowsDesktop' -Offer 'Windows-10'
Skus Offer PublisherName Location

---- ----- ------------- --------
rs4-pro Windows-10 MicrosoftWindowsDesktop eastus
rs4-pron Windows-10 MicrosoftWindowsDesktop eastus
rs5-enterprise Windows-10 MicrosoftWindowsDesktop eastus
rs5-enterprisen Windows-10 MicrosoftWindowsDesktop eastus
rs5-pro Windows-10 MicrosoftWindowsDesktop eastus
rs5-pron Windows-10 MicrosoftWindowsDesktop eastus
Para obter mais informações sobre imagens disponíveis, consulte Localizar e usar imagens de VM do Azure
Marketplace com Azure PowerShell
Carregando o VHD do Windows 10 no Azure

Se você está carregando um VHD de 10 Windows generalizado, observe o que Windows 10 não tem uma conta
de administrador interno habilitada por padrão. Para habilitar a conta de administrador interno, inclua o
comando a seguir como parte da extensão do script personalizado.
Net user <username> /active:yes
O trecho do PowerShell a seguir é marcar todas as contas de administrador como ativas, incluindo o
administrador interno. Esse exemplo é útil se o nome de usuário da conta de administrador interno é
desconhecido.
$adminAccount = Get-WmiObject Win32_UserAccount -filter "LocalAccount=True" | ? {$_.SID -Like "S-1-5-21-*-

500"}
if($adminAccount.Disabled)
{
$adminAccount.Disabled = $false
$adminAccount.Put()
}
Para mais informações:

Como carregar um VHD para o Azure
Como preparar um VHD do Windows para carregar no Azure
Implantando o Windows 10 com direitos de hospedagem

multilocatário
Verifique se você instalou e configurou o Azure PowerShell mais recente. Depois de preparar o VHD, carregue-o
em sua conta de Armazenamento do Azure usando o cmdlet Add-AzVhd da seguinte maneira:
Add-AzVhd -ResourceGroupName "myResourceGroup" -LocalFilePath "C:\Path\To\myvhd.vhd" `

-Destination "https://mystorageaccount.blob.core.windows.net/vhds/myvhd.vhd"
Implante usando a implantação de modelo do Azure Resource Manager Dentro de seus modelos do
Resource Manager, um parâmetro adicional para licenseType pode ser especificado. Você pode ler mais sobre a
criação de modelos de Azure Resource Manager. Quando o VHD for carregado no Azure, edite o modelo do
Resource Manager para incluir o tipo de licença como parte do provedor de computação e implantar o modelo
como normal:
"properties": {
"licenseType": "Windows_Client",
"vmSize": "[variables('vmSize')]"
}
Implantar via PowerShell Ao implantar a VM do Windows Server por meio do PowerShell, você tem um
parâmetro adicional para -LicenseType . Depois de carregar o VHD no Azure, você cria uma VM usando
New-AzVM e especifica o tipo de licenciamento da seguinte maneira:
New-AzVM -ResourceGroupName "myResourceGroup" -Location "West US" -VM $vm -LicenseType "Windows_Client"
Verifique se que sua VM está utilizando o benefício de licenciamento

Depois de implantar sua VM por meio do método de implantação do PowerShell ou do Resource Manager,
verifique o tipo de licença com Get-AzVM da seguinte maneira:
Get-AzVM -ResourceGroup "myResourceGroup" -Name "myVM"
A saída é semelhante ao seguinte exemplo do Windows 10 com o tipo de licença correto:
Location : westus
LicenseType : Windows_Client
Esta saída contrasta com a seguinte VM implantada sem o licenciamento do Benefício de Uso Híbrido do Azure,
como uma VM implantada diretamente da Galeria do Azure:
Location : westus
LicenseType :
Informações adicionais sobre ingresso no Azure AD

O Azure provisiona todas as VMs do Windows com a conta de administrador interno, que não pode ser usada
para ingressar no AAD. Por exemplo, Configurações > Conta > Acesso Corporativo ou de Estudante >
+Conectar não funcionará. Você deve criar e fazer logon como uma segunda conta de administrador para
ingressar manualmente no Microsoft Azure Active Directory. Você também pode configurar o Azure AD usando
um pacote de provisionamento, use o link na seção próximas etapas para saber mais.
Próximas etapas
Em Configurando VDA para Windows 10, aprenda mais sobre o assunto
Saiba mais sobre Hospedagem multilocatário para Windows 10
Economize custos com reservas de host dedicadas
do Azure
Ao se comprometer com uma instância reservada de hosts dedicados do Azure, você pode economizar dinheiro.
O desconto de reserva é aplicado automaticamente ao número de hosts dedicados em execução que
correspondem ao escopo e aos atributos de reserva. Você não precisa atribuir uma reserva a um host dedicado
para obter os descontos. Uma compra de instância reservada abrange apenas a parte de computação do seu
uso e inclui os custos de licenciamento de software. Consulte a visão geral dos hosts dedicados do Azure para
máquinas virtuais.
Determine o SKU do host dedicado correto antes de comprar

Antes de comprar uma reserva, você deve determinar qual host dedicado é necessário. Uma SKU é definida para
um host dedicado que representa a série e o tipo da VM.
Comece passando os tamanhos com suporte para a máquina virtual do Windows ou para o Linux para
identificar a série de VMs.
Em seguida, verifique se há suporte para os hosts dedicados do Azure. A página de preços dos hosts dedicados
do Azure tem a lista completa de SKUs de hosts dedicados, suas informações de CPU e várias opções de preços
(incluindo instâncias reservadas).
Você pode encontrar várias SKUs que dão suporte a uma série de VMs (com tipos diferentes). Identifique a
melhor SKU comparando a capacidade do host (número de vCPUs). Observe que você poderá aplicar sua
reserva a várias SKUs de hosts dedicados que dão suporte à mesma série de VMs (por exemplo DSv3_Type1 e
DSv3_Type2), mas não em séries de VM diferentes (como DSv3 e ESv3).
Considerações sobre a restrição de compra

As instâncias reservadas estão disponíveis para os tamanhos de host mais dedicados, com algumas exceções.
Os descontos de reserva não se aplicam ao seguinte:
Nuvens : as reservas não estão disponíveis para compra nas regiões da Alemanha ou da China.
Cota insuficiente – uma reserva com escopo para uma única assinatura deve ter a cota vCPU
disponível na assinatura para a nova instância reservada. Por exemplo, se a assinatura de destino tiver
um limite de cota de 10 vCPUs para a série DSv3, você não poderá comprar uma reserva de hosts
dedicados que dão suporte a essa série. A verificação de cota para reservas inclui as VMs e os hosts
dedicados já implantados na assinatura. Você pode criar uma solicitação de aumento de cota para
resolver esse problema.
Restrições de capacidade -em raras circunstâncias, o Azure limita a compra de novas reservas para o
subconjunto de SKUs de host dedicado, devido à baixa capacidade em uma região.
Comprar uma reserva

Você pode comprar uma instância reservada de uma instância de host dedicada do Azure no portal do Azure.
Pague pela reserva antecipadamente ou com pagamentos mensais. Esses requisitos se aplicam à compra de
uma instância de host dedicada reservada:
Você precisa ter a função Proprietário em, no mínimo, uma assinatura do EA ou uma assinatura com uma
taxa paga conforme o uso.
Para as assinaturas do EA, a opção Adicionar Instâncias Reser vadas precisa estar habilitada no Portal
do EA. Ou, se essa configuração estiver desabilitada, você precisará ser um Administrador de EA da
assinatura.
Para o programa do CSP (Provedor de Solução na Nuvem) somente os agentes administradores ou
agentes de vendas podem comprar reservas.
Para comprar uma instância:
1. Entre no portal do Azure.
2. Selecione Todos os ser viços > Reser vas .
3. Selecione Adicionar para comprar uma nova reserva e clique em hosts dedicados .
4. Preencha os campos obrigatórios. Executar instâncias de hosts dedicadas que correspondem aos
atributos que você selecionar qualificar para obter o desconto de reserva. O número real de suas
instâncias de host dedicadas que obtêm o desconto depende do escopo e da quantidade selecionada.
Se você tiver um contrato EA, poderá usar a opção Adicionar mais para adicionar mais instâncias
rapidamente. A opção não está disponível para outros tipos de assinaturas.
CAMPO DESC RIÇ Ã O
Subscription A assinatura usada para pagar pela reserva. Os custos da

reserva são cobrados segundo a forma de pagamento da
assinatura. O tipo de assinatura deve ser um contrato
empresarial (números da oferta: MS-AZR-0017P ou MS-
AZR-0148P) ou Contrato de Cliente da Microsoft ou ainda
uma assinatura individual com tarifas pagas conforme o uso
(números de oferta: MS-AZR-0003P ou MS-AZR-0023P).
Os preços são deduzidos do saldo do Pagamento antecipado
do Azure (anteriormente conhecido como compromisso
monetário), se disponível, ou cobrados como excedente. Para
uma assinatura com taxas pagas conforme o uso, as
cobranças são feitas na forma de pagamento de cartão de
crédito ou de fatura na assinatura.
Escopo O escopo de assinatura pode abranger uma ou várias

assinaturas (escopo compartilhado). Se você selecionar:
Região A região do Azure que é coberta pela reserva.
Tamanho de host dedicado O tamanho das instâncias de host dedicadas.
Termo Um ano ou três anos.
Quantidade O número de instâncias sendo compradas na reserva. A

quantidade é o número de instâncias de host dedicadas em
execução que podem obter o desconto de cobrança.
Escopo de grupo de recursos único — aplica o desconto de reserva apenas aos recursos
correspondentes no grupo de recursos selecionado.
Escopo de assinatura única — aplica o desconto de reserva apenas aos recursos correspondentes na
assinatura selecionada.
Escopo compar tilhado — aplica o desconto de reserva aos recursos correspondentes em assinaturas
qualificadas que estão no contexto de cobrança. Para clientes do EA, o contexto de cobrança é o registro.
Para assinaturas individuais com tarifas pagas conforme o uso, o escopo do orçamento são todas as
assinaturas qualificadas criadas pelo administrador da conta.
Dados de uso e utilização de reserva

Seus dados de uso têm um preço efetivo de zero para o uso, que obtém um desconto de reserva. Você pode ver
qual instância de VM recebeu o desconto de reserva para cada reserva.
Para obter mais informações sobre como os descontos de reserva aparecem nos dados de uso, consulte
entender o uso de reserva do Azure para o registro de sua empresa se você for um cliente do ea. Se você tiver
uma assinatura individual, consulte entender o uso de reserva do Azure para sua assinatura paga conforme o
uso.
Alterar uma reserva após a compra

É possível realizar os seguintes tipos de alterações em uma reserva após a compra:
Atualizar o escopo de reserva
Flexibilidade de tamanho de instância (se aplicável)
Propriedade
Você também pode dividir uma reserva em partes menores e mesclar reservas já divididas. Nenhuma das
alterações causa uma nova transação comercial ou alterar a data de término da reserva.
Você não pode fazer os seguintes tipos de alterações após a compra, diretamente:
Uma região de reserva existente
SKU
Quantidade
Duration
No entanto, você pode trocar uma reserva se desejar fazer alterações.
Cancelar, trocar ou reembolsar reservas

É possível cancelar, trocar ou reembolsar reservas com determinadas limitações. Para saber mais, confira Trocas
e reembolsos via autoatendimento para Reservas do Azure.
Precisa de ajuda? Entre em contato conosco.

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte.
Próximas etapas
Para aprender a gerenciar uma reserva, confira Gerenciar Reservas do Azure.
Para saber mais sobre as Reservas do Azure, consulte os seguintes artigos:
O que são Reservas do Azure?
Usando Hosts Dedicados do Azure
Preço de Hosts Dedicados
Gerenciar Reservas no Azure
Entender como o desconto de reserva é aplicado
Noções básicas sobre o uso de reserva para uma assinatura com taxas pagas conforme o uso
Entender o uso de reserva para seu registro de empresa
Custos de software do Windows não estão incluídos nas reservas
Reservas do Azure no programa de CSP (Provedor de Soluções na Nuvem) do Partner Center
As Reservas do Azure ajudam você a economizar dinheiro se comprometendo com planos de um ou de três
anos para vários produtos. O compromisso permite que você obtenha um desconto nos recursos que usar. As
reservas podem reduzir significativamente seus custos com recursos, podendo chegar a 72% com relação aos
preços pagos conforme o uso. As reservas fornecem um desconto de cobrança e não afetam o estado de
runtime dos recursos. Após você comprar uma reserva, o desconto se aplica automaticamente aos recursos
correspondentes.
Você pode pagar por uma reserva de forma antecipada ou mensal. O custo total das reservas antecipadas e
mensais é o mesmo e você não paga nenhuma taxa adicional quando opta por pagar mensalmente. O
pagamento mensal está disponível para reservas do Azure, e não para produtos de terceiros.
Você pode comprar uma instância reservada no portal do Azure.
Por que comprar uma reserva?

Se você tiver um uso de recursos consistente que dá suporte a reservas, a compra de uma reserva lhe oferecerá
a opção de reduzir os custos. Por exemplo, quando executa continuamente instâncias de um serviço sem a
reserva, você é cobrado com base em taxas pagas conforme o uso. Quando compra uma reserva, você obtém
imediatamente o desconto de reserva. Os recursos não serão mais cobrados com base nas taxas pagas
conforme o uso.
Como o desconto de reserva é aplicado

Após a compra, o desconto de reserva se aplica automaticamente para o uso de recursos que correspondem
aos atributos que você seleciona ao comprar a reserva. Os atributos incluem o SKU, as regiões (quando
aplicável) e o escopo. O escopo de uma reserva seleciona o local a que a economia da reserva se aplica.
Para obter mais informações sobre como o desconto é aplicado, confira Aplicação do desconto de instância
reservada.
Para obter mais informações sobre como funciona o escopo de reserva, confira Reservas de escopo.
Determinar o que comprar

Todas as reservas, exceto as do Azure Databricks, são aplicadas a cada hora. Considere as compras de reserva
com base no seu uso de base consistente. Você pode determinar qual reserva comprar analisando seus dados
de uso ou usando recomendações de reserva. As recomendações estão disponíveis em:
Assistente do Azure (somente VMs)
Experiência de compra de reserva no portal do Azure
Aplicativo Power BI do Gerenciamento de Custos
APIs
Para obter mais informações, confiraDeterminar qual reserva comprar
Comprar uma reserva

Você pode comprar reservas por meio do portal do Azure, das APIs, do PowerShell e da CLI.
Vá para o portal do Azure para fazer uma compra.
Para obter mais informações, confiraComprar uma reserva.
Como uma reserva é cobrada?

A reserva é cobrada no método de pagamento associado à assinatura. O custo de reserva é deduzido do saldo
do seu Pagamento antecipado do Azure (anteriormente conhecido como compromisso monetário), se
disponível. Quando o saldo do Pagamento antecipado do Azure não cobrir o custo da reserva, você será
cobrado pelo excedente. Se você tiver uma assinatura de um plano individual com tarifas pagas conforme o uso,
o cartão de crédito que você tem em sua conta será cobrado imediatamente para as compras antecipadas. Os
pagamentos mensais aparecem em sua fatura e seu cartão de crédito é cobrado mensalmente. Quando for
cobrado por fatura, você verá os encargos na sua próxima fatura.
Quem pode gerenciar uma reserva por padrão

Por padrão, os seguintes usuários podem ver e gerenciar reservas:
A pessoa que compra uma reserva e o administrador da conta da assinatura para cobrança usada para
comprar a reserva são adicionadas ao pedido de reserva.
Administradores de cobrança do Contrato Enterprise e do Contrato de Cliente da Microsoft.
Para permitir que outras pessoas gerenciem reservas, confira Gerenciar reservas para recursos do Azure.
Obter detalhes e a utilização da reserva após a compra

Se você tiver permissão para exibir a reserva, poderá ver a reserva e o uso dela no portal do Azure. Você pode
obter os dados usando APIs também.
Para obter mais informações sobre como ver reservas no portal do Azure, confiraExibir reservas no portal do
Azure
Gerenciar reservas após a compra

Após comprar uma reserva do Azure, você poderá atualizar o escopo para aplicar a reserva a uma assinatura
diferente, alterar quem pode gerenciar a reserva, dividir uma reserva em partes menores ou alterar a
flexibilidade de tamanho da instância.
Para obter mais informações, confiraGerenciar reservas para recursos do Azure
Flexibilidade com reservas do Azure

As Reservas do Azure fornecem flexibilidade para ajudar a atender às suas necessidades em constante evolução.
Você pode trocar uma reserva por outra do mesmo tipo. Você também poderá pedir reembolso de uma reserva
de até US$ 50.000 em uma janela de 12 meses se não precisar mais dela. O limite máximo do reembolso se
aplica a todas as reservas no escopo do seu contrato com a Microsoft.
Para obter mais informações, confira Trocas e reembolsos via autoatendimento para Reservas do Azure
Preços cobertos pela reserva

Instância de Máquina Vir tual Reser vada – uma reserva abrange apenas os custos de computação de
máquina virtual e de serviços de nuvem. Não cobre encargos adicionais de software, Windows, rede nem
armazenamento.
Capacidade reser vada de Armazenamento do Azure : uma reserva abrange a capacidade de contas de
armazenamento padrão para armazenamento de blobs ou do Azure Data Lake Storage Gen2. A reserva não
abrange a largura de banda nem as taxas de transação.
Capacidade reser vada do Azure Cosmos DB – cobre a taxa de transferência provisionada para seus
recursos. Ela não cobre encargos de armazenamento e rede.
vCore reser vado do Banco de Dados SQL – abrange a Instância Gerenciada de SQL e o Pool Elástico de
Banco de Dados SQL/banco de dados individual. Apenas os custos de computação são incluídos em uma
reserva. A licença do SQL é cobrada separadamente.
Azure Synapse Analytics – uma reserva abrange o uso da cDWU. Ela não abrange os encargos de
armazenamento nem de rede associados ao uso do Azure Synapse Analytics.
Azure Databricks – uma reserva abrange apenas o uso de DBU. Outros encargos, como computação,
armazenamento e rede, são aplicados separadamente.
Imposto de selo do Ser viço de Aplicativo – uma reserva cobre o uso do imposto de selo. Ela não se
aplica a funções de trabalho, de forma que todos os outros recursos associados ao selo são cobrados
separadamente.
Banco de Dados do Azure para MySQL – apenas os custos de computação são incluídos com uma
reserva. Uma reserva não cobre custos de software, rede ou armazenamento associados à instância do
servidor de Banco de Dados MySQL.
Banco de Dados do Azure para PostgreSQL – apenas os custos de computação são incluídos com uma
reserva. Uma reserva não cobre custos de software, rede ou armazenamento associados à instância dos
servidores de Banco de Dados PostgreSQL.
Banco de Dados do Azure para MariaDB – apenas os custos de computação são incluídos com uma
reserva. Uma reserva não cobre custos de software, rede ou armazenamento associados à instância do
servidor de banco de dados MariaDB.
Azure Data Explorer – uma reserva abrange os encargos de marcação. Uma reserva não se aplica aos
encargos de computação, rede ou armazenamento associados aos clusters.
Cache do Azure para Redis : apenas os custos de computação são incluídos com uma reserva. Uma
reserva não abrange os preços de rede ou armazenamento associados às instâncias de Cache Redis.
Host Dedicado do Azure – Somente os custos de computação estão incluídos no Host Dedicado.
Reser vas do Armazenamento em Disco do Azure – uma reserva cobre apenas SSDs Premium de
tamanho P30 ou superior. Ela não cobre nenhum outro tipo de disco ou tamanhos menores que P30.
Planos de software:
SUSE Linux – uma reserva abrange os custos do plano de software. Os descontos aplicam-se apenas aos
medidores do SUSE e não ao uso da máquina virtual.
Planos do Red Hat – uma reserva abrange os custos do plano de software. Os descontos aplicam-se
apenas aos medidores Red Hat e não ao uso da máquina virtual.
Solução VMware da CloudSimple no Azure – uma reserva abrange os nós VMWare da CloudSimple. Os
custos de software adicionais ainda se aplicam.
Red Hat OpenShift no Azure – uma reserva se aplica aos custos do OpenShift, mas não aos custos de
infraestrutura do Azure.
Para máquinas virtuais do Windows e o Banco de Dados SQL, o desconto de reserva não se aplica aos custos de
software. Você pode cobrir os custos de licenciamento com o Benefício Híbrido do Azure.
Precisa de ajuda? Entre em contato conosco.

Caso tenha dúvidas ou precise de ajuda, crie uma solicitação de suporte.
Próximas etapas
Saiba mais sobre as Reservas do Azure com os seguintes artigos:
Gerenciar Reservas do Azure
Noções básicas sobre o uso de reserva para sua assinatura com taxas pagas conforme o uso
Entender o uso de reserva para seu registro de empresa
Custos de software do Windows não estão incluídos nas reservas
Reservas do Azure no programa de CSP (Provedor de Soluções na Nuvem) do Partner Center
Saiba mais sobre reservas para planos de serviço:
Máquinas virtuais com Instâncias de VM Reservadas do Azure
Recursos do Azure Cosmos DB com capacidade reservada do Azure Cosmos DB
Recursos de computação do Banco de Dados SQL com capacidade reservada do Banco de Dados SQL
do Azure
Recursos do Cache do Azure para Redis com capacidade reservada do Cache do Azure para Redis
Saiba mais sobre as reservas para planos de software:
Planos de software Red Hat das Reservas do Azure
Planos de software SUSE das Reservas do Azure
Flexibilidade de tamanho de máquina virtual com
Instâncias de VM Reservadas
Ao comprar uma instância de VM reservada, você pode optar por otimizar a flexibilidade de tamanho da
instância ou a prioridade da capacidade. Para obter mais informações sobre como configurar ou alterar a
configuração de otimização para instâncias de VM reservadas, consulte alterar a configuração de otimização
para instâncias de VM reservadas.
Com uma instância de máquina virtual reservada que é otimizada para flexibilidade de tamanho de instância, a
reserva que você compra pode se aplicar a tamanhos de máquinas virtuais (VMs) no mesmo grupo de
flexibilidade de tamanho de instância. Por exemplo, se você comprar uma reserva para um tamanho de VM
listado na série DSv2, como Standard_DS3_v2, o desconto de reserva poderá ser aplicado aos outros tamanhos
listados no mesmo grupo de flexibilidade de tamanho de instância:
Standard_DS1_v2
Standard_DS2_v2
Standard_DS3_v2
Standard_DS4_v2
Mas esse desconto de reserva não se aplica a tamanhos de VMs que estão listados em diferentes grupos de
flexibilidade de tamanho de instância, como SKUs na série DSv2 de memória alta: Standard_DS11_v2,
Standard_DS12_v2 e assim por diante.
Dentro do grupo de flexibilidade do tamanho da instância, o número de VMs a que o desconto de reserva se
aplica depende do tamanho da VM que você escolher ao comprar uma reserva. Isso também depende das VMs
que você tem em execução. A coluna ratio compara a superfície relativa para cada tamanho de VM nesse grupo
de flexibilidade de tamanho de instância. Use o valor da proporção para calcular como o desconto de reserva se
aplica às VMs você tem em execução.
Exemplos
Os exemplos a seguir usam os tamanhos e proporções na tabela da série DSv2.
Você compra uma instância de VM reservada com o tamanho Standard_DS4_v2 em que a proporção ou o
volume relativo em comparação comparada os outros tamanhos dessa série é 8.
Cenário 1: executar oito VMs dimensionadas de acordo com Standard_DS1_v2 com uma proporção de 1. O
desconto de reserva se aplica a todas essas oito VMs.
Cenário 2: executar duas VMs dimensionadas de acordo com Standard_DS2_v2 com uma proporção de 2
cada. Além disso, executar uma VM dimensionada de acordo com Standard_DS3_v2 com uma proporção de
4. O volume total é de 2 + 2 + 4 = 8. Portanto, o desconto de reserva se aplica a todas essas três VMs.
Cenário 3: executar uma Standard_DS5_v2 com uma proporção de 16. O desconto de reserva se aplica à
metade do custo de computação da VM.
As seções a seguir mostram quais tamanhos estão no mesmo grupo de série de tamanho quando você compra
uma instância de VM reservada otimizada para a flexibilidade de tamanho da instância.
Taxa de flexibilidade de tamanho de instância para VMs

O CSV abaixo tem os grupos de flexibilidade de tamanho de instância, ArmSkuName e as proporções.
Taxas de flexibilidade de tamanho de instância
Manteremos a URL do arquivo e o esquema fixo para que você possa consumir esse arquivo
programaticamente. Os dados também estarão disponíveis por meio da API em breve.
Próximas etapas
Para obter mais informações, consulte o que são as reservas do Azure.
Distribuições do Linux endossadas no Azure
Os parceiros fornecem imagens do Linux no Azure Marketplace. A Microsoft trabalha com várias comunidades
do Linux para adicionar ainda mais tipos à lista de distribuição endossada. Para distribuições que não estão
disponíveis no Marketplace, você sempre pode trazer seu próprio Linux seguindo as diretrizes em criar e
carregar um disco rígido virtual que contém o sistema operacional Linux.
Distribuições e versões com suporte

A tabela a seguir lista as distribuições e versões do Linux com suporte no Azure. Para obter mais informações,
consulte suporte para imagens do Linux no Microsoft Azure.
Os drivers LIS (Serviços de Integração do Linux) para Hyper-V e Azure são módulos de kernel que a Microsoft
contribui diretamente para o kernel upstream do Linux. Alguns drivers LIS são incorporados no kernel de
distribuição por padrão. Distribuições mais antigas que se baseiam no Red Hat Enterprise (RHEL)/CentOS estão
disponíveis como um download separado em Serviços de integração do Linux versão 4.2 para o Hyper-V e
Microsoft Azure. Para obter mais informações, consulte requisitos do kernel do Linux.
O agente Linux do Azure já está pré-instalado nas imagens do Azure Marketplace e normalmente está
disponível no repositório de pacotes da distribuição. O código-fonte pode ser encontrado no GitHub.
DIST RIB UIÇ Ã O VERSÃ O DRIVERS A GEN T E
CentOS por software de CentOS 6. x, 7. x, 8. x CentOS 6,3: download do Pacote: no repositório em

Wave não autorizado LIS "WALinuxAgent"
CentOS 6.4 +: no Código-fonte: GitHub
kernel
CoreOS Não está mais disponível

CoreOS agora é o fim
da vida de 26 de maio
de 2020.
Debian da Credativ 8. x, 9. x, 10. x No kernel Pacote: no repositório, em

"waagent"
Código-fonte: GitHub
Flatcar contêiner Linux por Pro, estável, beta No kernel o wa-Linux-Agent já está
Kinvolk instalado
em/usr/share/OEM/bin/waa
gent
Oracle Linux pela Oracle 6.x, 7.x, 8.x No kernel Pacote: no repositório, em
"WALinuxAgent"
Red Hat Enterprise Linux 6.x, 7.x, 8.x No kernel Pacote: no repositório, em
por Red Hat "WALinuxAgent"
DIST RIB UIÇ Ã O VERSÃ O DRIVERS A GEN T E
SUSE Linux Enterprise pelo SLES/SLES para SAP 11. x, No kernel Pacote:
SUSE 12. x, 15. x para 11, no repositório
Ciclo de vida da imagem de Cloud:Tools
nuvem pública SUSE para 12, incluído no
módulo "Public Cloud"
em "python-azure-
agent"
openSUSE por SUSE openSUSE Leap 15.x No kernel Pacote: no repositório

Cloud:Tools em "python-
azure-agent"
Ubuntu por Canonical Servidor Ubuntu e pro. 16. No kernel Pacote: no repositório, em
x, 18. x, 20. x "WALinuxAgent"
Informações sobre o Código-fonte: GitHub
suporte estendido para
Ubuntu 12, 4 e 14, 4
podem ser encontradas
aqui: manutenção de
segurança estendida do
Ubuntu.
Cadência da atualização da imagem

O Azure exige que os editores das distribuições do Linux endossadas atualizem regularmente suas imagens no
Azure Marketplace com os patches e correções de segurança mais recentes, a uma cadência trimestral ou mais
rápida. As imagens atualizadas no Marketplace estão disponíveis automaticamente para os clientes como novas
versões de uma SKU de imagem. Mais informações sobre como encontrar imagens do Linux: Localizar imagens
de VM do Linux no Azure Marketplace.
Kernels ajustados para o Azure

O Azure trabalha em conjunto com várias distribuições do Linux endossadas para otimizar as imagens
publicadas no Azure Marketplace. Um aspecto dessa colaboração é o desenvolvimento de kernels do Linux
"ajustados" que são otimizados para a plataforma Azure e fornecidos como componentes totalmente
suportados da distribuição do Linux. Os kernels Azure-Tuned incorporam novos recursos e aprimoramentos de
desempenho e em uma cadência mais rápida (normalmente trimestral) em comparação com os kernels padrão
ou genéricos que estão disponíveis na distribuição.
Na maioria dos casos, você encontrará esses kernels pré-instalados nas imagens padrão no Azure Marketplace
para que os clientes obtenham imediatamente os benefícios desses kernels otimizados. Mais informações sobre
esses Azure-Tuned kernels podem ser encontradas nos links a seguir:
CentOS Azure-Tuned kernel – disponível por meio de SIG de virtualização CentOS
Kernel de nuvem Debian-disponível com a imagem "backports" do Debian 10 e Debian 9 no Azure
Kernel SLES Azure-Tuned
Kernel do Ubuntu Azure-Tuned
Flatcar contêiner Linux pro
Parceiros
CoreOS
O CoreOS está agendado para ser encerrado em 26 de maio de 2020. A Microsoft tem dois (2) canais de
migração para usuários do CoreOS.
Flatcar by Kinvolk (consulte a entrada "flatcar contêiner Linux por Kinvolk".)
Sistema operacional Fedora Core (os clientes devem carregar suas próprias imagens. Aqui está a
documentação de migração).
credativ
https://www.credativ.de/en/portfolio/support/open-source-support-center/
o credativ é uma empresa independente de consultoria e serviços que é especializada no desenvolvimento e na
implementação de soluções profissionais usando software gratuito. Como especialistas de código-fonte aberto,
a credativ tem reconhecimento internacional com muitos departamentos de ti que usam o seu suporte. Em
conjunto com a Microsoft, o credativ está preparando imagens Debian. As imagens são especialmente
projetadas para serem executadas no Azure e podem ser facilmente gerenciadas por meio da plataforma. o
credativ também dará suporte à manutenção e à atualização de longo prazo das imagens Debian para o Azure
por meio de seus centros de suporte de software livre.
Kinvolk
https://www.kinvolk.io/flatcar-container-linux/
Kinvolk é a empresa por trás do contêiner flatcar do Linux, continuando a visão original do CoreOS para uma
base mínima, imutável e de atualização automática para aplicativos em contêineres. Como um distribuição
mínimo, o flatcar contém apenas os pacotes necessários para a implantação de contêineres. Seu sistema de
arquivos imutável garante consistência e segurança, enquanto seus recursos de atualização automática,
permitem que você esteja sempre atualizado com as correções de segurança mais recentes.
O flatcar contêiner Linux é submetido a backup pela equipe global do Kinvolk de especialistas em tecnologia de
contêiner e Linux que oferece uma assinatura de suporte comercial opcional que inclui resposta 24x7,
segurança e alertas técnicos e imagens exclusivas otimizadas para o Azure, incluindo um canal de suporte a
longo prazo.
Oracle
https://www.oracle.com/technetwork/topics/cloud/faq-1963009.html
A estratégia da Oracle é oferecer um amplo portfólio de soluções para nuvens públicas e privadas. A estratégia
oferece aos clientes a opção e a flexibilidade em como implantar o software da Oracle nas nuvens da Oracle e
em outras nuvens. A parceria da Oracle com a Microsoft permite que os clientes implantem software Oracle em
nuvens públicas e privadas da Microsoft com a confiança da certificação e do suporte da Oracle. O compromisso
e o investimento da Oracle em soluções de nuvem pública e privada da Oracle estão inalterados.
Red Hat
https://www.redhat.com/en/partners/strategic-alliance/microsoft
O principal provedor de soluções de software livre do mundo, a Red Hat ajuda mais de 90% das empresas da
Fortune 500 a resolverem desafios comerciais, a alinhar suas estratégias de ti e de negócios e a se preparar para
o futuro da tecnologia. A Red Hat consegue isso fornecendo soluções seguras por meio de um modelo de
negócios aberto e um modelo de assinatura acessível e previsível.
SUSE
https://www.suse.com/suse-linux-enterprise-server-on-azure
O SUSE Linux Enterprise Server no Azure é uma plataforma testada que fornece confiabilidade e segurança
superiores para a computação em nuvem. A plataforma Linux versátil do SUSE se integra perfeitamente aos
serviços de nuvem do Azure para oferecer um ambiente de nuvem facilmente gerenciável. Com mais de 9.200
aplicativos certificados de mais de 1.800 fornecedores de software independentes para SUSE Linux Enterprise
Server, o SUSE garante que as cargas de trabalho em execução compatíveis no data center podem ser
implantadas com segurança no Azure.
Canônico
https://www.ubuntu.com/cloud/azure
O controle aberto da comunidade e a engenharia da Canonical impulsionam o sucesso do Ubuntu no cliente, no
servidor e na computação em nuvem, que inclui serviços de nuvem pessoais para os consumidores. A visão do
Canonical de uma plataforma unificada e gratuita no Ubuntu, do telefone à nuvem, fornece uma família de
interfaces coerentes para o telefone, tablet, TV e área de trabalho. Essa visão torna Ubuntu a primeira opção
para instituições diversificadas de provedores de nuvem pública para fabricantes de eletrônicos para os
consumidores e um favorito entre especialistas em tecnologias individuais.
Com desenvolvedores e centros de engenharia no mundo inteiro, a Canonical está posicionada exclusivamente
para fazer parceria com fabricantes de hardware, provedores de conteúdo e desenvolvedores de software para
oferecer soluções de Ubuntu no mercado para PCs, servidores e dispositivos portáteis.
Criar uma máquina virtual Linux completa com a
CLI do Azure
Para criar rapidamente uma VM (máquina virtual) no Azure, você pode usar um único comando da CLI do Azure
que usa valores padrão para criar quaisquer recursos de suporte necessários. Recursos como uma rede virtual,
um endereço IP público e regras de grupo de segurança de rede são criados automaticamente. Para obter mais
controle de seu ambiente no uso em produção, você pode criar esses recursos antecipadamente e depois
adicionar suas VMs a eles. Este artigo orienta você sobre como criar uma VM e cada um dos recursos de
suporte, um por um.
Certifique-se de que você instalou a versão mais recente da CLI do Azure e entrou em uma conta do Azure com
az login.
Nos exemplos a seguir, substitua os nomes de parâmetro de exemplo com seus próprios valores. Os nomes de
parâmetro de exemplo incluem myResourceGroup, myVnet e myVM.

gerenciados. Um grupo de recursos deve ser criado antes de uma máquina virtual e de recursos de rede virtual
de suporte. Crie o grupo de recursos com AZ Group Create. O exemplo a seguir cria um grupo de recursos
chamado myResourceGroup na localização eastus:
Por padrão, a saída de comandos da CLI do Azure é em JSON (JavaScript Object Notation). Para alterar a saída
padrão para uma lista ou tabela, por exemplo, use az configure --output. Você também pode adicionar
--output a qualquer comando para realizar uma alteração uma única vez no formato da saída. O exemplo a
seguir mostra a saída JSON do comando az group create :
{
"id": "/subscriptions/guid/resourceGroups/myResourceGroup",
"name": "myResourceGroup",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
}

Em seguida, você cria uma rede virtual no Azure e uma sub-rede na qual você possa criar suas VMs. Use az
network vnet create para criar uma rede virtual denominada myVnet com o prefixo de endereço 192.168.0.0/16.
Você também adiciona uma sub-rede chamada mySubnet com o prefixo de endereço 192.168.1.0/24:
--name myVnet \
--address-prefix 192.168.0.0/16 \
--subnet-name mySubnet \
A saída mostra que a sub-rede foi criada logicamente dentro da rede virtual:
{
"addressSpace": {
"192.168.0.0/16"
]
},
"dhcpOptions": {
"dnsServers": []
},
"etag": "W/\"e95496fc-f417-426e-a4d8-c9e4d27fc2ee\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet",
"name": "myVnet",
"resourceGroup": "myResourceGroup",
"resourceGuid": "ed62fd03-e9de-430b-84df-8a3b87cacdbb",
"subnets": [
{
"addressPrefix": "192.168.1.0/24",
"etag": "W/\"e95496fc-f417-426e-a4d8-c9e4d27fc2ee\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subne
ts/mySubnet",
"ipConfigurations": null,
"name": "mySubnet",
"networkSecurityGroup": null,
"resourceNavigationLinks": null,
"routeTable": null
}
],
"tags": {},
"virtualNetworkPeerings": null
}

Agora, criaremos um endereço IP público com az network public-ip create. Um endereço IP público permite que
você se conecte a suas VMs da Internet. Como o endereço padrão é dinâmico, crie uma entrada DNS nomeada
com o parâmetro --domain-name-label . O exemplo a seguir cria um IP público chamado myPublicIP com o
nome DNS de mypublicdns. Já que o nome DNS deve ser exclusivo, forneça seu próprio nome DNS exclusivo:

--name myPublicIP \
--dns-name mypublicdns
Saída:
{
"publicIp": {
"dnsSettings": {
"domainNameLabel": "mypublicdns",
"fqdn": "mypublicdns.eastus.cloudapp.azure.com",
"reverseFqdn": null
},
"etag": "W/\"2632aa72-3d2d-4529-b38e-b622b4202925\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/publicIPAddresses/myPublicIP
",
"idleTimeoutInMinutes": 4,
"ipAddress": null,
"ipConfiguration": null,
"name": "myPublicIP",
"publicIpAddressVersion": "IPv4",
"resourceGuid": "4c65de38-71f5-4684-be10-75e605b3e41f",
"tags": null,
"type": "Microsoft.Network/publicIPAddresses"
}
}
Criar um grupo de segurança de rede

Para controlar o fluxo de entrada e saída de tráfego de suas VMs, aplique um grupo de segurança de rede a um
NIC ou sub-rede virtual. O exemplo a seguir usa az network nsg create para criar um grupo de segurança de
rede chamado myNetworkSecurityGroup:

Defina regras que permitam ou neguem o tráfego específico. Para permitir conexões de entrada na porta 22
(para habilitar o acesso ao SSH), crie uma regra de entrada com az network nsg rule create. O exemplo a seguir
cria uma regra chamada myNetworkSecurityGroupRuleSSH:

--name myNetworkSecurityGroupRuleSSH \
--protocol tcp \
--priority 1000 \
--destination-port-range 22 \
--access allow
Para permitir conexões de entrada na porta 80 (para tráfego da Web), adicione outra regra de grupo de
segurança de rede. O exemplo a seguir cria uma regra chamada myNetworkSecurityGroupRuleHTTP:
--name myNetworkSecurityGroupRuleWeb \
--protocol tcp \
--priority 1001 \
--access allow
Examine o grupo de segurança de rede e as regras com az network nsg show:
az network nsg show --resource-group myResourceGroup --name myNetworkSecurityGroup
Saída:
{
"defaultSecurityRules": [
{
"access": "Allow",
"description": "Allow inbound traffic from all VMs in VNET",
"destinationAddressPrefix": "VirtualNetwork",
"destinationPortRange": "*",
"etag": "W/\"3371b313-ea9f-4687-a336-a8ebdfd80523\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup/defaultSecurityRules/AllowVnetInBound",
"name": "AllowVnetInBound",
"priority": 65000,
"protocol": "*",
"sourceAddressPrefix": "VirtualNetwork",
"sourcePortRange": "*"
},
{
"access": "Allow",
"description": "Allow inbound traffic from azure load balancer",
"id":
orkSecurityGroup/defaultSecurityRules/AllowAzureLoadBalancerInBou",
"name": "AllowAzureLoadBalancerInBound",
"priority": 65001,
"protocol": "*",
"sourceAddressPrefix": "AzureLoadBalancer",
},
{
"access": "Deny",
"description": "Deny all inbound traffic",
"id":
orkSecurityGroup/defaultSecurityRules/DenyAllInBound",
"name": "DenyAllInBound",
"priority": 65500,
"priority": 65500,
"protocol": "*",
},
{
"access": "Allow",
"description": "Allow outbound traffic from all VMs to all VMs in VNET",
"destinationAddressPrefix": "VirtualNetwork",
"direction": "Outbound",
"id":
orkSecurityGroup/defaultSecurityRules/AllowVnetOutBound",
"name": "AllowVnetOutBound",
"priority": 65000,
"protocol": "*",
"sourceAddressPrefix": "VirtualNetwork",
},
{
"access": "Allow",
"description": "Allow outbound traffic from all VMs to Internet",
"destinationAddressPrefix": "Internet",
"id":
orkSecurityGroup/defaultSecurityRules/AllowInternetOutBound",
"name": "AllowInternetOutBound",
"priority": 65001,
"protocol": "*",
},
{
"access": "Deny",
"description": "Deny all outbound traffic",
"id":
orkSecurityGroup/defaultSecurityRules/DenyAllOutBound",
"name": "DenyAllOutBound",
"priority": 65500,
"protocol": "*",
}
],
"id":
orkSecurityGroup",
"name": "myNetworkSecurityGroup",
"networkInterfaces": null,
"resourceGuid": "47a9964e-23a3-438a-a726-8d60ebbb1c3c",
"securityRules": [
{
"access": "Allow",
"description": null,
"etag": "W/\"9e344b60-0daa-40a6-84f9-0ebbe4a4b640\"",
"id":
orkSecurityGroup/securityRules/myNetworkSecurityGroupRuleSSH",
"name": "myNetworkSecurityGroupRuleSSH",
"priority": 1000,
"protocol": "Tcp",
},
{
"access": "Allow",
"etag": "W/\"9e344b60-0daa-40a6-84f9-0ebbe4a4b640\"",
"id":
orkSecurityGroup/securityRules/myNetworkSecurityGroupRuleWeb",
"name": "myNetworkSecurityGroupRuleWeb",
"priority": 1001,
"protocol": "Tcp",
}
],
"subnets": null,
"tags": null,
"type": "Microsoft.Network/networkSecurityGroups"
}
Criar um adaptador de rede virtual

Os adaptadores de rede virtual estão disponíveis por meio de programação porque você pode aplicar regras ao
seu uso. Dependendo do tamanho da VM, você pode anexar várias NICs virtuais a uma VM. No comando az
network nic create a seguir, você cria um adaptador de rede nomeado myNic e associa-o ao seu grupo de
segurança de rede. O endereço IP público myPublicIP também é associado ao adaptador de rede virtual.

--name myNic \
--subnet mySubnet \
--public-ip-address myPublicIP \
--network-security-group myNetworkSecurityGroup
Saída:
{
{
"NewNIC": {
"dnsSettings": {
"appliedDnsServers": [],
"dnsServers": [],
"internalDnsNameLabel": null,
"internalDomainNameSuffix": "brqlt10lvoxedgkeuomc4pm5tb.bx.internal.cloudapp.net",
"internalFqdn": null
},
"enableAcceleratedNetworking": false,
"enableIpForwarding": false,
"etag": "W/\"04b5ab44-d8f4-422a-9541-e5ae7de8466d\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/myNic",
{
"applicationGatewayBackendAddressPools": null,
"etag": "W/\"04b5ab44-d8f4-422a-9541-e5ae7de8466d\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/myNic/ipCo
nfigurations/ipconfig1",
"loadBalancerBackendAddressPools": null,
"loadBalancerInboundNatRules": null,
"primary": true,
"privateIpAddressVersion": "IPv4",
"privateIpAllocationMethod": "Dynamic",
"dnsSettings": null,
"etag": null,
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/publicIPAddresses/myPublicIP
",
"idleTimeoutInMinutes": null,
"ipAddress": null,
"ipConfiguration": null,
"location": null,
"name": null,
"provisioningState": null,
"publicIpAddressVersion": null,
"publicIpAllocationMethod": null,
"resourceGuid": null,
"tags": null,
"type": null
},
"subnet": {
"addressPrefix": null,
"etag": null,
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subne
ts/mySubnet",
"ipConfigurations": null,
"name": null,
"networkSecurityGroup": null,
"resourceNavigationLinks": null,
"routeTable": null
}
}
],
"macAddress": null,
"name": "myNic",
"defaultSecurityRules": null,
"defaultSecurityRules": null,
"etag": null,
"id":
orkSecurityGroup",
"location": null,
"name": null,
"networkInterfaces": null,
"resourceGuid": null,
"securityRules": null,
"subnets": null,
"tags": null,
"type": null
},
"primary": null,
"resourceGuid": "b3dbaa0e-2cf2-43be-a814-5cc49fea3304",
"tags": null,
"virtualMachine": null
}
}

Conjuntos de disponibilidade ajudam a difundir suas VMs em domínios de falha e domínios de atualização.
Embora você crie apenas uma VM no momento, é uma melhor prática usar conjuntos de disponibilidade para
facilitar a expansão no futuro.
Os domínios de falha definem um agrupamento de máquinas virtuais que compartilham uma mesma fonte de
alimentação e um mesmo comutador de rede. Por padrão, as máquinas virtuais que são configuradas dentro do
seu conjunto de disponibilidade são separadas entre até três domínios de falha. Um problema de hardware em
um desses domínios de falha não afeta todas as VMs que estiverem executando seu aplicativo.
Os domínios de atualização indicam grupos de máquinas virtuais e hardware físico subjacente que podem ser
reinicializados ao mesmo tempo. A ordem de reinicialização dos domínios de atualização pode não ser
sequencial durante a manutenção planejada, mas apenas um domínio de atualização é reinicializado por vez.
O Azure distribui automaticamente as VMs entre os domínios de falha e de atualização ao colocá-las em um
conjunto de disponibilidade. Para obter mais informações, consulte Gerenciamento da disponibilidade de VMs.
Crie um conjunto de disponibilidade para sua VM com az vm availability-set create. O exemplo a seguir cria um
conjunto de disponibilidade chamado myAvailabilitySet:
A saída anota os domínios de atualização e domínios de falha:

{
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Compute/availabilitySets/myAvailabil
itySet",
"managed": null,
"name": "myAvailabilitySet",
"platformFaultDomainCount": 2,
"platformUpdateDomainCount": 5,
"sku": {
"capacity": null,
"managed": true,
"tier": null
},
"statuses": null,
"tags": {},
"type": "Microsoft.Compute/availabilitySets",
"virtualMachines": []
}

Você criou os recursos de rede para dar suporte a VMs que podem ser acessadas pela Internet. Agora crie uma
VM e proteja-a com uma chave SSH. Neste exemplo, vamos criar uma VM do Ubuntu com base no LTS mais
recente. Você pode encontrar imagens adicionais com az vm image list, conforme descrito em localizando
imagens de VM do Azure.
Especifique uma chave SSH a ser usada para autenticação. Se você não tem um par de chaves públicas SSH,
você pode criá-las ou usar o parâmetro --generate-ssh-keys para criá-las para você. Se você já tem um par de
chaves, esse parâmetro usará as chaves existentes em ~/.ssh .
Crie a VM reunindo todos os recursos e informações com o comando az vm create. O exemplo a seguir cria uma
VM chamada myVM:
az vm create \
--name myVM \
--location eastus \
--nics myNic \
--image UbuntuLTS \
--generate-ssh-keys
Conecte-se por SSH à VM com a entrada DNS que você forneceu ao criar o endereço IP público. Esse fqdn é
mostrado na saída, conforme você cria a VM:
{
"fqdns": "mypublicdns.eastus.cloudapp.azure.com",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",
"macAddress": "00-0D-3A-13-71-C8",
}
ssh azureuser@mypublicdns.eastus.cloudapp.azure.com
Saída:
The authenticity of host 'mypublicdns.eastus.cloudapp.azure.com (13.90.94.252)' can't be established.

ECDSA key fingerprint is SHA256:SylINP80Um6XRTvWiFaNz+H+1jcrKB1IiNgCDDJRj6A.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mypublicdns.eastus.cloudapp.azure.com,13.90.94.252' (ECDSA) to the list of known
hosts.
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.11.0-1016-azure x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Get cloud support with Ubuntu Advantage Cloud Guest:

https://www.ubuntu.com/business/services/cloud
0 packages can be updated.

0 updates are security updates.
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by

applicable law.
To run a command as administrator (user "root"), use "sudo <command>".

See "man sudo_root" for details.
azureuser@myVM:~$
Você pode instalar o NGINX e ver o fluxo de tráfego para a VM. Instale o NGINX conforme demonstrado a
seguir:
sudo apt-get install -y nginx
Para ver o site NGINX padrão em ação, abra seu navegador da Web e digite o FQDN:
Exportar como um modelo

E se agora você quiser criar um ambiente de desenvolvimento adicional usando os mesmos parâmetros ou um
ambiente de produção corresponde? O Gerenciador de Recursos usa modelos JSON que definem todos os
parâmetros para seu ambiente. Crie ambientes inteiros fazendo referência a esse modelo JSON. Você pode criar
modelos JSON manualmente ou exportar um ambiente existente para criar o modelo JSON para você. Use az
group export para exportar seu grupo de recursos da seguinte maneira:
az group export --name myResourceGroup > myResourceGroup.json
Esse comando cria o arquivo myResourceGroup.json no diretório de trabalho atual. Quando você cria um
ambiente com base neste modelo, será solicitado que você informe todos os nomes de recursos. Você pode
popular esses nomes em seu arquivo de modelo adicionando o parâmetro --include-parameter-default-value
ao comando az group export . Edite o modelo JSON para especificar os nomes dos recursos ou crie um
parameters.jsno arquivo que especifique os nomes dos recursos.
Para criar um ambiente a partir de seu modelo, use AZ Deployment Group Create da seguinte maneira:
az deployment group create \

--resource-group myNewResourceGroup \
--template-file myResourceGroup.json
Pode ser útil ler mais detalhes sobre a implantações de modelos. Saiba como atualizar ambientes
gradativamente, usar o arquivo de parâmetros e acessar os modelos de uma única localização de
armazenamento.
Próximas etapas
Agora, você está pronto para começar a trabalhar com vários componentes de rede e VMs. Você pode usar esse
ambiente de exemplo para criar seu aplicativo usando os principais componentes introduzidos aqui.
Como criar uma máquina virtual do Linux com os
modelos do Azure Resource Manager
Saiba como criar uma VM (máquina virtual) do Linux usando um modelo de Azure Resource Manager e o CLI
do Azure do Azure cloud Shell. Para criar uma máquina virtual do Windows, consulte criar uma máquina virtual
do Windows a partir de um modelo do Resource Manager.
Uma alternativa é implantar o modelo do portal do Azure. Para abrir o modelo no portal, selecione o botão
implantar no Azure .
Visão geral de modelos

Os modelos do Azure Resource Manager são arquivos JSON que definem a infraestrutura e a configuração de
sua solução do Azure. Usando um modelo, você pode implantar a solução repetidamente em todo seu ciclo de
vida e com a confiança de que seus recursos serão implantados em um estado consistente. Para saber mais
sobre o formato do modelo e como construí-lo, consulte início rápido: criar e implantar modelos de Azure
Resource Manager usando o portal do Azure. Para exibir a sintaxe JSON para os tipos de recursos, consulte
Definir recursos nos modelos do Azure Resource Manager.

A criação de uma máquina virtual do Azure geralmente inclui duas etapas:
1. Crie um grupos de recursos. Um grupo de recursos do Azure é um contêiner lógico no qual os recursos do
Azure são implantados e gerenciados. Você deve criar um grupo de recursos antes de criar uma máquina
virtual.
2. Crie uma máquina virtual.
O exemplo a seguir cria uma VM a partir de um modelo de início rápido do Azure. Somente a autenticação SSH
é permitida para essa implantação. Mediante solicitação, forneça o valor de sua própria chave pública SSH,
como o conteúdo de ~/.ssh/id_rsa.pub. Se você precisar criar um par de chaves SSH, confira Como criar um par
de chaves SSH para VMs Linux no Azure. Veja uma cópia do modelo:
{
"parameters": {
"projectName": {
"type": "string",
"metadata": {
"description": "Specifies a name for generating resource names."
}
},
"location": {
"type": "string",
"metadata": {
"description": "Specifies the location for all resources."
}
},
"adminUsername": {
"type": "string",
"metadata": {
"description": "Specifies a username for the Virtual Machine."
}
},
"adminPublicKey": {
"type": "string",
"metadata": {
"description": "Specifies the SSH rsa public key file as a string. Use \"ssh-keygen -t rsa -b 2048\"
to generate your SSH key pairs."
}
},
"vmSize": {
"type": "string",
"defaultValue": "Standard_D2s_v3",
"metadata": {
"description": "description"
}
}
},
"variables": {
"vNetName": "[concat(parameters('projectName'), '-vnet')]",
"vNetAddressPrefixes": "10.0.0.0/16",
"vNetSubnetName": "default",
"vNetSubnetAddressPrefix": "10.0.0.0/24",
"vmName": "[concat(parameters('projectName'), '-vm')]",
"publicIPAddressName": "[concat(parameters('projectName'), '-ip')]",
"networkInterfaceName": "[concat(parameters('projectName'), '-nic')]",
"networkSecurityGroupName": "[concat(parameters('projectName'), '-nsg')]",
"networkSecurityGroupName2": "[concat(variables('vNetSubnetName'), '-nsg')]"
},
"resources": [
{
"apiVersion": "2020-05-01",
"properties": {
"securityRules": [
{
"name": "ssh_rule",
"properties": {
"description": "Locks inbound down to ssh default port 22.",
"protocol": "Tcp",
"access": "Allow",
"priority": 123,
"direction": "Inbound"
}
}
]
}
},
{
"apiVersion": "2020-05-01",
"name": "[variables('publicIPAddressName')]",
"properties": {
"publicIPAllocationMethod": "Dynamic"
},
"sku": {
"name": "Basic"
}
},
{
{
"comments": "Simple Network Security Group for subnet [variables('vNetSubnetName')]",
"apiVersion": "2020-05-01",
"name": "[variables('networkSecurityGroupName2')]",
"properties": {
"securityRules": [
{
"properties": {
"priority": 1000,
"access": "Allow",
"protocol": "Tcp",
}
}
]
}
},
{
"apiVersion": "2020-05-01",
"name": "[variables('vNetName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName2'))]"
],
"properties": {
"addressSpace": {
"[variables('vNetAddressPrefixes')]"
]
},
"subnets": [
{
"name": "[variables('vNetSubnetName')]",
"properties": {
"addressPrefix": "[variables('vNetSubnetAddressPrefix')]",
variables('networkSecurityGroupName2'))]"
}
}
}
]
}
},
{
"apiVersion": "2020-05-01",
"name": "[variables('networkInterfaceName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', variables('publicIPAddressName'))]",
"[resourceId('Microsoft.Network/virtualNetworks', variables('vNetName'))]",
],
"properties": {
{
"properties": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses',
"id": "[resourceId('Microsoft.Network/publicIPAddresses',
variables('publicIPAddressName'))]"
},
"subnet": {
"id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('vNetName'),
variables('vNetSubnetName'))]"
}
}
}
]
}
},
{
"apiVersion": "2019-12-01",
"name": "[variables('vmName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', variables('networkInterfaceName'))]"
],
"properties": {
},
"osProfile": {
"computerName": "[variables('vmName')]",
"disablePasswordAuthentication": true,
"ssh": {
"publicKeys": [
{
"keyData": "[parameters('adminPublicKey')]"
}
]
}
}
},
"storageProfile": {
"imageReference": {
"sku": "18.04-LTS",
"version": "latest"
},
"osDisk": {
"createOption": "fromImage"
}
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', variables('networkInterfaceName'))]"
}
]
}
}
}
]
}
Para executar o script da CLI, selecione Experimente- o para abrir o Azure cloud Shell. Para colar o script, clique
com o botão direito do mouse no Shell e selecione colar :
echo "Enter the Resource Group name:" &&
read resourceGroupName &&
echo "Enter the location (i.e. centralus):" &&
read location &&
echo "Enter the project name (used for generating resource names):" &&
read projectName &&
echo "Enter the administrator username:" &&
read username &&
echo "Enter the SSH public key:" &&
read key &&
az group create --name $resourceGroupName --location "$location" &&
az deployment group create --resource-group $resourceGroupName --template-uri
https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/101-vm-sshkey/azuredeploy.json --
parameters projectName=$projectName adminUsername=$username adminPublicKey="$key" &&
az vm show --resource-group $resourceGroupName --name "$projectName-vm" --show-details --query publicIps --
output tsv
O último comando CLI do Azure mostra o endereço IP público da VM recém-criada. Você precisa do endereço IP
público para se conectar à máquina virtual. Consulte a próxima seção deste artigo.
No exemplo anterior, você especificou um modelo armazenado no GitHub. Também é possível baixar ou criar
um modelo e especificar o caminho local com o parâmetro --template-file .
Estes são alguns recursos adicionais:
Para saber como desenvolver modelos do Resource Manager, confira a Documentação do Azure Resource
Manager.
Para ver os esquemas de máquina virtual do Azure, consulte referência de modelo do Azure.
Para ver mais exemplos de modelo de máquina virtual, consulte modelos de início rápido do Azure.

Depois, você pode enviar por SSH para sua VM, como de costume. Forneça seu próprio endereço IP público do
comando anterior:
ssh <adminUsername>@<ipAddress>
Próximas etapas
Neste exemplo, você criou uma VM básica do Linux. Para obter mais modelos do Resource Manager que
incluem estruturas de aplicativo ou criar ambientes mais complexos, procure os modelos de início rápido do
Azure.
Confira a sintaxe e as propriedades do JSON para os tipos de recursos que você implantou para saber mais
sobre a criação de modelos:
Microsoft.Network/networkSecurityGroups
Microsoft.Network/publicIPAddresses
Microsoft.Network/virtualNetworks
Microsoft.Network/networkInterfaces
Microsoft.Compute/virtualMachines
Criar uma máquina virtual do Linux que usa
autenticação SSH com a API REST
Uma VM (máquina virtual) do Linux no Azure consiste em vários recursos, como discos e interfaces de rede, e
define parâmetros como localização, tamanho e imagem do sistema operacional e configurações de
autenticação.
É possível criar uma VM do Linux por meio do portal do Azure, CLI do Azure 2.0, muitos SDKs do Azure,
modelos do Azure Resource Manager e muitas ferramentas de terceiros, como Ansible ou Terraform. Em última
análise, todas essas ferramentas usam a API REST para criar a VM do Linux.
Este artigo mostra a você como usar a API REST para criar uma VM do Linux que executa o Ubuntu 18.04-LTS
com discos gerenciados e autenticação SSH.
Antes de começar
Antes de criar e enviar a solicitação, você precisará de:
O {subscription-id}para sua assinatura
Se você tiver várias assinaturas, confira Trabalhando com várias assinaturas
Um {resourceGroupName} criado com antecedência
Um adaptador de rede virtual no mesmo grupo de recursos
Um par de chaves SSH (você pode gerar um novo caso não tenha)
Noções básicas de solicitação

Para criar ou atualizar uma máquina virtual, use a seguinte operação PUT:
PUT https://management.azure.com/subscriptions/{subscription-
id}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vmName}?api-
version=2017-12-01
Além dos parâmetros {subscription-id} e {resourceGroupName} , você precisará especificar o {vmName} (

api-version é opcional, mas este artigo foi testado com api-version=2017-12-01 )
Os cabeçalhos a seguir são necessários:
C A B EÇ A L H O DA SO L IC ITA Ç Ã O DESC RIÇ Ã O
Tipo de Conteúdo: Obrigatórios. Defina como application/json .
Autorização: Obrigatórios. Defina como um token de acesso Bearer

válido.
Para obter informações gerais sobre como trabalhar com solicitações da API REST, confira Componentes de uma
solicitação/resposta da API REST.
Criar o corpo da solicitação

As definições comuns a seguir são usadas para criar um corpo de solicitação:
NOME O B RIGATÓ RIO TYPE DESC RIÇ Ã O
local True string Local do recurso.
name string Nome da máquina virtual.
properties.hardwareProfile HardwareProfile Especifica as configurações

de hardware da máquina
virtual.
properties.storageProfile StorageProfile Especifica as configurações

de armazenamento dos
discos da máquina virtual.
properties.osProfile OSProfile Especifica as configurações

do sistema operacional da
máquina virtual.
properties.networkProfile NetworkProfile Especifica as interfaces de

rede da máquina virtual.
Abaixo, há um exemplo de corpo da solicitação. Lembre-se de especificar o nome da VM nos parâmetros

{computerName} e {name} , o nome do adaptador de rede que criou em networkInterfaces , seu nome de usuário
em adminUsername e path e a parte pública do seu par de chaves SSH (localizada em, por exemplo,
~/.ssh/id_rsa.pub ) em keyData . Outros parâmetros que talvez queira modificar incluem location e vmSize .
{
"name": "{vmName}",
"properties": {
"vmSize": "Standard_DS1_v2"
},
"storageProfile": {
"imageReference": {
"sku": "18.04-LTS",
"version": "latest",
"offer": "UbuntuServer"
},
"osDisk": {
"caching": "ReadWrite",
"managedDisk": {
"storageAccountType": "Premium_LRS"
},
"name": "myVMosdisk",
}
},
"osProfile": {
"adminUsername": "{your-username}",
"computerName": "{vmName}",
"ssh": {
"publicKeys": [
{
"path": "/home/{your-username}/.ssh/authorized_keys",
"keyData": "ssh-rsa AAAAB3NzaC1{snip}mf69/J1"
}
]
},
"disablePasswordAuthentication": true
}
},
"networkProfile": {
{
"id": "/subscriptions/{subscription-
id}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/networkInterfaces/{existing-nic-name}",
"properties": {
"primary": true
}
}
]
}
}
}
Para obter uma lista completa das definições disponíveis no corpo da solicitação, consulte máquinas virtuais
criar ou atualizar definições do corpo da solicitação.
Enviando a solicitação
É possível usar o cliente de sua preferência para enviar essa solicitação HTTP. Você também pode usar uma
ferramenta no navegador clicando no botão Experimentar .
Respostas
Há duas respostas bem-sucedidas para a operação criar ou atualizar uma máquina virtual:
NOME T IP O DESC RIÇ Ã O
200 OK VirtualMachine OK
201 Criado VirtualMachine Criado
Uma resposta 201 Criado condensada do exemplo anterior de corpo da solicitação que cria uma VM mostra que
uma vmId foi atribuída e o provisioningState como Criando:
{
"vmId": "e0de9b84-a506-4b95-9623-00a425d05c90",
"provisioningState": "Creating"
}
Para saber mais sobre as respostas da API REST, veja Processar a mensagem de resposta.
Próximas etapas
Para saber mais sobre as APIs REST do Azure ou outras ferramentas de gerenciamento, como a CLI do Azure ou
o Azure PowerShell, veja o seguinte:
API REST do provedor de Computação do Azure
Iniciar com a API REST do Azure
CLI do Azure
Módulo do Azure PowerShell
Criar uma cópia da sua VM Linux usando a CLI do
Azure e Managed Disks
Este artigo mostra como criar uma cópia de sua VM (máquina virtual) do Azure executando o Linux usando o
CLI do Azure. Para copiar, criar, armazenar e compartilhar imagens de VM em escala, consulte galerias de
imagens compartilhadas.
Você também pode carregar e criar uma VM com base em um VHD.
Pré-requisitos
Instale a CLI do Azure.
Entre em uma conta do Azure com az login.
Tenha uma VM do Azure para usar como origem para a cópia.
Pare a VM de origem
Desaloque a VM de origem usando az vm deallocate. O seguinte exemplo desaloca a VM myVM no grupo de
recursos chamado myResourceGroup:
az vm deallocate \
--name myVM
Copiar a VM de origem
Para copiar uma máquina virtual, você deve criar uma cópia do disco rígido virtual subjacente. Esse processo
cria um disco rígido virtual (VHD) especializado como disco gerenciado que contém a mesma configuração e
configurações da VM de origem.
Para saber mais sobre Azure Managed Disks, veja Visão geral dos Azure Managed Disks.
1. Lista cada VM e o nome do disco do sistema operacional com az vm list. O exemplo a seguir lista todas as
VMs no grupo de recursos denominado myResourceGroup:
az vm list -g myResourceGroup \
--query '[].{Name:name,DiskName:storageProfile.osDisk.name}' \
--output table
Name DiskName
------ --------
myVM myDisk
2. Copie o disco criando um novo disco gerenciado e usando az disk create. O exemplo a seguir cria um
disco chamado myCopiedDisk do disco gerenciado chamado myDisk:
az disk create --resource-group myResourceGroup \
--name myCopiedDisk --source myDisk
3. Verifique se os discos gerenciados agora em seu grupo de recursos usando az disk list. O exemplo a
seguir lista os discos gerenciados no grupo de recursos denominado myResourceGroup:
az disk list --resource-group myResourceGroup --output table
Configurar uma rede virtual

As etapas opcionais a seguir criam uma nova rede virtual, uma sub-rede, um endereço IP público e uma placa
de adaptador de rede virtual (NIC).
Se você estiver copiando uma VM para fins ou implantações adicionais de solução de problemas, não convém
usar uma máquina virtual em uma rede virtual existente.
Se quiser criar uma infraestrutura de rede virtual para as VMs copiadas, siga as próximas etapas. Se você não
quiser criar uma rede virtual, vá para Criar uma VM.
1. Crie a rede virtual usando az network vnet create. O exemplo a seguir cria uma rede virtual chamada
myVnet e uma sub-rede chamada mySubnet:
az network vnet create --resource-group myResourceGroup \

--location eastus --name myVnet \
--address-prefix 192.168.0.0/16 \
2. Crie um IP público usando az network public-ip create. O exemplo a seguir cria um IP público chamado
myPublicIP com o nome DNS de mypublicdns. (Como o nome DNS deve ser exclusivo, forneça um nome
exclusivo.)
az network public-ip create --resource-group myResourceGroup \

--location eastus --name myPublicIP --dns-name mypublicdns \
--allocation-method static --idle-timeout 4
3. Criar a NIC usando az network nic create. O exemplo a seguir cria uma NIC chamada myNic anexada à
sub-rede mySubnet:
az network nic create --resource-group myResourceGroup \

--location eastus --name myNic \
--vnet-name myVnet --subnet mySubnet \
--public-ip-address myPublicIP

Criar uma VM usando az vm create.
Especifique o disco copiado gerenciado para usar como o disco do sistema operacional ( --attach-os-disk ) da
seguinte maneira:
--name myCopiedVM --nics myNic \
--size Standard_DS1_v2 --os-type Linux \
--attach-os-disk myCopiedDisk
Próximas etapas
Para saber como usar uma Galeria de imagens compartilhadas para gerenciar imagens de VM.
Tutorial – Configurar estratégia de implantação sem
interrupção para Máquinas Virtuais do Linux do
Azure
O Azure DevOps é um serviço interno do Azure que automatiza cada parte do processo de DevOps para
qualquer recurso do Azure. Quer o aplicativo use máquinas virtuais, aplicativos Web, Kubernetes ou qualquer
outro recurso, você pode implementar IaC (infraestrutura como código), integração contínua, teste contínuo,
entrega contínua e monitoramento contínuo com o Azure e o Azure DevOps.
IaaS (infraestrutura como serviço) – configurar CI/CD

O Azure Pipelines fornece um conjunto de ferramentas de automação de CI/CD para implantações em
máquinas virtuais. Você pode configurar um pipeline de entrega contínua para uma VM do Azure do portal do
Azure.
Este artigo mostra como configurar um pipeline de CI/CD para a reversão de implantações de vários
computadores do portal do Azure. O portal do Azure também dá suporte a outras estratégias, como canário e
azul-verde.
Configurar CI/CD em máquinas virtuais
Você pode adicionar máquinas virtuais como destinos a um grupo de implantação. Em seguida, você pode
direcioná-las para atualizações de vários computadores. Depois de implantar o computadores, veja o Histórico
de Implantação em um grupo de implantação. Essa exibição permite que você rastreie da VM para o pipeline
e, em seguida, para a confirmação.
Implantações sem interrupção
Em cada iteração, uma implantação sem interrupção substitui as instâncias da versão anterior de um aplicativo.
Ela os substitui por instâncias da nova versão em um conjunto fixo de computadores (conjunto dinâmico). As
instruções a seguir mostram como configurar uma atualização sem interrupção para máquinas virtuais.
Usando a opção de entrega contínua, você pode configurar atualizações sem interrupção em suas máquinas
virtuais dentro do portal do Azure. Veja um passo a passo do processo:
1. Entre no portal do Azure e navegue até uma máquina virtual.
2. No painel mais à esquerda das configurações da VM, selecione Entrega contínua . Em seguida, selecione
Configurar .
3. No painel de configuração, clique em Organização do Azure DevOps para selecionar uma conta ou
criar uma. Em seguida, selecione o projeto no qual deseja configurar o pipeline.
4. Um grupo de implantação é um conjunto lógico de computadores de destino de implantação que
representam os ambientes físicos. Desenvolvimento, teste, UAT e produção são exemplos. Você pode criar
um grupo de implantação ou selecionar um existente.
5. Selecione o pipeline de build que publica o pacote a ser implantado na máquina virtual. O pacote
publicado deve ter um script de implantação chamado deploy.ps1 ou deploy.sh na pasta deployscripts na
pasta raiz do pacote. O pipeline executa esse script de implantação.
6. Em Estratégia de implantação , selecione Sem interrupção .
7. Opcionalmente, você pode marcar cada computador com sua função. As marcas "web" e "db" são
exemplos. Essas marcas ajudam a direcionar apenas as VMs que têm uma função específica.
8. Selecione OK para configurar o pipeline de entrega contínua.
9. Após a conclusão da configuração, você tem um pipeline de entrega contínua configurado para implantar
na máquina virtual.
10. Os detalhes da implantação para a máquina virtual são exibidos. Você pode selecionar o link para acessar
o pipeline, Release-1 para exibir a implantação ou Editar para modificar a definição do pipeline de
lançamento.
11. Se você estiver configurando várias VMs, repita as etapas de 2 a 4 para outras VMs a serem adicionadas
ao grupo de implantação. Se você selecionar um grupo de implantação que já tenha uma execução de
pipeline, as VMs serão adicionadas apenas ao grupo de implantação. Nenhum pipeline é criado.
12. Após a conclusão da configuração, selecione a definição de pipeline, navegue até a organização Azure
DevOps e selecione Editar para o pipeline de lançamento.
13. Selecione 1 trabalho, 1 tarefa na fase dev . Selecione a fase Implantar .

14. No painel de configuração à direita, você pode especificar o número de computadores que deseja
implantar em paralelo em cada iteração. Se você quiser implantar em vários computadores por vez,
poderá especificar o número de computadores como um percentual usando o controle deslizante.
15. A tarefa Executar Script de Implantação, por padrão, executa o script de implantação deploy.ps1 ou
deploy.sh. O script está na pasta deployscripts na pasta raiz do pacote publicado.
Outras estratégias de implantação

Configurar a estratégia de implantação azul-verde
Azure DevOps Projects

Você pode começar a usar o Azure facilmente. Com o Azure DevOps Projects, comece a executar seu aplicativo
em qualquer serviço do Azure em apenas três etapas, selecionando:
Uma linguagem do aplicativo
Um runtime
Um serviço do Azure
Saiba mais.
Recursos adicionais
Implantar em máquinas virtuais do Azure usando Azure DevOps Projects
Implementar a implantação contínua do aplicativo em um conjunto de dimensionamento de máquinas
virtuais do Azure
Tutorial – Configurar a estratégia de implantação
canário para Máquinas Virtuais do Linux do Azure

Azure.
Este artigo mostra como configurar um pipeline de CI/CD que usa a estratégia canário para implantações em
vários computadores. O portal do Azure também dá suporte a outras estratégias, como dinâmica e azul-verde.
Implantações canário
Uma implantação canário reduz o risco, distribuindo lentamente as alterações para um pequeno subconjunto de
usuários. À medida que você tiver confiança na nova versão, poderá liberá-la para mais servidores na sua
infraestrutura e rotear mais usuários para ela.
Usando a opção de entrega contínua, você pode configurar implantações canário para suas máquinas virtuais
usando o portal do Azure. Veja um passo a passo do processo:
Configurar .

6. Em Estratégia de implantação , selecione Canário .
7. Adicione uma marca "canário" às VMs que fazem parte de implantações canário. Adicione uma marca
"prod" às VMs que fazem parte das implantações feitas após a implantação do canário ser realizada com
sucesso. As marcas ajudam a direcionar apenas as VMs que têm uma função específica.
8. Selecione OK para configurar o pipeline de entrega contínua para implantar na máquina virtual.
o pipeline de lançamento no Azure DevOps. No pipeline de lançamento, selecione Editar para ver a
configuração do pipeline. O pipeline tem estas três fases:
a. Esta fase é uma fase de grupo de implantação. Os aplicativos são implantados em VMs que são
marcadas como "canário".
b. Nessa fase, pipeline é colocado em pausa e aguarda a intervenção manual para retomar a
execução.
c. Essa é novamente uma fase do grupo de implantação. A atualização agora é implantada em VMs
marcadas como "Prod".
10. Antes de retomar a execução do pipeline, verifique se pelo menos uma VM está marcada como "prod".
Na terceira fase do pipeline, os aplicativos são implantados somente para as VMs que têm a marca
"prod".
deploy.sh. O script está na pasta deployscripts na pasta raiz do pacote publicado. Verifique se o pipeline
de build selecionado publica a implantação na pasta raiz do pacote.

Configurar a estratégia de implantação azul-verde

Um runtime
Saiba mais.
Recursos adicionais
virtuais do Azure
Tutorial – Configurar a estratégia de implantação
azul-verde para máquinas virtuais do Linux do
Azure

Azure.
Este artigo mostra como configurar um pipeline de CI/CD que usa a estratégia azul-verde para implantações em
vários computadores. O portal do Azure também dá suporte a outras estratégias, como sem interrupção e
canário.
Implantações azul-verde
Uma implantação azul-verde reduz o tempo de inatividade por ter um ambiente de espera idêntico. Apenas um
ambiente está ativo por vez.
Ao se preparar para uma nova versão, você conclui o estágio final do teste no ambiente verde. Depois que o
software funciona no ambiente verde, alterne o tráfego para todas as solicitações de entrada irem para o
ambiente verde. O ambiente azul está ocioso.
Usando a opção de entrega contínua, você pode configurar implantações do tipo azul-verde em suas máquinas
virtuais no portal do Azure. Veja um passo a passo do processo:
Configurar .

6. Em Estratégia de implantação , selecione Azul-verde .
7. Adicione uma tag "azul" ou "verde" às VMs que devem fazer parte das implantações do tipo azul-verde.
Se uma VM for para uma função em espera, marque-a como "verde". Caso contrário, marque-a como
"azul".
8. Selecione OK para configurar o pipeline de entrega contínua para implantar na máquina virtual.
o pipeline de lançamento no Azure DevOps. No pipeline de lançamento, selecione Editar para ver a
configuração do pipeline. O pipeline tem estas três fases:
a. Esta fase é uma fase de grupo de implantação. Os aplicativos são implantados em VMs em espera,
que são marcadas como "verdes".
b. Nessa fase, pipeline é colocado em pausa e aguarda a intervenção manual para retomar a
execução. Os usuários podem retomar a execução do pipeline depois de garantir manualmente a
estabilidade da implantação para as VMs marcadas como "verdes".
c. Essa fase troca as marcas "azul" e "verde" nas VMs. Isso garante que as VMs com versões mais
antigas do aplicativo agora estejam marcadas como "verdes". Durante a próxima execução do
pipeline, os aplicativos serão implantados nessas VMs.
deploy.sh. O script está na pasta deployscripts na pasta raiz do pacote publicado. Verifique se o pipeline
de build selecionado publica a implantação na pasta raiz do pacote.


Um runtime
Saiba mais.
Recursos adicionais
virtuais do Azure
Tutorial: Implantar seu aplicativo em máquinas
virtuais do Linux no Azure usando o Azure DevOps
Services e o Azure Pipelines
A CI (integração contínua) e a CD (implantação contínua) formam um pipeline por meio do qual você pode criar,
lançar e implantar seu código após cada commit. Este documento contém as etapas associadas à configuração
de um pipeline de CI/CD para fazer implantações em vários computadores usando o Azure Pipelines.
O Azure Pipelines fornece um conjunto completo de ferramentas de automação de CI/CD para implantações em
máquinas virtuais, tanto localmente quanto em qualquer nuvem.
Neste tutorial, você configurará um pipeline de CI/CD baseado em YAML para implantar seu aplicativo em um
ambiente do Azure Pipelines com máquinas virtuais do Linux como recursos, cada uma das quais servirá como
um servidor Web para executar o aplicativo.
Você aprenderá como:
Obter um aplicativo de exemplo.
Criar um pipeline de CI do Azure Pipelines baseado em YAML para criar o aplicativo de exemplo.
Criar um ambiente do Azure Pipelines para as máquinas virtuais do Azure
Criar um pipeline de CD do Azure Pipelines.
Execute implantações manuais e disparadas por CI.
Antes de começar
Entre em sua organização do Azure DevOps Services ( https://dev.azure.com/ ). Você precisa obter
uma organização do Azure DevOps Services gratuita.
NOTE
Para saber mais, confira Conectar-se ao Azure DevOps Services.
É necessária uma máquina virtual Linux para um destino de implantação. Para obter mais informações,
consulte Criar e gerenciar VMs Linux com a CLI do Azure.
Abra a porta de entrada 80 para sua máquina virtual. Para obter mais informações, consulte Criar grupos
de segurança de rede usando o Portal do Azure.
Obtenha seu código do aplicativo de exemplo

Se já tiver um aplicativo no GitHub que deseja implantar, você poderá tentar criar um pipeline para esse código.
No entanto, se você for um novo usuário, poderá começar melhor usando nosso código de exemplo. Nesse
caso, crie um fork deste repositório no GitHub:
Java
JavaScript
https://github.com/spring-projects/spring-petclinic
NOTE
O Petclinic é um aplicativo Java Spring boot criado usando o Maven.
Pré-requisitos para a VM Linux

Os aplicativos de exemplo mencionados acima foram testados no Ubuntu 16.04. Recomendamos que, para este
início rápido, você use a mesma versão da VM do Linux. Siga as etapas adicionais descritas abaixo com base na
pilha de runtime usada para o aplicativo.
Java
JavaScript
Para implantar aplicativos baseados em Java Spring Boot e Spring Cloud, crie uma VM do Linux no Azure
usando este modelo, que fornece um runtime baseado em OpenJDK totalmente compatível.
Para implantar Servlets Java no servidor Tomcat, crie uma VM do Linux com o Java 8 usando este modelo do
Azure e configure o Tomcat 9.x como um serviço.
Para implantar o aplicativo baseado em Java EE, use um modelo do Azure para criar uma VM do Linux + Java
+ WebSphere 9.x ou uma VM do Linux + Java + WebLogic 12.x ou uma VM do Linux + Java + WildFly/JBoss
14
Criar um ambiente do Azure Pipelines com máquinas virtuais do

Azure
As máquinas virtuais podem ser adicionadas como recursos em ambientes e podem ser direcionadas para
implantações em vários computadores. As exibições do histórico de implantação no ambiente fornecem
capacidade de rastreamento da VM para o pipeline e, em seguida, para o commit.
Você pode criar um ambiente no Hub "Ambientes " na seção "Pipelines ".
1. Entre na sua organização do Azure DevOps e navegue até seu projeto.
2. Em seu projeto, navegue até a página Pipelines . Em seguida, escolha Ambientes e clique em Criar
Ambiente . Especifique um Nome (obrigatório) para o ambiente e uma Descrição .
3. Escolha Máquinas Vir tuais como um Recurso a ser adicionado ao ambiente e clique em Avançar .
4. Escolha o sistema operacional (Windows/Linux) e copie o script de registro do PS .
5. Agora, execute o script copiado de um prompt de comando com privilégios de administrador do
PowerShell em cada uma das VMs de destino a serem registradas com esse ambiente.
NOTE
O token de acesso pessoal do usuário conectado é previamente inserido no script que expira no mesmo dia,
fazendo com que o script copiado fique inutilizável desse ponto em diante.
Se sua VM já tiver algum agente em execução, forneça um nome exclusivo para o "agente" a registrar no
ambiente.
6. Depois que a VM for registrada, ela começará a aparecer como um recurso de ambiente na guia
"recursos" do ambiente.
7. Para adicionar mais VMs, você pode exibir e copiar o script novamente clicando em "Adicionar recurso" e
escolhendo "Máquinas Virtuais" como recurso. Esse script permaneceria o mesmo para que todas as VMs
fossem adicionadas a esse ambiente.
8. Cada computador interage com o Azure Pipelines para coordenar a implantação do seu aplicativo.
9. É possível adicionar marcas à VM como parte do script de registro interativo do PowerShell ou

adicionar/remover esse script do modo de exibição de recursos, clicando no ícone de três pontos
disponível no final de cada recurso da VM no modo de exibição de recursos.
As marcas atribuídas permitem que você limite a implantação a máquinas virtuais específicas quando o
ambiente é usado em um trabalho de implantação. As marcas são limitadas a 256 caracteres, mas não há
nenhum limite para o número de marcas que você pode usar.
Definir o pipeline de build de CI
Você precisará de um pipeline de build de CI (integração contínua) que publica seu aplicativo Web, bem como
um script de implantação que pode ser executado localmente no servidor Ubuntu. Configure um pipeline de
build de CI com base no runtime que você deseja usar.
1. Entre na sua organização do Azure DevOps e navegue até seu projeto.
2. Em seu projeto, navegue até a página Pipelines . Em seguida, escolha a ação para criar um novo pipeline.
3. Percorra as etapas do assistente selecionando primeiro GitHub como o local do código-fonte.
4. Você pode ser redirecionado para o GitHub para então entrar. Nesse caso, insira suas credenciais do
GitHub.
5. Quando a lista de repositórios for exibida, selecione o repositório de aplicativo de exemplo que desejar.
6. O Azure Pipelines analisará seu repositório e recomendará um modelo de pipeline adequado.
Java
JavaScript
Selecione o modelo inicial e copie o snippet de código YAML abaixo que cria seu projeto Java e executa testes
com o Apache Maven:
jobs:
- job: Build
displayName: Build Maven Project
steps:
- task: Maven@3
displayName: 'Maven Package'
inputs:
mavenPomFile: 'pom.xml'
- task: CopyFiles@2
displayName: 'Copy Files to artifact staging directory'
inputs:
SourceFolder: '$(System.DefaultWorkingDirectory)'
Contents: '**/target/*.?(war|jar)'
TargetFolder: $(Build.ArtifactStagingDirectory)
- upload: $(Build.ArtifactStagingDirectory)
artifact: drop
Para obter mais diretrizes, siga as etapas mencionadas em Crie seu aplicativo Java com o Maven.
Definir as etapas da CD para implantar na VM do Linux

1. Altere o arquivo YAML do pipeline acima para incluir um trabalho de implantação referenciando o
ambiente e os recursos da VM que você usou anteriormente com a sintaxe YAML abaixo:
jobs:
- deployment: VMDeploy
displayName: web
environment:
name: <environment name>
resourceType: VirtualMachine
tags: web
2. Você pode selecionar conjuntos específicos de máquinas virtuais do ambiente para receber a
implantação, especificando as marcas que você definiu para cada máquina virtual no ambiente. Confira
aqui o esquema completo do YAML para o trabalho de implantação.
3. É possível especificar runOnce ou rolling como a estratégia de implantação.
runOnce é a estratégia de implantação mais simples, em que todos os ganchos de ciclo de vida,
especificamente preDeploy deploy , routeTraffic e postRouteTraffic , são executados uma vez. Em
seguida, on: success ou on: failure é executado.
Veja abaixo o snippet de código YAML de exemplo para runOnce :
jobs:
displayName: web
pool:
vmImage: 'Ubuntu-16.04'
environment:
strategy:
runOnce:
deploy:
steps:
- script: echo my first deployment
4. Abaixo está um exemplo do snippet de código YAML que você pode usar para definir uma estratégia sem
interrupção para atualizações de máquinas virtuais para até cinco destinos em cada iteração.
maxParallel determinará o número de destinos para os quais as implantações podem ocorrer
paralelamente. As contas de seleção para um número absoluto ou um percentual de destinos que devem
permanecer disponíveis a qualquer momento, excluindo os destinos para os quais as implantações estão
sendo realizadas. Ele também é usado para determinar as condições de êxito e falha durante a
implantação.
jobs:
displayName: web
environment:
strategy:
rolling:
maxParallel: 5 #for percentages, mention as x%
preDeploy:
steps:
- download: current
artifact: drop
- script: echo initialize, cleanup, backup, install certs
deploy:
steps:
- task: Bash@3
inputs:
targetType: 'inline'
script: |
# Modify deployment script based on the app type
echo "Starting deployment script run"
sudo java -jar '$(Pipeline.Workspace)/drop/**/target/*.jar'
routeTraffic:
steps:
- script: echo routing traffic
postRouteTraffic:
steps:
- script: echo health check post-route traffic
on:
failure:
steps:
- script: echo Restore from backup! This is on failure
success:
steps:
- script: echo Notify! This is on success
Com cada execução desse trabalho, o histórico de implantação é registrado no ambiente de

<environment name> que você criou e no qual registrou as VMs.
Executar seu pipeline e obter exibições de capacidade de

rastreamento no ambiente
A exibição de implantações do ambiente fornece uma capacidade completa de rastreamento de commits e itens
de trabalho, bem como um histórico de implantação entre pipelines por ambiente/recurso.
Próximas etapas
Você pode prosseguir para personalizar o pipeline que você acabou de criar.
Para saber o que mais você pode fazer em pipelines do YAML, confira referência de esquema do YAML.
Para saber mais sobre como implantar uma pilha LAMP (Linux, Apache, MySQL e PHP), avance para o
próximo tutorial.
Implantar a pilha LAMP
Tutorial: Instalar um servidor Web do LAMP em
uma máquina virtual do Linux no Azure
Este artigo explica como implantar um servidor Web Apache, MySQL e PHP (a pilha LAMP) em uma VM do
Ubuntu no Azure. Para ver o servidor LAMP em ação, opcionalmente, você pode instalar e configurar um site de
WordPress. Neste tutorial, você aprenderá a:
Criar uma VM Ubuntu (o "L" na pilha de LAMP)
Instalar Apache, MySQL e PHP
Verificar a instalação e a configuração
Instalar o WordPress no servidor LAMP
Essa configuração destina-se a testes rápidos ou provas de conceito. Para saber mais sobre a pilha LAMP,
incluindo recomendações para um ambiente de produção, consulte a Documentação do Ubuntu.


O exemplo a seguir cria uma VM denominada myVM e cria chaves SSH, se elas ainda não existirem em um local
de chave padrão. Para usar um conjunto específico de chaves, use a opção --ssh-key-value . O comando
também define azureuser como um nome de usuário de administrador. Use esse nome posteriormente para se
conectar à máquina virtual.
az vm create \
--name myVM \
--image UbuntuLTS \
--generate-ssh-keys
Quando a VM tiver sido criada, a CLI do Azure mostra informações semelhantes ao exemplo a seguir. Anote
publicIpAddress . Esse endereço é usado para acessar a VM em etapas posteriores.
{
"fqdns": "",
"id": "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",
"macAddress": "00-0D-3A-23-9A-49",
}

Por padrão, somente as conexões de SSH têm permissão em VMs Linux implantadas no Azure. Como essa VM
será um servidor Web, você precisa abrir a porta 80 na Internet. Use o comando az vm open-port para abrir a
porta desejada.
SSH em sua VM
Se você ainda não souber o endereço IP público de sua VM, execute o comando az network public-ip list. Você
precisa desse endereço IP para várias etapas posteriores.
az network public-ip list --resource-group myResourceGroup --query [].ipAddress
Use o seguinte comando para criar uma sessão SSH com a máquina virtual. Substitua o endereço IP público
correto de sua máquina virtual. Neste exemplo, o endereço IP é 40.68.254.142. azureuser é o nome de usuário
de administrador definido quando você criou a VM.

Execute o seguinte comando para atualizar as fontes de pacote do Ubuntu e instalar o Apache, o MySQL e o PHP.
Observe o acento circunflexo (^) no final do comando, que é parte do nome do pacote lamp-server^ .
sudo apt update && sudo apt install lamp-server^
Você será solicitado a instalar os pacotes e outras dependências. Esse processo instala as extensões PHP
mínimas obrigatórias e necessárias para usar o PHP com o MySQL.

Verifique o Apache
Verifique a versão do Apache com o seguinte comando:
apache2 -v
Com o Apache instalado e a porta 80 aberta para a sua VM, o servidor Web agora pode ser acessado por meio
da Internet. Para exibir a página padrão do Apache2 Ubuntu, abra um navegador da Web e digite o endereço IP
público da VM. Insira o endereço IP público que você usou para o SSH para a VM:
Verificar e proteger o MySQL

Verifique a versão do MySQL com o seguinte comando (observe o parâmetro V em letra maiúscula):
mysql -V
Para ajudar a proteger a instalação do MySQL, incluindo a configuração de uma senha raiz, execute o script
mysql_secure_installation .
sudo mysql_secure_installation
Também é possível configurar o Plug-in de Validação de Senha (recomendado). Em seguida, defina uma senha
para o usuário raiz do MySQL e as configurações de segurança restantes para o seu ambiente. É recomendável
que você responda "Y" (sim) para todas as perguntas.
Se você quiser experimentar os recursos MySQL (criar um banco de dados MySQL, adicionar usuários ou alterar
as definições de configuração), faça logon no MySQL. Esta etapa não é necessária para concluir este tutorial.
sudo mysql -u root -p
Quando terminar, saia do prompt do MySQL digitando \q .

Verificar PHP
Verifique a versão do PHP com o seguinte comando:
php -v
Se você deseja realizar mais testes, crie uma página de informações rápida de PHP para exibição em um
navegador. O comando a seguir cria a página de informações de PHP:
sudo sh -c 'echo "<?php phpinfo(); ?>" > /var/www/html/info.php'

Agora você pode verificar a página de informações de PHP que você criou. Abra um navegador e acesse
http://yourPublicIPAddress/info.php . Substitua o endereço IP público de sua VM. A página deve ser semelhante
a esta imagem.
Instalar o WordPress
Se você quiser experimentar sua pilha, instale um aplicativo de exemplo. Por exemplo, as etapas a seguir
instalam a plataforma WordPress de código-fonte aberto para criar sites e blogs. Outras cargas de trabalho
tentam incluir Drupal e Moodle.
Esta instalação do WordPress destina-se apenas à prova de conceito. Para instalar o WordPress mais recente em
produção com as configurações de segurança recomendadas, consulte a Documentação do WordPress.
Instalar o pacote de WordPress
Execute o comando a seguir:
sudo apt install wordpress
Configurar WordPress
Configure o WordPress para usar PHP e MySQL.
Em um diretório de trabalho, crie um arquivo de texto wordpress.sql para configurar o banco de dados MySQL
do WordPress:
sudo sensible-editor wordpress.sql
Adicione os comandos a seguir, substituindo uma senha de banco de dados de sua escolha por suaSenha (não
altere outros valores). Caso você tenha configurado uma política de segurança do MySQL para validar a força da
senha, garanta que a senha atenda aos requisitos de força de senha. Salve o arquivo.
CREATE DATABASE wordpress;
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER
ON wordpress.*
TO wordpress@localhost
IDENTIFIED BY 'yourPassword';
Execute o comando a seguir para criar o banco de dados:
cat wordpress.sql | sudo mysql --defaults-extra-file=/etc/mysql/debian.cnf
Como o arquivo wordpress.sql contém as credenciais do banco de dados, exclua-o após o uso:
sudo rm wordpress.sql
Para configurar o PHP, execute o seguinte comando para abrir um editor de texto de sua preferência e criar o
arquivo /etc/wordpress/config-localhost.php :
sudo sensible-editor /etc/wordpress/config-localhost.php
Copie as linhas a seguir para o arquivo, substituindo a senha do banco de dados do WordPress por suaSenha
(não altere outros valores). Em seguida, salve o arquivo.
<?php
define('DB_NAME', 'wordpress');
define('DB_USER', 'wordpress');
define('DB_PASSWORD', 'yourPassword');
define('DB_HOST', 'localhost');
define('WP_CONTENT_DIR', '/usr/share/wordpress/wp-content');
?>
Mova a instalação do WordPress para a raiz do documento do servidor Web:
sudo ln -s /usr/share/wordpress /var/www/html/wordpress
sudo mv /etc/wordpress/config-localhost.php /etc/wordpress/config-default.php
Agora você pode concluir a instalação do WordPress e publicar na plataforma. Abra um navegador e acesse
http://yourPublicIPAddress/wordpress . Substitua o endereço IP público de sua VM. A página deve ser
semelhante a esta imagem.
Próximas etapas
Neste tutorial, você implantou um servidor LAMP no Azure. Você aprendeu a:
Criar uma VM do Ubuntu
Instalar o WordPress no servidor LAMP
Vá para o próximo tutorial para saber como proteger servidores Web com certificados TLS/SSL.
Proteger o servidor Web com TLS
Tutorial: Proteger um servidor Web em uma
máquina virtual do Linux no Azure com certificados
TLS/SSL armazenados no Key Vault
Para proteger servidores Web, um certificado de protocolo TLS, anteriormente conhecido como protocolo SSL,
pode ser usado para criptografar o tráfego da Web. Esses certificados TLS/SSL podem ser armazenados no
Azure Key Vault e permitem implantações seguras de certificados em VMs (máquinas virtuais) do Linux no
Azure. Neste tutorial, você aprenderá a:
Criar uma VM e instalar o servidor Web NGINX
Inserir o certificado na VM e configurar o NGINX com uma associação de TLS
Visão geral
O Azure Key Vault protege chaves e segredos criptográficos, como certificados ou senhas. O Key Vault simplifica
o processo de gerenciamento de certificados e permite que você mantenha o controle das chaves que acessam
esses certificados. Você pode criar um certificado autoassinado no Key Vault ou carregar um certificado
confiável existente que você já tenha.
Em vez de usar uma imagem de VM personalizada que inclui certificados incorporados, você injeta certificados
em uma VM em execução. Esse processo garante que os certificados mais recentes sejam instalados em um
servidor Web durante a implantação. Se você renova ou substitui um certificado, também não precisa criar uma
nova imagem de VM personalizada. Os certificados mais recentes são inseridos automaticamente, conforme
você cria outras VMs. Durante todo o processo, os certificados nunca deixam a plataforma do Azure ou são
expostos em um script, no histórico da linha de comando ou no modelo.

Antes de criar um Key Vault e os certificados, crie um grupo de recursos com az group create. O exemplo a
seguir cria um grupo de recursos chamado myResourceGroupSecureWeb no local eastus:
az group create --name myResourceGroupSecureWeb --location eastus
Em seguida, crie um Key Vault com o az keyvault create e habilite-o para ser usado quando você implantar uma
VM. Cada Key Vault requer um nome exclusivo e deve ter todas as letras minúsculas. Substitua <mykeyvault>
no exemplo a seguir com seu próprio nome exclusivo do Key Vault:
keyvault_name=<mykeyvault>
az keyvault create \
--resource-group myResourceGroupSecureWeb \
--name $keyvault_name \
--enabled-for-deployment
Gerar um certificado e armazenar no Key Vault

Para uso em produção, você deve importar um certificado válido assinado por um fornecedor confiável com o
az keyvault certificate import. Para este tutorial, o exemplo a seguir mostra como você pode gerar um
certificado autoassinado com criar certificado de keyvault az que usa a política de certificado padrão:
az keyvault certificate create \

--name mycert \
--policy "$(az keyvault certificate get-default-policy)"
Preparar um certificado para usar com uma VM

Para usar o certificado durante o processo de criação de VM, obtenha a identificação do seu certificado com as
versões secretas de az keyvault. Converta o certificado com az vm secret format. O exemplo a seguir atribui a
saída desses comandos variáveis de facilidade de uso nas próximas etapas:
secret=$(az keyvault secret list-versions \

--name mycert \
--query "[?attributes.enabled].id" --output tsv)
vm_secret=$(az vm secret format --secrets "$secret" -g myResourceGroupSecureWeb --keyvault $keyvault_name)
Criar uma configuração de cloud-init para proteger o NGINX

Inicialização de nuvem é uma abordagem amplamente utilizada para personalizar uma VM do Linux, quando ela
é inicializada pela primeira vez. Você pode utilizar a inicialização de nuvem para instalar pacotes e gravar
arquivos, ou para configurar usuários e segurança. Como a inicialização de nuvem é executada durante o
processo de inicialização inicial, não há etapa adicional ou agentes necessários para aplicar a configuração.
Quando você cria uma VM, certificados e chaves são armazenados no diretório protegido /var/lib/waagent/ .
Para automatizar a adição do certificado à VM e configurar o servidor Web, use o cloud-init. Neste exemplo,
instale e configure o servidor Web NGINX. Você pode usar o mesmo processo para instalar e configurar o
Apache.
Crie um arquivo chamado cloud-init-web-server.txt e cole a seguinte configuração:
#cloud-config
packages:
- nginx
write_files:
content: |
server {
listen 443 ssl;
ssl_certificate /etc/nginx/ssl/mycert.cert;
ssl_certificate_key /etc/nginx/ssl/mycert.prv;
}
runcmd:
- secretsname=$(find /var/lib/waagent/ -name "*.prv" | cut -c -57)
- mkdir /etc/nginx/ssl
- cp $secretsname.crt /etc/nginx/ssl/mycert.cert
- cp $secretsname.prv /etc/nginx/ssl/mycert.prv
Criar uma VM segura

Agora, crie uma VM com az vm create. Os dados do certificado são injetados no cofre da chave com o
--secrets parâmetro. Você passa a configuração cloud-init com o parâmetro --custom-data :
az vm create \
--name myVM \
--image UbuntuLTS \
--custom-data cloud-init-web-server.txt \
--secrets "$vm_secret"
Demora alguns minutos para que a VM seja criada, os pacotes para instalar e iniciar o aplicativo. Quando a VM
tiver sido criada, observe o publicIpAddress exibido pela CLI do Azure. Este endereço é usado para acessar seu
site em um navegador da Web.
az vm open-port \
--name myVM \
--port 443
Testar o aplicativo Web protegido

Agora, abra um navegador da Web e insira https://<publicIpAddress> na barra de endereços. Forneça seu
próprio endereço de IP público do processo de criação da máquina virtual. Se você usou um certificado
autoassinado, aceite o aviso de segurança:
Seu site de NGINX protegido é exibido, como no exemplo a seguir:
Próximas etapas
Neste tutorial, você protegeu um servidor Web NGINX com um certificado TLS/SSL armazenado no Azure Key
Vault. Você aprendeu a:
Criar uma VM e instalar o servidor Web NGINX
Inserir o certificado na VM e configurar o NGINX com uma associação de TLS
Siga este link para ver exemplos de script de máquina virtual predefinido.
Exemplos de script de máquina virtual do Linux
Tutorial: Proteger um servidor Web em uma
máquina virtual do Windows no Azure com
certificados TLS/SSL armazenados no Key Vault
NOTE
Atualmente, este documento funciona apenas para imagens Generalizadas. Se tentar realizar este tutorial usando um
disco Especializado, você receberá um erro.
Para proteger servidores Web, um certificado de protocolo TLS, anteriormente conhecido como protocolo SSL,
pode ser usado para criptografar o tráfego da Web. Esses certificados TLS/SSL podem ser armazenados no
Azure Key Vault e permitem implantações seguras de certificados em VMs (máquinas virtuais) do Windows no
Azure. Neste tutorial, você aprenderá a:
Criar uma VM e instalar o servidor Web do IIS
Inserir o certificado na VM e configurar o IIS com uma associação de TLS

Visão geral
O cofre da chave do Azure protege chaves criptográficas e segredos, esses certificados ou senhas. O Key Vault
simplifica o processo de gerenciamento de certificados e permite que você mantenha o controle das chaves que
acessam esses certificados. Você pode criar um certificado autoassinado no Key Vault ou carregar um
certificado confiável existente que você já tenha.
Em vez de usar uma imagem de VM personalizada que inclui certificados incorporados, você injeta certificados
em uma VM em execução. Esse processo garante que os certificados mais recentes sejam instalados em um
servidor Web durante a implantação. Se você renova ou substitui um certificado, também não precisa criar uma
nova imagem de VM personalizada. Os certificados mais recentes são inseridos automaticamente, conforme
você cria outras VMs. Durante todo o processo, os certificados nunca deixam a plataforma do Azure ou são
expostos em um script, no histórico da linha de comando ou no modelo.

Antes de criar um Key Vault e certificados, crie um grupo de recursos com New-AzResourceGroup. O exemplo a
seguir cria um grupo de recursos chamado myResourceGroupSecureWeb no local Leste dos EUA:
$resourceGroup = "myResourceGroupSecureWeb"
$location = "East US"
New-AzResourceGroup -ResourceGroupName $resourceGroup -Location $location
Em seguida, crie um Key Vault com New-AzKeyVault. Cada Cofre de Chave requer um nome exclusivo e deve
estar escrito com todas as letras minúsculas. Substitua mykeyvault no exemplo a seguir com seu próprio nome
exclusivo de Cofre da Chave:
$keyvaultName="mykeyvault"
New-AzKeyVault -VaultName $keyvaultName `
-ResourceGroup $resourceGroup `
-EnabledForDeployment
Gerar um certificado e armazenar no Key Vault

Para uso em produção, você deve importar um certificado válido assinado por um fornecedor confiável com
Import-AzKeyVaultCertificate. Para este tutorial, o exemplo a seguir mostra como você pode gerar um
certificado autoassinado com Add-AzKeyVaultCertificate, que usa a política de certificado padrão de New-
AzKeyVaultCertificatePolicy.
$policy = New-AzKeyVaultCertificatePolicy `
-SubjectName "CN=www.contoso.com" `
-SecretContentType "application/x-pkcs12" `
-IssuerName Self `
-ValidityInMonths 12
Add-AzKeyVaultCertificate `
-VaultName $keyvaultName `
-Name "mycert" `
-CertificatePolicy $policy

Defina o nome de usuário e a senha de um administrador para a VM com Get-Credential:
Agora você pode criar a VM com New-AzVM. O exemplo a seguir cria uma VM chamada myVM na localização
EastUs. Se ainda não existirem, os recursos de rede de suporte são criados. Para permitir o tráfego seguro da
Web, o cmdlet também abre a porta 443.
# Create a VM
New-AzVm `
-ResourceGroupName $resourceGroup `
-Name "myVM" `
-Credential $cred `
-OpenPorts 443
# Use the Custom Script Extension to install IIS

Set-AzVMExtension -ResourceGroupName $resourceGroup `
-VMName "myVM" `
-ExtensionType "CustomScriptExtension" `
-SettingString '{"commandToExecute":"powershell Add-WindowsFeature Web-Server -IncludeManagementTools"}'
A criação da VM demora alguns minutos. A última etapa usa a Extensão de Script Personalizado do Azure para
instalar o servidor Web do IIS com Set-AzVmExtension.
Adicionar um certificado à VM a partir do Key Vault

Para adicionar o certificado a partir do Key Vault para uma VM, obtenha a ID de seu certificado com Get-
AzKeyVaultSecret. Adicione o certificado à VM com Add-AzVMSecret:
$certURL=(Get-AzKeyVaultSecret -VaultName $keyvaultName -Name "mycert").id
$vm=Get-AzVM -ResourceGroupName $resourceGroup -Name "myVM"

$vaultId=(Get-AzKeyVault -ResourceGroupName $resourceGroup -VaultName $keyVaultName).ResourceId
$vm = Add-AzVMSecret -VM $vm -SourceVaultId $vaultId -CertificateStore "My" -CertificateUrl $certURL
Update-AzVM -ResourceGroupName $resourceGroup -VM $vm
Configurar o IIS para usar o certificado

Use a Extensão de Script Personalizado novamente com Set-AzVMExtension para atualizar a configuração do IIS.
Esta atualização aplica o certificado inserido do Key Vault para o IIS e configura a associação da Web:
$PublicSettings = '{
"fileUris":["https://raw.githubusercontent.com/Azure-Samples/compute-automation-
configurations/master/secure-iis.ps1"],
"commandToExecute":"powershell -ExecutionPolicy Unrestricted -File secure-iis.ps1"
}'
Set-AzVMExtension -ResourceGroupName $resourceGroup `

-VMName "myVM" `
-SettingString $publicSettings
Testar o aplicativo Web protegido

Obtenha o endereço IP público da VM com Get-AzPublicIPAddress. O exemplo a seguir obtém o endereço IP
para myPublicIP criado anteriormente:
Get-AzPublicIPAddress -ResourceGroupName $resourceGroup -Name "myPublicIPAddress" | select "IpAddress"
Agora, abra um navegador da Web e digite https://<myPublicIP> na barra de endereços. Para aceitar o aviso de
segurança se você usou um certificado autoassinado, selecione Detalhes e Prosseguir para a página da
Web :
Seu site de IIS protegido é exibido, como no exemplo a seguir:

Próximas etapas
Neste tutorial, você protegeu um servidor Web do IIS com um certificado TLS/SSL armazenado no Azure Key
Vault. Você aprendeu a:
Criar uma VM e instalar o servidor Web do IIS
Inserir o certificado na VM e configurar o IIS com uma associação de TLS
Siga este link para ver exemplos de script de máquina virtual predefinido.
Exemplos de script de máquina virtual do Windows
Etapas rápidas: Criar e usar um par de chaves SSH
pública e privada para VMs Linux no Azure
Com um par de chaves SSH (Secure Shell), você pode criar VMs (máquinas virtuais) no Azure que usam chaves
SSH para autenticação. Este artigo mostra como gerar e usar rapidamente um par de arquivos de chaves SSH
pública e privada para VMs Linux. Você pode concluir essas etapas com o Azure Cloud Shell, um host macOS ou
Linux.
NOTE
As VMs criadas usando chaves SSH são por padrão configuradas com senhas desabilitadas, o que aumenta muito a
dificuldade de ataques de adivinhação de força bruta.
Para obter mais informações e exemplos, confira Etapas detalhadas para criar pares de chaves SSH.
Para ver outras maneiras de gerar e usar chaves SSH em um computador Windows, consulte Como usar chaves
SSH com o Windows no Azure.
Formatos de chave SSH compatíveis

No momento, o Azure é compatível com o protocolo SSH 2 RSA (SSH-2) de pares de chaves pública e privada
com tamanho mínimo de 2048 bits. Outros formatos de chave como ED25519 e ECDSA não são compatíveis.
Criar um par de chaves SSH

Use o comando ssh-keygen para gerar arquivos de chave SSH pública e privada. Por padrão, esses arquivos são
criados no diretório ~/.ssh. Você pode especificar um local diferente e uma senha opcional (frase secreta) para
acessar o arquivo de chave privada. Se um par de chaves SSH com o mesmo nome existir no local especificado,
esses arquivos serão substituídos.
O seguinte comando cria um par de chaves SSH usando a criptografia RSA e o tamanho de bit 4096:
Ao usar a CLI do Azure para criar a VM com o comando az vm create, opcionalmente, você pode gerar arquivos
de chave SSH pública e privada executando a opção --generate-ssh-keys . Os arquivos de chave são
armazenados no diretório ~/.ssh, a menos que você especifique outro local com a opção --ssh-dest-key-path .
Se um par de chaves SSH já existir e a --generate-ssh-keys opção for usada, um novo par de chaves não será
gerado, mas em vez disso, o par de chaves existente será usado. No comando a seguir, substitua VMname e
RGname pelos seus próprios valores:
az vm create --name VMname --resource-group RGname --image UbuntuLTS --generate-ssh-keys
Fornecer uma chave pública SSH ao implantar uma VM

Para criar uma VM do Linux que use chaves SSH para autenticação, especifique sua chave pública SSH ao criar a
VM usando o portal do Azure, a CLI do Azure, os modelos do Azure Resource Manager ou outros métodos:
Criar uma máquina virtual Linux com o Portal do Azure
Criar uma máquina virtual Linux com a CLI do Azure
Criar uma VM Linux usando um modelo do Azure
Se você não estiver familiarizado com o formato de uma chave SSH pública, exiba sua chave pública com o
seguinte comando cat , substituindo ~/.ssh/id_rsa.pub pelo caminho e o nome de arquivo do seu próprio
arquivo de chave pública, se necessário:
cat ~/.ssh/id_rsa.pub
Um valor de chave pública típico se parece com este exemplo:
ssh-rsa
AAAAB3NzaC1yc2EAABADAQABAAACAQC1/KanayNr+Q7ogR5mKnGpKWRBQU7F3Jjhn7utdf7Z2iUFykaYx+MInSnT3XdnBRS8KhC0IP8ptbng
IaNOWd6zM8hB6UrcRTlTpwk/SuGMw1Vb40xlEFphBkVEUgBolOoANIEXriAMvlDMZsgvnMFiQ12tD/u14cxy1WNEMAftey/vX3Fgp2vEq4zH
XEliY/sFZLJUJzcRUI0MOfHXAuCjg/qyqqbIuTDFyfg8k0JTtyGFEMQhbXKcuP2yGx1uw0ice62LRzr8w0mszftXyMik1PnshRXbmE2xgINY
g5xo/ra3mq2imwtOKJpfdtFoMiKhJmSNHBSkK7vFTeYgg0v2cQ2+vL38lcIFX4Oh+QCzvNF/AXoDVlQtVtSqfQxRVG79Zqio5p12gHFktlfV
7reCBvVIhyxc2LlYUkrq4DHzkxNY5c9OGSHXSle9YsO3F1J5ip18f6gPq4xFmo6dVoJodZm9N0YMKCkZ4k1qJDESsJBk2ujDPmQQeMjJX3Fn
DXYYB182ZCGQzXfzlPDC29cWVgDZEXNHuYrOLmJTmYtLZ4WkdUhLLlt5XsdoKWqlWpbegyYtGZgeZNRtOOdN6ybOPJqmYFd2qRtb4sYPniGJ
DOGhx4VodXAjT09omhQJpE6wlZbRWDvKC55R2d/CSPHJscEiuudb+1SG2uA/oik/WQ== username@domainname
Se você copiar e colar o conteúdo do arquivo de chave pública a ser usado no portal do Azure ou em um
modelo do Resource Manager, não copie nenhum espaço em branco à direita. Para copiar uma chave pública no
macOS, redirecione o arquivo de chave pública para pbcopy . Como no Linux, é possível redirecionar o arquivo
de chave pública para programas como o xclip .
A chave pública colocada em sua VM do Linux no Azure é armazenada, por padrão, em ~/.ssh/id_rsa.pub, a
menos que tenha especificado um local diferente ao criar o par de chaves. Para usar a CLI do Azure 2.0 para
criar sua VM com uma chave pública existente, especifique o valor e, opcionalmente, o local dessa chave pública
usando o comando az vm create a opção --ssh-key-values . No seguinte comando, substitua myVM,
myResourceGroup, UbuntuLTS , azureuser e mysshkey.pub por valores próprios:
az vm create \
--name myVM \
--image UbuntuLTS \
--ssh-key-values mysshkey.pub
Caso deseje usar várias chaves SSH com a VM, insira-as em uma lista separada por espaço, como este
--ssh-key-values sshkey-desktop.pub sshkey-laptop.pub .
SSH em sua VM
Com a chave pública implantada em sua VM do Azure e a chave privada em seu sistema local, entre com SSH na
VM usando o endereço IP ou o nome DNS da VM. No comando a seguir, substitua azureuser e
myvm.westus.cloudapp.azure.com pelo nome de usuário administrador e o nome de domínio totalmente
qualificado (ou o endereço IP):
ssh azureuser@myvm.westus.cloudapp.azure.com
Se você tiver especificado uma frase secreta quando criou o par de chaves, insira-a quando solicitado durante o
processo de logon. A VM é adicionada ao arquivo ~/.ssh/known_hosts e você não precisará se conectar
novamente até que a chave pública na VM do Azure seja alterada ou o nome do servidor seja removido de
~/.ssh/known_hosts.
Se a VM estiver usando a política de acesso Just-In-Time, você precisará solicitar acesso antes que possa se
conectar à VM. Para obter mais informações sobre a política Just-In-Time, confira Gerenciar o acesso à máquina
virtual usando a política Just-In-Time.
Próximas etapas
Para obter mais informações de como trabalhar com pares de chaves SSH, confira Etapas detalhadas para
criar e gerenciar pares de chaves SSH.
Se você tiver dificuldades com conexões SSH às VM no Azure, confira Solucionar problemas de conexão
SSH a uma VM do Linux no Azure.
Como usar chaves SSH com o Windows no Azure
Este artigo é para usuários do Windows que desejam criar e usar chaves SSH ( Secure Shell ) para se conectar a
VMS (máquinas virtuais) do Linux no Azure. Você também pode gerar e armazenar chaves SSH no portal do
Azure para usar ao criar VMs no Portal.
Para usar chaves SSH de um cliente Linux ou macOS, consulte as etapas rápidas. Para obter uma visão geral
mais detalhada do SSH, consulte etapas detalhadas: criar e gerenciar chaves SSH para autenticação em uma VM
do Linux no Azure.
Visão geral do SSH e das chaves

O SSH é um protocolo de conexão criptografado que permite entradas seguras em conexões não seguras. SSH é
o protocolo de conexão padrão para as VMs Linux hospedadas no Azure. Embora o SSH em si forneça uma
conexão criptografada, o uso de senhas com o SSH ainda deixa a VM vulnerável a ataques de força bruta. É
recomendável conectar-se a uma VM por SSH usando um par de chaves pública-privada, também conhecido
como chaves SSH .
O par de chaves pública-privada é como o bloqueio na sua porta de frente. O bloqueio é exposto ao público ,
qualquer pessoa com a chave correta pode abrir a porta. A chave é privada e só é fornecida às pessoas
confiáveis, pois podem ser usadas para desbloquear a porta.
A chave pública é colocada em sua VM Linux quando você cria a VM.
A chave privada permanece em seu sistema local. Proteja essa chave privada. Não a compartilhe.
Quando você se conecta à VM do Linux, a VM testa o cliente SSH para verificar se ele tem a chave privada
correta. Se o cliente tiver a chave privada, será concedido o acesso à VM.
Dependendo das políticas de segurança de sua organização, você pode reutilizar um único par de chaves para
acessar várias VMs e serviços do Azure. Você não precisa de um par separado de chaves para cada VM.
Sua chave pública pode ser compartilhada com qualquer pessoa, mas apenas você (ou sua infraestrutura de
segurança local) deve ter acesso à sua chave privada.

Clientes SSH
As versões recentes do Windows 10 incluem comandos de cliente do OpenSSH para criar e usar chaves SSH e
fazer conexões SSH do PowerShell ou de um prompt de comando. Essa é a maneira mais fácil de criar uma
conexão SSH para sua VM Linux, de um computador Windows.
Você também pode usar o bash no Azure cloud Shell para se conectar à sua VM. Você pode usar Cloud Shell em
um navegador da Web, na portal do Azureou como um terminal no Visual Studio Code usando a extensão de
conta do Azure.
Você também pode instalar o subsistema do Windows para Linux para se conectar à VM por SSH e usar outras
ferramentas nativas do Linux em um shell bash.
Criar um par de chaves SSH
Crie um par de chaves SSH usando o ssh-keygen comando. Insira um nome de arquivo ou use o padrão
mostrado entre parênteses (por exemplo C:\Users\username/.ssh/id_rsa ). Insira uma frase secreta para o
arquivo ou deixe a frase secreta em branco se você não quiser usar uma frase secreta.
Criar uma VM usando sua chave

Para criar uma VM do Linux que usa chaves SSH para autenticação, forneça sua chave pública SSH ao criar a
VM.
Usando o CLI do Azure, você especifica o caminho e o nome do arquivo para a chave pública usando
az vm create e o --ssh-key-value parâmetro.
az vm create \
--name myVM \
--image UbuntuLTS\
--ssh-key-value ~/.ssh/id_rsa.pub
Com o PowerShell, use New-AzVM e adicione a chave SSH à configuração da VM usando '. Para obter um
exemplo, consulte início rápido: criar uma máquina virtual Linux no Azure com o PowerShell.
Se você fizer muitas implantações usando o portal, talvez queira carregar sua chave pública no Azure, onde ela
pode ser facilmente selecionada ao criar uma VM no Portal. Para obter mais informações, consulte carregar uma
chave SSH.
Conectar-se à sua VM
Com a chave pública implantada em sua VM do Azure e a chave privada em seu sistema local, realize SSH para
sua VM usando o endereço IP ou nome DNS da VM. Substitua azureuser e 10.111.12.123 no comando a seguir
pelo nome de usuário administrador, o endereço IP (ou nome de domínio totalmente qualificado) e o caminho
para a chave privada:
ssh -i ~/.ssh/id_rsa.pub azureuser@10.111.12.123
Se você tiver configurado uma frase secreta quando criou o par de chaves, insira a frase secreta quando
solicitado.
Próximas etapas
Para obter informações sobre chaves SSH no portal do Azure, consulte gerar e armazenar chaves SSH no
portal do Azure para usar ao criar VMs no Portal.
Para ver etapas detalhadas, opções e exemplos avançados para trabalhar com chaves SSH, confira
Detailed steps to create SSH key pairs (Etapas detalhadas para criar pares de chave SSH).
Você também pode usar o PowerShell no Azure Cloud Shell para gerar as chaves SSH e estabelecer
conexões SSH com VMs Linux. Consulte o Início rápido do PowerShell.
Se você tiver dificuldades ao usar o SSH para se conectar às suas VMs Linux, confira Solucionar
problemas de conexão SSH com uma VM Linux no Azure.
Gerar e armazenar chaves SSH no portal do Azure
Se usar o portal com frequência para implantar VMs do Linux, você poderá tornar o uso de chaves SSH mais
simples, criando-as diretamente no portal ou carregando-as do seu computador.
Você pode criar uma chave SSH ao criar uma VM pela primeira vez e reutilizá-las para outras VMs. Ou, você
pode criar chaves SSH separadamente, para que você tenha um conjunto de chaves armazenadas no Azure para
atender às necessidades de suas organizações.
Se você tiver chaves existentes e quiser simplificar o uso deles no portal, poderá carregá-las e armazená-las no
Azure para reutilização.
Para obter informações mais detalhadas sobre como criar e usar chaves SSH com VMs do Linux, consulte usar
chaves SSH para se conectar a VMs Linux.
Gerar novas chaves

2. Na parte superior da página, digite SSH para pesquisar. Em Marketplace , selecione chaves SSH .
3. Na página chave SSH , selecione criar .
4. Em grupo de recursos , selecione criar novo para criar um novo grupo de recursos para armazenar
suas chaves. Digite um nome para seu grupo de recursos e selecione OK .
5. Em região , selecione uma região para armazenar suas chaves. Você pode usar as chaves em qualquer
região, essa é apenas a região em que elas serão armazenadas.
6. Digite um nome para a chave no nome do par de chaves .
7. Em origem de chave pública SSH , selecione gerar fonte de chave pública .
8. Quando terminar, selecione Revisar + criar .
9. Depois de passar na validação, selecione Criar .
10. Em seguida, você receberá uma janela pop-up para, selecione baixar chave privada e criar recurso .
Isso baixará a chave SSH como um arquivo. PEM.
11. Depois que o arquivo. pem for baixado, talvez você queira movê-lo em algum lugar no computador em
que é fácil apontar para o cliente SSH.
Conectar-se à VM
No computador local, abra um prompt do PowerShell e digite:
ssh -i <path to the .pem file> username@<ipaddress of the VM>
Por exemplo, digite: ssh -i /Downloads/mySSHKey.pem azureuser@123.45.67.890
Carregar uma chave SSH

Você também pode carregar uma chave SSH pública para armazenar no Azure. Para obter informações sobre
como criar um par de chaves SSH, consulte usar chaves SSH para se conectar a VMs Linux.
2. Na parte superior da página, digite SSH para pesquisar. Em *Marketplace, selecione chaves SSH .
3. Na página chave SSH , selecione criar .
4. Em grupo de recursos , selecione criar novo para criar um novo grupo de recursos para armazenar
suas chaves. Digite um nome para seu grupo de recursos e selecione OK .
5. Em região , selecione uma região para armazenar suas chaves. Você pode usar as chaves em qualquer
região, essa é apenas a região em que elas serão armazenadas.
6. Digite um nome para a chave no nome do par de chaves .
7. Em origem de chave pública SSH , selecione carregar chave pública existente .
8. Cole o conteúdo completo da chave pública na chave de carregamento e, em seguida, selecione
revisar + criar .
9. Depois de concluir a validação, selecione Criar .
Depois que a chave for carregada, você poderá optar por usá-la ao criar uma VM.
Listar chaves
As chaves SSH criadas no portal são armazenadas como recursos, de modo que você pode filtrar sua exibição
de recursos para ver todas elas.
1. No portal, selecione todos os recursos .
2. Nos filtros, selecione tipo , desmarque a opção selecionar tudo para limpar a lista.
3. Digite SSH no filtro e selecione chave SSH .
Obter a chave pública
Se você precisar de sua chave pública, poderá copiá-la facilmente da página do portal para a chave. Basta listar
suas chaves (usando o processo na última seção) e, em seguida, selecionar uma chave na lista. A página da sua
chave será aberta e você poderá clicar no ícone Copiar na área de transferência ao lado da chave para
copiá-la.
Próximas etapas
Para saber mais sobre como usar chaves SSH com VMs do Azure, confira usar chaves SSH para se conectar a
VMs Linux.
Etapas detalhadas: Criar e gerenciar chaves SSH
para autenticação para uma VM do Linux no Azure
Com um par de chaves SSH (Secure Shell), você pode criar uma máquina virtual Linux que usa chaves SSH para
autenticação. Este artigo mostra como criar e usar um par de arquivos de chave pública-privada do SSH RSA
para conexões de cliente SSH.
Se você quiser usar comandos rápidos, consulte Como criar e usar um par de chaves SSH pública e privada para
VMs Linux no Azure.
Para criar chaves SSH e usá-las para se conectar a um computador com Windows , consulte como usar chaves
SSH com o Windows no Azure. Você também pode usar o portal do Azure para criar e gerenciar chaves SSH
para criar VMs no Portal.
Visão geral do SSH e das chaves

O SSH é um protocolo de conexão criptografado que fornece entradas seguras em conexões não seguras. SSH é
o protocolo de conexão padrão para as VMs Linux hospedadas no Azure. Embora o SSH forneça uma conexão
criptografada, o uso de senhas com conexões SSH ainda deixa a VM vulnerável a ataques de força bruta. É
recomendável conectar-se a uma VM por SSH usando um par de chaves pública-privada, também conhecido
como chaves SSH.
A chave pública é colocada em sua VM Linux.
A chave privada permanece em seu sistema local. Proteja essa chave privada. Não a compartilhe.
Quando você usa um cliente SSH para se conectar à VM do Linux (que tem a chave pública), a VM remota testa
o cliente para verificar se ele tem a chave privada correta. Se o cliente tiver a chave privada, será concedido o
acesso à VM.
Dependendo das políticas de segurança da sua organização, você pode reutilizar um único par de chaves
públicas e privadas para acessar vários serviços e VMs do Azure. Não é preciso um par de chaves separado para
cada VM ou serviço que você deseja acessar.
Sua chave pública pode ser compartilhada com qualquer pessoa, mas apenas você (ou sua infraestrutura de
segurança local) deve ter acesso à sua chave privada.

Benefícios e uso das chaves SSH

Quando você criar uma VM do Azure especificando a chave pública, o Azure copia a chave pública (no formato
.pub ) para a pasta ~/.ssh/authorized_keys na VM. As chaves SSH no ~/.ssh/authorized_keys são usadas para
desafiar o cliente para coincidir com a chave privada correspondente em uma conexão SSH. Em uma VM Linux
do Azure que usa chaves SSH para autenticação, o Azure configura o servidor SSHD para não permitir entrada
com senha, apenas com chaves SSH. Ao criar uma VM Linux do Azure com chaves SSH, você pode ajudar a
proteger a implantação da VM e salvar a etapa de configuração pós-implantação típica de desabilitar as senhas
no sshd_config arquivo.
Se não quiser usar chaves SSH, você ainda poderá configurar suas VMs Linux usando uma autenticação de
senha. Se a VM não for exposta à Internet, o uso de senhas pode ser suficiente. No entanto, ainda é preciso
gerenciar as senhas para cada VM Linux, bem como manter políticas e práticas de senha íntegras, como
tamanho mínimo de senha e atualizações regulares.
Gerar chaves com ssh-keygen

Para criar as chaves, um comando preferencial é ssh-keygen , que está disponível em utilitários OpenSSH no
Azure Cloud Shell, um host do macOS ou do Linux e o Windows 10. O ssh-keygen faz uma série de perguntas e,
em seguida, grava uma chave privada e uma chave pública correspondente.
As chaves SSH são mantidas por padrão no diretório ~/.ssh . Se você não tiver um diretório ~/.ssh ,o
comando ssh-keygen o criará para você com as permissões corretas.
Exemplo básico
O comando a seguir ssh-keygen gera arquivos de chave pública e privada RSA do ssh de 4096 bits por padrão
no ~/.ssh diretório. Se um par de chaves SSH existir no local atual, esses arquivos serão substituídos.
Exemplo detalhado
O exemplo a seguir mostra as opções de comando adicionais para criar um par de chaves SSH RSA. Se um par
de chaves SSH existir no local atual, esses arquivos serão substituídos.
ssh-keygen \
-m PEM \
-t rsa \
-b 4096 \
-C "azureuser@myserver" \
-f ~/.ssh/mykeys/myprivatekey \
-N mypassphrase
Comando explicado
ssh-keygen = programa usado para criar as chaves
-m PEM = formatar a chave como PEM
-t rsa = tipo de chave a ser criada, nesse caso o formato de RSA
-b 4096 = o número de bits na chave, nesse caso, 4096
-C "azureuser@myserver" = um comentário acrescentado ao fim do arquivo de chave pública para identificá-lo
facilmente. Normalmente, um endereço de email é usado como o comentário, mas você pode usar o que
melhor funcionar para sua infraestrutura.
-f ~/.ssh/mykeys/myprivatekey= o nome do arquivo de chave privada se você optar por não usar o nome
padrão. Um arquivo de chave pública correspondente é acrescentado com .pub e gerado no mesmo diretório.
O diretório precisa existir.
-N mypassphrase = uma frase secreta adicional usada para acessar o arquivo de chave privada.
Exemplo de ssh-keygen
ssh-keygen -t -m PEM rsa -b 4096 -C "azureuser@myserver"
Generating public/private rsa key pair.
Enter file in which to save the key (/home/azureuser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/azureuser/.ssh/id_rsa.
Your public key has been saved in /home/azureuser/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:vFfHHrpSGQBd/oNdvNiX0sG9Vh+wROlZBktNZw9AUjA azureuser@myserver
The key's randomart image is:
+---[RSA 4096]----+
| .oE=*B*+ |
| o+o.*++|
| .oo++*|
| . .B+.O|
| S o=BO.|
| . .o++o |
| . ... . |
| .. . |
| .. |
+----[SHA256]-----+
Arquivos de chave salvos

Enter file in which to save the key (/home/azureuser/.ssh/id_rsa): ~/.ssh/id_rsa
O nome do par de chaves para este artigo. Ter um par de chaves denominado id_rsa é o padrão; algumas
ferramentas podem esperar o nome de arquivo da chave privada id_rsa , portanto, é uma boa ideia ter um. O
diretório ~/.ssh/ é o local padrão para os pares de chave SSH e o arquivo de configuração SSH. Se não for
especificado com um caminho completo, ssh-keygen criará as chaves no diretório de trabalho atual e não o
~/.ssh padrão.
Lista do diretório ~/.ssh
ls -al ~/.ssh
-rw------- 1 azureuser staff 1675 Aug 25 18:04 id_rsa
-rw-r--r-- 1 azureuser staff 410 Aug 25 18:04 id_rsa.pub
Frase secreta da chave

Enter passphrase (empty for no passphrase):
É altamente recomendável adicionar uma frase secreta à sua chave privada. Sem uma frase secreta para
proteger o arquivo de chave, qualquer pessoa com o arquivo poderá usá-lo para entrar em qualquer servidor
com a chave pública correspondente. Portanto, adicionar uma frase secreta oferece mais proteção caso alguém
obtenha acesso ao arquivo da chave privada, concedendo tempo para alterar as chaves.
Gerar chaves automaticamente durante a implantação

Ao usar a CLI do Azure para criar a VM, opcionalmente, você poderá gerar arquivos de chave SSH pública e
privada executando o comando az vm create com a opção --generate-ssh-keys . As chaves são armazenadas no
diretório ~/.ssh. Observe que essa opção de comando não substitui as chaves se elas já existem no local.
Forneça a chave pública SSH ao implantar uma VM

Para criar uma VM Linux que usa chaves SSH para autenticação, forneça sua chave SSH pública ao criar a VM
usando o Portal do Azure, a CLI, modelos do Resource Manager ou outros métodos. Ao usar o portal, insira a
chave pública em si. Se você usar a CLI do Azure para criar a VM com uma chave pública existente, especifique o
valor ou o local dessa chave pública executando o comando az vm create com a opção --ssh-key-value .
Se você não estiver familiarizado com o formato de uma chaves públicas SSH, veja sua chave pública
executando cat da seguinte forma, substituindo ~/.ssh/id_rsa.pub por seu próprio local de arquivo de chave
pública:
cat ~/.ssh/id_rsa.pub
A saída é semelhante à seguinte (mostrada aqui em uma versão editada):
ssh-rsa
XXXXXXXXXXc2EAAAADAXABAAABAXC5Am7+fGZ+5zXBGgXS6GUvmsXCLGc7tX7/rViXk3+eShZzaXnt75gUmT1I2f75zFn2hlAIDGKWf4g12K
WcZxy81TniUOTjUsVlwPymXUXxESL/UfJKfbdstBhTOdy5EG9rYWA0K43SJmwPhH28BpoLfXXXXXG+/ilsXXXXXKgRLiJ2W19MzXHp8z3Lxw
7r9wx3HaVlP4XiFv9U4hGcp8RMI1MP1nNesFlOBpG4pV2bJRBTXNXeY4l6F8WZ3C4kuf8XxOo08mXaTpvZ3T1841altmNTZCcPkXuMrBjYSJ
bA8npoXAXNwiivyoe3X2KMXXXXXdXXXXXXXXXXCXXXXX/ azureuser@myserver
Se você copiar e colar o conteúdo do arquivo de chave pública no Portal do Azure ou em um modelo do
Resource Manager, não copie um espaço em branco adicional nem introduza quebras de linha adicionais. Por
exemplo, caso use o macOS, direcione o arquivo de chave pública (por padrão, ~/.ssh/id_rsa.pub ) para
pbcopy para copiar o conteúdo (há outros programas Linux que fazem o mesmo, como o xclip ).
Se você preferir usar uma chave pública que está em um formato de várias linhas, gere uma chave formatada
RFC4716 em um contêiner de pem da chave pública que você criou anteriormente.
Para criar uma chave formatada RFC4716 com base em uma chave pública SSH existente:
ssh-keygen \
-f ~/.ssh/id_rsa.pub \
-e \
-m RFC4716 > ~/.ssh/id_ssh2.pem
SSH para a VM com um cliente SSH

Com a chave pública implantada em sua VM do Azure e a chave privada em seu sistema local, realize SSH para
sua VM usando o endereço IP ou nome DNS da VM. Substitua azureuser e myvm.westus.cloudapp.azure.com no
comando a seguir pelo nome de usuário administrador e o nome de domínio totalmente qualificado (ou
endereço IP):
Se você tiver fornecido uma senha ao criar o par de chaves, insira a senha quando receber a solicitação durante
o processo de entrada. (O servidor é adicionado à sua pasta ~/.ssh/known_hosts e você não receberá uma
solicitação para se conectar novamente até que a chave pública em sua VM do Azure mude ou o nome do
servidor seja removido do ~/.ssh/known_hosts .)
Usando ssh-agent para armazenar sua frase secreta da chave privada

Para evitar digitar sua frase secreta do arquivo de chave privada a cada entrada do SSH, você poderá usar
ssh-agent para armazenar em cache a frase secreta do arquivo de chave privada. Se você estiver usando um
Mac, o Keychain do macOS armazenará com segurança a frase secreta da chave privada ao invocar ssh-agent .
Verifique e use ssh-agent e ssh-add para informar o sistema SSH sobre os arquivos de chave, para que a frase
secreta não precise ser usada interativamente.
eval "$(ssh-agent -s)"
Agora, adicione a chave privada ao ssh-agent usando o comando ssh-add .
ssh-add ~/.ssh/id_rsa
Agora, a frase secreta da chave privada está armazenada em ssh-agent .
Usar ssh-copy-id para copiar a chave para uma VM existente

Se você já tiver criado uma VM, poderá adicionar uma nova chave pública SSH à sua VM do Linux usando
ssh-copy-id .
ssh-copy-id -i ~/.ssh/id_rsa.pub azureuser@myserver
Criar e configurar um arquivo de configuração do SSH

Você pode criar e configurar um arquivo de configuração SSH ( ~/.ssh/config ) para acelerar os logons e
otimizar o comportamento do seu cliente SSH.
O exemplo a seguir mostra uma configuração simples que você pode usar para entrar rapidamente como um
usuário para uma VM específica usando a chave privada SSH padrão.
Crie o arquivo.
touch ~/.ssh/config
Edite o arquivo para adicionar a nova configuração de SSH
vim ~/.ssh/config
Adicione os parâmetros de configurações apropriadas para a VM do seu host. Neste exemplo, o nome da VM é
MyVM e o nome da conta é azureuser.
# Azure Keys
Host myvm
Hostname 102.160.203.241
User azureuser
# ./Azure Keys
Você pode acrescentar configurações para os hosts adicionais para permitir que cada um use seu próprio par de
chaves dedicado. Consulte o arquivo de configuração SSH para obter mais opções de configuração avançadas.
Agora que tem um par de chaves SSH e um arquivo de configuração do SSH configurado, você pode entrar na
VM do Linux de forma rápida e segura. Quando você executa o comando a seguir, o SSH localiza e carrega as
configurações do bloco Host myvm no arquivo de configuração SSH.
ssh myvm
Na primeira vez que você entrar em um servidor usando uma chave SSH, o comando solicitará a frase secreta
para esse arquivo de chave.
Próximas etapas
A próxima etapa é criar VMs do Linux do Azure usando a nova chave pública SSH. As VMs do Azure criadas com
uma chave pública SSH como a entrada estão mais protegidas do que as VMs criadas com as senhas do método
de entrada padrão.
Criar uma máquina virtual Linux com a CLI do Azure
Criar uma VM Linux usando um modelo do Azure
Instalar e configurar a Área de Trabalho Remota
para conectar-se uma VM do Linux no Azure
As VMs (máquinas virtuais) do Linux no Azure são normalmente gerenciadas a partir da linha de comando
usando uma conexão SSH (secure shell). Para novos usuários Linux, ou para cenários de solução rápida de
problemas, o uso da área de trabalho remota pode ser mais fácil. Este artigo fornece detalhes sobre como
instalar e configurar um ambiente de área de trabalho (xfce) e área de trabalho remota (xrdp) para sua VM do
Linux usando o modelo de implantação do Resource Manager.
Pré-requisitos
Este artigo exige uma VM do Ubuntu 18.04 LTS existente no Azure. Se você precisar criar uma VM, use um dos
seguintes métodos:
A CLI do Azure
O Portal do Azure
Instalar um ambiente de área de trabalho em sua VM do Linux

A maioria das VMs do Linux no Azure não tem um ambiente de área de trabalho instalado por padrão. As VMs
do Linux são gerenciadas normalmente usando conexões SSH, em vez de um ambiente de área de trabalho. Há
vários ambientes de área de trabalho no Linux para sua escolha. Dependendo de sua escolha de ambiente de
área de trabalho, ele pode consumir de um a 2 GB de espaço em disco e demorar de cinco a 10 minutos para
instalar e configurar todos os pacotes necessários.
O exemplo a seguir instala o ambiente de área de trabalho leve xfce4 em uma VM do Ubuntu 18.04 LTS. Os
comandos para outras distribuições variam um pouco (use yum para instalar no Red Hat Enterprise Linux e
configurar as regras selinux apropriadas ou use zypper para instalar no SUSE, por exemplo).
Primeiro, SSH para sua VM. O seguinte exemplo conecta-se à VM chamada myvm.westus.cloudapp.azure.com
com o nome de usuário azureuser. Use seus próprios valores:
Se você estiver usando o Windows e precisar de mais informações sobre como usar o SSH, veja Como usar
chaves do SSH com o Windows.
Em seguida, instale o xfce usando apt da seguinte maneira:
sudo apt-get update

sudo apt-get -y install xfce4
Instalar e configurar um servidor de área de trabalho remoto

Agora que você tem um ambiente de área de trabalho instalado, configure um serviço de área de trabalho
remoto para escutar as conexões de entrada. xrdp é um servidor RDP (Protocolo de Área de Trabalho Remota)
de código-fonte aberto que está disponível na maioria das distribuições Linux e funciona bem com xfce. Instale
o xrdp em sua VM do Ubuntu da seguinte maneira:
sudo apt-get -y install xrdp
sudo systemctl enable xrdp
Diga ao xrdp o ambiente de área de trabalho a ser usado ao iniciar a sessão. Configure xrdp para usar xfce como
seu ambiente de área de trabalho da seguinte maneira:
echo xfce4-session >~/.xsession
Reinicie o serviço xrdp para que as alterações entrem em vigor da seguinte maneira:
sudo service xrdp restart
Definir a senha da conta de usuário local

Se você tiver criado uma senha para sua conta de usuário durante a criação de sua VM, ignore esta etapa. Se
você usar apenas a autenticação de chave SSH e não tiver uma senha de conta local definida, especifique uma
senha antes de usar o xrdp para fazer logon em sua VM. O xrdp não pode aceitar chaves SSH para autenticação.
O seguinte exemplo especifica uma senha para a conta de usuário azureuser:
sudo passwd azureuser
NOTE
A especificação de uma senha não atualiza a configuração de SSHD para permitir logons de senha, caso ela não permita
no momento. De uma perspectiva de segurança, convém conectar-se à sua VM com um túnel SSH usando a autenticação
baseada em chave e, depois, conectar-se ao xrdp. Nesse caso, ignore a etapa a seguir sobre a criação de uma regra de
grupo de segurança de rede para permitir o tráfego de área de trabalho remota.
Criar uma regra de Grupo de Segurança de Rede para tráfego de Área

de Trabalho Remota
Para permitir que o tráfego da Área de Trabalho Remota alcance sua VM do Linux, é necessário criar uma regra
de grupo de segurança de rede que permite ao TCP na porta 3389 acessar sua VM. Para saber mais sobre
grupos de segurança de rede, confira O que é um grupo de segurança de rede? Você também pode usar o
Portal do Azure para criar uma regra de grupo de segurança de rede.
O exemplo a seguir cria uma regra de grupo de segurança de rede com az vm open-port na porta 3389. De CLI
do Azure, não a sessão SSH para sua VM, abra a seguinte regra de grupo de segurança de rede:
az vm open-port --resource-group myResourceGroup --name myVM --port 3389
Conectar-se a sua VM do Linux com um cliente de Área de Trabalho

Remota
Abra o cliente da área de trabalho remota local e conecte-se ao endereço IP ou nome DNS de sua VM do Linux.
Insira o nome de usuário e a senha da conta de usuário em sua VM da seguinte maneira:
Após a autenticação, o ambiente de área de trabalho xfce carregará e será semelhante ao exemplo a seguir:
Se o cliente RDP local usar o NLA (autenticação no nível da rede), talvez você precise desabilitar essa
configuração de conexão. Atualmente, o XRDP não dá suporte ao NLA. Examine também soluções RDP
alternativas que dão suporte ao NLA, como o FreeRDP.
Se você não puder se conectar à sua VM do Linux usando um cliente de Área de Trabalho Remota, use netstat
em sua VM do Linux para verificar se sua VM está escutando conexões RDP da seguinte maneira:
sudo netstat -plnt | grep rdp
O exemplo a seguir mostra a VM escutando na porta TCP 3389, conforme o esperado:
tcp 0 0 127.0.0.1:3350 0.0.0.0:* LISTEN 53192/xrdp-sesman

tcp 0 0 0.0.0.0:3389 0.0.0.0:* LISTEN 53188/xrdp
Se o serviço xrdp-sesman não estiver escutando, em uma VM do Ubuntu, reinicie o serviço da seguinte maneira:
sudo service xrdp restart
Examine os logs em /var/log na VM Ubuntu para obter indicações sobre o motivo de o serviço não estar
respondendo. Você também pode monitorar o syslog durante uma tentativa de conexão de área de trabalho
remota para exibir quaisquer erros:
tail -f /var/log/syslog
Outras distribuições do Linux como Red Hat Enterprise Linux e SUSE podem ter maneiras diferentes de reiniciar
serviços e locais alternativos de arquivos de log para examinar.
Se você não receber nenhuma resposta em seu cliente de área de trabalho remota e não ver quaisquer eventos
no log do sistema, esse comportamento indicará que o tráfego da área de trabalho remota não consegue
alcançar a VM. Examine suas regras de grupo de segurança de rede para garantir que você tenha uma regra
para permitir o TCP na porta 3389. Para saber mais, veja Solucionar problemas de conectividade do aplicativo.
Próximas etapas
Para saber mais sobre como criar e usar chaves SSH com VMs do Linux, veja Criar chaves SSH para VMs do
Linux no Azure.
Para saber mais sobre como usar o SSH do Windows, veja Como usar chaves SSH com o Windows.
Implantar recursos com modelos ARM e Azure
Resource Manager API REST
Este artigo explica como usar a API REST do Azure Resource Manager com modelos de Azure Resource Manager
(modelos ARM) para implantar seus recursos no Azure.
Você pode incluir seu modelo no corpo da solicitação ou vinculá-lo a um arquivo. Se optar pelo arquivo, ele
poderá ser local ou um arquivo externo disponível por meio de um URI. Quando seu modelo estiver em uma
conta de armazenamento, você poderá restringir o acesso a ele e fornecer um token de SAS (Assinatura de
Acesso Compartilhado) durante a implantação.
Escopo da implantação
Você pode direcionar sua implantação para um grupo de recursos, assinatura do Azure, grupo de
gerenciamento ou locatário. Dependendo do escopo da implantação, você usará comandos diferentes.
Para implantar em um grupo de recursos , use Implantações – Criar. A solicitação é enviada para:
PUT
https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/provid
ers/Microsoft.Resources/deployments/{deploymentName}?api-version=2020-06-01
Para implantar em uma assinatura , use Implantações – Criar no escopo da assinatura. A solicitação é
enviada para:
PUT
https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Resources/deployments
/{deploymentName}?api-version=2020-06-01
Para saber mais sobre as implantações de nível de assinatura, confira Criar grupos de recursos e recursos
no nível da assinatura.
Para implantar em um grupo de gerenciamento , use Implantações – Criar no escopo do grupo de
gerenciamento. A solicitação é enviada para:
PUT
https://management.azure.com/providers/Microsoft.Management/managementGroups/{groupId}/providers/Micr
osoft.Resources/deployments/{deploymentName}?api-version=2020-06-01
Para saber mais sobre implantações de nível de grupo de gerenciamento, confira Criar recursos no nível
de grupo de gerenciamento.
Para implantar um locatário , use Implantações – Criar ou atualizar no escopo do locatário. A solicitação
é enviada para:
PUT https://management.azure.com/providers/Microsoft.Resources/deployments/{deploymentName}?api-
version=2020-06-01
Para saber mais sobre implantações de nível de locatário, confira Criar recursos no nível de locatário.
Os exemplos neste artigo usam implantações de grupo de recursos.
Implantar com a API REST

1. Definir Parâmetros e cabeçalhos comuns, incluindo tokens de autenticação.
2. Se você estiver implantando em um grupo de recursos que não existe, crie o grupo de recursos. Forneça
sua ID de assinatura, o nome do novo grupo de recursos e local que você precisa para sua solução. Para
obter mais informações, consulte Criar um grupo de recursos.
PUT
https://management.azure.com/subscriptions/<YourSubscriptionId>/resourcegroups/<YourResourceGroupName
>?api-version=2020-06-01
Com um corpo de solicitação como:
{
"location": "West US",
"tags": {
"tagname1": "tagvalue1"
}
}
3. Antes de implantar seu modelo, você pode visualizar as alterações que o modelo fará no seu ambiente.
Use a operação What-If para verificar se o modelo faz as alterações que você espera. O What-If também
valida o modelo para erros.
4. Para implantar um modelo, forneça a ID da assinatura, o nome do grupo de recursos e o nome da
implantação na URI de solicitação.
PUT
https://management.azure.com/subscriptions/<YourSubscriptionId>/resourcegroups/<YourResourceGroupName
>/providers/Microsoft.Resources/deployments/<YourDeploymentName>?api-version=2019-10-01
No corpo da solicitação, forneça um link para o modelo e o arquivo de parâmetro. Para saber mais sobre
o arquivo de parâmetro, confira Criar arquivo de parâmetro do Resource Manager.
Observe que o mode está definido como incremental . Para executar uma implantação completa, defina
mode como concluída . Tenha cuidado ao usar o modo completo, pois você pode excluir acidentalmente
recursos que não estão em seu modelo.
{
"properties": {
"templateLink": {
"uri": "http://mystorageaccount.blob.core.windows.net/templates/template.json",
"contentVersion": "1.0.0.0"
},
"parametersLink": {
"uri": "http://mystorageaccount.blob.core.windows.net/templates/parameters.json",
},
"mode": "Incremental"
}
}
Se você quiser registrar em log o conteúdo da resposta, o conteúdo da solicitação ou ambos, inclua
debugSetting na solicitação.
{
"properties": {
"templateLink": {
"uri": "http://mystorageaccount.blob.core.windows.net/templates/template.json",
},
"parametersLink": {
"uri": "http://mystorageaccount.blob.core.windows.net/templates/parameters.json",
},
"mode": "Incremental",
"debugSetting": {
"detailLevel": "requestContent, responseContent"
}
}
}
Você pode configurar sua conta de armazenamento para usar um token de SAS (Assinatura de Acesso
Compartilhado). Para obter mais informações, consulte delegar acesso com uma assinatura de acesso
compartilhado.
Se você precisar fornecer um valor confidencial para um parâmetro (como uma senha), adicione esse
valor em um cofre de chaves. Recupere o cofre de chaves durante a implantação, conforme mostrado no
exemplo anterior. Para saber mais, confira Usar o Azure Key Vault para passar um valor de parâmetro
seguro durante a implantação.
5. Em vez de vincular os modelo e parâmetros a um arquivo, você pode incluí-los no corpo da solicitação. O
exemplo a seguir mostra o corpo da solicitação com o modelo e a linha do parâmetro:
{
"properties": {
"mode": "Incremental",
"template": {
"parameters": {
"storageAccountType": {
"type": "string",
"defaultValue": "Standard_LRS",
"allowedValues": [
"Standard_LRS",
"Standard_GRS",
"Standard_ZRS",
"Premium_LRS"
],
"metadata": {
"description": "Storage Account type"
}
},
"location": {
"type": "string",
"metadata": {
}
}
},
"variables": {
"storageAccountName": "[concat(uniquestring(resourceGroup().id), 'standardsa')]"
},
"resources": [
{
"apiVersion": "2018-02-01",
"sku": {
"name": "[parameters('storageAccountType')]"
},
"kind": "StorageV2",
"properties": {}
}
],
"outputs": {
"storageAccountName": {
"type": "string",
"value": "[variables('storageAccountName')]"
}
}
},
"parameters": {
"location": {
"value": "eastus2"
}
}
}
}
6. Para obter o status da implantação do modelo, use Implantações – Obter.
GET
https://management.azure.com/subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/provid
ers/Microsoft.Resources/deployments/{deploymentName}?api-version=2019-10-01
Nome da implantação
Você pode dar um nome à sua implantação, como ExampleDeployment .
Toda vez que você executa uma implantação, uma entrada é adicionada ao histórico de implantação do grupo de
recursos com o nome da implantação. Se você executar outra implantação e fornecer o mesmo nome, a entrada
anterior será substituída pela implantação atual. Se você quiser manter entradas exclusivas no histórico de
implantação, dê a cada implantação um nome exclusivo.
Para criar um nome exclusivo, você pode atribuir um número aleatório. Ou adicione um valor de data.
Se você executar implantações simultâneas no mesmo grupo de recursos com o mesmo nome de implantação,
somente a última implantação será concluída. Todas as implantações com o mesmo nome que não foram
concluídas são substituídas pela última implantação. Por exemplo, se você executar uma implantação chamada
newStorage que implanta uma conta de armazenamento denominada storage1 e, ao mesmo tempo, executar
outra implantação chamada newStorage que implanta uma conta de armazenamento denominada storage2 ,
você implanta apenas uma conta de armazenamento. A conta de armazenamento resultante é denominada
storage2 .
No entanto, se você executar uma implantação chamada newStorage que implanta uma conta de
armazenamento denominada storage1 e imediatamente após a conclusão da execução de outra implantação
chamada newStorage que implanta uma conta de armazenamento denominada storage2 , você tem duas
contas de armazenamento. Um é chamado storage1 , e o outro é nomeado storage2 . Mas, você tem apenas
uma entrada no histórico de implantação.
Ao especificar um nome exclusivo para cada implantação, você pode executá-los simultaneamente sem
conflitos. Se você executar uma implantação chamada newStorage1 que implanta uma conta de armazenamento
denominada storage1 e, ao mesmo tempo, executar outra implantação chamada newStorage2 que implanta
uma conta de armazenamento denominada storage2 , você tem duas contas de armazenamento e duas
entradas no histórico de implantação.
Para evitar conflitos com implantações simultâneas e para garantir entradas exclusivas no histórico de
implantação, dê a cada implantação um nome exclusivo.
Próximas etapas
Para reverter para uma implantação bem-sucedida quando você receber um erro, confira Reverter em caso
de erro para uma implantação bem-sucedida.
Para especificar como lidar com os recursos existentes no grupo de recursos, mas que não estão definidos no
modelo, confira Modos de implantação do Azure Resource Manager.
Para saber mais sobre como lidar com operações assíncronas de REST, confira Track asynchronous Azure
operations (Rastrear operações assíncronas do Azure).
Para saber mais sobre modelos, confira Noções básicas de estrutura e sintaxe dos modelos do ARM.
Crie uma VM a partir de um VHD usando o portal
do Azure
Existem várias maneiras de criar uma máquina virtual (VM) no Azure:

Se você já tiver um disco rígido virtual (VHD) para usar ou quiser copiar o VHD de uma VM existente
para usar, crie uma nova VM, anexando o VHD à nova VM como um sistema operacional disco.
Você pode criar uma nova VM do VHD de uma VM que foi excluído. Por exemplo, se você tiver uma VM
do Azure que não está funcionando corretamente, poderá excluir a VM e usar seu VHD para criar uma
nova VM. Você pode reutilizar o mesmo VHD ou criar uma cópia do VHD criando um instantâneo e, em
seguida, criando um novo disco gerenciado a partir do instantâneo. Embora a criação de um instantâneo
precise de mais algumas etapas, ele preserva o VHD original e fornece um retorno.
Use uma VM clássica e use o VHD para criar uma VM que usa o modelo de implantação do Resource
Manager e discos gerenciados. Para obter melhores resultados, pare a VM clássica no portal do Azure
antes de criar o instantâneo.
Você pode criar uma VM do Azure a partir de um VHD local fazendo o upload do VHD local e anexando-o
a uma nova VM. Você usa o PowerShell ou outra ferramenta para carregar o VHD em uma conta de
armazenamento e, em seguida, cria um disco gerenciado a partir do VHD. Para obter mais informações,
consulte carregar um VHD especializado.
IMPORTANT
Quando você usa um disco especializado para criar uma nova VM, a nova VM retém o nome do computador da VM
original. Outras informações específicas do computador (por exemplo, CMID) também são mantidas e, em alguns casos,
essas informações duplicadas podem causar problemas. Ao copiar uma VM, esteja ciente de quais tipos de informações
específicas do computador seus aplicativos dependem.
Portanto, não use um disco especializado se desejar criar várias VMs. Em vez disso, para implantações maiores, criar uma
imagem e, em seguida usar essa imagem para criar várias VMs.
Recomendamos que você limite o número de implantações simultâneas a 20 VMs de um único instantâneo ou
VHD.
Copiar um disco
Crie um instantâneo e crie um disco a partir do instantâneo. Essa estratégia permite que você mantenha o VHD
original como um substituto:
1. No Portal do Azure, no menu à esquerda, selecione Todos os ser viços .
2. No todos os ser viços caixa de pesquisa, digite discos e, em seguida, selecione discos para exibir a lista de
discos disponíveis.
3. Selecione o disco que você deseja usar. O disco página para que o disco é exibido.
4. No menu na parte superior, selecione criar snapshot .
5. Insira um Nome para o instantâneo.
6. Escolha um Grupo de Recursos para o instantâneo. Você pode usar um grupo de recursos existente ou
criar um novo.
7. Para Tipo de conta , escolha entre Armazenamento padrão (HDD) ou Premium (SSD) .
8. Quando terminar, selecione criar para criar o instantâneo.
9. Depois que o instantâneo foi criado, selecione criar um recurso no menu à esquerda.
10. Na caixa de pesquisa, digite disco gerenciado e, em seguida, selecione Managed Disks na lista.
11. Sobre a página Managed Disks , selecione criar .
12. Insira um nome para o disco.
13. Escolha um Grupo de Recursos para o disco. Você pode usar um grupo de recursos existente ou criar um
novo. Essa seleção também será usada como o grupo de recursos no qual você cria a VM a partir do disco.
14. Para Tipo de conta , escolha entre Armazenamento padrão (HDD) ou Premium (SSD) .
15. Em tipo de fonte , verifique se snapshot está selecionado.
16. Na lista suspensa Fonte instantâneo , selecione o instantâneo que você deseja usar.
17. Faça quaisquer outros ajustes conforme necessário e, em seguida, selecione criar para criar o disco.
Criar uma VM de um disco

Depois de ter o VHD de disco gerenciado que você deseja usar, você pode criar a VM no portal:
1. No Portal do Azure, no menu à esquerda, selecione Todos os ser viços .
2. No todos os ser viços caixa de pesquisa, digite discos e, em seguida, selecione discos para exibir a lista de
discos disponíveis.
3. Selecione o disco que você deseja usar. O disco página esse disco é aberto.
4. Na página Visão geral , verifique se DISK STATE está listado como Desmarcado . Se não estiver, talvez seja
necessário desanexar o disco da VM ou excluir a VM para liberar o disco.
5. No menu na parte superior da página, selecione Criar VM .
6. Na página Básico da nova VM, insira um Nome da máquina vir tual e selecione um grupo de recursos
existente ou crie um novo.
7. Para Tamanho , selecione Alterar tamanho para acessar a página Tamanho .
8. Selecione uma linha do tamanho VM e, em seguida, escolha selecionar .
9. Na página Rede , você pode deixar o portal criar todos os novos recursos ou selecionar uma rede vir tual e
grupo de segurança de rede existente. O portal sempre cria uma nova interface de rede e o endereço IP
público para a nova VM.
10. Na página Gerenciamento , faça as alterações nas opções de monitoramento.
11. Na página Guest config , adicione as extensões conforme necessário.
12. Quando terminar, selecione Review + create .
13. Se a configuração da VM passar na validação, selecione criar para iniciar a implantação.
Próximas etapas
Você também pode usar o PowerShell para carregar um VHD no Azure e criar uma VM especializada.
Criar uma VM do Windows a partir de um disco
especializado usando o PowerShell
Crie uma nova VM anexando um disco gerenciado especializado como o disco do sistema operacional. Um
disco especializado é uma cópia de um disco rígido virtual (VHD) de uma VM existente que contém as contas de
usuário, aplicativos e outros dados de estado de sua VM original.
Você tem várias opções:
Use um disco gerenciado existente. Essa opção é útil se você tiver uma VM que não esteja funcionando
corretamente. Você pode excluir a VM e reutilizar o disco gerenciado para criar uma nova VM.
Carregar um VHD
Copie uma VM do Azure existente usando snapshots
Você também pode usar o portal do Azure para criar uma nova VM a partir de um VHD especializado.
Este artigo mostra como usar discos gerenciados. Se você tiver uma implantação legada que exija o uso de uma
conta de armazenamento, consulte Criar uma VM a partir de um VHD especializado em uma conta de
armazenamento.
IMPORTANT
Quando você usa um disco especializado para criar uma nova VM, a nova VM retém o nome do computador da VM
original. Outras informações específicas do computador (por exemplo, CMID) também são mantidas e, em alguns casos,
essas informações duplicadas podem causar problemas. Ao copiar uma VM, esteja ciente de quais tipos de informações
específicas do computador seus aplicativos dependem.
Portanto, não use um disco especializado se desejar criar várias VMs. Em vez disso, para implantações maiores, criar uma
imagem e, em seguida usar essa imagem para criar várias VMs.
É recomendável que você limite o número de implantações simultâneas para 20 VMs a partir de um único VHD
ou instantâneo.
Opção 1: usar um disco existente

Se você tinha uma VM que foi excluída e quer reutilizar o disco do sistema operacional para criar uma nova, use
Get-AzDisk.
$resourceGroupName = 'myResourceGroup'
$osDiskName = 'myOsDisk'
$osDisk = Get-AzDisk `
-ResourceGroupName $resourceGroupName `
-DiskName $osDiskName
Agora você pode anexar esse disco como o disco do sistema operacional para uma nova VM.
Opção 2: carregar um VHD especializado

Você pode carregar o VHD de uma VM especializada criado com uma ferramenta de virtualização local, como o
Hyper-V, ou em uma VM exportada de outra nuvem.
Preparar a VM
Use o VHD como-é criar uma nova VM.
Preparar um VHD do Windows para carregar no Azure. Não generalize a VM usando o Sysprep.
Remova quaisquer ferramentas e agentes de virtualização de convidados instalados na VM (como
ferramentas VMware).
Verifique se a VM está configurada para obter o endereço IP e as configurações de DNS do DHCP. Isso
garante que o servidor obtenha um endereço IP dentro da rede virtual quando for inicializado.
Carregar o VHD
Agora você pode carregar um VHD diretamente em um disco gerenciado. Para obter instruções, confira
Carregar um VHD no Azure usando o Azure PowerShell.
Opção 3: Copiar uma VM existente do Azure

Você pode criar uma cópia de uma VM que usa discos gerenciados, tirando um instantâneo da VM e usando
esse instantâneo para criar um novo disco gerenciado e uma nova VM.
Se você quiser copiar uma VM existente para outra região, talvez queira usar azcopy para criar uma cópia de um
disco em outra região.
Tirar um instantâneo do disco do sistema operacional
Você pode tirar um instantâneo de uma VM inteira (incluindo todos os discos) ou de apenas um único disco. As
etapas a seguir mostram como tirar um instantâneo apenas do disco do sistema operacional da VM com o
cmdlet New-AzSnapshot.
Primeiro, defina alguns parâmetros.
$vmName = 'myVM'
$location = 'westus'
$snapshotName = 'mySnapshot'
Obtenha o objeto da VM.
$vm = Get-AzVM -Name $vmName `

-ResourceGroupName $resourceGroupName
Obtenha o nome de disco do sistema operacional.
$disk = Get-AzDisk -ResourceGroupName $resourceGroupName `

-DiskName $vm.StorageProfile.OsDisk.Name
Crie a configuração do instantâneo.
$snapshotConfig = New-AzSnapshotConfig `
-SourceUri $disk.Id `
-OsType Windows `
-CreateOption Copy `
-Location $location
Crie o instantâneo.
$snapShot = New-AzSnapshot `
-Snapshot $snapshotConfig `
-SnapshotName $snapshotName `
Para usar o instantâneo e criar uma VM que precisa ser de alto desempenho, adicione o parâmetro
-AccountType Premium_LRS ao comando New-AzSnapshotConfig. Esse parâmetro cria o instantâneo para que
seja armazenado como um disco gerenciado Premium. Os discos gerenciados premium são mais caros que o
padrão, portanto, verifique se você precisa do Premium antes de usar esse parâmetro.
Criar um novo disco a partir do instantâneo
Crie um disco gerenciado com base no instantâneo usando New-AzDisk. Este exemplo usa myOSDisk para o
nome do disco.
Criar um novo grupo de recursos para a nova VM.
$destinationResourceGroup = 'myDestinationResourceGroup'
New-AzResourceGroup -Location $location `
-Name $destinationResourceGroup
Defina o nome de disco do sistema operacional.
$osDiskName = 'myOsDisk'
Criar o disco gerenciado.
$osDisk = New-AzDisk -DiskName $osDiskName -Disk `

(New-AzDiskConfig -Location $location -CreateOption Copy `
-SourceResourceId $snapshot.Id) `
-ResourceGroupName $destinationResourceGroup
Crie a nova VM
Crie rede e outros recursos de máquina virtual a ser usado pela nova VM.
Crie a sub-rede e a rede virtual
Criar a rede virtual e uma sub-rede para a VM.
1. Crie a sub-rede. Este exemplo cria uma sub-rede chamada mySubNet no grupo de recursos
myDestinationResourceGroup e defina o prefixo de endereço como 10.0.0.0/24.
$subnetName = 'mySubNet'
$singleSubnet = New-AzVirtualNetworkSubnetConfig `
-Name $subnetName `
2. Crie a rede virtual. Este exemplo define o nome da rede virtual como myVnetName, o local como West
US e o prefixo de endereço da rede virtual como 10.0.0.0/16.
$vnetName = "myVnetName"
-Name $vnetName -ResourceGroupName $destinationResourceGroup `
-Subnet $singleSubnet
Criar o grupo de segurança de rede e uma regra RDP

Para poder entrar em sua VM com o RDP (Remote Desktop Protocol), você precisará ter uma regra de segurança
que permita acesso RDP na porta 3389. Em nosso exemplo, o VHD para a nova VM foi criado a partir de uma
VM especializada existente, para que você possa usar uma conta que existia na máquina virtual de origem para
o RDP.
Este exemplo define o nome do grupo de segurança de rede (NSG) para myNsg e o nome da regra de RDP para
myRdpRule.
$nsgName = "myNsg"
$rdpRule = New-AzNetworkSecurityRuleConfig -Name myRdpRule -Description "Allow RDP" `

-Access Allow -Protocol Tcp -Direction Inbound -Priority 110 `
-SourceAddressPrefix Internet -SourcePortRange * `
-DestinationAddressPrefix * -DestinationPortRange 3389
-ResourceGroupName $destinationResourceGroup `
-Name $nsgName -SecurityRules $rdpRule
Para obter mais informações sobre pontos de extremidade e regras do NSG, consulte abrir portas para uma VM
no Azure usando o PowerShell.
Criar um endereço IP público e uma NIC
Para permitir a comunicação com a máquina virtual na rede virtual, você precisará de um endereço IP público e
uma interface de rede.
1. Crie o endereço IP público. Neste exemplo, o nome do endereço IP público é definido como myIP.
$ipName = "myIP"
-Name $ipName -ResourceGroupName $destinationResourceGroup `
-AllocationMethod Dynamic
2. Crie a NIC. Neste exemplo, o nome da NIC é definido como myNicName.
$nicName = "myNicName"
$nic = New-AzNetworkInterface -Name $nicName `
-ResourceGroupName $destinationResourceGroup `
-Location $location -SubnetId $vnet.Subnets[0].Id `
Como definir o nome e tamanho da VM

Este exemplo define o nome da VM para myVM e o tamanho da VM para Standard_A2.
$vmName = "myVM"
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize "Standard_A2"
Como adicionar o NIC
$vm = Add-AzVMNetworkInterface -VM $vmConfig -Id $nic.Id
Adicionar o disco do sistema operacional

Inclua o disco do sistema operacional na configuração usando Set-AzVMOSDisk. Este exemplo define o tamanho
do disco para 128 GB e anexa o disco gerenciado como um disco do sistema operacional do Windows.
$vm = Set-AzVMOSDisk -VM $vm -ManagedDiskId $osDisk.Id -StorageAccountType Standard_LRS `

-DiskSizeInGB 128 -CreateOption Attach -Windows
Concluir a VM
Crie a VM usando New-AzVM com as configurações que acabamos de criar.
New-AzVM -ResourceGroupName $destinationResourceGroup -Location $location -VM $vm
Se esse comando for bem-sucedido, você verá uma saída como esta:
RequestId IsSuccessStatusCode StatusCode ReasonPhrase

--------- ------------------- ---------- ------------
True OK OK
Verificar se a VM foi criada

Você deve ver a VM recém-criada na portal do Azure sob procurar > máquinas vir tuais , ou usando os
seguintes comandos do PowerShell.
$vmList = Get-AzVM -ResourceGroupName $destinationResourceGroup

$vmList.Name
Próximas etapas
Logue na nova máquina virtual. Para obter mais informações, veja Como se conectar e fazer logon em uma
máquina virtual do Azure executando o Windows.
Criar e gerenciar VMs Windows no Azure usando o
Java
Uma VM (Máquina Virtual) do Azure precisa de vários recursos do Azure suporte. Este artigo aborda a criação, o
gerenciamento e a exclusão de recursos de VM usando o Java. Você aprenderá como:
Criar um projeto Maven
Adicionar dependências
Criar credenciais
Criar recursos
Executar tarefas de gerenciamento
Excluir recursos
Executar o aplicativo
São necessários cerca de 20 minutos para a conclusão destas etapas.
Criar um projeto Maven

1. Se você ainda não fez isso, instale o Java.
2. Instale o Maven.
3. Crie uma nova pasta e o projeto:
mkdir java-azure-test
cd java-azure-test
mvn archetype:generate -DgroupId=com.fabrikam -DartifactId=testAzureApp -DarchetypeArtifactId=maven-

archetype-quickstart -DinteractiveMode=false
Adicionar dependências
1. Na pasta testAzureApp , abra o arquivo pom.xml e adicione a configuração de build ao <projeto> para
habilitar a criação do aplicativo:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<configuration>
<mainClass>com.fabrikam.testAzureApp.App</mainClass>
</configuration>
</plugin>
</plugins>
</build>
2. Adicione as dependências necessárias para acessar o SDK do Java do Azure.

<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>azure</artifactId>
<version>1.1.0</version>
</dependency>
<dependency>
<artifactId>azure-mgmt-compute</artifactId>
</dependency>
<dependency>
<artifactId>azure-mgmt-resources</artifactId>
</dependency>
<dependency>
<artifactId>azure-mgmt-network</artifactId>
</dependency>
<dependency>
<groupId>com.squareup.okio</groupId>
<artifactId>okio</artifactId>
</dependency>
<dependency>
<groupId>com.nimbusds</groupId>
<artifactId>nimbus-jose-jwt</artifactId>
<version>3.6</version>
</dependency>
<dependency>
<groupId>net.minidev</groupId>
<artifactId>json-smart</artifactId>
<version>1.0.6.3</version>
</dependency>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
</dependency>
3. Salve o arquivo.
Criar credenciais
Antes de começar essa etapa, verifique se você tem acesso a uma entidade de serviço do Active Directory. Você
também deve registrar a ID do aplicativo, a chave de autenticação e a ID de locatário que precisará em uma
etapa posterior.
Criar o arquivo de autorização
1. Crie um arquivo chamado azureauth.properties e adicione estas propriedades a ele:
subscription=<subscription-id>
client=<application-id>
key=<authentication-key>
tenant=<tenant-id>
managementURI=https://management.core.windows.net/
baseURL=https://management.azure.com/
authURL=https://login.windows.net/
graphURL=https://graph.microsoft.com/
Substitua <subscription-id> pelo identificador da assinatura, <application-id> pelo identificador de

aplicativo do Active Directory, <authentication-key> pela chave do aplicativo e <tenant-id> pelo
identificador do locatário.
2. Salve o arquivo.
3. Defina uma variável de ambiente chamada AZURE_AUTH_LOCATION no shell com o caminho completo
para o arquivo de autenticação.
Criar o cliente de gerenciamento
1. Abra o arquivo App.java em src\main\java\com\fabrikam e verifique se esta declaração de pacote está
na parte superior:
package com.fabrikam.testAzureApp;
2. Abaixo da declaração de pacote, adicione estas instruções de importação:
import com.microsoft.azure.management.Azure;
import com.microsoft.azure.management.compute.AvailabilitySet;
import com.microsoft.azure.management.compute.AvailabilitySetSkuTypes;
import com.microsoft.azure.management.compute.CachingTypes;
import com.microsoft.azure.management.compute.InstanceViewStatus;
import com.microsoft.azure.management.compute.DiskInstanceView;
import com.microsoft.azure.management.compute.VirtualMachine;
import com.microsoft.azure.management.compute.VirtualMachineSizeTypes;
import com.microsoft.azure.management.network.PublicIPAddress;
import com.microsoft.azure.management.network.Network;
import com.microsoft.azure.management.network.NetworkInterface;
import com.microsoft.azure.management.resources.ResourceGroup;
import com.microsoft.azure.management.resources.fluentcore.arm.Region;
import com.microsoft.azure.management.resources.fluentcore.model.Creatable;
import com.microsoft.rest.LogLevel;
import java.io.File;
import java.util.Scanner;
3. Para criar as credenciais do Active Directory necessárias para fazer solicitações, adicione este código ao
método principal da classe App:
try {
final File credFile = new File(System.getenv("AZURE_AUTH_LOCATION"));
Azure azure = Azure.configure()
.withLogLevel(LogLevel.BASIC)
.authenticate(credFile)
.withDefaultSubscription();
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
Criar recursos
Criar o grupo de recursos
Todos os recursos devem estar contidos em um Grupo de recursos.
Para especificar valores para o aplicativo e criar o grupo de recursos, adicione este código ao bloco try no
método principal:
System.out.println("Creating resource group...");
ResourceGroup resourceGroup = azure.resourceGroups()
.define("myResourceGroup")
.withRegion(Region.US_EAST)
.create();
Criar o conjunto de disponibilidade

Os conjuntos de disponibilidade facilitam a manutenção das máquinas virtuais usadas por seu aplicativo.
Para criar o conjunto de disponibilidade, adicione este código ao bloco try no método principal:
System.out.println("Creating availability set...");

AvailabilitySet availabilitySet = azure.availabilitySets()
.define("myAvailabilitySet")
.withExistingResourceGroup("myResourceGroup")
.withSku(AvailabilitySetSkuTypes.MANAGED)
.create();

Um endereço IP público é necessário para se comunicar com a máquina virtual.
Para criar o endereço IP público para a máquina virtual, adicione este código ao bloco try no método principal:
System.out.println("Creating public IP address...");

PublicIPAddress publicIPAddress = azure.publicIPAddresses()
.define("myPublicIP")
.withDynamicIP()
.create();
Criar a rede virtual

Uma máquina virtual precisa estar em uma sub-rede de uma Rede virtual.
Para criar uma sub-rede e uma rede virtual, adicione este código ao bloco try no método principal:
System.out.println("Creating virtual network...");

Network network = azure.networks()
.define("myVN")
.withAddressSpace("10.0.0.0/16")
.withSubnet("mySubnet","10.0.0.0/24")
.create();
Criar a interface de rede

Uma máquina virtual precisa de uma interface de rede para se comunicar na rede virtual.
Para criar um adaptador de rede, adicione este código ao bloco try no método principal:
System.out.println("Creating network interface...");
NetworkInterface networkInterface = azure.networkInterfaces()
.define("myNIC")
.withExistingPrimaryNetwork(network)
.withSubnet("mySubnet")
.withPrimaryPrivateIPAddressDynamic()
.withExistingPrimaryPublicIPAddress(publicIPAddress)
.create();
Criar a máquina virtual

Agora que você criou todos os recursos de suporte, você pode criar uma máquina virtual.
Para criar a máquina virtual, adicione este código ao bloco try no método principal:
System.out.println("Creating virtual machine...");

VirtualMachine virtualMachine = azure.virtualMachines()
.define("myVM")
.withExistingPrimaryNetworkInterface(networkInterface)
.withLatestWindowsImage("MicrosoftWindowsServer", "WindowsServer", "2012-R2-Datacenter")
.withAdminUsername("azureuser")
.withAdminPassword("Azure12345678")
.withComputerName("myVM")
.withExistingAvailabilitySet(availabilitySet)
.withSize("Standard_DS1")
.create();
Scanner input = new Scanner(System.in);
System.out.println("Press enter to get information about the VM...");
input.nextLine();
NOTE
Este tutorial cria uma máquina virtual executando uma versão do sistema operacional do Windows Server. Para saber mais
sobre a seleção de outras imagens, veja Navegar e selecionar imagens de máquina virtual do Azure com o Windows
PowerShell e a CLI do Azure.
Se você quiser usar um disco existente em vez de uma imagem do marketplace, use este código:
ManagedDisk managedDisk = azure.disks.define("myosdisk")

.withWindowsFromVhd("https://mystorage.blob.core.windows.net/vhds/myosdisk.vhd")
.withSizeInGB(128)
.withSku(DiskSkuTypes.PremiumLRS)
.create();
azure.virtualMachines.define("myVM")
.withExistingPrimaryNetworkInterface(networkInterface)
.withSpecializedOSDisk(managedDisk, OperatingSystemTypes.Windows)
.withExistingAvailabilitySet(availabilitySet)
.withSize(VirtualMachineSizeTypes.StandardDS1)
.create();
Executar tarefas de gerenciamento
Durante o ciclo de vida de uma máquina virtual, é possível que você queira executar tarefas de gerenciamento,
como inicialização, interrupção ou exclusão de uma máquina virtual. Além disso, é possível que você queira criar
um código para automatizar tarefas complexas ou repetitivas.
Quando você precisar fazer alguma coisa com a VM, precisará obter uma instância dela. Adicione este código ao
bloco try do método principal:
VirtualMachine vm = azure.virtualMachines().getByResourceGroup("myResourceGroup", "myVM");

Para obter informações sobre a máquina virtual, adicione este código ao bloco try no método principal:
System.out.println("hardwareProfile");
System.out.println(" vmSize: " + vm.size());
System.out.println("storageProfile");
System.out.println(" imageReference");
System.out.println(" publisher: " + vm.storageProfile().imageReference().publisher());
System.out.println(" offer: " + vm.storageProfile().imageReference().offer());
System.out.println(" sku: " + vm.storageProfile().imageReference().sku());
System.out.println(" version: " + vm.storageProfile().imageReference().version());
System.out.println(" osDisk");
System.out.println(" osType: " + vm.storageProfile().osDisk().osType());
System.out.println(" name: " + vm.storageProfile().osDisk().name());
System.out.println(" createOption: " + vm.storageProfile().osDisk().createOption());
System.out.println(" caching: " + vm.storageProfile().osDisk().caching());
System.out.println("osProfile");
System.out.println(" computerName: " + vm.osProfile().computerName());
System.out.println(" adminUserName: " + vm.osProfile().adminUsername());
System.out.println(" provisionVMAgent: " + vm.osProfile().windowsConfiguration().provisionVMAgent());
System.out.println(" enableAutomaticUpdates: " +
vm.osProfile().windowsConfiguration().enableAutomaticUpdates());
System.out.println("networkProfile");
System.out.println(" networkInterface: " + vm.primaryNetworkInterfaceId());
System.out.println("vmAgent");
System.out.println(" vmAgentVersion: " + vm.instanceView().vmAgent().vmAgentVersion());
System.out.println(" statuses");
for(InstanceViewStatus status : vm.instanceView().vmAgent().statuses()) {
System.out.println(" code: " + status.code());
System.out.println(" displayStatus: " + status.displayStatus());
System.out.println(" message: " + status.message());
System.out.println(" time: " + status.time());
}
System.out.println("disks");
for(DiskInstanceView disk : vm.instanceView().disks()) {
System.out.println(" name: " + disk.name());
System.out.println(" statuses");
for(InstanceViewStatus status : disk.statuses()) {
System.out.println(" time: " + status.time());
}
}
System.out.println("VM general status");
System.out.println(" provisioningStatus: " + vm.provisioningState());
System.out.println(" id: " + vm.id());
System.out.println(" name: " + vm.name());
System.out.println(" type: " + vm.type());
System.out.println("VM instance status");
for(InstanceViewStatus status : vm.instanceView().statuses()) {
}
System.out.println("Press enter to continue...");
input.nextLine();
Pare a VM.
Você pode parar uma máquina virtual e manter todas as suas configurações, mas continuará a ser cobrado por
ela, ou pode parar uma máquina virtual e desalocá-la. Quando uma máquina virtual é desalocada, todos os
recursos associados a ela também são desalocadas e a cobrança para eles termina.
Para interromper a máquina virtual sem desalocá-la, adicione este código ao bloco try no método principal:
System.out.println("Stopping vm...");
vm.powerOff();
input.nextLine();
Se você desejar desalocar a máquina virtual, altere a chamada PowerOff para este código:
vm.deallocate();
Iniciar a VM
Para iniciar a máquina virtual, adicione este código ao bloco try no método principal:
System.out.println("Starting vm...");
vm.start();
input.nextLine();
Redimensionar a VM
Muitos aspectos da implantação devem ser considerados ao decidir sobre um tamanho para sua máquina
virtual. Para obter mais informações, consulte Tamanhos de VM.
Para alterar o tamanho da máquina virtual, adicione este código ao bloco try no método principal:
System.out.println("Resizing vm...");
vm.update()
.withSize(VirtualMachineSizeTypes.STANDARD_DS2)
.apply();
input.nextLine();
Adicionar um disco de dados à VM

Para adicionar um disco de dados à máquina virtual que tem 2 GB de tamanho, um LUN igual a 0 e um tipo de
cache ReadWrite, adicione este código ao bloco try no método principal:
System.out.println("Adding data disk...");

vm.update()
.withNewDataDisk(2, 0, CachingTypes.READ_WRITE)
.apply();
System.out.println("Press enter to delete resources...");
input.nextLine();
Excluir recursos
Como você é cobrado pelos recursos utilizados no Azure, sempre é uma boa prática excluir os recursos que não
são mais necessários. Se você quiser excluir as máquinas virtuais e todos os recursos de suporte, tudo o que
precisa fazer é excluir o grupo de recursos.
1. Para excluir o grupo de recursos, adicione este código ao bloco try no método principal:
System.out.println("Deleting resources...");
azure.resourceGroups().deleteByName("myResourceGroup");
2. Salve o arquivo App.java.

Executar o aplicativo
Devem ser necessários cerca de cinco minutos para o aplicativo de console executar completamente do início ao
fim.
1. Para executar o aplicativo, use este comando do Maven:
mvn compile exec:java
2. Antes de pressionar Enter para iniciar a exclusão de recursos, reserve alguns minutos para verificar a
criação dos recursos no portal do Azure. Clique no status de implantação para ver informações sobre a
implantação.
Próximas etapas
Saiba mais sobre como usar as bibliotecas do Azure para Java.
Criar uma máquina virtual Windows usando um
modelo do Resource Manager
Saiba como criar uma máquina virtual do Windows usando um modelo de Azure Resource Manager e Azure
PowerShell do Azure cloud Shell. O modelo usado neste artigo implanta uma única máquina virtual executando
o Windows Server em uma nova rede virtual com uma única sub-rede. Para criar uma máquina virtual do Linux,
consulte como criar uma máquina virtual Linux com modelos de Azure Resource Manager.
Uma alternativa é implantar o modelo do portal do Azure. Para abrir o modelo no portal, selecione o botão
implantar no Azure .

A criação de uma máquina virtual do Azure geralmente inclui duas etapas:
Crie um grupos de recursos. Um grupo de recursos do Azure é um contêiner lógico no qual os recursos do
Azure são implantados e gerenciados. Você deve criar um grupo de recursos antes de criar uma máquina
virtual.
Crie uma máquina virtual.
O exemplo a seguir cria uma VM a partir de um modelo de início rápido do Azure. Veja uma cópia do modelo:
{
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
}
},
"adminPassword": {
"minLength": 12,
"metadata": {
"description": "Password for the Virtual Machine."
}
},
"dnsLabelPrefix": {
"type": "string",
"defaultValue": "[toLower(concat(parameters('vmName'),'-', uniqueString(resourceGroup().id,
parameters('vmName'))))]",
"metadata": {
}
},
"publicIpName": {
"type": "string",
"defaultValue": "myPublicIP",
"metadata": {
"description": "Name for the Public IP used to access the Virtual Machine."
}
},
"publicIPAllocationMethod": {
"type": "string",
"defaultValue": "Dynamic",
"allowedValues": [
"Dynamic",
"Static"
],
"metadata": {
"description": "Allocation method for the Public IP used to access the Virtual Machine."
}
},
"publicIpSku": {
"type": "string",
"defaultValue": "Basic",
"allowedValues": [
"Basic",
"Standard"
],
"metadata": {
"description": "SKU for the Public IP used to access the Virtual Machine."
}
},
"OSVersion": {
"type": "string",
"defaultValue": "2019-Datacenter",
"allowedValues": [
"2008-R2-SP1",
"2012-Datacenter",
"2012-R2-Datacenter",
"2016-Nano-Server",
"2016-Datacenter",
"2019-Datacenter",
"2019-Datacenter-Core",
"2019-Datacenter-Core-smalldisk",
"2019-Datacenter-Core-with-Containers",
"2019-Datacenter-Core-with-Containers-smalldisk",
"2019-Datacenter-smalldisk",
"2019-Datacenter-with-Containers-smalldisk"
],
"metadata": {
"description": "The Windows version for the VM. This will pick a fully patched image of this given
Windows version."
}
},
"vmSize": {
"type": "string",
"defaultValue": "Standard_D2_v3",
"metadata": {
"description": "Size of the virtual machine."
}
},
"location": {
"type": "string",
"metadata": {
}
},
"vmName": {
"type": "string",
"defaultValue": "simple-vm",
"metadata": {
"description": "Name of the virtual machine."
}
}
},
"variables": {
"nicName": "myVMNic",
"subnetName": "Subnet",
"subnetPrefix": "10.0.0.0/24",
"virtualNetworkName": "MyVNET",
"subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'),
variables('subnetName'))]",
"networkSecurityGroupName": "default-NSG"
},
"resources": [
{
"apiVersion": "2019-06-01",
"sku": {
},
"kind": "Storage",
"properties": {}
},
{
"apiVersion": "2020-06-01",
"name": "[parameters('publicIPName')]",
"sku": {
"name": "[parameters('publicIpSku')]"
},
"properties": {
"publicIPAllocationMethod": "[parameters('publicIPAllocationMethod')]",
"dnsSettings": {
}
}
},
{
"apiVersion": "2020-06-01",
"properties": {
"securityRules": [
{
"properties": {
"priority": 1000,
"access": "Allow",
"protocol": "Tcp",
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('virtualNetworkName')]",
"dependsOn": [
],
],
"properties": {
"addressSpace": {
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]",
variables('networkSecurityGroupName'))]"
}
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"name": "[variables('nicName')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPName'))]",
"[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworkName'))]"
],
"properties": {
{
"properties": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPName'))]"
},
"subnet": {
}
}
}
]
}
},
{
"apiVersion": "2020-06-01",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces', variables('nicName'))]"
],
"properties": {
},
"osProfile": {
},
"storageProfile": {
"imageReference": {
"version": "latest"
},
"osDisk": {
"managedDisk": {
}
},
"dataDisks": [
{
"diskSizeGB": 1023,
"lun": 0,
}
]
},
"networkProfile": {
{
"id": "[resourceId('Microsoft.Network/networkInterfaces', variables('nicName'))]"
}
]
},
"enabled": true,
"storageUri": "[reference(resourceId('Microsoft.Storage/storageAccounts',
variables('storageAccountName'))).primaryEndpoints.blob]"
}
}
}
}
],
"outputs": {
"hostname": {
"type": "string",
"value": "[reference(parameters('publicIPName')).dnsSettings.fqdn]"
}
}
}
Para executar o script do PowerShell, selecione Experimente- o para abrir o Azure cloud Shell. Para colar o
script, clique com o botão direito do mouse no Shell e selecione colar :
$resourceGroupName = Read-Host -Prompt "Enter the Resource Group name"

$location = Read-Host -Prompt "Enter the location (i.e. centralus)"
$adminUsername = Read-Host -Prompt "Enter the administrator username"
$adminPassword = Read-Host -Prompt "Enter the administrator password" -AsSecureString
$dnsLabelPrefix = Read-Host -Prompt "Enter an unique DNS name for the public IP"
New-AzResourceGroup -Name $resourceGroupName -Location "$location"

New-AzResourceGroupDeployment `
-TemplateUri "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-vm-simple-
windows/azuredeploy.json" `
-adminUsername $adminUsername `
-adminPassword $adminPassword `
-dnsLabelPrefix $dnsLabelPrefix
(Get-AzVm -ResourceGroupName $resourceGroupName).name
Se você optar por instalar e usar o PowerShell localmente em vez do Azure cloud Shell, este tutorial exigirá o
módulo Azure PowerShell. Execute Get-Module -ListAvailable Az para encontrar a versão. Se você precisa
atualizar, consulte Instalar o módulo do Azure PowerShell. Se você estiver executando o PowerShell localmente,
também precisará executar o Connect-AzAccount para criar uma conexão com o Azure.
No exemplo anterior, você especificou um modelo armazenado no GitHub. Também é possível baixar ou criar
um modelo e especificar o caminho local com o parâmetro --template-file .
Estes são alguns recursos adicionais:
Para saber como desenvolver modelos do Resource Manager, confira a Documentação do Azure Resource
Manager.
Para ver os esquemas de máquina virtual do Azure, consulte referência de modelo do Azure.
Para ver mais exemplos de modelo de máquina virtual, consulte modelos de início rápido do Azure.
Conecte-se à máquina virtual

O último comando do PowerShell do script anterior mostra o nome da máquina virtual. Para se conectar à
máquina virtual, consulte como se conectar e entrar em uma máquina virtual do Azure que executa o Windows.
Próximas etapas
Se houver problemas com a implantação, confira Solução de erros de implantação comuns do Azure com o
Azure Resource Manager.
Saiba como criar e gerenciar uma máquina virtual em Criar e gerenciar VMs Windows com o módulo do
Azure PowerShell.
Confira a sintaxe e as propriedades do JSON para os tipos de recursos que você implantou para saber mais
sobre a criação de modelos:
Microsoft.Network/publicIPAddresses
Microsoft.Network/virtualNetworks
Microsoft. Network/networkInterfaces
Microsoft. Compute/virtualMachines
Como se conectar e entrar em uma máquina virtual
do Azure executando o Windows
Você usará o botão Conectar no portal do Azure para iniciar uma sessão da Área de Trabalho Remota (RDP) a
partir de uma área de trabalho do Windows. Primeiramente, conecte-se à máquina virtual então faça logon.
Para conectar-se a uma VM do Windows por meio de um Mac, será necessário instalar um cliente do RDP para
Mac, como a Área de Trabalho Remota da Microsoft.
Conecte-se à máquina virtual

1. Vá para o portal do Azure a fim de se conectar a uma VM. Pesquise por Máquinas vir tuais e selecione
essa opção.
2. Selecione a máquina virtual na lista.
3. No início da página da máquina virtual, selecione Conectar .
4. Na página Conectar à máquina vir tual , selecione RDP e, em seguida, selecione o Endereço IP e o
Número da por ta apropriados. Na maioria dos casos, o endereço IP e a porta padrão devem ser
usados. Selecione Baixar Arquivo RDP . Se a VM tiver uma política Just-In-Time definida, você primeiro
precisará selecionar o botão Solicitar acesso para solicitar acesso antes de baixar o arquivo RDP. Para
obter mais informações sobre a política Just-In-Time, confira Gerenciar o acesso à máquina virtual
usando a política Just-In-Time.
5. Abra o arquivo RDP baixado e selecione Conectar quando solicitado. Você receberá um aviso de que o
arquivo .rdp é proveniente de um editor desconhecido. Isso é esperado. Na janela Conexão de Área
de Trabalho Remota , selecione Conectar para continuar.
6. Na janela Segurança do Windows , selecione Mais opções e Usar uma conta diferente . Digite as
credenciais de uma conta na máquina virtual e selecione OK .
Conta local (2008) : Isso é geralmente o nome de usuário da conta local e senha que você especificou
ao criar a máquina virtual. Nesse caso, o domínio é o nome da máquina virtual e é inserido como
nomedavm\nome de usuário.
VM ingressada no domínio : Se a VM pertencer a um domínio, digite o nome de usuário no formato
Domínio\Nome de usuário. A conta precisa estar no grupo Administradores ou ter privilégios de acesso
remoto concedidos à VM.
Controlador de domínio : Se a VM for um controlador de domínio, digite o nome de usuário e a senha
da conta de administrador para esse domínio.
7. Selecione Sim para verificar a identidade da máquina virtual e concluir o logon.
TIP
Se o botão Conectar no portal estiver esmaecido e você não estiver conectado ao Azure por meio de uma
Express Route ou de uma conexão VPN Site a Site, será necessário criar e atribuir à VM um endereço IP público
antes de usar o RDP. Para obter mais informações, consulte Endereços IP públicos no Azure.
Conecte-se à máquina virtual usando o PowerShell

Se você estiver usando o PowerShell e tiver instalado o módulo do Azure PowerShell, você também poderá se
conectar usando o cmdlet Get-AzRemoteDesktopFile , conforme mostrado abaixo.
Este exemplo iniciará imediatamente a conexão de RDP, levando você por meio de prompts semelhantes
conforme acima.
Get-AzRemoteDesktopFile -ResourceGroupName "RgName" -Name "VmName" -Launch
Você também pode salvar o arquivo RDP para uso futuro.
Get-AzRemoteDesktopFile -ResourceGroupName "RgName" -Name "VmName" -LocalPath "C:\Path\to\folder"
Próximas etapas
Se você tiver dificuldade para se conectar, consulte Solucionar problemas de conexões de Área de Trabalho
Remota.
Configurando o acesso do WinRM para as
máquinas virtuais no Azure Resource Manager
Aqui estão as etapas que você precisa realizar para configurar uma VM com conectividade do WinRM
1. Criar um cofre de chaves
2. Criará um certificado autoassinado
3. Carregar seu certificado autoassinado no Cofre de Chaves
4. Obtenha a URL para seu certificado autoassinado no Cofre de Chaves
5. Referenciar a URL de seus certificados autoassinados ao criar uma VM
Etapa 1: Criar um cofre de chaves

Você pode usar o comando abaixo para criar o Cofre de Chaves
New-AzKeyVault -VaultName "<vault-name>" -ResourceGroupName "<rg-name>" -Location "<vault-location>" -

EnabledForDeployment -EnabledForTemplateDeployment
Etapa 2: Criar um certificado autoassinado

Você pode criar um certificado autoassinado usando esse script do PowerShell
$certificateName = "somename"
$thumbprint = (New-SelfSignedCertificate -DnsName $certificateName -CertStoreLocation Cert:\CurrentUser\My -

KeySpec KeyExchange).Thumbprint
$cert = (Get-ChildItem -Path cert:\CurrentUser\My\$thumbprint)
$password = Read-Host -Prompt "Please enter the certificate password." -AsSecureString
Export-PfxCertificate -Cert $cert -FilePath ".\$certificateName.pfx" -Password $password
Etapa 3: Carregar seu certificado autoassinado no Cofre de Chaves

Antes de carregar o certificado para o Cofre de Chaves criado na Etapa 1, ele precisa ser convertido em um
formato que o provedor de recursos Microsoft.Compute entenda. O script do PowerShell abaixo permitirá que
você faça isso
$fileName = "<Path to the .pfx file>"
$fileContentBytes = Get-Content $fileName -Encoding Byte
$fileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
[System.Collections.HashTable]$TableForJSON = @{
"data" = $filecontentencoded;
"dataType" = "pfx";
"password" = "<password>";
}
[System.String]$JSONObject = $TableForJSON | ConvertTo-Json
$secret = ConvertTo-SecureString -String $jsonEncoded -AsPlainText –Force

Set-AzKeyVaultSecret -VaultName "<vault name>" -Name "<secret name>" -SecretValue $secret
Etapa 4: Obter a URL para seu certificado autoassinado no Cofre de

Chaves
O provedor de recursos Microsoft.Compute precisa de uma URL para o segredo do Cofre de Chaves ao
provisionar a VM. Isso permite que o provedor de recursos Microsoft.Compute baixe o segredo e crie o
certificado equivalente na VM.
NOTE
A URL do segredo precisa incluir a versão também. Uma URL de exemplo é semelhante a https: /
/contosovault.Vault.Azure.net:443/Secrets/contososecret/01h9db0df2cd4300a20ence585a6s7ve
Modelos
Você pode obter o link para a URL no modelo usando o código abaixo
"certificateUrl": "[reference(resourceId(resourceGroup().name, 'Microsoft.KeyVault/vaults/secrets', '<vault-

name>', '<secret-name>'), '2015-06-01').secretUriWithVersion]"
PowerShell
Você pode obter essa URL usando o comando do PowerShell abaixo
$secretURL = (Get-AzKeyVaultSecret -VaultName "<vault name>" -Name "<secret name>").Id
Etapa 5: Referenciar a URL de seus certificados autoassinados ao criar

uma VM
Modelos do Azure Resource Manager
Ao criar uma VM por meio de modelos, o certificado é referenciado na seção de segredos e na seção winRM
como é apresentado abaixo:
"osProfile": {
...
"secrets": [
{
"sourceVault": {
"id": "<resource id of the Key Vault containing the secret>"
},
"vaultCertificates": [
{
"certificateUrl": "<URL for the certificate you got in Step 4>",
"certificateStore": "<Name of the certificate store on the VM>"
}
]
}
],
"windowsConfiguration": {
...
"winRM": {
"listeners": [
{
"protocol": "http"
},
{
"protocol": "https",
"certificateUrl": "<URL for the certificate you got in Step 4>"
}
]
},
...
}
},
É possível encontrar um modelo de exemplo para o indicado acima em 201-vm-winrm-keyvault-windows

O código-fonte para este modelo pode ser encontrado no GitHub
PowerShell
$vm = New-AzVMConfig -VMName "<VM name>" -VMSize "<VM Size>"

$credential = Get-Credential
$secretURL = (Get-AzKeyVaultSecret -VaultName "<vault name>" -Name "<secret name>").Id
$vm = Set-AzVMOperatingSystem -VM $vm -Windows -ComputerName "<Computer Name>" -Credential $credential -
WinRMHttp -WinRMHttps -ProvisionVMAgent -WinRMCertificateUrl $secretURL
$sourceVaultId = (Get-AzKeyVault -ResourceGroupName "<Resource Group name>" -VaultName "<Vault
Name>").ResourceId
$CertificateStore = "My"
$vm = Add-AzVMSecret -VM $vm -SourceVaultId $sourceVaultId -CertificateStore $CertificateStore -
CertificateUrl $secretURL
Etapa 6: Conectando-se à VM
Antes de poder se conectar à VM você precisará se certificar de que seu computador esteja configurado para o
gerenciamento remoto do WinRM. Inicie o PowerShell como administrador e execute o comando abaixo para
garantir que você esteja configurado.
Enable-PSRemoting -Force
NOTE
Você precisará garantir que o serviço WinRM está em execução se o indicado acima não funcionar. Você pode fazer isso
usando Get-Service WinRM
Quando a instalação estiver concluída, você poderá se conectar à VM usando o comando abaixo
Enter-PSSession -ConnectionUri https://<public-ip-dns-of-the-vm>:5986 -Credential $cred -SessionOption (New-

PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck) -Authentication Negotiate
Extensões e recursos da máquina virtual do Azure
Extensões são pequenos aplicativos que fornecem configuração pós-implantação e automação em VMs do
Azure. A plataforma Azure hospeda muitas extensões que abrangem aplicativos de configuração,
monitoramento, segurança e utilitário da VM. Os editores usam um aplicativo, o encapsulam em uma extensão
e simplificam a instalação. Tudo o que você precisa fazer é fornecer parâmetros obrigatórios.
Como posso encontrar quais extensões estão disponíveis?

Você pode exibir as extensões disponíveis selecionando uma VM, selecionando extensões no menu à esquerda.
Para efetuar pull de uma lista completa de extensões, consulte descobrindo extensões de VM para Linux e
descobrindo extensões de VM para Windows.
Como instalar uma extensão?

As extensões de VM do Azure podem ser gerenciadas usando o CLI do Azure, o PowerShell, os modelos do
Resource Manager e o portal do Azure. Para tentar uma extensão, vá para a portal do Azure, selecione a
extensão de script personalizado e, em seguida, passe um comando ou script para executar a extensão.
Para obter mais informações, consulte extensão de script personalizado do Windows e extensão de script
personalizado do Linux.
Como gerenciar o ciclo de vida do aplicativo de extensão?

Você não precisa se conectar a uma VM diretamente para instalar ou excluir uma extensão. O ciclo de vida da
extensão do Azure é gerenciado fora da VM e integrado à plataforma Azure.
Qualquer outra coisa que devo estar pensando sobre extensões?

Alguns aplicativos de extensão VM individuais podem ter seus próprios pré-requisitos de ambiente, como
acesso a um ponto de extremidade. Cada extensão tem um artigo que explica os pré-requisitos, incluindo quais
sistemas operacionais têm suporte.
Solucionar problemas de extensões

As informações de solução de problemas para cada extensão podem ser encontradas na seção solução de
problemas e supor te na visão geral da extensão. Aqui está uma lista das informações de solução de
problemas disponíveis:
N A M ESPA C E SO L UÇ Ã O DE P RO B L EM A S
Microsoft. Azure. Monitoring. dependencyagent. Dependência de Azure Monitor para Linux

dependencyagentlinux
Microsoft. Azure. Monitoring. dependencyagent. Dependência Azure Monitor para Windows

dependencyagentwindows
Microsoft. Azure. Security. azurediskencryptionforlinux Azure Disk Encryption para Linux

N A M ESPA C E SO L UÇ Ã O DE P RO B L EM A S
Microsoft. Azure. Security. azurediskencryption Azure Disk Encryption para o Windows
Microsoft. COMPUTE. customscriptextension Script personalizado para Windows
Microsoft. ostcextensions. às customscriptforlinux Configuração de estado desejado para Linux
Microsoft. PowerShell. DSC Configuração de estado desejado para o Windows
Microsoft. hpccompute. nvidiagpudriverlinux Extensão de Driver NVIDIA GPU para Linux
Microsoft. hpccompute. nvidiagpudriverwindows Extensão de Driver NVIDIA GPU para Windows
Microsoft. Azure. Security. iaasantimalware da Extensão antimalware para Windows
Microsoft. enterprisecloud. Monitoring. omsagentforlinux Azure Monitor para Linux
Microsoft. enterprisecloud. Monitoring. extensão Azure Monitor para Windows

microsoftmonitoringagent
stackify. linuxagent. Extension. stackifylinuxagentextension Stackify retrace para Linux
vmaccessforlinux. Microsoft. ostcextensions Redefinir senha para Linux
Microsoft. recoveryservices. vmsnapshot Instantâneo para Linux
Microsoft. recoveryservices. vmsnapshot Instantâneo para Windows
Próximas etapas
Para obter mais informações sobre como o agente e as extensões do Linux funcionam, consulte recursos e
extensões de VM do Azure para Linux.
Para obter mais informações sobre como o agente convidado do Windows e as extensões funcionam,
consulte extensões e recursos de VM do Azure para Windows.
Para instalar o agente convidado do Windows, consulte visão geral do agente de máquina virtual do
Windows do Azure.
Para instalar o agente do Linux, consulte visão geral do agente de máquina virtual Linux do Azure.
Recursos e extensões da máquina virtual para Linux
As extensões da máquina virtual (VM) do Azure são pequenos aplicativos que fornecem tarefas de configuração
e automação pós-implantação nas VMs do Azure. Por exemplo, se uma máquina virtual exigir instalação de
software, proteção antivírus ou executar um script dentro dela, uma extensão de VM poderá ser usada. As
extensões da VM do Azure podem ser executadas com a CLI do Azure, o PowerShell, modelos do Azure
Resource Manager e o portal do Azure. As extensões podem ser agrupadas com uma nova implantação de VM
ou executar qualquer sistema existente.
Este artigo fornece uma visão geral das extensões da VM, pré-requisitos para utilização das extensões da VM do
Azure e diretrizes sobre como detectar, gerenciar e remover as extensões da VM. Este artigo fornece
informações generalizadas, pois há muitas extensões de VM disponíveis, cada uma delas tem uma configuração
possivelmente exclusiva. Encontre detalhes específicos sobre cada extensão na documentação individual.
Casos de uso e exemplos

Há várias extensões de VM do Azure diferentes disponíveis, cada uma com um caso de uso específico. Alguns
exemplos incluem:
Aplique as configurações de Estado Desejado do PowerShell a uma VM usando a extensão de DSC para
Linux. Para saber mais, confira Extensão de configuração de Estado Desejado do Azure.
Configure o monitoramento de uma VM com a extensão de VM do Microsoft Monitoring Agent. Para saber
mais, confira Como monitorar uma VM Linux.
Configure o monitoramento da infraestrutura do Azure com a extensão Chef ou Datadog. Para obter mais
informações, consulte os documentos do Chef ou o Blog do Datadog.
Além de extensões específicas ao processo, uma extensão de Script Personalizado está disponível para
máquinas virtuais Windows e Linux. A extensão de Script Personalizado para Linux permite a execução de
qualquer script Bash em uma VM. Scripts personalizados são úteis para a criação de implantações do Azure que
exigem uma configuração que vai além da capacidade das ferramentas nativas do Azure. Para saber mais,
confira Extensão de Script Personalizado de VM do Linux.
Pré-requisitos
Para lidar com a extensão na VM, é necessário ter o Agente Linux do Microsoft Azure instalado. Algumas
extensões individuais têm pré-requisitos, como acesso a recursos ou dependências.
Agente de VM do Azure
O agente de VM do Azure gerencia a interação entre uma VM do Azure e o controlador de malha do Azure. O
agente de VM é responsável por muitos aspectos funcionais de implantação e gerenciamento de VMs do Azure,
incluindo a execução de extensões da VM. O agente de VM do Azure é pré-instalado em imagens do Microsoft
Azure Marketplace e pode ser instalado manualmente em sistemas operacionais com suporte. O Agente de VM
do Azure para Linux é conhecido como o agente para Linux.
Para obter informações sobre sistemas operacionais e instruções de instalação com suporte, consulte agente de
máquina virtual do Azure.
Versões do agente com suporte
Para fornecer a melhor experiência possível, há versões mínimas do agente. Para obter mais informações,
consulte este artigo.
Sistemas operacionais com suporte
O agente para Linux executa em vários sistemas operacionais. No entanto, a estrutura de extensões tem um
limite para os sistemas operacionais com extensões. Para obter mais informações, consulte este artigo.
Algumas extensões não têm suporte em todos os sistemas de operacionais e podem emitir Código de Erro 51,
'SO sem suporte'. Consulte a documentação da extensão individual sobre a capacidade de suporte.
Acesso de rede
Os pacotes de extensão são baixados do repositório de extensão do Armazenamento do Microsoft Azure, e os
carregamentos de status de extensão são postados no Armazenamento do Microsoft Azure. Se usar a versão
com suporte dos agentes, você não precisará permitir o acesso ao Armazenamento do Microsoft Azure na
região da VM, já que poderá usar o agente para redirecionar a comunicação para o controlador de malha do
Azure para comunicações do agente. Se você estiver usando uma versão sem suporte do agente, será
necessário permitir o acesso de saída no armazenamento do Microsoft Azure nessa região por meio da VM.
IMPORTANT
Se você tiver bloqueado o acesso a 168.63.129.16 usando o firewall convidado, as extensões falharão independentemente
das informações acima.
Os agentes só podem ser usados para baixar os pacotes de extensão e o status do relatório. Por exemplo, se
uma instalação da extensão precisar baixar um script do GitHub (Script Personalizado) ou precisar ter acesso ao
Armazenamento do Microsoft Azure (Backup do Azure), então outras portas de firewall/Grupo de Segurança de
Rede precisarão ser abertas. Diferentes extensões têm requisitos diferentes, já que são aplicativos por si só. Para
extensões que exigem acesso ao Armazenamento do Microsoft Azure, você poderá permitir acesso usando
Marcas de Serviço do NSG do Azure para Armazenamento.
Para redirecionar as solicitações de tráfego do agente, o Agente para Linux tem suporte de servidor proxy. No
entanto, esse suporte de servidor proxy não aplica extensões. É necessário configurar cada extensão individual
para trabalhar com um proxy.
Descobrir extensões de VM
Muitas extensões de VM diferentes estão disponíveis para uso com as VMs do Azure. Para consultar uma lista
completa, use az vm extension image list. O exemplo a seguir lista todas as extensões disponíveis no local
westus :
az vm extension image list --location westus --output table
Executar extensões de VM
As extensões da VM do Azure podem ser executadas em VMs existentes, o que é útil quando você precisa fazer
alterações de configuração ou recuperar a conectividade em uma VM já implantada. As extensões de VM
também podem ser agrupadas com implantações de modelo do Azure Resource Manager. Ao usar extensões
com modelos do Resource Manager, as VMs do Azure podem ser implantadas e configuradas sem intervenção
pós-implantação.
Os métodos a seguir podem ser usados para executar uma extensão em uma VM existente.
CLI do Azure
As extensões da VM do Azure podem executar em uma VM existente com o comando az vm extension set. O
exemplo a seguir executa a extensão de script personalizado em uma VM chamada myVM em um grupo de
recursos chamado MyResource Group. Substitua o nome do grupo de recursos de exemplo, o nome da VM e o
script a ser executado (https: / /RAW.githubusercontent.com/me/Project/Hello.sh) com suas próprias
informações.
az vm extension set `
--resource-group myResourceGroup `
--vm-name myVM `
--name customScript `
--publisher Microsoft.Azure.Extensions `
--settings '{"fileUris": ["https://raw.githubusercontent.com/me/project/hello.sh"],"commandToExecute":
"./hello.sh"}'
Quando a extensão executa corretamente, a saída é semelhante ao exemplo a seguir:
info: Executing command vm extension set

+ Looking up the VM "myVM"
+ Installing extension "CustomScript", VM: "mvVM"
info: vm extension set command OK
Portal do Azure
É possível aplicar extensões de VM a uma VM existente por meio do portal do Azure. Selecione a VM no portal,
escolha Extensões e depois selecione Adicionar . Escolha a extensão desejada na lista de extensões disponíveis
e siga as instruções no assistente.
A imagem a seguir mostra a instalação da extensão Script Personalizado do Linux no portal do Azure:

É possível adicionar extensões de VM a um modelo do Azure Resource Manager e executá-las com a
implantação do modelo. Ao implantar uma extensão com um modelo, você pode criar implantações do Azure
totalmente configuradas. Por exemplo, o JSON a seguir é obtido de um modelo do Resource Manager que
implanta um conjunto de VMs com balanceamento de carga e o banco de dados SQL do Azure e, em seguida,
instala um aplicativo .NET Core em cada VM. A extensão da VM se encarrega da instalação do software.
Para obter mais informações, consulte o modelo completo do Resource Manager.
{
"apiVersion": "2015-06-15",
"type": "extensions",
"name": "config-app",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', concat(variables('vmName'),copyindex()))]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Azure.Extensions",
"type": "CustomScript",
"typeHandlerVersion": "2.0",
"autoUpgradeMinorVersion": true,
"settings": {
"fileUris": [
"https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-
linux/scripts/config-music.sh"
]
},
"protectedSettings": {
"commandToExecute": "[concat('sudo sh config-music.sh ',variables('musicStoreSqlName'), ' ',
parameters('adminUsername'), ' ', parameters('sqlAdminPassword'))]"
}
}
}
Para obter mais informações sobre os modelos do Resource Manager, consulte Criando modelos do Azure
Resource Manager.
Proteger dados de extensão da VM

Ao executar uma extensão de VM, talvez seja necessário incluir informações confidenciais, como credenciais,
nomes de conta de armazenamento e chaves de acesso da conta de armazenamento. Muitas extensões de VM
incluem uma configuração protegida que criptografa dados e os descriptografa somente dentro da VM de
destino. Cada extensão tem um esquema específico de configuração protegida, e cada um é detalhado na
documentação específica à extensão.
O exemplo a seguir mostra uma instância da extensão de Script Personalizado para Linux. O comando a ser
executado inclui um conjunto de credenciais. Neste exemplo, o comando a ser executado não é criptografado:
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
"fileUris": [
],
}
}
}
A movimentação da propriedade comando para execução para a configuração protegida protege a cadeia
de caracteres de execução, conforme mostrado no exemplo a seguir:
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
"fileUris": [
]
},
}
}
}
Como agentes e extensões são atualizados?

Os Agentes e as Extensões compartilham o mesmo mecanismo de atualização. Algumas atualizações não
exigem regras de firewall adicionais.
Quando uma atualização estiver disponível, ela só será instalada na VM quando houver uma alteração nas
extensões e outras alterações de Modelo de VM como:
Discos de dados
Extensões
Contêiner de diagnóstico de inicialização
Segredos do sistema operacional convidado
Tamanho da VM
Perfil de rede
Os editores tornam atualizações disponíveis para regiões em momentos diferentes, então é possível ter VMs em
regiões e versões diferentes.
Atualizações de agentes
O Agente de VM Linux contém Código de Agente de Provisionamento e Código de Manipulação de Extensão em
um pacote, que não pode ser separado. É possível desabilitar o Agente de Provisionamento quando quiser
provisionar no Azure utilizando cloud-init. Para fazer isso, consulte usando cloud-init.
Versões com suporte para Agentes podem usar atualizações automáticas. O único código que pode ser
atualizado é o Código de Manipulação de Extensão, não o código de provisionamento. O Código de Agente de
Provisionamento é código de execução única.
O código de Tratamento de Extensão é responsável por se comunicar com a malha do Azure e manipular as
operações de extensões da VM, como instalações, relatando status, atualizando as extensões individuais e
removendo-as. As atualizações contêm correções de segurança, correções de bug e aprimoramentos para o
código de Tratamento de Extensão.
Quando o agente é instalado, um daemon pai é criado. Esse pai, então, gera um processo filho que é usado para
manipular as extensões. Se uma atualização estiver disponível para o agente, ele será baixado, o pai
interromperá o processo filho, fará o upgrade e o reinicializará. Se houver um problema com a atualização, o
processo pai será revertido para a versão filho anterior.
O processo pai não pode ser atualizado automaticamente. O pai somente pode ser atualizado por uma
atualização do pacote de distribuição.
Para verificar qual versão está em execução, verifique waagent , conforme a seguir:
waagent --version
WALinuxAgent-2.2.17 running on ubuntu 16.04

Python: 3.5.2
Goal state agent: 2.2.18
Na saída do exemplo anterior, o pai ou a 'versão implantada por pacote' é WALinuxAgent-2.2.17

O 'Agente de estado de meta' é a versão de atualização automática.
É altamente recomendável sempre ter uma atualização automática para o agente, AutoUpdate.Enabled=y. Não
ter isso habilitado significa que será necessário manter a atualização manual do agente e não receber correções
de bugs e de segurança.
Atualizações de extensão
Quando uma atualização de extensão está disponível, o Agente para Linux baixa e atualiza a extensão.
Atualizações automáticas de extensão são Secundárias ou Hotfix. Você pode aceitar ou recusar atualizações de
extensões Secundárias ao provisionar a extensão. O exemplo a seguir mostra como atualizar automaticamente
as versões secundárias em um modelo do Resource Manager com autoUpgradeMinorVersion": true,':
"settings": {
"fileUris": [
]
},
Para obter as correções de bug de versão secundária mais recentes, é altamente recomendável que você
selecione sempre a atualização automática em suas implantações de extensão. As atualizações de hotfix que
realizam correções de bug essenciais ou de segurança não podem ser recusadas.
Como identificar as atualizações de extensão
Identificar se a extensão foi definida com autoUpgradeMinorVersion em uma VM
Você pode ver no modelo da VM se a extensão foi provisionada com 'autoUpgradeMinorVersion'. Para verificar,
use az vm show e forneça o grupo de recursos e o nome da VM, conforme a seguir:
az vm show --resource-group myResourceGroup --name myVM
O seguinte exemplo de saída mostra que autoUpgradeMinorVersion foi definido como true:
"resources": [
{
"forceUpdateTag": null,
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM/extensi
ons/CustomScriptExtension",
Identificar quando ocorreu uma autoUpgradeMinorVersion

Para ver quando ocorreu uma atualização na extensão, revise os logs do agente na VM em /var/log/waagent.log.
No exemplo abaixo, a VM tinha o Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9025 instalado. Um hotfix
estava disponível para Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027:
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Expected handler state: enabled

INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Decide which version to use
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Use version: 2.3.9027
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Current handler state is: NotInstalled
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Download extension package
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Unpack extension package
INFO Event: name=Microsoft.OSTCExtensions.LinuxDiagnostic, op=Download, message=Download succeeded
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Initialize extension directory
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Update settings file: 0.settings
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9025] Disable extension.
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9025] Launch command:diagnostic.py -disable
...
INFO Event: name=Microsoft.OSTCExtensions.LinuxDiagnostic, op=Disable, message=Launch command succeeded:
diagnostic.py -disable
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Update extension.
INFO [Microsoft.OSTCExtensions.LinuxDiagnostic-2.3.9027] Launch command:diagnostic.py -update
2017/08/14 20:21:57 LinuxAzureDiagnostic started to handle.
Permissões de agente
Para executar as tarefas, o agente precisa executar como raiz.
Solucionar problemas de extensões de VM

Cada extensão de VM pode ter etapas de solução de problemas específicas à extensão. Por exemplo, ao usar a
extensão Script Personalizado, detalhes de execução do script poderão ser encontrados localmente na VM na
qual a extensão foi executada. As etapas de solução de problemas específicas à extensão são detalhadas na
documentação associada.
As seguintes etapas de solução de problemas aplicam-se a todas as extensões da VM.
1. Para verificar o Log do agente do Linux, observe a atividade em que a extensão estava sendo
provisionada em /var/log/waagent.log
2. Verifique os logs de extensão reais para mais detalhes em /var/log/azure/<extensionName>
3. Verifique as seções de solução de problemas da documentação específica da extensão para códigos de
erro, problemas conhecidos etc.
4. Examine os logs do sistema. Verifique se há outras operações que podem ter interferido na extensão,
como uma instalação de longa execução de outro aplicativo que exigia acesso exclusivo ao gerenciador
de pacotes.
Motivos comuns para falhas na extensão
1. As extensões têm 20 minutos para serem executadas (exceções são as extensões de CustomScript, Chef e
DSC que têm 90 minutos). Se a implantação exceder esse tempo, será marcada como um tempo limite.
Isso pode ocorrer devido a poucas VMs de recursos, outras configurações da VM/tarefas de inicialização
consumindo grande quantidade de recursos durante a extensão que está tentando provisionar.
2. Pré-requisitos mínimos não atendidos. Algumas extensões têm dependências em SKUs da VM, como
imagens HPC. As extensões podem exigir certos requisitos de acesso à rede, como comunicação com o
Armazenamento do Microsoft Azure ou serviços públicos. Outros exemplos podem ser o acesso a
repositórios de pacote, ficando sem espaço em disco, ou restrições de segurança.
3. Acesso exclusivo ao gerenciador de pacotes. Em alguns casos, você pode encontrar uma configuração da
VM de longa execução e uma instalação da extensão em conflito, nas quais ambas precisam de acesso
exclusivo ao gerenciador de pacotes.
Exibir o status da extensão
Depois que uma extensão da VM tiver sido executada em uma VM, use az vm get-instance-view para retornar o
status da extensão, conforme a seguir:
az vm get-instance-view \
--resource-group rgName \
--name myVM \
--query "instanceView.extensions"
A saída é semelhante ao seguinte exemplo de saída:

{
"name": "customScript",
"statuses": [
{
"code": "ProvisioningState/failed/0",
"displayStatus": "Provisioning failed",
"level": "Error",
"message": "Enable failed: failed to execute command: command terminated with exit
status=127\n[stdout]\n\n[stderr]\n/bin/sh: 1: ech: not found\n",
"time": null
}
],
"substatuses": null,
"type": "Microsoft.Azure.Extensions.customScript",
"typeHandlerVersion": "2.0.6"
}
O status de execução da extensão também pode ser encontrado no Portal do Azure. Para exibir o status de uma
extensão, selecione a VM, escolha Extensões e selecione a extensão desejada.
Executar novamente uma extensão de VM
Pode haver casos nos quais uma extensão da VM precisa ser executada novamente. Você pode executar
novamente uma extensão removendo-a e, em seguida, executando novamente a extensão com um método de
execução de sua escolha. Para remover uma extensão, use az vm extension delete, conforme a seguir:
az vm extension delete \
--vm-name myVM \
--name customScript
Você também pode remover uma extensão no portal do Azure da seguinte maneira:
1. Selecione uma VM.
2. Escolha Extensões .
3. Selecione a extensão desejada.
4. Escolha Desinstalar .
Referência à extensão VM comum

N O M E DA EXT EN SÃ O DESC RIÇ Ã O M A IS IN F O RM A Ç Õ ES
Extensão de Script Personalizado para Executar scripts em uma máquina Extensão de Script Personalizado para
Linux virtual do Azure Linux
Extensão de acesso à VM Restabelecer o acesso a uma máquina Extensão de acesso à VM

virtual do Azure
Extensão de Diagnóstico do Azure Gerenciar Diagnóstico do Azure Extensão de Diagnóstico do Azure
Extensão de Acesso à VM do Azure Gerenciar usuários e credenciais Extensão de Acesso à VM para Linux
Próximas etapas
Para obter mais informações sobre extensões de VM, consulte Visão geral de recursos e extensões de máquina
virtual do Azure.
Noções básicas e uso do Agente Linux do Azure
O Agente Linux do Microsoft Azure (waagent) gerencia o provisionamento de Linux e FreeBSD e a interação de
VM com o Controlador de malha do Azure. Além do Agente do Linux fornecendo a funcionalidade de
provisionamento, o Azure também fornece a opção de usar a inicialização de nuvem para alguns OSes Linux. O
Agente Linux fornece a seguinte funcionalidade para implantações IaaS do Linux e FreeBSD:
NOTE
Para obter mais informações, veja o README.
Provisionamento de imagem
Criação de uma conta de usuário
Configurando os tipos de autenticação do SSH
Implantação de chaves públicas do SSH e pares de chaves
Configuração do nome de host
Publicando o nome do host para a plataforma de DNS
Relatório de impressão digital da chave host SSH para a plataforma
Gerenciamento de recursos de disco
Formatação e montagem do disco do recurso
Configurando o espaço de permuta
Rede
Gerencia as rotas para melhorar a compatibilidade com os servidores DHCP de plataforma
Garante a estabilidade do nome da interface de rede
Kernel
Configura NUMA virtual (desabilitar para kernel < 2.6.37 )
Consome entropia de Hyper-V para /dev/random
Configura os tempos limite de SCSI para o dispositivo raiz (o qual poderia ser remoto)
Diagnóstico
Redirecionamento de console de porta serial
Implantações SCVMM
Detecta e inicializa o agente VMM para Linux quando executado em um ambiente de System Center
Virtual Machine Manager 2012 R2
Extensão de VM
Injete o componente criado pela Microsoft e seus Parceiros na VM do Linux (IaaS) para habilitar o
software e a automação da configuração
Implementação de referência de extensão de VM em https://github.com/Azure/azure-linux-extensions
Comunicação
O fluxo de informações da plataforma para o agente ocorre por meio de dois canais:
Um DVD anexado ao tempo de inicialização para as implementações de IaaS. Este DVD inclui um arquivo de
configuração compatível com OVF que inclui todas as informações de configuração que não seja os pares de
chaves SSH real.
Um ponto de extremidade TCP expondo uma API REST usada para obter a implantação e a configuração de
topologia.
Requisitos
Os sistemas a seguir foram testados e funcionam com o agente Linux do Azure:
NOTE
Essa lista pode ser diferente da lista oficial de distribuições com suporte.
CoreOS
CentOS 6.3+
Red Hat Enterprise Linux 6.7+
Debian 7.0+
Ubuntu 12.04+
openSUSE 12.3+
SLES 11 SP3+
Oracle Linux 6.4+
Outros sistemas com suporte:
FreeBSD 10+ (Agente Linux do Azure v2.0.10+)
O agente do Linux depende de alguns pacotes de sistema para funcionar corretamente:
Python 2.6+
OpenSSL 1.0+
OpenSSH 5.3+
Utilitários de sistema de arquivos: sfdisk, fdisk, mkfs, parted
Ferramentas de senha: chpasswd, sudo
Ferramentas de processamento de texto: sed, grep
Ferramentas de rede: roteamento ip
Suporte a kernel para montar sistemas de arquivos UDF.
Verifique se sua VM tem acesso ao endereço IP 168.63.129.16. Para obter mais informações, consulte o que é o
endereço IP 168.63.129.16.
Instalação
Instalação usando um RPM ou um pacote DEB do repositório de pacotes da distribuição é o método preferencial
para instalar e atualizar o Azure do Agente Linux do Azure. Todos os provedores de distribuição aprovados
integram o pacote do agente Linux do Azure em suas imagens e repositórios.
Consulte a documentação do repositório do agente Linux do Azure no GitHub para ver opções de instalação
avançada, como instalação da origem ou em locais personalizados ou prefixos.
Opções de Linha de Comando

Flags
verbose: aumentar o nível de detalhes do comando especificado
forçar: Ignorar confirmação interativa para alguns comandos
Comandos
Ajuda: lista os comandos com suporte e sinalizadores.
deprovisionar: tentativa de limpar o sistema e torná-lo adequado para reprovisionamento. A operação a
seguir deleta:
Todas as chaves de host SSH (se Provisioning.RegenerateSshHostKeyPair for 'y' no arquivo de
configuração)
Configuração de servidor de nomes em /etc/resolv.conf
Senha raiz do /etc/shadow (se Provisioning.DeleteRootPassword for 'y' no arquivo de configuração)
Concessões de cliente DHCP em cache
Reinicia o nome de host para localdomain.localdomain
WARNING
O desprovisionamento não garante que a imagem estará livre de todas as informações confidenciais e adequada para
redistribuição.
deprovisionar + usuário: executa tudo em - deprovisiona (acima) e também exclui a última conta de usuário
provisionado (obtida em /var/lib/waagent) e dados associados. Este parâmetro é quando a desconfiguração
de uma imagem que foi anteriormente provisionamento no Azure para podem ser capturada e usada
novamente.
versão: exibe a versão do waagent
serialconsole: configura GRUB para marcar ttyS0 (a primeira porta serial) como o console de inicialização.
Isso garante que os logs de inicialização do kernel são enviados para a porta serial e disponibilizados para
depuração.
daemon: executar waagent como um daemon para gerenciar a interação com a plataforma. Esse argumento
é especificado para waagent no script de inicialização de waagent.
Iniciar: executar waagent como um processo em segundo plano
Configuração
Um arquivo de configuração (/ etc/waagent.conf) controla as ações de waagent. A seguir mostra um arquivo de
configuração de exemplo:
Provisioning.Enabled=y
Provisioning.DeleteRootPassword=n
Provisioning.RegenerateSshHostKeyPair=y
Provisioning.SshHostKeyPairType=rsa
Provisioning.MonitorHostName=y
Provisioning.DecodeCustomData=n
Provisioning.ExecuteCustomData=n
Provisioning.AllowResetSysUser=n
Provisioning.PasswordCryptId=6
Provisioning.PasswordCryptSaltLength=10
ResourceDisk.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.MountOptions=None
ResourceDisk.EnableSwap=n
ResourceDisk.SwapSizeMB=0
LBProbeResponder=y
Logs.Verbose=n
OS.RootDeviceScsiTimeout=300
OS.OpensslPath=None
HttpProxy.Host=None
HttpProxy.Port=None
AutoUpdate.Enabled=y
Várias opções de configuração são descritas em detalhes abaixo. Há três tipos opções de configuração: Booliano,
String ou Integer. As opções de configuração booliana podem ser especificadas como "y" ou "n". A palavra-chave
especial "Nenhum" pode ser usado para entradas de configuração de tipo algum sequência conforme seguintes
detalhes:
Provisioning.Enabled:
Type: Boolean
Default: y
Isso permite que o usuário habilite ou desabilite a funcionalidade de provisionamento no agente. Os valores
válidos são "y" ou "n". Se o provisionamento for desabilitado, as chaves SSH de host e usuário da imagem serão
preservadas e qualquer configuração especificada na API de provisionamento do Azure será ignorada.
NOTE
O parâmetro Provisioning.Enabled segue o padrão "n" do Ubuntu Cloud Images, que usa cloud-init para
provisionamento.
Provisioning.DeleteRootPassword:
Type: Boolean
Default: n
Se definido, a senha raiz no arquivo sombra é apagado durante o processo de provisionamento.

Provisioning.RegenerateSshHostKeyPair :
Type: Boolean
Default: y
Se o conjunto de todos os SSH host pares de chaves (ecdsa, dsa e rsa) será excluído durante o processo de
provisionamento de /etc/ssh/. E um único par de chave novo é gerado.
O tipo de criptografia para o novo par de chaves é configurável pela entrada do
Provisioning.SshHostKeyPairType. Algumas distribuições novamente criam pares de chaves SSH para todos os
tipos de criptografia está faltando quando é reiniciado o daemon do SSH (por exemplo, após uma
reinicialização).
Provisioning.SshHostKeyPairType:
Type: String
Default: rsa
Isso pode ser definido como um tipo de algoritmo de criptografia com suporte pelo daemon SSH na máquina
virtual. Os valores geralmente aceitos são "rsa", "dsa" e "ecdsa". "putty.exe" no Windows não oferece suporte a
"ecdsa". Portanto, se você pretende usar putty.exe no Windows para conectar-se a uma implantação do Linux,
use "rsa" ou "dsa".
Provisioning.MonitorHostName:
Type: Boolean
Default: y
Se definido, waagent monitora máquina virtual Linux para alterações de nome do host (conforme retornado
pelo comando "hostname") e atualizar automaticamente a configuração de rede da imagem para refletir a
alteração. Para enviar a alteração do nome para os servidores DNS, a rede é reiniciada na máquina virtual. Isso
resulta em resumo perda de conectividade com a Internet.
Provisioning.DecodeCustomData
Type: Boolean
Default: n
Se definido, o waagent decodifica o CustomData da Base64.

Provisioning.ExecuteCustomData
Type: Boolean
Default: n
Se definido, o waagent executa o CustomData após o provisionamento.

Provisioning.AllowResetSysUser
Type: Boolean
Default: n
Essa opção permite que a senha do usuário sys seja redefinida; o padrão é ficar desabilitada.
Provisioning.PasswordCr yptId
Type: String
Default: 6
Algoritmo usado pelo Crypt ao gerar o hash de senha.

1 - MD5
2a - Blowfish
5 - SHA-256
6 - SHA-512
Provisioning.PasswordCr yptSaltLength
Type: String
Default: 10
Comprimento de sal aleatório usado ao gerar o hash de senha.

ResourceDisk . Format:
Type: Boolean
Default: y
Se definido, o disco de recursos fornecido pela plataforma é formatado e montado por waagent se o tipo de
sistema de arquivos solicitado pelo usuário em "ResourceDisk.Filesystem" for algo diferente de "ntfs". Uma
única partição do tipo Linux (83) é disponibilizada no disco. Esta partição não é formatada se ela pode ser
montado com êxito.
ResourceDisk . FileSystem:
Type: String
Default: ext4
Especifica o tipo de sistema de arquivos para o disco do recurso. Valores aceitos variam de acordo com a
distribuição do Linux. Se a sequência for X, em seguida, mkfs.X deve estar presente na imagem do Linux.
Imagens de 11 SLES geralmente devem utilizar 'ext3'. FreeBSD imagens devem usar 'ufs2' aqui.
ResourceDisk .MountPoint:
Type: String
Default: /mnt/resource
Especifica o caminho em que o disco do recurso é montado. O disco de recurso é um disco temporário e pode
ser esvaziado quando a VM é desprovisionada.
ResourceDisk .MountOptions
Type: String
Default: None
Especifica opções de montagem de disco a serem passadas ao comando de montagem -o. Trata-se de uma lista
de valores separados por vírgulas, por exemplo. 'nodev, nosuid'. Consulte montagem(8) para obter detalhes.
ResourceDisk .EnableSwap:
Type: Boolean
Default: n
Se definir um arquivo de permuta (/ arquivo de permuta) é criado no disco recursos e adicionado ao espaço de
troca de sistema.
ResourceDisk . SwapSizeMB:
Type: Integer
Default: 0
Especifica o tamanho máximo do arquivo de permuta em megabytes.

Logs.Verbose:
Type: Boolean
Default: n
Se definido, a verbosidade do log é aumentado. Waagent faz /var/log/waagent.log e utiliza a funcionalidade de

logrotate do sistema para girar os logs.
OS.EnableRDMA
Type: Boolean
Default: n
Se definido, o agente tenta instalar e, em seguida, carregar um driver de kernel RDMA que corresponde à versão
do firmware do hardware subjacente.
OS.RootDeviceScsiTimeout:
Type: Integer
Default: 300
Esta configuração configura o tempo limite de SCSI em segundos nos drives de disco e os dados de SO. Se não
for definido, o sistema de padrões são usados.
OS.OpensslPath:
Type: String
Default: None
Esta configuração pode ser usado para especificar um caminho alternativo para o openssl binário a ser usado
para operações de criptografia.
HttpProxy.Host, HttpProxy.Por t
Type: String
Default: None
Se definido, o agente usa este servidor proxy para acessar a internet.

AutoUpdate.Enabled
Type: Boolean
Default: y
Habilite ou desabilite a atualização automática para o processamento de estado de meta; o padrão é habilitada.
Imagens de nuvem do Ubuntu

As Imagens de Nuvem do Ubuntu utilizam cloud-init para executar muitas tarefas de configuração que de outra
forma seriam gerenciadas pelo Agente Linux do Azure. As seguintes diferenças aplicam:
Provisioning.Enabled segue o padrão "n" nas Imagens de Nuvem do Ubuntu que usam cloud-init para
executar tarefas de provisionamento.
Os seguintes parâmetros de configuração não têm efeito nas Imagens de Nuvem do Ubuntu que usam
cloud-init para gerenciar o disco de recurso e o espaço de troca:
ResourceDisk .Format
ResourceDisk .Filesystem
ResourceDisk . MountPoint
ResourceDisk . EnableSwap
ResourceDisk .SwapSizeMB
Para mais informações, consulte os seguintes recursos para configurar o ponto de montagem do disco de
recurso e o espaço de troca nas Imagens de Nuvem do Ubuntu durante o provisionamento:
Wiki do Ubuntu: configurar partições de troca
Injetando dados personalizados em uma máquina virtual do Azure
Recursos e extensões da máquina virtual para
Windows
As extensões da máquina virtual (VM) do Azure são pequenos aplicativos que fornecem tarefas de configuração
e automação pós-implantação nas VMs do Azure. Por exemplo, se uma máquina virtual exigir instalação de
software, proteção antivírus ou executar um script dentro dela, uma extensão de VM poderá ser usada. As
extensões da VM do Azure podem ser executadas com a CLI do Azure, o PowerShell, modelos do Azure
Resource Manager e o portal do Azure. As extensões podem ser agrupadas com uma nova implantação de VM
ou executar qualquer sistema existente.
Este artigo fornece uma visão geral das extensões da VM, pré-requisitos para utilização das extensões da VM do
Azure e diretrizes sobre como detectar, gerenciar e remover as extensões da VM. Este artigo fornece
informações generalizadas, pois há muitas extensões de VM disponíveis, cada uma delas tem uma configuração
possivelmente exclusiva. Encontre detalhes específicos sobre cada extensão na documentação individual.
Casos de uso e exemplos

Há várias extensões de VM do Azure diferentes disponíveis, cada uma com um caso de uso específico. Alguns
exemplos incluem:
Aplique as configurações de Estado Desejado do PowerShell a uma VM usando a extensão de DSC para
Windows. Para saber mais, confira Extensão de configuração de Estado Desejado do Azure.
Configure o monitoramento de uma VM com a extensão de VM do agente de Log Analytics. Para obter mais
informações, consulte conectar VMs do Azure a logs de Azure monitor.
Configure uma VM do Azure ao usar o Chef. Para obter mais informações, consulte Automatizar a
implantação de VM do Azure com o Chef.
Configure o monitoramento de sua infraestrutura do Azure com a extensão Datadog. Para saber mais,
confira blog Datadog.
Além de extensões específicas ao processo, uma extensão de Script Personalizado está disponível para
máquinas virtuais Windows e Linux. A extensão de Script personalizado para Windows permite a execução de
qualquer script do PowerShell em uma VM. Scripts personalizados são úteis para a criação de implantações do
Azure que exigem uma configuração que vai além da capacidade das ferramentas nativas do Azure. Para saber
mais, veja Extensão de Script personalizado de VM do Windows.
Pré-requisitos
Para lidar com a extensão na VM, você precisa ter o agente do Windows Azure instalado. Algumas extensões
individuais têm pré-requisitos, como acesso a recursos ou dependências.
Agente de VM do Azure
O agente de VM do Azure gerencia a interação entre uma VM do Azure e o controlador de malha do Azure. O
agente de VM é responsável por muitos aspectos funcionais de implantação e gerenciamento de VMs do Azure,
incluindo a execução de extensões da VM. O agente de VM do Azure é pré-instalado em imagens do Microsoft
Azure Marketplace e pode ser instalado manualmente em sistemas operacionais com suporte. O agente de VM
do Azure para Windows é conhecido como o agente Convidado do Windows.
Para obter informações sobre sistemas operacionais e instruções de instalação com suporte, consulte agente de
máquina virtual do Azure.
Versões do agente com suporte
Para fornecer a melhor experiência possível, há versões mínimas do agente. Para obter mais informações,
consulte este artigo.
Sistemas operacionais com suporte
O agente Convidado do Windows é executado em vários sistemas operacionais. No entanto, a estrutura de
extensões tem um limite para os sistemas operacionais com extensões. Para obter mais informações, consulte
este artigo.
Algumas extensões não têm suporte em todos os sistemas de operacionais e podem emitir Código de Erro 51,
'SO sem suporte'. Consulte a documentação da extensão individual sobre a capacidade de suporte.
Acesso de rede
Os pacotes de extensão são baixados do repositório de extensão do Armazenamento do Microsoft Azure, e os
carregamentos de status de extensão são postados no Armazenamento do Microsoft Azure. Se você usar a
versão com suporte dos agentes, não será necessário permitir o acesso ao armazenamento do Azure na região
da VM, pois pode usar o agente para redirecionar a comunicação para o controlador de malha do Azure para
comunicações do agente (recurso HostGAPlugin por meio do canal privilegiado em 168.63.129.16de IP
privado). Se você estiver usando uma versão sem suporte do agente, será necessário permitir o acesso de saída
no armazenamento do Microsoft Azure nessa região por meio da VM.
IMPORTANT
Se você tiver bloqueado o acesso ao 168.63.129.16 usando o firewall convidado ou com um proxy, as extensões falharão
independentemente das anteriores. As portas 80, 443 e 32526 são necessárias.
Os agentes só podem ser usados para baixar os pacotes de extensão e o status do relatório. Por exemplo, se
uma instalação da extensão precisar baixar um script do GitHub (Script Personalizado) ou precisar ter acesso ao
Armazenamento do Microsoft Azure (Backup do Azure), então outras portas de firewall/Grupo de Segurança de
Rede precisarão ser abertas. Diferentes extensões têm requisitos diferentes, já que são aplicativos por si só. Para
extensões que exigem acesso ao armazenamento ou Azure Active Directory do Azure, você pode permitir o
acesso usando as marcas do serviço NSG do Azure para armazenamento ou AzureActiveDirectory.
O agente convidado do Windows não tem suporte de servidor proxy para redirecionar solicitações de tráfego
do agente por meio do, o que significa que o agente convidado do Windows dependerá do seu proxy
personalizado (se você tiver um) para acessar recursos na Internet ou no host por meio de 168.63.129.16 IP.
Descobrir extensões de VM
Muitas extensões de VM diferentes estão disponíveis para uso com as VMs do Azure. Para ver uma lista
completa, use Get-AzVMExtensionImage. O exemplo a seguir lista todas as extensões disponíveis no local
WestUS :
Get-AzVmImagePublisher -Location "WestUS" | `

Get-AzVMExtensionImageType | `
Get-AzVMExtensionImage | Select Type, Version
Executar extensões de VM
As extensões da VM do Azure podem ser executadas em VMs existentes, o que é útil quando você precisa fazer
alterações de configuração ou recuperar a conectividade em uma VM já implantada. As extensões de VM
também podem ser agrupadas com implantações de modelo do Azure Resource Manager. Ao usar extensões
com modelos do Resource Manager, as VMs do Azure podem ser implantadas e configuradas sem intervenção
pós-implantação.
Os métodos a seguir podem ser usados para executar uma extensão em uma VM existente.
PowerShell
Há vários comandos do PowerShell para a execução de extensões individuais. Para ver uma lista, use Get-
Command e filtre pela Extensão:
Get-Command Set-Az*Extension* -Module Az.Compute
O resultado é semelhante ao seguinte:
CommandType Name Version Source

----------- ---- ------- ------
Cmdlet Set-AzVMAccessExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMADDomainExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMAEMExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMBackupExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMBginfoExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMChefExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMCustomScriptExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMDiagnosticsExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMDiskEncryptionExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMDscExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMExtension 4.5.0 Az.Compute
Cmdlet Set-AzVMSqlServerExtension 4.5.0 Az.Compute
Cmdlet Set-AzVmssDiskEncryptionExtension 4.5.0 Az.Compute
O exemplo a seguir usa a extensão de Script personalizado para baixar um script de um repositório do GitHub
para a máquina virtual de destino e, em seguida, executa o script. Para saber mais sobre como usar a extensão
de Script personalizado, veja Visão geral da extensão de Script personalizado.
Set-AzVMCustomScriptExtension -ResourceGroupName "myResourceGroup" `

-VMName "myVM" -Name "myCustomScript" `
-FileUri "https://raw.githubusercontent.com/neilpeterson/nepeters-azure-templates/master/windows-custom-
script-simple/support-scripts/Create-File.ps1" `
-Run "Create-File.ps1" -Location "West US"
No seguinte exemplo, a extensão de acesso à VM é usada para redefinir a senha administrativa de uma VM
Windows para uma senha temporária. Para saber mais sobre a extensão de acesso à VM, veja Serviço de
redefinição de área de trabalho remota em uma VM do Windows. Depois de ter executado isso, você deverá
redefinir a senha no primeiro logon:
$cred=Get-Credential
Set-AzVMAccessExtension -ResourceGroupName "myResourceGroup" -VMName "myVM" -Name "myVMAccess" `

-Location WestUS -UserName $cred.GetNetworkCredential().Username `
-Password $cred.GetNetworkCredential().Password -typeHandlerVersion "2.0"
O comando Set-AzVMExtension pode ser usado para iniciar qualquer extensão de VM. Para saber mais, veja a
referência de Set-AzVMExtension.
Portal do Azure
É possível aplicar extensões de VM a uma VM existente por meio do portal do Azure. Selecione a VM no portal,
escolha Extensões e depois selecione Adicionar . Escolha a extensão desejada na lista de extensões disponíveis
e siga as instruções no assistente.
O exemplo a seguir mostra a instalação da extensão Microsoft Antimalware no portal do Azure:

É possível adicionar extensões de VM a um modelo do Azure Resource Manager e executá-las com a
implantação do modelo. Ao implantar uma extensão com um modelo, você pode criar implantações do Azure
totalmente configuradas. Por exemplo, o JSON a seguir é obtido de um modelo do Resource Manager que
implanta um conjunto de VMs com balanceamento de carga e um banco de dados SQL do Azure e instala um
aplicativo .NET Core em cada VM. A extensão da VM se encarrega da instalação do software.
Para saber mais, confira o Modelo completo do Resource Manager.
{
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'),copyindex())]",
"[variables('musicstoresqlName')]"
],
"tags": {
},
"properties": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"settings": {
"fileUris": [
windows/scripts/configure-music-app.ps1"
]
},
"commandToExecute": "[concat('powershell -ExecutionPolicy Unrestricted -File configure-music-app.ps1
-user ',parameters('adminUsername'),' -password ',parameters('adminPassword'),' -sqlserver
',variables('musicstoresqlName'),'.database.windows.net')]"
}
}
}
Para obter mais informações sobre a criação de modelos do Resource Manager, consulte Criando modelos do
Azure Resource Manager com extensões da VM do Windows.
Proteger dados de extensão da VM

Ao executar uma extensão de VM, talvez seja necessário incluir informações confidenciais, como credenciais,
nomes de conta de armazenamento e chaves de acesso da conta de armazenamento. Muitas extensões de VM
incluem uma configuração protegida que criptografa dados e os descriptografa somente dentro da VM de
destino. Cada extensão tem um esquema específico de configuração protegida, e cada um é detalhado na
documentação específica à extensão.
O exemplo a seguir mostra uma instância da extensão Script personalizado para Windows. O comando a ser
executado inclui um conjunto de credenciais. Neste exemplo, o comando a ser executado não é criptografado:
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
"fileUris": [
],
}
}
}
A movimentação da propriedade comando para execução para a configuração protegida protege a cadeia
de caracteres de execução, conforme mostrado no exemplo a seguir:
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
"fileUris": [
]
},
}
}
}
Em uma VM IaaS do Azure que usa extensões, no console certificados, você pode ver certificados que têm o
assunto gerador de cer tificado do Microsoft Azure CRP . Em uma VM RDFE clássica, esses certificados têm
o nome da entidade Gerenciamento de ser viços do Windows Azure para extensões .
Esses certificados protegem a comunicação entre a VM e seu host durante a transferência de configurações
protegidas (senha, outras credenciais) usadas pelas extensões. Os certificados são criados pelo controlador de
malha do Azure e passados para o agente de VM. Se você parar e iniciar a VM todos os dias, um novo
certificado poderá ser criado pelo controlador de malha. O certificado será armazenado no repositório de
certificados pessoais do computador. Esses certificados podem ser excluídos. O agente de VM recria certificados
se necessário.
Como agentes e extensões são atualizados?
Os Agentes e as Extensões compartilham o mesmo mecanismo de atualização. Algumas atualizações não
exigem regras de firewall adicionais.
Quando uma atualização estiver disponível, ela só será instalada na VM quando houver uma alteração nas
extensões e outras alterações de Modelo de VM como:
Discos de dados
Extensões
Contêiner de diagnóstico de inicialização
Segredos do sistema operacional convidado
Tamanho da VM
Perfil de rede
Os editores tornam atualizações disponíveis para regiões em momentos diferentes, então é possível ter VMs em
regiões e versões diferentes.
Listando extensões implantadas em uma VM
$vm = Get-AzVM -ResourceGroupName "myResourceGroup" -VMName "myVM"

$vm.Extensions | select Publisher, VirtualMachineExtensionType, TypeHandlerVersion
Publisher VirtualMachineExtensionType TypeHandlerVersion

--------- --------------------------- ------------------
Microsoft.Compute CustomScriptExtension 1.9
Atualizações de agentes
O Agente de Convidado do Windows contém somente o código de Tratamento de Extensão. O código de
Provisionamento do Windows é separado. Você pode desinstalar o Agente de Convidado do Windows. Não é
possível desabilitar a atualização automática do agente de Convidado do Windows.
O código de Tratamento de Extensão é responsável por se comunicar com a malha do Azure e manipular as
operações de extensões da VM, como instalações, relatando status, atualizando as extensões individuais e
removendo-as. As atualizações contêm correções de segurança, correções de bug e aprimoramentos para o
código de Tratamento de Extensão.
Para verificar qual versão você está executando, consulte Detectando o Agente de Convidado do Windows
instalado.
Atualizações de extensão
Quando uma atualização da extensão estiver disponível, o Agente de Convidado do Windows baixará e
atualizará a extensão. Atualizações automáticas de extensão são Secundárias ou Hotfix. Você pode aceitar ou
recusar atualizações de extensões Secundárias ao provisionar a extensão. O exemplo a seguir mostra como
atualizar automaticamente as versões secundárias em um modelo do Resource Manager com
autoUpgradeMinorVersion": true,':
"properties": {
"settings": {
"fileUris": [
]
},
Para obter as correções de bug de versão secundária mais recentes, é altamente recomendável que você
selecione sempre a atualização automática em suas implantações de extensão. As atualizações de hotfix que
realizam correções de bug essenciais ou de segurança não podem ser recusadas.
Como identificar as atualizações de extensão
Identificar se a extensão foi definida com autoUpgradeMinorVersion em uma VM
Você pode ver no modelo da VM se a extensão foi provisionada com 'autoUpgradeMinorVersion'. Para verificar,
use Get-AzVm e forneça o grupo de recursos e o nome da VM da seguinte maneira:
$vm = Get-AzVm -ResourceGroupName "myResourceGroup" -VMName "myVM"

$vm.Extensions
O seguinte exemplo de saída mostra que autoUpgradeMinorVersion foi definido como true:
ForceUpdateTag :
Publisher : Microsoft.Compute
VirtualMachineExtensionType : CustomScriptExtension
TypeHandlerVersion : 1.9
AutoUpgradeMinorVersion : True
Identificar quando ocorreu uma autoUpgradeMinorVersion

Para ver quando ocorreu uma atualização da extensão, examine os registros de agente na VM em
C:\WindowsAzure\Logs\WaAppAgent.log
No exemplo a seguir, Microsoft.Compute.CustomScriptExtension 1.8 estava instalado na VM. Um hotfix estava
disponível para a versão 1.9:
[INFO] Getting plugin locations for plugin 'Microsoft.Compute.CustomScriptExtension'. Current Version:

'1.8', Requested Version: '1.9'
[INFO] Auto-Upgrade mode. Highest public version for plugin 'Microsoft.Compute.CustomScriptExtension' with
requested version: '1.9', is: '1.9'
Permissões de agente
Para executar suas tarefas, o agente precisa executar como Sistema Local.
Solucionar problemas de extensões de VM

Cada extensão de VM pode ter etapas de solução de problemas específicas à extensão. Por exemplo, ao usar a
extensão Script Personalizado, detalhes de execução do script poderão ser encontrados localmente na VM na
qual a extensão foi executada. As etapas de solução de problemas específicas à extensão são detalhadas na
documentação associada.
As seguintes etapas de solução de problemas aplicam-se a todas as extensões da VM.
1. Para verificar o log do agente convidado do Windows, examine a atividade quando sua extensão estava
sendo provisionada no C:\WindowsAzure\Logs\WaAppAgent.log
2. Verifique os logs de extensão reais para obter mais detalhes em C:\WindowsAzure\Logs\Plugins \
3. Verifique as seções de solução de problemas da documentação específica da extensão para códigos de
erro, problemas conhecidos etc.
4. Examine os logs do sistema. Verifique se há outras operações que podem ter interferido na extensão,
como uma instalação de longa execução de outro aplicativo que exigia acesso exclusivo ao gerenciador
de pacotes.
Motivos comuns para falhas na extensão
1. As extensões têm 20 minutos para serem executadas (exceções são as extensões de CustomScript, Chef e
DSC que têm 90 minutos). Se a implantação exceder esse tempo, será marcada como um tempo limite.
Isso pode ocorrer devido a poucas VMs de recursos, outras configurações da VM/tarefas de inicialização
consumindo grande quantidade de recursos durante a extensão que está tentando provisionar.
2. Pré-requisitos mínimos não atendidos. Algumas extensões têm dependências em SKUs da VM, como
imagens HPC. As extensões podem exigir certos requisitos de acesso à rede, como comunicação com o
Armazenamento do Microsoft Azure ou serviços públicos. Outros exemplos podem ser o acesso a
repositórios de pacote, ficando sem espaço em disco, ou restrições de segurança.
3. Acesso exclusivo ao gerenciador de pacotes. Em alguns casos, você pode encontrar uma configuração da
VM de longa execução e uma instalação da extensão em conflito, nas quais ambas precisam de acesso
exclusivo ao gerenciador de pacotes.
Exibir o status da extensão
Depois que uma extensão de VM for executada em uma VM, use Get-AzVM para retornar o status da extensão.
O Substatus [0] mostra que o provisionamento de extensão foi bem-sucedido, o que significa que foi
implantado com sucesso na VM, mas que houve falha na execução da extensão dentro da VM, Substatus [1].
Get-AzVM -ResourceGroupName "myResourceGroup" -VMName "myVM" -Status
A saída é semelhante ao seguinte exemplo de saída:

Extensions[0] :
Name : CustomScriptExtension
Type : Microsoft.Compute.CustomScriptExtension
TypeHandlerVersion : 1.9
Substatuses[0] :
Code : ComponentStatus/StdOut/succeeded
Level : Info
Message : Windows PowerShell \nCopyright (C) Microsoft Corporation. All rights reserved.\n
Substatuses[1] :
Code : ComponentStatus/StdErr/succeeded
Level : Info
Message : The argument 'cseTest%20Scriptparam1.ps1' to the -File parameter does not exist.
Provide the path to an existing '.ps1' file as an argument to the
-File parameter.
Statuses[0] :
Code : ProvisioningState/failed/-196608
Level : Error
DisplayStatus : Provisioning failed
Message : Finished executing command
O status de execução da extensão também pode ser encontrado no Portal do Azure. Para exibir o status de uma
extensão, selecione a VM, escolha Extensões e selecione a extensão desejada.
Executar extensões de VM novamente
Pode haver casos nos quais uma extensão da VM precisa ser executada novamente. Você pode executar
novamente uma extensão removendo-a e, em seguida, executando novamente a extensão com um método de
execução de sua escolha. Para remover uma extensão, use Remove-AzVMExtension da seguinte maneira:
Remove-AzVMExtension -ResourceGroupName "myResourceGroup" -VMName "myVM" -Name "myExtensionName"
Você também pode remover uma extensão no portal do Azure da seguinte maneira:
1. Selecione uma VM.
2. Escolha Extensões .
3. Selecione a extensão desejada.
4. Escolha Desinstalar .
Referência a extensões de VM comuns

N O M E DA EXT EN SÃ O DESC RIÇ Ã O M A IS IN F O RM A Ç Õ ES
Extensão de script personalizado para Executar scripts em uma máquina Extensão de script personalizado para
o Windows virtual do Azure o Windows
Extensão de DSC para o Windows Extensão PowerShell DSC Extensão de DSC para o Windows
(Configuração de Estado Desejado)
Extensão de Diagnóstico do Azure Gerenciar Diagnóstico do Azure Extensão de Diagnóstico do Azure
Extensão de acesso à VM do Azure Gerenciar usuários e credenciais Extensão de acesso à VM para Linux
Próximas etapas
virtual do Azure.
Visão geral do Agente de Máquina Virtual do Azure
O Agente de VM (Máquina Virtual) do Microsoft Azure é um processo seguro e leve que gerencia a interação da
máquina virtual (VM) com o Controlador de Malha do Azure. O Agente de VM tem uma função fundamental na
habilitação e execução de extensões de máquina virtual do Azure. Extensões de VM habilitam a configuração de
VM pós-implantação, como instalação e configuração de software. Extensões de VM também habilitam os
recursos de recuperação como redefinir a senha administrativa de uma VM. Sem o Agente de VM do Azure, não
é possível executar extensões da VM.
Este artigo detalha a instalação e a detecção do agente de máquina virtual do Azure.
Instalar o Agente VM
Imagem do Azure Marketplace
O Agente de VM do Azure é instalado por padrão em qualquer VM Windows implantada de uma imagem do
Azure Marketplace. Ao implantar uma imagem do Azure Marketplace do portal, PowerShell, Interface de Linha
de Comando ou de um modelo do Azure Resource Manager, o Agente de VM do Azure também é instalado.
O Pacote de Agente de Convidado do Windows é dividido em duas partes:
Agente de Provisionamento (PA)
Agente de Convidado do Windows (WinGA)
Para inicializar uma VM, você deve ter o PA instalado na VM, no entanto o WinGA não precisa ser instalado. Na
hora da implantação da VM, você pode optar por não instalar o WinGA. O exemplo a seguir mostra como
selecionar a opção provisionVmAgent com um modelo do Azure Resource Manager:
"resources": [{
"name": "[parameters('virtualMachineName')]",
"apiVersion": "2016-04-30-preview",
"dependsOn": ["[concat('Microsoft.Network/networkInterfaces/', parameters('networkInterfaceName'))]"],
"properties": {
"osProfile": {
"computerName": "[parameters('virtualMachineName')]",
"adminPassword": "[parameters('adminPassword')]",
"windowsConfiguration": {
"provisionVmAgent": "false"
}
Se você não tiver os Agentes instalados, você não pode usar alguns dos serviços do Azure, como o Azure
Backup ou segurança do Azure. Esses serviços exigem uma extensão para serem instalados. Se você tiver
implantado uma VM sem o WinGA, você pode instalar a versão mais recente do agente mais tarde.
Instalação manual
O agente de VM do Windows pode ser instalado manualmente com um pacote do Windows Installer. Instalação
manual pode ser necessária quando você cria uma imagem VM personalizada que é implantada no Azure. Para
instalar manualmente o Agente de VM do Windows, faça o download do instalador do Agente de VM. O agente
de VM tem suporte no Windows Server 2008 (64 bits) e posterior.
NOTE
É importante atualizar a opção AllowExtensionOperations depois de instalar manualmente o VMAgent em uma VM que
foi implantada a partir da imagem sem o ProvisionVMAgent Enable.
$vm.OSProfile.AllowExtensionOperations = $true
$vm | Update-AzVM
Pré -requisitos
O agente de VM do Windows precisa de pelo menos o Windows Server 2008 SP2 (64 bits) para ser
executado, com o .NET Framework 4,0. Consulte suporte mínimo de versão para agentes de máquina
virtual no Azure.
Verifique se sua VM tem acesso ao endereço IP 168.63.129.16. Para obter mais informações, consulte o
que é o endereço IP 168.63.129.16.
Verifique se o DHCP está habilitado dentro da VM convidada. Isso é necessário para obter o endereço de
host ou de malha do DHCP para que o agente de VM IaaS e as extensões funcionem. Se você precisar de
um IP privado estático, deverá configurá-lo por meio do portal do Azure ou do PowerShell e certificar-se
de que a opção DHCP dentro da VM esteja habilitada. Saiba mais sobre como configurar um endereço IP
estático com o PowerShell.
Detectar o Agente de VM
PowerShell
O módulo do Azure Resource Manager PowerShell pode ser usado para recuperar informações sobre as VMs do
Azure. Para obter informações sobre uma VM, como o estado de provisionamento para o Agente de VM do
Azure, use Get-AzVM:
Get-AzVM
A saída de exemplo condensada a seguir mostra a propriedade ProvisionVMAgent aninhada dentro OSProfile .
Essa propriedade pode ser usada para determinar se o agente de VM foi implantado na VM:
OSProfile :
ComputerName : myVM
AdminUsername : myUserName
WindowsConfiguration :
ProvisionVMAgent : True
EnableAutomaticUpdates : True
O script a seguir pode ser usado para retornar uma lista concisa de nomes de VM e o estado do Agente de VM:
$vms = Get-AzVM
foreach ($vm in $vms) {

$agent = $vm | Select -ExpandProperty OSProfile | Select -ExpandProperty Windowsconfiguration | Select
ProvisionVMAgent
Write-Host $vm.Name $agent.ProvisionVMAgent
}
Detecção Manual
Quando conectado a uma VM do Windows, o Gerenciador de Tarefas pode ser usado para examinar os
processos em execução. Para verificar o Agente de VM do Azure, abra o Gerenciador de Tarefas, clique na guia
Detalhes e procure pelo nome de processo WindowsAzureGuestAgent.exe . A presença desse processo indica
que o agente de VM está instalado.
Atualizar o Agente de VM
O agente de VM do Azure para Windows é atualizado automaticamente em imagens implantadas no Azure
Marketplace. Conforme novas VMs são implantadas no Azure, elas receberão o agente de VM mais recente em
tempo de provisionamento. Se você tiver instalado o agente manualmente ou estiver implantando imagens de
VM personalizadas, será necessário atualizar manualmente para incluir o novo agente de VM no momento da
criação da imagem.
Coleção de logs automáticos do agente convidado do Windows

O agente convidado do Windows tem um recurso para coletar automaticamente alguns logs. Esse recurso é o
controlador pelo processo de CollectGuestLogs.exe. Ele existe para os serviços de nuvem PaaS e para máquinas
virtuais IaaS e seu objetivo é & rapidamente coletar automaticamente alguns logs de diagnóstico de uma VM,
para que eles possam ser usados para análise offline. Os logs coletados são logs de eventos, logs do sistema
operacional, logs do Azure e algumas chaves do registro. Ele produz um arquivo ZIP que é transferido para o
host da VM. Esse arquivo ZIP pode então ser examinado por equipes de engenharia e profissionais de suporte
para investigar problemas na solicitação do cliente que possui a VM.
Agente convidado e certificados OSProfile

O agente de VM do Azure é responsável por instalar os certificados referenciados no OSProfile de um
conjunto de dimensionamento de máquinas virtuais ou VM. Se você remover manualmente esses certificados
do console do MMC certificados dentro da VM convidada, espera-se que o agente convidado os adicione de
volta. Para remover permanentemente um certificado, você precisará removê-lo do OSProfile e, em seguida,
removê-lo de dentro do sistema operacional convidado.
Para uma máquina virtual, use para remover certificados do
Remove-AzVMSecret
OSProfile .
Para obter mais informações sobre os certificados do conjunto de dimensionamento de máquinas virtuais,
consulte conjuntos de dimensionamento de máquinas virtuais-como fazer remover certificados preteridos?
Próximas etapas
virtual do Azure.
Azure Disk Encryption para Linux
(Microsoft.Azure.Security.AzureDiskEncryptionForLinux)
Visão geral
Azure Disk Encryption aproveita o subsistema de dm-crypt no Linux para fornecer criptografia de disco
completo em selecionar distribuições de Linux do Azure. A solução é integrada ao Azure Key Vault para gerenciar
as chaves de criptografia de disco e segredos.
Pré-requisitos
Para obter uma lista completa de pré-requisitos, consulte Azure Disk Encryption para VMs do Linux,
especificamente as seguintes seções:
Sistemas operacionais e VMs com suporte
Requisitos adicionais da VM
Requisitos de rede
Requisitos de armazenamento de chave de criptografia
Esquema de Extensão
Há duas versões do esquema de extensão para Azure Disk Encryption (ADE):
v 1.1-um esquema mais recente recomendado que não usa as propriedades Azure Active Directory (AAD).
v 0.1-um esquema mais antigo que requer Propriedades Azure Active Directory (AAD).
Para selecionar um esquema de destino, a typeHandlerVersion propriedade deve ser definida igual à versão do
esquema que você deseja usar.
Esquema v 1.1: sem AAD (recomendado )
O esquema v 1.1 é recomendado e não requer as propriedades Azure Active Directory (AAD).
{
"name": "[name]",
"apiVersion": "2019-07-01",
"location": "[location]",
"properties": {
"publisher": "Microsoft.Azure.Security",
"type": "AzureDiskEncryptionForLinux",
"settings": {
"DiskFormatQuery": "[diskFormatQuery]",
"EncryptionOperation": "[encryptionOperation]",
"KeyEncryptionAlgorithm": "[keyEncryptionAlgorithm]",
"KeyVaultURL": "[keyVaultURL]",
"KeyVaultResourceId": "[KeyVaultResourceId]",
"KeyEncryptionKeyURL": "[keyEncryptionKeyURL]",
"KekVaultResourceId": "[KekVaultResourceId",
"SequenceVersion": "sequenceVersion]",
"VolumeType": "[volumeType]"
}
}
}
Esquema v 0,1: com o AAD

O esquema 0,1 requer o AADClientID e o AADClientSecret ou o AADClientCertificate .
Usando AADClientSecret :
{
"name": "[name]",
"apiVersion": "2019-07-01",
"properties": {
"AADClientSecret": "[aadClientSecret]",
"Passphrase": "[passphrase]"
},
"settings": {
"AADClientID": "[aadClientID]",
}
}
}
Usando AADClientCertificate :
{
"name": "[name]",
"apiVersion": "2019-07-01",
"properties": {
"AADClientCertificate": "[aadClientCertificate]",
"Passphrase": "[passphrase]"
},
"settings": {
}
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
apiVersion 2019-07-01 date
publicador Microsoft.Azure.Security string
type AzureDiskEncryptionForLinux string
typeHandlerVersion 1,1, 0,1 INT
(esquema 0,1) AADClientID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx guid
(esquema 0,1) AADClientSecret password string
(esquema 0,1) AADClientCertificate thumbprint string
adicional (esquema 0,1) Senha password string
DiskFormatQuery {"dev_path":"","name":"","file_system":""} Dicionário JSON
EncryptionOperation EnableEncryption, string

EnableEncryptionFormatAll
(opcional-padrão RSA-OAEP) 'RSA-OAEP', 'RSA-OAEP-256', 'RSA1_5' string

KeyEncryptionAlgorithm
KeyVaultURL url string
KeyVaultResourceId url string

adicional KeyEncryptionKeyURL url string
adicional KekVaultResourceId url string
adicional SequenceVersion UNIQUEIDENTIFIER string
VolumeType Sistema operacional, Dados, Tudo string
Implantação de modelo
Para obter um exemplo de implantação de modelo com base no esquema v 1.1, consulte o modelo de início
rápido do Azure 201-Encrypt-running-Linux-VM-sem-AAD.
Para obter um exemplo de implantação de modelo com base no esquema v 0.1, consulte o modelo de início
rápido do Azure 201-Encrypt-running-Linux-VM.
WARNING
Se você já tiver usado o Azure Disk Encryption com o Azure AD anteriormente para criptografar uma VM, deverá
continuar usando essa opção para criptografar a VM.
Ao criptografar volumes do sistema operacional Linux, a VM deve ser considerada não disponível. É altamente
recomendável evitar logons SSH enquanto a criptografia estiver em andamento para evitar problemas ao bloquear os
arquivos abertos que precisarão ser acessados durante o processo de criptografia. Para verificar o progresso, use o
cmdlet do PowerShell Get-AzVMDiskEncryptionStatus ou o comando VM Encryption show CLI. Esse processo deve
levar algumas horas para um volume do sistema operacional de 30 GB, mais algum tempo para criptografar volumes
de dados. O tempo para criptografia de volume de dados será proporcional ao tamanho e à quantidade dos volumes
de dados, a menos que a opção EncryptFormatAll seja usada.
Desabilitar criptografia nas VMs do Linux tem suporte apenas para volumes de dados. Não haverá suporte em dados
ou volumes de SO, se o volume de SO tiver sido criptografado.
NOTE
Além disso VolumeType , se o parâmetro for definido como todos, os discos de dados serão criptografados somente se
forem montados corretamente.
Solução de problemas e suporte

Para solução de problemas, consulte o Guia de solução de problemas do Azure Disk Encryption.
Suporte
Caso precise de mais ajuda em qualquer ponto deste artigo, entre em contato com os especialistas do Azure nos
fóruns do Azure e do Stack Overflow no MSDN.
Como alternativa, você pode registrar um incidente de suporte do Azure. Vá para o suporte do Azure e selecione
obter suporte. Para obter informações sobre como usar o suporte do Azure, leia as perguntas frequentes sobre
suporte do Microsoft Azure.
Próximas etapas
Para obter mais informações sobre extensões de VM, consulte Recursos e extensões da máquina virtual para
Linux.
Para obter mais informações sobre Azure Disk Encryption para Linux, consulte máquinas virtuais do Linux.
Azure Disk Encryption para Windows
(Microsoft.Azure.Security.AzureDiskEncryption)
Visão geral
O Azure Disk Encryption utiliza o Bitlocker para fornecer criptografia de disco completa em máquinas virtuais
do Azure que executam o Windows. Está solução é integrada ao Azure Key Vault para gerenciar os segredos e as
chaves de criptografia de disco em sua assinatura do cofre de chaves.
Pré-requisitos
Para obter uma lista completa de pré-requisitos, consulte Azure Disk Encryption para VMs do Windows,
especificamente as seguintes seções:
Requisitos de rede
Requisitos de Política de Grupo
Esquema de Extensão
Há duas versões do esquema de extensão para Azure Disk Encryption (ADE):
v 2.2-um esquema recomendado mais recente que não usa as propriedades Azure Active Directory (AAD).
v 1.1-um esquema mais antigo que requer Propriedades Azure Active Directory (AAD).
Para selecionar um esquema de destino, a typeHandlerVersion propriedade deve ser definida igual à versão do
esquema que você deseja usar.
Esquema v 2.2: sem AAD (recomendado )
O esquema v 2.2 é recomendado para todas as novas VMs e não requer Azure Active Directory Propriedades.
{
"name": "[name]",
"apiVersion": "2019-07-01",
"properties": {
"type": "AzureDiskEncryption",
"settings": {
"KeyVaultResourceId": "[keyVaultResourceID]",
"KekVaultResourceId": "[kekVaultResourceID]",
}
}
}
Esquema v 1.1: com AAD

O esquema 1,1 requer o aadClientID e o aadClientSecret ou AADClientCertificate e não é recomendado para
novas VMS.
Usando aadClientSecret :
{
"name": "[name]",
"apiVersion": "2019-07-01",
"properties": {
"AADClientSecret": "[aadClientSecret]"
},
"settings": {
}
}
}
Usando AADClientCertificate :
{
"name": "[name]",
"apiVersion": "2019-07-01",
"properties": {
"AADClientCertificate": "[aadClientCertificate]"
},
"settings": {
}
}
}
publicador Microsoft.Azure.Security string
type AzureDiskEncryption string
typeHandlerVersion 2,2, 1,1 string
(esquema 1,1) AADClientID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx guid
(esquema 1,1) AADClientSecret password string
(esquema 1,1) AADClientCertificate thumbprint string
EncryptionOperation EnableEncryption string
(opcional-padrão RSA-OAEP) 'RSA-OAEP', 'RSA-OAEP-256', 'RSA1_5' string

KeyEncryptionAlgorithm
KeyVaultURL url string
KeyVaultResourceId url string
adicional KeyEncryptionKeyURL url string
adicional KekVaultResourceId url string

adicional SequenceVersion UNIQUEIDENTIFIER string
VolumeType Sistema operacional, Dados, Tudo string
Para obter um exemplo de implantação de modelo com base no esquema v 2.2, consulte modelo de início
rápido do Azure 201-Encrypt-running-Windows-VM-sem-AAD.
Para obter um exemplo de implantação de modelo com base no esquema v 1.1, consulte modelo de início
rápido do Azure 201-Encrypt-running-Windows-VM.
NOTE
Além disso VolumeType , se o parâmetro for definido como todos, os discos de dados serão criptografados somente se
estiverem formatados corretamente.

Para solução de problemas, consulte o Guia de solução de problemas do Azure Disk Encryption.
Suporte
fóruns do Azure e do Stack Overflow no MSDN.
Como alternativa, você pode registrar um incidente de suporte do Azure. Vá para o suporte do Azure e selecione
obter suporte. Para obter informações sobre como usar o suporte do Azure, leia as perguntas frequentes sobre
suporte do Microsoft Azure.
Próximas etapas
Para obter mais informações sobre extensões, consulte Recursos e extensões da máquina virtual para
Windows.
Para obter mais informações sobre Azure Disk Encryption para Windows, consulte máquinas virtuais do
Windows.
Extensão da máquina virtual de Key Vault para
Linux
A extensão de VM de Key Vault fornece a atualização automática dos certificados armazenados no cofre de
chaves do Azure. Especificamente, a extensão monitora uma lista de certificados observados armazenados em
cofres de chaves. Após detectar uma alteração, a extensão recupera e instala os certificados correspondentes. A
extensão de VM do Key Vault é publicada e suportada pela Microsoft, no momento em VMs do Linux. Este
documento detalha as plataformas com opções de plataformas, configurações e implantação com suporte para
a extensão da VM de Key Vault para Linux.
Sistema operacional
A extensão de VM do Key Vault dá suporte a essas distribuições do Linux:
Ubuntu-1604
Ubuntu-1804
Debian-9
Suse-15
Tipos suportados de conteúdo de certificado
PKCS #12
PEM
Pré-requisitos
Key Vault instância com certificado. Consulte criar um Key Vault
VM/VMSS devem ter uma identidade gerenciada atribuída
A política de acesso de Key Vault deve ser definida com segredos get e list permissão para a
identidade gerenciada VM/VMSS para recuperar a parte de um segredo do certificado. Consulte como
autenticar para Key Vault e atribuir uma política de acesso de Key Vault.
VMSS deve ter a seguinte configuração de identidade:
"identity": { "type": "UserAssigned", "userAssignedIdentities": { "
[parameters('userAssignedIdentityResourceId')]": {} } }
A extensão AKV deve ter essa configuração:

"authenticationSettings": { "msiEndpoint": "[parameters('userAssignedIdentityEndpoint')]",
"msiClientId": "[reference(parameters('userAssignedIdentityResourceId'),
variables('msiApiVersion')).clientId]" }
Esquema de extensão
O JSON a seguir mostra o esquema para a extensão da VM de Key Vault. A extensão não requer configurações
protegidas - todas as suas configurações são consideradas informações sem impacto de segurança. A extensão
requer uma lista dos segredos monitorados, a frequência de sondagem e o repositório de certificados de
destino. Especificamente:
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "KVVMExtensionForLinux",
"apiVersion": "2019-07-01",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vmName>)]"
],
"properties": {
"publisher": "Microsoft.Azure.KeyVault",
"type": "KeyVaultForLinux",
"settings": {
"secretsManagementSettings": {
"pollingIntervalInS": <polling interval in seconds, e.g. "3600">,
"certificateStoreName": <It is ignored on Linux>,
"linkOnRenewal": <Not available on Linux e.g.: false>,
"certificateStoreLocation": <disk path where certificate is stored, default:
"/var/lib/waagent/Microsoft.Azure.KeyVault">,
"requireInitialSync": <initial synchronization of certificates e..g: true>,
"observedCertificates": <list of KeyVault URIs representing monitored certificates, e.g.:
["https://myvault.vault.azure.net/secrets/mycertificate",
"https://myvault.vault.azure.net/secrets/mycertificate2"]>
},
"authenticationSettings": {
"msiEndpoint": <Optional MSI endpoint e.g.: "http://169.254.169.254/metadata/identity">,
"msiClientId": <Optional MSI identity e.g.: "c7373ae5-91c2-4165-8ab6-7381d6e75619">
}
}
}
}
NOTE
Suas URLs de certificado observadas devem estar no formato
https://myVaultName.vault.azure.net/secrets/myCertName .
Isso porque o caminho /secrets retorna todo o certificado, incluindo a chave privada, enquanto o caminho
/certificates não faz isso. Mais informações sobre certificados podem ser encontradas aqui: Certificados do Key Vault
IMPORTANT
A propriedade ' authenticationSettings ' é necessária somente para VMs com identidades atribuídas pelo usuário .
Especifica a identidade a ser usada para autenticação para Key Vault.
publicador Microsoft.Azure.KeyVault string
type KeyVaultForLinux string
typeHandlerVersion 1.0 INT

pollingIntervalInS 3600 string
certificateStoreName Ele é ignorado no Linux string
linkOnRenewal false booleano
certificateStoreLocation /var/lib/waagent/Microsoft.Azure.KeyV string

ault
requireInitialSync true booleano
observedCertificates ["https://myvault.vault.azure.net/secret Matriz de cadeia de caracteres

s/mycertificate",
"https://myvault.vault.azure.net/secrets
/mycertificate2"]
msiEndpoint http://169.254.169.254/metadata/iden string

tity
msiClientId c7373ae5-91c2-4165-8ab6- string

7381d6e75619
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. Modelos são
ideais ao implantar uma ou mais máquinas virtuais que exigem renovação de certificados pós-implantação. A
extensão pode ser implantada em VMs individuais ou conjunto de dimensionamento de máquinas virtuais. O
esquema e a configuração são comuns a ambos os tipos de modelo.
A configuração JSON para uma extensão de máquina virtual deve ser aninhada dentro do fragmento do recurso
de máquina virtual do modelo, especificamente o objeto "resources": [] para o modelo de máquina virtual e,
no caso de conjunto de dimensionamento de máquinas virtuais, no objeto
"virtualMachineProfile":"extensionProfile":{"extensions" :[] .
NOTE
A extensão de VM exigiria que a identidade gerenciada do sistema ou do usuário fosse atribuída para autenticar no Key
Vault. Consulte como autenticar para Key Vault e atribuir uma política de acesso de Key Vault.
{
"name": "KeyVaultForLinux",
"apiVersion": "2019-07-01",
"dependsOn": [
],
"properties": {
"type": "KeyVaultForLinux",
"settings": {
"pollingIntervalInS": <polling interval in seconds, e.g. "3600">,
"certificateStoreName": <ingnored on linux>,
"certificateStoreLocation": <disk path where certificate is stored, default:
"/var/lib/waagent/Microsoft.Azure.KeyVault">,
"https://myvault.vault.azure.net/secrets/mycertificate"
}
}
}
}
Ordenação de dependência de extensão

A extensão de VM Key Vault dá suporte à ordenação de extensão, se configurada. Por padrão, a extensão relata
que ela foi iniciada com êxito assim que começou a sondagem. No entanto, ele pode ser configurado para
aguardar até que tenha baixado com êxito a lista completa de certificados antes de relatar um início bem-
sucedido. Se outras extensões dependerem de ter o conjunto completo de certificados instalados antes de
serem iniciadas, habilitar essa configuração permitirá que essas extensões declarem uma dependência na
extensão de Key Vault. Isso impedirá que essas extensões sejam iniciadas até que todos os certificados dos quais
dependem tenham sido instalados. A extensão tentará novamente o download inicial de forma indefinida e
permanecerá em um Transitioning estado.
Para ativar isso, defina o seguinte:
"requireInitialSync": true,
...
}
Anotações O uso desse recurso não é compatível com um modelo ARM que cria uma identidade atribuída
pelo sistema e atualiza uma política de acesso de Key Vault com essa identidade. Isso resultará em um
deadlock, uma vez que a política de acesso do cofre não pode ser atualizada até que todas as extensões
sejam iniciadas. Em vez disso, você deve usar uma identidade de MSI atribuída por um único usuário e pré-
ACL de seus cofres com essa identidade antes da implantação.
Implantação do Azure PowerShell

WARNING
Os clientes do PowerShell geralmente se adicionam \ ao " no settings.js, o que caakvvm_service usará falha com o
erro: [CertificateManagementConfiguration] Failed to parse the configuration settings with:not an object.
O Azure PowerShell pode ser usado para implantar a extensão da VM do Diagnóstico de Key Vault em uma
máquina virtual existente ou em um conjunto de dimensionamento de máquina virtual.
Para implantar a extensão em uma VM:
# Build settings
$settings = '{"secretsManagementSettings":
{ "pollingIntervalInS": "' + <pollingInterval> +
'", "certificateStoreName": "' + <certStoreName> +
'", "certificateStoreLocation": "' + <certStoreLoc> +
'", "observedCertificates": ["' + <observedCert1> + '","' + <observedCert2> + '"] } }'
$extName = "KeyVaultForLinux"
$extPublisher = "Microsoft.Azure.KeyVault"
$extType = "KeyVaultForLinux"
# Start the deployment

Set-AzVmExtension -TypeHandlerVersion "1.0" -ResourceGroupName <ResourceGroupName> -Location
<Location> -VMName <VMName> -Name $extName -Publisher $extPublisher -Type $extType -SettingString
$settings
Para implantar a extensão em um conjunto de dimensionamento de máquinas virtuais:
# Build settings
$extName = "KeyVaultForLinux"
$extType = "KeyVaultForLinux"
# Add Extension to VMSS

$vmss = Get-AzVmss -ResourceGroupName <ResourceGroupName> -VMScaleSetName <VmssName>
Add-AzVmssExtension -VirtualMachineScaleSet $vmss -Name $extName -Publisher $extPublisher -Type
$extType -TypeHandlerVersion "1.0" -Setting $settings

Update-AzVmss -ResourceGroupName <ResourceGroupName> -VMScaleSetName <VmssName> -
VirtualMachineScaleSet $vmss
Implantação da CLI do Azure

A CLI do Azure pode ser usada para implantar a extensão da VM do Key Vault em uma máquina virtual existente
ou em um conjunto de dimensionamento de máquinas virtuais.

az vm extension set -n "KeyVaultForLinux" `
--publisher Microsoft.Azure.KeyVault `
-g "<resourcegroup>" `
--vm-name "<vmName>" `
--settings '{\"secretsManagementSettings\": { \"pollingIntervalInS\": \"<pollingInterval>\",
\"certificateStoreName\": \"<certStoreName>\", \"certificateStoreLocation\": \"<certStoreLoc>\",
\"observedCertificates\": [\" <observedCert1> \", \" <observedCert2> \"] }}'

az vmss extension set -n "KeyVaultForLinux" `
-g "<resourcegroup>" `
Por favor esteja ciente das seguintes restrições/exigências:

Restrições de Key Vault:
Ele deve existir no momento da implantação
A política de acesso de Key Vault deve ser definida para a identidade VM/VMSS usando uma
identidade gerenciada. Consulte como autenticar para Key Vault e atribuir uma política de acesso de
Key Vault.
Há um limite no número de observedCertificates que você pode configurar? Não, Key Vault extensão de VM
não tem limite no número de observedCertificates.
Os dados sobre o estado das implantações de extensão podem ser recuperados no Portal do Azure usando o
Azure PowerShell. Para ver o estado da implantação das extensões de uma determinada VM, execute o comando
a seguir usando o Azure PowerShell.
PowerShell do Azure
Get-AzVMExtension -VMName <vmName> -ResourceGroupname <resource group name>
CLI do Azure
az vm get-instance-view --resource-group <resource group name> --name <vmName> --query

"instanceView.extensions"
Logs e configuração
/var/log/waagent.log
/var/log/azure/Microsoft.Azure.KeyVault.KeyVaultForLinux/*
/var/lib/waagent/Microsoft.Azure.KeyVault.KeyVaultForLinux-<most recent version>/config/*
Usando symlink
Links simbólicos ou symlinks são basicamente atalhos avançados. Para evitar o monitoramento da pasta e obter
o certificado mais recente automaticamente, você pode usar esse symlink ([VaultName].[CertificateName]) para
obter a versão mais recente do certificado no Linux.
Suporte
fóruns do Azure e do Stack Overflow no MSDN. Como alternativa, você pode registrar um incidente de suporte
do Azure. Vá para o site de suporte do Azure e selecione Obter suporte. Para saber mais sobre como usar o
suporte do Azure, leia as Perguntas frequentes sobre o suporte do Microsoft Azure.
Extensão da máquina virtual de Key Vault para
Windows
A extensão de VM de Key Vault fornece a atualização automática dos certificados armazenados no cofre de
chaves do Azure. Especificamente, os monitores de extensão observado de uma lista de certificados
armazenados no cofre de chaves e, ao detectar uma alteração, recupera e instala os certificados
correspondentes. Este documento detalha as plataformas com opções de plataformas, configurações e
implantação com suporte para a extensão da VM de Key Vault para Windows.
Sistema operacional
A extensão de VM Key Vault dá suporte a versões anteriores do Windows:
Windows Server 2019
Windows Server 2016
Windows Server 2012
A extensão de VM Key Vault também tem suporte na VM local Personalizada que é carregada e convertida em
uma imagem especializada para uso no Azure usando a instalação básica do Windows Server 2019.
Tipos suportados de conteúdo de certificado
PKCS #12
PEM
Pré-requisitos
Key Vault instância com certificado. Consulte criar um Key Vault
A VM deve ter a identidade gerenciada atribuída
A política de acesso de Key Vault deve ser definida com segredos get e list permissão para a identidade
gerenciada VM/VMSS para recuperar a parte de um segredo do certificado. Consulte como autenticar para
Key Vault e atribuir uma política de acesso de Key Vault.
Os conjuntos de dimensionamento de máquinas virtuais devem ter a seguinte configuração de identidade:
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"[parameters('userAssignedIdentityResourceId')]": {}
}
}
A extensão AKV deve ter essa configuração:
"msiEndpoint": "[parameters('userAssignedIdentityEndpoint')]",
"msiClientId": "[reference(parameters('userAssignedIdentityResourceId'),
variables('msiApiVersion')).clientId]"
}
O JSON a seguir mostra o esquema para a extensão da VM de Key Vault. A extensão não requer configurações
protegidas. todas as suas configurações são consideradas informações públicas. A extensão requer uma lista de
certificados monitorados, a frequência de sondagem e o repositório de certificados de destino. Especificamente:
{
"name": "KVVMExtensionForWindows",
"apiVersion": "2019-07-01",
"dependsOn": [
],
"properties": {
"type": "KeyVaultForWindows",
"settings": {
"pollingIntervalInS": <polling interval in seconds, e.g: "3600">,
"certificateStoreName": <certificate store name, e.g.: "MY">,
"linkOnRenewal": <Only Windows. This feature ensures s-channel binding when certificate renews,
without necessitating a re-deployment. e.g.: false>,
"certificateStoreLocation": <certificate store location, currently it works locally only e.g.:
"LocalMachine">,
"requireInitialSync": <initial synchronization of certificates e..g: true>,
"https://myvault.vault.azure.net/secrets/mycertificate"
},
"msiEndpoint": <Optional MSI endpoint e.g.: "http://169.254.169.254/metadata/identity">,
"msiClientId": <Optional MSI identity e.g.: "c7373ae5-91c2-4165-8ab6-7381d6e75619">
}
}
}
}
NOTE
Suas URLs de certificado observadas devem estar no formato
https://myVaultName.vault.azure.net/secrets/myCertName .
Isso porque o caminho /secrets retorna todo o certificado, incluindo a chave privada, enquanto o caminho
/certificates não faz isso. Mais informações sobre certificados podem ser encontradas aqui: Certificados do Key Vault
IMPORTANT
A propriedade ' authenticationSettings ' é necessária somente para VMs com identidades atribuídas pelo usuário .
Especifica a identidade a ser usada para autenticação para Key Vault.
publicador Microsoft.Azure.KeyVault string

type KeyVaultForWindows string
pollingIntervalInS 3600 string
certificateStoreName MY string
linkOnRenewal false booleano
certificateStoreLocation LocalMachine ou CurrentUser string

(diferencia maiúsculas de minúsculas)
requireInitialSync true booleano
observedCertificates ["https://myvault.vault.azure.net/secret Matriz de cadeia de caracteres

s/mycertificate","https://myvault.vault.a
zure.net/secrets/mycertificate2"]
msiEndpoint http://169.254.169.254/metadata/iden string

tity
msiClientId c7373ae5-91c2-4165-8ab6- string

7381d6e75619
ideais ao implantar uma ou mais máquinas virtuais que exigem renovação de certificados pós-implantação. A
extensão pode ser implantada em VMs individuais ou conjunto de dimensionamento de máquinas virtuais. O
esquema e a configuração são comuns a ambos os tipos de modelo.
A configuração JSON para uma extensão de máquina virtual deve ser aninhada dentro do fragmento do recurso
de máquina virtual do modelo, especificamente o objeto "resources": [] para o modelo de máquina virtual e,
no caso de conjunto de dimensionamento de máquinas virtuais, no objeto
"virtualMachineProfile":"extensionProfile":{"extensions" :[] .
NOTE
A extensão de VM exigiria que a identidade gerenciada do sistema ou do usuário fosse atribuída para autenticar no Key
Vault. Consulte como autenticar para Key Vault e atribuir uma política de acesso de Key Vault.
{
"name": "KeyVaultForWindows",
"apiVersion": "2019-07-01",
"dependsOn": [
],
"properties": {
"type": "KeyVaultForWindows",
"settings": {
"pollingIntervalInS": <polling interval in seconds, e.g: "3600">,
"certificateStoreName": <certificate store name, e.g.: "MY">,
"certificateStoreLocation": <certificate store location, currently it works locally only e.g.:
"LocalMachine">,
["https://myvault.vault.azure.net/secrets/mycertificate",
"https://myvault.vault.azure.net/secrets/mycertificate2"]>
}
}
}
}
Ordenação de dependência de extensão

A extensão de VM Key Vault dá suporte à ordenação de extensão, se configurada. Por padrão, a extensão relata
que ela foi iniciada com êxito assim que começou a sondagem. No entanto, ele pode ser configurado para
aguardar até que tenha baixado com êxito a lista completa de certificados antes de relatar um início bem-
sucedido. Se outras extensões dependerem de ter o conjunto completo de certificados instalados antes de
serem iniciadas, habilitar essa configuração permitirá que essas extensões declarem uma dependência na
extensão de Key Vault. Isso impedirá que essas extensões sejam iniciadas até que todos os certificados dos quais
dependem tenham sido instalados. A extensão tentará novamente o download inicial de forma indefinida e
permanecerá em um Transitioning estado.
Para ativar isso, defina o seguinte:
"requireInitialSync": true,
...
}
NOTE
O uso desse recurso não é compatível com um modelo ARM que cria uma identidade atribuída pelo sistema e atualiza
uma política de acesso de Key Vault com essa identidade. Isso resultará em um deadlock, uma vez que a política de acesso
do cofre não pode ser atualizada até que todas as extensões sejam iniciadas. Em vez disso, você deve usar uma identidade
de MSI atribuída por um único usuário e pré-ACL de seus cofres com essa identidade antes da implantação.
Implantação do Azure PowerShell

WARNING
Os clientes do PowerShell geralmente se adicionam \ ao " no settings.js, o que caakvvm_service usará falha com o
erro: [CertificateManagementConfiguration] Failed to parse the configuration settings with:not an object.
O Azure PowerShell pode ser usado para implantar a extensão da VM do Diagnóstico de Key Vault em uma
máquina virtual existente ou em um conjunto de dimensionamento de máquina virtual.
# Build settings
$extName = "KeyVaultForWindows"
$extType = "KeyVaultForWindows"

Set-AzVmExtension -TypeHandlerVersion "1.0" -ResourceGroupName <ResourceGroupName> -Location
<Location> -VMName <VMName> -Name $extName -Publisher $extPublisher -Type $extType -SettingString
$settings
# Build settings
$extName = "KeyVaultForWindows"
$extType = "KeyVaultForWindows"
# Add Extension to VMSS

$vmss = Get-AzVmss -ResourceGroupName <ResourceGroupName> -VMScaleSetName <VmssName>
Add-AzVmssExtension -VirtualMachineScaleSet $vmss -Name $extName -Publisher $extPublisher -Type
$extType -TypeHandlerVersion "1.0" -Setting $settings

Update-AzVmss -ResourceGroupName <ResourceGroupName> -VMScaleSetName <VmssName> -
VirtualMachineScaleSet $vmss

A CLI do Azure pode ser usada para implantar a extensão da VM do Key Vault em uma máquina virtual existente
ou em um conjunto de dimensionamento de máquinas virtuais.
az vm extension set -name "KeyVaultForWindows" `
-resource-group "<resourcegroup>" `

az vmss extension set -name "KeyVaultForWindows" `
-resource-group "<resourcegroup>" `
--vmss-name "<vmName>" `
Por favor esteja ciente das seguintes restrições/exigências:

Restrições de Key Vault:
Ele deve existir no momento da implantação
A política de acesso de Key Vault deve ser definida para a identidade VM/VMSS usando uma
identidade gerenciada. Consulte como autenticar para Key Vault e atribuir uma política de acesso de
Key Vault.

Azure PowerShell. Para ver o estado da implantação das extensões de uma determinada VM, execute o comando
a seguir usando o Azure PowerShell.
PowerShell do Azure
Get-AzVMExtension -VMName <vmName> -ResourceGroupname <resource group name>
CLI do Azure
az vm get-instance-view --resource-group <resource group name> --name <vmName> --query

"instanceView.extensions"
Logs e configuração
%windrive%\WindowsAzure\Logs\Plugins\Microsoft.Azure.KeyVault.KeyVaultForWindows\
<version>\akvvm_service_<date>.log
Suporte
Backup do Azure para SQL Server em execução na
VM do Azure
O backup do Azure, entre outras ofertas, oferece suporte ao backup de cargas de trabalho, como SQL Server em
execução em VMs do Azure. Como o aplicativo SQL está sendo executado em uma VM do Azure, o serviço de
backup precisa de permissão para acessar o aplicativo e buscar os detalhes necessários. Para fazer isso, o
backup do Azure instala a extensão AzureBackupWindowsWorkload na VM, na qual o SQL Server está em
execução, durante o processo de registro disparado pelo usuário.
Pré-requisitos
Para obter a lista de cenários com suporte, consulte a matriz de suporte com suporte do backup do Azure.
Conectividade de rede
O backup do Azure dá suporte a marcas NSG, implantando um servidor proxy ou intervalos de IP listados; para
obter detalhes sobre cada um dos métodos, consulte este artigo.
O esquema de extensão e os valores de propriedade são os valores de configuração (configurações de tempo de
execução) que o serviço está passando para a API do CRP. Esses valores de configuração são usados durante o
registro e a atualização. A extensão AzureBackupWindowsWorkload também usa esse esquema. O esquema
é predefinido; um novo parâmetro pode ser adicionado no campo objectStr
"runtimeSettings": [{
"handlerSettings": {
"protectedSettingsCertThumbprint": "",
"objectStr": "",
"logsBlobUri": "",
"statusBlobUri": ""
}
},
"publicSettings": {
"locale": "en-us",
"taskId": "1c0ae461-9d3b-418c-a505-bb31dfe2095d",
"objectStr": "",
"commandStartTimeUTCTicks": "636295005824665976",
"vmType": "vmType"
}
}]
}
O JSON a seguir mostra o esquema para a extensão WorkloadBackup.

{
"name": "WorkloadBackup",
"location":"<myLocation>",
"properties": {
"publisher": "Microsoft.RecoveryServices",
"type": "AzureBackupWindowsWorkload",
"settings": {
"locale":"<location>",
"taskId":"<TaskId used by Azure Backup service to communicate with extension>",
"objectStr": "<The configuration passed by Azure Backup service to extension>",
"commandStartTimeUTCTicks": "<Scheduled start time of registration or upgrade task>",

"vmType": "<Type of VM where registration got triggered Eg. Compute or ClassicCompute>"
},
"objectStr": "<The sensitive configuration passed by Azure Backup service to extension>",
"logsBlobUri": "<blob uri where logs of command execution by extension are written to>",
"statusBlobUri": "<blob uri where status of the command executed by extension is written>"
}
}
}
localidade pt-br string
taskId "1c0ae461-9d3b-418c-a505- string

bb31dfe2095d"
objectStr "eyJjb250YWluZXJQcm9wZXJ0aWVzIjp string

PublicSettings 7IkNvbnRhaW5lcklEIjoiMzVjMjQxYTItO
GRjNy00ZGE5LWI4NTMtMjdjYTJhNDZl
M2ZkIiwiSWRNZ210Q29udGFpbmVyS
WQiOjM0NTY3ODg5LCJSZXNvdXJjZUl
kIjoiMDU5NWIwOGEtYzI4Zi00ZmFlLW
E5ODItOTkwOWMyMGVjNjVhIiwiU3Vi
c2NyaXB0aW9uSWQiOiJkNGEzOTliNy1
iYjAyLTQ2MWMtODdmYS1jNTM5ODI
3ZTgzNTQiLCJVbmlxdWVDb250
YWluZXJOYW1lIjoiODM4MDZjODUtN
TQ4OS00NmNhLWEyZTctNWMzNzNh
Yjg3OTcyIn0sInN0YW1wTGlzdCI6W3si
U2VydmljZU5hbWUiOjUsIlNlcnZpY2V
TdGFtcFVybCI6Imh0dHA6XC9cL015V0
xGYWJTdmMuY29tIn1dfQ = ="
commandStartTimeUTCTicks "636967192566036845" string
vmType "Microsoft. Compute/VirtualMachines" string

objectStr "eyJjb250YWluZXJQcm9wZXJ0aWVzIjp string

ProtectedSettings 7IkNvbnRhaW5lcklEIjoiMzVjMjQxYTItO
GRjNy00ZGE5LWI4NTMtMjdjYTJhNDZl
M2ZkIiwiSWRNZ210Q29udGFpbmVyS
WQiOjM0NTY3ODg5LCJSZXNvdXJjZUl
kIjoiMDU5NWIwOGEtYzI4Zi00ZmFlLW
E5ODItOTkwOWMyMGVjNjVhIiwiU3Vi
c2NyaXB0aW9uSWQiOiJkNGEzOTliNy1
iYjAyLTQ2MWMtODdmYS1jNTM5ODI
3ZTgzNTQiLCJVbmlxdWVDb250
YWluZXJOYW1lIjoiODM4MDZjODUtN
TQ4OS00NmNhLWEyZTctNWMzNzNh
Yjg3OTcyIn0sInN0YW1wTGlzdCI6W3si
U2VydmljZU5hbWUiOjUsIlNlcnZpY2V
TdGFtcFVybCI6Imh0dHA6XC9cL015V0
xGYWJTdmMuY29tIn1dfQ = ="
logsBlobUri https://seapod01coord1exsapk732.blo string

b.core.windows.net/bcdrextensionlogs-
d45d8a1c-281e-4bc8-9d30-
3b25176f68ea/sopattna-
vmubuntu1404ltsc.v2.Logs.txt?
sv=2014-02-
14&sr=b&sig=DbwYhwfeAC5YJzISgxo
Kk%2FEWQq2AO1vS1E0rDW%2FlsBw
%3D&st=2017-11-
09T14%3A33%3A29Z&se=2017-11-
09T17%3A38%3A29Z&sp=rw
statusBlobUri https://seapod01coord1exsapk732.blo string

d45d8a1c-281e-4bc8-9d30-
vmubuntu1404ltsc.v2.Status.txt?
sv=2014-02-
14&sr=b&sig=96RZBpTKCjmV7QFeX
m5IduB%2FILktwGbLwbWg6Ih96Ao%
3D&st=2017-11-
09T14%3A33%3A29Z&se=2017-11-
09T17%3A38%3A29Z&sp=rw
Recomendamos adicionar a extensão AzureBackupWindowsWorkload a uma máquina virtual, habilitando SQL
Server backup na máquina virtual. Isso pode ser obtido por meio do modelo do Resource Manager projetado
para automatizar o backup em uma VM SQL Server.
Implantação do PowerShell
Você precisa ' Registrar ' a VM do Azure que contém o aplicativo SQL com um cofre dos serviços de
recuperação. Durante o registro, a extensão AzureBackupWindowsWorkload é instalada na VM. Use o
cmdletRegister-AzRecoveryServicesBackupContainerPS para registrar a VM.
$myVM = Get-AzVM -ResourceGroupName <VMRG Name> -Name <VMName>

Register-AzRecoveryServicesBackupContainer -ResourceId $myVM.ID -BackupManagementType AzureWorkload -
WorkloadType MSSQL -VaultId $targetVault.ID -Force
O comando retornará um contêiner de backup desse recurso e o status será registrado .
Próximas etapas
Saiba mais sobre as diretrizes de solução de problemas de backup de VM do Azure SQL Server
Perguntas comuns sobre como fazer backup de bancos de dados SQL Server executados em VMS (máquinas
virtuais) do Azure e que usam o serviço de backup do Azure.
Usar a Versão 2 da Extensão de Script
Personalizado do Azure com máquinas virtuais do
Linux
A Versão 2 da Extensão de Script Personalizado baixa e executa scripts em máquinas virtuais do Azure. Essa
extensão é útil para a configuração de implantação de postagem, instalação de software ou qualquer outra
configuração/tarefa de gerenciamento. Você pode fazer o download de scripts a partir do Armazenamento do
Microsoft Azure ou outro local acessível da internet, ou você pode fornecê-los para o runtime da extensão.
A extensão de Script personalizado se integra com os modelos do Azure Resource Manager. Você também pode
executá-la usando a CLI do Azure, o PowerShell, o portal do Azure ou a API de REST de máquinas virtuais do
Azure.
Este artigo fornece detalhes sobre como usar a extensão de Script personalizado da CLI do Azure, e como
executar a extensão usando um modelo do Azure Resource Manager. Este artigo também fornece as etapas de
solução de problemas para os sistemas do Linux.
Há duas Extensões do Script Personalizado do Linux:
Versão 1 - Microsoft.OSTCExtensions.CustomScriptForLinux
Versão 2 - Microsoft.Azure.Extensions.CustomScript
Alterne entre implantações novas e existentes para usar a nova versão 2. A nova versão tem o objetivo de ser
uma substituição perfeita. Assim, a migração é tão fácil quanto alterar o nome e versão. Você não precisa alterar
a configuração de extensão.
Sistema operacional
A extensão de script personalizado para Linux será executada na extensão do so de extensão com suporte, para
obter mais informações, consulte este artigo.
Local do script
Você pode utilizar a extensão para usar suas credenciais do Armazenamento de Blobs do Azure para acessar
esse armazenamento. Como alternativa, o local do script pode ser qualquer lugar, desde que a VM possa rotear
para esse ponto de extremidade, como GitHub, servidor de arquivos interno, etc.
Conectividade com a Internet
Se você precisar fazer o download um script externamente, como do GitHub ou do Armazenamento do Azure,
será necessário abrir portas adicionais do firewall ou do Grupo de Segurança de Rede. Por exemplo, se o seu
script estiver localizado no armazenamento do Azure, você poderá permitir o acesso usando as marcas do
serviço NSG do Azure para armazenamento.
Se o script estiver em um servidor local, ainda poderá ser necessário abrir portas adicionais do firewall ou do
Grupo de Segurança de Rede.
Dicas e truques
A taxa de falha mais alta para esta extensão acontece devido a erros de sintaxe no script. Teste as execuções
de script sem erros e também insira um registro em log adicional no script para facilitar a localização da
falha.
Escreva scripts idempotentes, para que se forem executados mais de uma vez por acidente, eles não causem
alterações no sistema.
Verifique se os scripts não exigem entrada do usuário quando são executados.
É permitido que o script seja executado em até 90 minutos. Um período mais longo resultará em falha na
provisão da extensão.
Não coloque reinicializações no script, pois isso causará problemas com outras extensões que estão sendo
instaladas e, após a reinicialização, a extensão será interrompida.
Não é recomendável executar um script que causará uma parada ou atualização do agente de VM. Isso pode
deixar a extensão em um estado de transição e levar a um tempo limite.
Se você tiver um script que causará uma reinicialização, instale aplicativos e execute scripts, etc. Você deve
agendar a reinicialização usando um trabalho cron ou usando ferramentas como DSC, ou chefe, Puppet
Extensions.
A extensão executará um script somente uma vez. Se quiser executar um script em cada inicialização, então
você poderá usar imagem de inicialização de nuvem e um módulo Scripts Por Inicialização. Como alternativa,
você pode usar o script para criar uma unidade de serviço do sistema.
Você só pode ter uma versão de uma extensão aplicada à VM. Para executar um segundo script
personalizado, você pode atualizar a extensão existente com a nova configuração. Como alternativa, você
pode remover a extensão de script personalizado e reaplicá-la novamente com o script atualizado.
Se quiser agendar quando um script será executado, você deverá usar a extensão para criar um trabalho
Cron.
Quando o script for executado, você só verá um status da extensão 'em transição' no portal do Azure ou no
CLI. Se quiser atualizações de status mais frequentes de um script em execução, você precisará criar sua
própria solução.
A extensão de script personalizado não dá suporte nativo a servidores proxy, no entanto, você pode usar
uma ferramenta de transferência de arquivo que dá suporte a servidores proxy em seu script, como
ondulação.
Lembre-se de locais de diretório não padrão nos quais seus scripts ou comandos podem confiar e ter lógica
para lidar com isso.
Ao implantar o script personalizado em instâncias de VMSS de produção, é recomendável implantar por
meio do modelo JSON e armazenar sua conta de armazenamento de script onde você tem controle sobre o
token SAS.
A configuração de extensão de script personalizado especifica itens como localização de script e o comando a
ser executado. Você pode armazenar essa configuração em arquivos de configuração, especificá-la na linha de
comando ou especificá-la em um modelo do Azure Resource Manager.
Você pode armazenar dados confidenciais em uma configuração protegida, que é criptografada e
descriptografada somente dentro da máquina virtual. A configuração protegida é útil quando o comando de
execução inclui segredos, como uma senha.
Esses itens devem ser tratados como dados confidenciais e especificados na configuração de definição
protegida por extensões. Os dados de configuração protegidos pela extensão da VM do Azure são
criptografados, sendo descriptografados apenas na máquina virtual de destino.
{
"type": "Extensions",
"apiVersion": "2019-03-01",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
"skipDos2Unix":false,
"timestamp":123456789
},
"commandToExecute": "<command-to-execute>",
"script": "<base64-script-to-execute>",
"storageAccountName": "<storage-account-name>",
"storageAccountKey": "<storage-account-key>",
"fileUris": ["https://.."],
"managedIdentity" : "<managed-identity-identifier>"
}
}
}
NOTE
A propriedade managedIdentity não pode ser usada em conjunto com as propriedades storageAccountName ou
storageAccountKey
publicador Microsoft.Compute.Extensions string
type CustomScript string
fileUris (por exemplo) matriz

https://github.com/MyProject/Archive/MyPythonScript.py
commandToExecute (por exemplo) MyPythonScript.py Python <my- string

param1>
Script IyEvYmluL3NoCmVjaG8gIlVwZGF0aW string

5nIHBhY2thZ2VzIC4uLiIKYXB0IHVwZ
GF0ZQphcHQgdXBncmFkZSAteQo=
skipDos2Unix (exemplo) false booleano

carimbo de data/hora (exemplo) 123456789 Inteiro de 32 bits
storageAccountName (por exemplo) examplestorageacct string
storageAccountKey (por exemplo) TmJK/1N3AbAZ3q/+hOXoi/l73zOqsax string

XDhqa9Y83/v5UpXQp2DQIBuv2Tifp6
0cE/OaHsJZmQZ7teQfczQj8hg==
managedIdentity (por exemplo) { } ou { "clientId": "31b403aa-c364- objeto JSON

4240-a7ff-d85fb6cd7232" } ou {
"objectId": "12dd289c-0583-46e5-
b9b4-115d5c19ef4b" }
Detalhes de valor de propriedade

apiVersion : O apiVersion mais atualizado pode ser encontrado usando o Gerenciador de recursos ou de CLI
do Azure usando o comando a seguir az provider list -o json
skipDos2Unix : (opcional, booliano) ignore a conversão de dos2unix das URLs de arquivos baseado no script
ou do script.
timestamp (opcional, inteiro de 32 bits) use este campo somente para disparar uma nova execução do script
ao alterar o valor desse campo. Qualquer valor inteiro é aceitável. Só deve ser diferente do valor anterior.
commandToExecute (obrigatório se o script não for definido, cadeia de caracteres) o script de ponto de
entrada a ser executado. Use este campo se o comando tiver segredos, como senhas.
script : (necessário se commandToExecute não for definido, cadeia de caracteres) um script codificado em
Base64 (e opcionalmente compactado com Gzip) executado pelo /bin/sh.
fileUris : (opcional, matriz de cadeia de caracteres) as URLs dos arquivos a serem baixados.
storageAccountName : (opcional, cadeia de caracteres) o nome da conta de armazenamento. Se você
especificar credenciais de armazenamento, todos os fileUris deverão ser URLs para Blobs do Azure.
storageAccountKey : (opcional, cadeia de caracteres) a chave de acesso da conta de armazenamento
managedIdentity : (opcional, objeto JSON) a identidade gerenciada para baixar arquivos
clientId : (opcional, cadeia de caracteres) a ID do cliente da identidade gerenciada
objectId : (opcional, cadeia de caracteres) a ID de objeto da identidade gerenciada
Os valores a seguir podem ser definidos nas configurações públicas ou protegidas. A extensão rejeitará
qualquer configuração em que os valores abaixo estejam definidos tanto nas configurações protegidas quanto
nas públicas.
commandToExecute
script
fileUris
Usar as configurações públicas pode ser útil para depuração, mas é altamente recomendável usar as
configurações protegidas.
As configurações públicas são enviadas em texto não criptografado para a VM na qual o script será executado.
As configurações protegidas são criptografadas usando uma chave conhecida apenas pelo Azure e pela VM. As
configurações são salvas na VM no estado em que foram enviadas, ou seja, se foram criptografadas, elas serão
salvas criptografadas na VM. O certificado usado para descriptografar os valores criptografados é armazenado
na VM e usado para descriptografar as configurações (se necessário) no runtime.
Propriedade: skipDos2Unix
O valor padrão é false, o que significa que a conversão de dos2unix foi executada.
A versão anterior do CustomScript, Microsoft.OSTCExtensions.CustomScriptForLinux, seria converter
automaticamente arquivos DOS para arquivos do UNIX ao traduzir \r\n para \n . Essa translação ainda existe
e está ativada por padrão. Essa conversão é aplicada a todos os arquivos baixados do fileUris ou à configuração
de script com base em qualquer um dos critérios a seguir.
Se a extensão for uma dos .sh , .txt , .py ou .pl , ela será convertida. A configuração de script sempre
corresponderá a esse critério, pois ele é considerado um script executado com /bin/sh e é salvo como
script.sh na VM.
Se o arquivo começar com #! .
A conversão de dos2unix poderá ser ignorada ao definir o skipDos2Unix como true.
{
"fileUris": ["<url>"],
"skipDos2Unix": true
}
Propriedade: script
CustomScript dá suporte à execução de um script definido pelo usuário. As configurações de script para
combinar commandToExecute e fileUris em uma única configuração. Em vez de ter que configurar um arquivo
para download do armazenamento do Azure ou do gist do GitHub, você pode simplesmente codificar o script
como uma configuração. O script pode ser usado para commandToExecute e fileUris substituídos.
O script deve ser codificado em Base64. O script pode, opcionalmente , ser compactado com Gzip. A
configuração de script pode ser usada nas configurações públicas ou protegidas. O tamanho máximo dos dados
do parâmetro do script é 256 KB. Se o script exceder esse tamanho, não será executado.
Por exemplo, considerando o seguinte script salvo no arquivo /script.sh/.
#!/bin/sh
echo "Updating packages ..."
apt update
apt upgrade -y
A configuração correta do script de CustomScript deve ser construída ao utilizar a saída do comando a seguir.
cat script.sh | base64 -w0
{
"script": "IyEvYmluL3NoCmVjaG8gIlVwZGF0aW5nIHBhY2thZ2VzIC4uLiIKYXB0IHVwZGF0ZQphcHQgdXBncmFkZSAteQo="
}
O script pode, opcionalmente, ser compactado com Gzip para reduzir o tamanho (na maioria dos casos).
(CustomScript detecta automaticamente o uso de compactação gzip.)
cat script | gzip -9 | base64 -w 0
CustomScript usa o algoritmo a seguir para executar um script.

1. declarar que o comprimento do valor do script não excede 256 KB.
2. Base64 decodifica o valor do script
3. tentativa de efetuar gunzip no valor decodificado em Base64
4. gravar o valor decodificado (e opcionalmente descompactado) para o disco (/var/lib/waagent/custom-
script/#/script.sh)
5. execute o script usando _/bin/sh -c /var/lib/waagent/custom-script/#/script.sh.
Propriedade: managedIdentity
NOTE
Essa propriedade precisa ser especificada somente em configurações protegidas.
O CustomScript (versão 2,1 em diante) dá suporte à identidade gerenciada para baixar arquivo (s) de URLs
fornecidas na configuração "fileuris". Ele permite que o CustomScript acesse contêineres ou blobs privados do
Armazenamento do Azure sem que o usuário precise passar segredos como tokens SAS ou chaves de conta de
armazenamento.
Para usar esse recurso, o usuário precisa adicionar uma identidade atribuída pelo sistema ou atribuída pelo
usuário à VM ou VMSS em que se espera que o CustomScript seja executado e permitir acesso de identidade
gerenciada ao blob ou contêiner do Armazenamento do Azure.
Para usar a identidade atribuída pelo sistema na VM/VMSS de destino, defina o campo "managedidentity" como
um objeto JSON vazio.
Exemplo:
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.sh"],
"commandToExecute": "sh script1.sh",
"managedIdentity" : {}
}
Para usar a identidade atribuída pelo usuário na VM/VMSS de destino, configure o campo "managedidentity"
com a ID do cliente ou a ID de objeto da identidade gerenciada.
Exemplos:
{
"managedIdentity" : { "clientId": "31b403aa-c364-4240-a7ff-d85fb6cd7232" }
}
{
"managedIdentity" : { "objectId": "12dd289c-0583-46e5-b9b4-115d5c19ef4b" }
}
NOTE
storageAccountKey
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. O esquema JSON
detalhado na seção anterior pode ser usado em um modelo do Azure Resource Manager para executar a
Extensão de Script Personalizado durante uma implantação de modelo do Azure Resource Manager. Um modelo
de exemplo que inclui a Extensão de Script Personalizado pode ser encontrado aqui, GitHub.
{
"apiVersion": "2019-03-01",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
},
"commandToExecute": "sh hello.sh <param2>",
"fileUris": ["https://github.com/MyProject/Archive/hello.sh"
]
}
}
}
NOTE
Esses nomes de propriedade diferenciam maiúsculas de minúsculas. Para evitar problemas de implantação, use os nomes
conforme mostrado aqui.
CLI do Azure
Quando você estiver usando a CLI do Azure para executar a extensão de Script personalizado, crie um arquivo
ou arquivos de configuração. No mínimo, você deve ter 'commandToExecute'.
az vm extension set \
--vm-name myVM --name customScript \
--publisher Microsoft.Azure.Extensions \
--protected-settings ./script-config.json
Opcionalmente, você pode especificar as configurações no comando como uma cadeia de caracteres do formato
JSON. Isso permite especificar a configuração durante a execução e sem um arquivo de configuração separado.
--resource-group exttest \
--vm-name exttest \
--name customScript \
--protected-settings '{"fileUris": ["https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-
templates/master/dotnet-core-music-linux/scripts/config-music.sh"],"commandToExecute": "./config-music.sh"}'
Exemplos de CLI do Azure

Configuração pública com o arquivo de script
{
"fileUris": ["https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-
music-linux/scripts/config-music.sh"],
"commandToExecute": "./config-music.sh"
}
Comando CLI do Azure:
--settings ./script-config.json
Configuração pública sem arquivo de script
{
"commandToExecute": "apt-get -y update && apt-get install -y apache2"
}
Arquivos de configuração protegida e pública

Você usa um arquivo de configuração pública para especificar o URI do arquivo de script. Você usa um arquivo
de configuração protegida para especificar o comando a ser executado.
Arquivo de configuração pública:
{
music-linux/scripts/config-music.sh"]
}
Arquivo de configuração protegida:
{
"commandToExecute": "./config-music.sh <param1>"
}
--vm-name myVM \
--settings ./script-config.json \
--protected-settings ./protected-config.json
Quando a extensão de script personalizado é executada, o script é criado ou baixado em um diretório
semelhante ao exemplo a seguir. A saída do comando também é salva nesse diretório nos arquivos stdout e
stderr .
/var/lib/waagent/custom-script/download/0/
Para solucionar problemas, primeiro verifique o Log de Agente do Linux, confira a extensão executada, verifique:
Você deve procurar a execução da extensão, a exibição será algo assim:
2018/04/26 17:47:22.110231 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] [Enable] current handler

state is: notinstalled
2018/04/26 17:47:22.306407 INFO Event: name=Microsoft.Azure.Extensions.customScript, op=Download,
message=Download succeeded, duration=167
2018/04/26 17:47:22.339958 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] Initialize extension
directory
2018/04/26 17:47:22.368293 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] Update settings file:
0.settings
2018/04/26 17:47:22.394482 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] Install extension
[bin/custom-script-shim install]
2018/04/26 17:47:23.432774 INFO Event: name=Microsoft.Azure.Extensions.customScript, op=Install,
message=Launch command succeeded: bin/custom-script-shim install, duration=1007
2018/04/26 17:47:23.476151 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] Enable extension
[bin/custom-script-shim enable]
2018/04/26 17:47:24.516444 INFO Event: name=Microsoft.Azure.Extensions.customScript, op=Enable,
message=Launch command succeeded: bin/custom-sc
Alguns pontos a serem observados:

1. Habilitar é quando o comando é iniciado.
2. O download está relacionado ao download do pacote de extensão CustomScript do Azure, não aos arquivos
de script especificados no fileUris.
A extensão de script do Azure produz um log, que pode ser encontrado aqui:
/var/log/azure/custom-script/handler.log
Você deve procurar a execução individual; ela terá uma aparência semelhante a:
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=start
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=pre-check
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="comparing seqnum"
path=mrseq
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="seqnum saved"
path=mrseq
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="reading
configuration"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="read configuration"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="validating json
schema"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="json schema valid"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="parsing
configuration json"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="parsed
configuration json"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="validating
configuration logically"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="validated
configuration"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="creating output
directory" path=/var/lib/waagent/custom-script/download/0
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="created output
directory"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 files=1
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 file=0 event="download
start"
complete" output=/var/lib/waagent/custom-script/download/0
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="executing command"
output=/var/lib/waagent/custom-script/download/0
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="executing protected
commandToExecute" output=/var/lib/waagent/custom-script/download/0
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="executed command"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=enabled
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=end
Aqui, você pode ver:

O início do comando Habilitar é este log
As configurações passadas para a extensão
A extensão baixando o arquivo e o resultado disso.
O comando em execução e o resultado.
Você também pode recuperar o estado de execução da extensão de script personalizado, incluindo os
argumentos reais passados como o commandToExecute usando CLI do Azure:
az vm extension list -g myResourceGroup --vm-name myVM
A saída se parece com o seguinte texto:

[
{
"id":
"/subscriptions/subscriptionid/resourceGroups/rgname/providers/Microsoft.Compute/virtualMachines/vmname/exte
nsions/customscript",
"resourceGroup": "rgname",
"settings": {
"commandToExecute": "sh script.sh > ",
"fileUris": [
"https://catalogartifact.azureedge.net/publicartifacts/scripts/script.sh",
"https://catalogartifact.azureedge.net/publicartifacts/scripts/script.sh"
]
},
"tags": null,
"virtualMachineExtensionType": "CustomScript"
},
{
"id":
nsions/OmsAgentForLinux",
"instanceView": null,
"name": "OmsAgentForLinux",
"protectedSettings": null,
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"settings": {
"workspaceId": "workspaceid"
},
"tags": null,
"virtualMachineExtensionType": "OmsAgentForLinux"
}
]
Próximas etapas
Para ver o código, os problemas atuais e as versões, consulte custom-script-extension-linux repo.
Extensão de script personalizado para o Windows
A extensão de script personalizado baixa e executa scripts em máquinas virtuais do Azure. Essa extensão é útil
para a configuração de pós-implantação, instalação de software ou qualquer outra configuração ou tarefas de
Portal do Azure no tempo de execução da extensão. A Extensão de Script Personalizado se integra com modelos
do Azure Resource Manager e pode ser executada usando a CLI do Azure, o PowerShell, o portal do Azure ou a
API REST da máquina virtual do Azure.
Este documento detalha como usar a Extensão de Script Personalizado usando o módulo do Azure PowerShell e
modelos do Azure Resource Manager, além de detalhar as etapas da solução de problemas em sistemas
Windows.
Pré-requisitos
NOTE
Não use a Extensão de Script Personalizado para executar Update-AzVM com a mesma VM como seu parâmetro, pois ela
aguardará por si própria.
Sistema operacional
A Extensão de Script Personalizado para Windows executará nos SOs de extensão compatíveis da extensão.
Windows
Windows Server 2008 R2
Windows Server 2012
Windows 10
Windows Server 2016
Windows Server 2016 Core
Windows Server 2019
Local do script
Você pode configurar a extensão para usar suas credenciais do Armazenamento de Blobs do Azure para acessar
esse armazenamento. A localização do script pode estar em qualquer lugar, desde que a VM possa rotear para
esse ponto de extremidade, como o GitHub ou um servidor de arquivos interno.
será necessário abrir portas adicionais do firewall e do Grupo de Segurança de Rede. Por exemplo, se o script
estiver localizado no Armazenamento do Azure, você poderá permitir acesso usando Marcas de Serviço do NSG
do Azure para Armazenamento.
Observe que a extensão CustomScript não tem nenhuma maneira de ignorar a validação do certificado.
Portanto, se você estiver baixando de um local seguro com por exemplo. um certificado autoassinado, você
pode acabar com erros como "o certificado remoto é inválido de acordo com o procedimento de validação".
Certifique-se de que o certificado esteja instalado corretamente no repositório "autoridades de certificação raiz
confiáveis" na máquina virtual.
Se o script estiver em um servidor local, ainda poderá ser necessário abrir portas adicionais do firewall e do
Dicas e truques
falha.
Escreva scripts idempotentes. Isso garante que, se eles forem executados novamente por acidente, não
causarão alterações no sistema.
Assegure-se de que os scripts não exigirão a entrada do usuário quando forem executados.
É permitido que o script seja executado em até 90 minutos e um período mais longo resultará em falha na
Não coloque reinicializações dentro do script, pois essa ação causará problemas com outras extensões que
estão sendo instaladas. Após a reinicialização, a extensão não continuará depois de reiniciar.
Se você tiver um script que causará uma reinicialização, instalará aplicativos e executará scripts, você poderá
agendar a reinicialização usando uma Tarefa Agendada do Windows ou usar ferramentas como as extensões
DSC, Chef ou Puppet.
deixar a extensão em um estado de transição, levando a um tempo limite.
A extensão executará um script somente uma vez. Se você quiser executar um script em cada inicialização,
use a extensão pra criar uma Tarefa Agendada do Windows.
Se você quiser agendar quando um script será executado, use a extensão para criar uma Tarefa Agendada do
Windows.
CLI. Se quiser atualizações de status mais frequentes de um script em execução, será necessário criar sua
própria solução.
uma ferramenta de transferência de arquivo que dá suporte a servidores proxy em seu script, como Invoke-
WebRequest
Esteja ciente dos locais de diretório não padrão nos quais os scripts ou comandos podem confiar e mantenha
uma lógica para lidar com essa situação.
A extensão de script personalizado será executada na conta LocalSystem
Se você planeja usar as propriedades storageAccountName e storageAccountKey , essas propriedades
deverão ser posicionadas no protectedSettings.
{
"apiVersion": "2018-06-01",
"name": "virtualMachineName/config-app",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
"fileUris": [
"script location"
],
},
"commandToExecute": "myExecutionCommand",
"storageAccountName": "myStorageAccountName",
"storageAccountKey": "myStorageAccountKey",
}
}
}
NOTE
storageAccountKey
NOTE
Somente uma versão de uma extensão pode ser instalada em uma VM em um determinado momento. A especificação de
um script personalizado duas vezes no mesmo modelo do Resource Manager para a mesma VM falhará.
NOTE
Podemos usar esse esquema dentro do recurso VirtualMachine ou como um recurso autônomo. O nome do recurso
precisará estar neste formato: "nomeDaMáquinaVirtual/nomeDaExtensão", se essa extensão for usada como um recurso
autônomo no modelo do ARM.
publicador Microsoft.Compute string
type CustomScriptExtension string
typeHandlerVersion 1,10 INT
fileUris (por exemplo) https://raw.githubusercontent.com/Mic matriz

rosoft/dotnet-core-sample-
templates/master/dotnet-core-music-
windows/scripts/configure-music-
app.ps1
commandToExecute (por exemplo) powershell -ExecutionPolicy string

Unrestricted -File configure-music-
app.ps1


4240-a7ff-d85fb6cd7232" } ou {
"objectId": "12dd289c-0583-46e5-
b9b4-115d5c19ef4b" }
NOTE

commandToExecute : (necessária , cadeia de caracteres) o script de ponto de entrada a ser executado. Use esse
campo se o comando contiver segredos, como senhas, ou se os fileUris diferenciarem maiúsculas de
minúsculas.
timestamp (opcional, inteiro de 32 bits) use esse campo apenas para disparar uma nova execução do script,
alterando o valor desse campo. Qualquer valor inteiro é aceitável. Só deve ser diferente do valor anterior.
nas públicas.
commandToExecute
Usar configurações públicas talvez seja útil para depuração, mas é recomendável usar configurações protegidas.
configurações são salvas na VM conforme são enviadas, ou seja, se as configurações forem criptografadas, elas
serão salvas criptografadas na VM. O certificado usado para descriptografar os valores criptografados é
armazenado na VM e usado para descriptografar as configurações (se necessário) no runtime.
NOTE
O CustomScript (versão 1.10 em diante) é compatível com identidade gerenciada para baixar arquivos de URLs
fornecidas na configuração "fileUris". Ele permite que o CustomScript acesse contêineres ou blobs privados do
armazenamento.
Exemplo:
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.ps1"],
"commandToExecute": "powershell.exe script1.ps1",
}
Exemplos:
{
}
{
}
NOTE
storageAccountKey
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. O esquema
JSON, detalhado na seção anterior, pode ser usado em um modelo do Azure Resource Manager para executar a
Extensão de Script Personalizado durante uma implantação. Os exemplos a seguir mostram como usar a
extensão de Script personalizado:
Tutorial: Implantar extensões de máquina virtual com modelos do Azure Resource Manager
Implante o aplicativo de duas camadas no Windows e no banco de dados SQL do Azure
O comando Set-AzVMCustomScriptExtension pode ser usado para adicionar a Extensão de Script Personalizado a
uma máquina virtual existente. Para obter mais informações, confira Set-AzVMCustomScriptExtension.
Set-AzVMCustomScriptExtension -ResourceGroupName <resourceGroupName> `

-VMName <vmName> `
-Location myLocation `
-FileUri <fileUrl> `
-Run 'myScript.ps1' `
-Name DemoScriptExtension
Mais exemplos
Usando vários scripts
Neste exemplo, você tem três scripts que são usados para criar seu servidor. O commandToExecute chama o
primeiro script e, em seguida, você tem opções sobre como os outros são chamados. Por exemplo, você pode
ter um script mestre que controla a execução, com o tratamento de erro, o registro em log e o gerenciamento de
estado corretos. Os scripts são baixados no computador local para execução. Por exemplo, em 1_Add_Tools.ps1 ,
você chamaria 2_Add_Features.ps1 adicionando .\2_Add_Features.ps1 ao script e repetiria esse processo para
os outros scripts definidos em $settings .
$fileUri = @("https://xxxxxxx.blob.core.windows.net/buildServer1/1_Add_Tools.ps1",
"https://xxxxxxx.blob.core.windows.net/buildServer1/2_Add_Features.ps1",
"https://xxxxxxx.blob.core.windows.net/buildServer1/3_CompleteInstall.ps1")
$settings = @{"fileUris" = $fileUri};
$storageAcctName = "xxxxxxx"
$storageKey = "1234ABCD"
$protectedSettings = @{"storageAccountName" = $storageAcctName; "storageAccountKey" = $storageKey;
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File 1_Add_Tools.ps1"};
#run command
Set-AzVMExtension -ResourceGroupName <resourceGroupName> `
-Location <locationName> `
-VMName <vmName> `
-Name "buildserver1" `
-TypeHandlerVersion "1.10" `
-Settings $settings `
-ProtectedSettings $protectedSettings;
Executando scripts de um compartilhamento local

Neste exemplo, talvez você queira usar um servidor SMB local para a localização do script. Se fizer isso, você
não precisará fornecer outras configurações, exceto commandToExecute .
$protectedSettings = @{"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File

\\filesvr\build\serverUpdate1.ps1"};

-VMName <vmName> `
-Name "serverUpdate"
-ProtectedSettings $protectedSettings
Como executar o script personalizado mais de uma vez com a CLI

Se você quiser executar a extensão do script personalizado mais de uma vez, poderá executar essa ação
somente sob estas condições:
O parâmetro Name da extensão é o mesmo que o da implantação anterior da extensão.
Atualize a configuração, caso contrário, o comando não executará novamente. É possível adicionar uma
propriedade dinâmica ao comando, como um carimbo de data/hora.
Como alternativa, você pode definir a propriedade ForceUpdateTag como true .
Como usar Invoke-WebRequest
Se você estiver usando Invoke-WebRequest em seu script, precisará especificar o parâmetro -UseBasicParsing
ou, caso contrário, receberá o seguinte erro ao verificar o status detalhado:
The response content cannot be parsed because the Internet Explorer engine is not available, or Internet
Explorer's first-launch configuration is not complete. Specify the UseBasicParsing parameter and try again.
Conjuntos de Dimensionamento de Máquinas Virtuais

Para implantar a extensão de script personalizado em um conjunto de dimensionamento, confira Add-
AzVmssExtension
VMs clássicas
IMPORTANT
Para implantar a extensão de script personalizado em VMs clássicas, você pode usar o portal do Azure ou os
cmdlets clássicos do Azure PowerShell.
Portal do Azure
Navegue até o recurso de VM clássica. Em Configurações , selecione Extensões .
Clique em + Adicionar e, na lista de recursos, escolha Extensão de Script Personalizado .
Na página Instalar a extensão , selecione o arquivo local do PowerShell, preencha eventuais argumentos e
clique em Ok .
PowerShell
Use o cmdlet Set-AzureVMCustomScriptExtension para adicionar a extensão de script personalizado a uma
máquina virtual existente.
# define your file URI

$fileUri = 'https://xxxxxxx.blob.core.windows.net/scripts/Create-File.ps1'
# create vm object
$vm = Get-AzureVM -Name <vmName> -ServiceName <cloudServiceName>
# set extension
Set-AzureVMCustomScriptExtension -VM $vm -FileUri $fileUri -Run 'Create-File.ps1'
# update vm
$vm | Update-AzureVM

módulo do Azure PowerShell. Para ver o estado da implantação das extensões de uma determinada VM, execute
o comando a seguir:
Get-AzVMExtension -ResourceGroupName <resourceGroupName> -VMName <vmName> -Name myExtensionName
A saída da extensão é registrada nos arquivos localizados na pasta a seguir, na máquina virtual de destino.
C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension
Os arquivos especificados são baixados na pasta a seguir, na máquina virtual de destino.
C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.*\Downloads\<n>
em que <n> é um inteiro decimal que pode ser alterado entre as execuções da extensão. O valor 1.*
corresponde ao valor typeHandlerVersion atual e real da extensão. Por exemplo, o diretório real pode ser
C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloads\2 .
Ao executar o comando commandToExecute , a extensão definirá esse diretório (por exemplo, ...\Downloads\2 )
como o diretório de trabalho atual. Esse processo permite o uso de caminhos relativos para localizar os arquivos
baixados por meio da propriedade fileURIs . Veja a tabela abaixo para obter exemplos.
Como o caminho absoluto do download pode variar ao longo do tempo, é melhor optar por caminhos de
arquivo/script relativos na cadeia de caracteres commandToExecute , sempre que possível. Por exemplo:
"commandToExecute": "powershell.exe . . . -File \"./scripts/myscript.ps1\""
As informações de caminho após o primeiro segmento do URI são retidas para os arquivos baixados por meio
da lista de propriedades fileUris . Conforme mostrado na tabela a seguir, os arquivos baixados são mapeados
em subdiretórios de download para refletir a estrutura dos valores fileUris .
Exemplos de Arquivos Baixados
URI N O F IL EURIS LO C A L IZ A Ç Ã O B A IXA DA REL AT IVA LO C A L IZ A Ç Ã O B A IXA DA A B SO L UTA 1
https://someAcct.blob.core.windows.net/aContainer/scripts/myscript.ps1
./scripts/myscript.ps1 C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloads\2\scri
https://someAcct.blob.core.windows.net/aContainer/topLevel.ps1
./topLevel.ps1 C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloads\2\topL
1 Os caminhos de diretório absolutos são alterados durante o tempo de vida da VM, mas não em uma execução
da extensão CustomScript.
Suporte
fóruns do Azure e do Stack Overflow no MSDN. Você também pode registrar um incidente de Suporte do Azure.
Vá para o site de suporte do Azure e selecione Obter suporte. Para saber mais sobre como usar o suporte do
Azure, leia as Perguntas frequentes sobre o suporte do Microsoft Azure.
Extensão de Antimalware da Microsoft para
Windows
Visão geral
O panorama atual de ameaças a ambientes de nuvem é extremamente dinâmico, aumentando a pressão sobre
assinantes de nuvem de TI comercial para manter uma proteção eficaz e atender aos requisitos de
conformidade e segurança na nuvem. O Microsoft Antimalware para Azure é uma funcionalidade de proteção
em tempo real gratuita que ajuda a identificar e remover vírus, spyware e outros softwares mal-intencionados,
com alertas configuráveis quando softwares mal-intencionados ou indesejados conhecidos tentam se instalar
ou ser executados nos sistemas do Azure. A solução baseia-se na mesma plataforma de antimalware do MSE
(Microsoft Security Essentials), do Microsoft Forefront Endpoint Protection, do Microsoft System Center
Endpoint Protection, do Windows Intune e do Windows Defender para Windows 8.0 e posterior. O Antimalware
da Microsoft para Azure é uma solução de agente único para aplicativos e ambientes de locatário, projetado
para ser executado em segundo plano sem intervenção humana. Você pode implantar a proteção baseada nas
necessidades de suas cargas de trabalho do aplicativo, com configuração básica padronizada ou personalizada
avançada, incluindo monitoramento de antimalware.
Pré-requisitos
Sistema operacional
A solução Microsoft Antimalware para Azure inclui o Cliente e o Serviço Microsoft Antimalware, o modelo de
implantação clássico do Antimalware, cmdlets do PowerShell do Antimalware e a Extensão Diagnóstico do
Azure. A solução Microsoft Antimalware tem suporte no Windows Server 2008 R2, no Windows Server 2012 e
nas famílias de sistemas operacionais Windows Server 2012 R2. Não há suporte no sistema operacional
Windows Server 2008 e também não há suporte no Linux.
O Windows Defender é o Antimalware interno habilitado no Windows Server 2016. A Interface do Windows
Defender também é habilitada por padrão em alguns Windows Server 2016 SKU. A extensão de Antimalware de
VM do Azure ainda pode ser adicionada a uma VM do Azure do Windows Server 2016 com o Windows
Defender, mas nesse cenário, a extensão será aplicada a qualquer política de configuração a ser usada pelo
Windows Defender, a extensão não implantará qualquer serviço de antimalware adicional. Leia mais sobre essa
atualização aqui.
O Antimalware da Microsoft para o Windows exige que a máquina virtual de destino esteja conectada à internet
para receber o mecanismo e as atualizações regulares de assinatura.
ideais ao implantar uma ou mais máquinas virtuais que exigem configuração pós-implantação, tal como
integração ao Azure Antimalware.
A configuração do JSON para uma extensão da máquina virtual pode ser aninhado dentro do recurso de
máquina virtual ou localizado no nível de raiz ou superior de um modelo JSON do Resource Manager. O
posicionamento da configuração do JSON afeta o valor do tipo e nome do recurso. Para obter mais
informações, consulte Definir o nome e o tipo de recursos filho.
O exemplo a seguir pressupõe que a extensão de VM está aninhada dentro do recurso de máquina virtual. Ao
aninhar o recurso de extensão, o JSON é colocado no objeto "resources": [] da máquina virtual.
{
"name": "[concat(parameters('vmName'),'/', parameters('vmExtensionName'))]",
"apiVersion": "2019-07-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"
],
"properties": {
"type": "IaaSAntimalware",
"settings": {
"AntimalwareEnabled": "true",
"Exclusions": {
"Extensions": ".log;.ldf",
"Paths": "D:\\IISlogs;D:\\DatabaseLogs",
"Processes": "mssence.svc"
},
"RealtimeProtectionEnabled": "true",
"ScheduledScanSettings": {
"isEnabled": "true",
"scanType": "Quick",
"day": "7",
"time": "120"
}
},
"protectedSettings": null
}
}
Depende do tipo de implantação, use comandos correspondentes para implantar a extensão de máquina virtual
do Azure Antimalware para uma máquina virtual existente.
Máquina virtual baseada em Azure Resource Manager
Clusters de Service Fabric do Azure
Serviço de nuvem clássico

Logs de extensão do Microsoft Antimalware estão disponíveis em -
%Systemdrive%\WindowsAzure\Logs\Plugins\Microsoft.Azure.Security.IaaSAntimalware(Or
PaaSAntimalware)\1.5.5.x(version#)\CommandExecution.log
Códigos de erro e seus significados
C Ó DIGO DO ERRO SIGN IF IC A DO A Ç Ã O P O SSÍVEL
-2147156224 MSI está ocupado com uma instalação Tente executar a instalação do último
diferente
-2147156221 A instalação do MSE já está em Executar apenas uma instância de cada

execução vez
-2147156208 Pouco espaço em disco < 200 MB Excluir arquivos não utilizados e tentar
novamente a instalação
-2147156187 Última instalação, atualização, atualizar Reiniciar e tentar novamente a

ou desinstalar reinicialização solicitada instalação
-2147156121 A instalação tentou remover o produto Tente remover o produto concorrente

concorrente. Mas o produto manualmente, reinicialize e repita a
concorrente falhou na desinstalação instalação
-2147156116 Falha na validação do arquivo de Verifique se você passa um arquivo

Política XML de política válido para a
instalação
-2147156095 A instalação não pôde iniciar o serviço Verifique se todos os binários são
de Antimalware assinados corretamente e
licenciamento de arquivo correto estão
instalados
-2147023293 Um erro fatal ocorreu durante a Logs do MSI de EPP.msi são

instalação. Em muitos casos, ocorrerá. necessários aqui para investigação
EPP.msi, não é possível futura
register\start\stop AM serviço ou mini
driver de filtro
-2147023277 Não foi possível abrir o pacote de Verifique se o pacote existe, e é

instalação acessível, ou contate o fornecedor do
aplicativo para verificar se este é um
pacote válido do Windows Installer
-2147156109 Defender é necessário como um pré-

requisito
-2147205073 Não há suporte para o emissor websso
-2147024893 O sistema não pode localizar o

caminho especificado
-2146885619 Não criptografada ou a mensagem de

criptografia não está formatada
corretamente
-1073741819 A instrução em 0x%p memória

referenciada em 0x%p. A memória não
pôde ser %s
1 Função Incorreta
Suporte
do Azure. Vá para o site de suporte do Azuree selecione obter suporte. Para saber mais sobre como usar o
Extensão Linux de janelas de VM instantânea para
Azure Backup
O Backup do Azure oferece suporte para backup de cargas de trabalho do local para nuvem e fazendo backup
de recursos de nuvem para o cofre de Serviços de Recuperação. Azure Backup usa extensão de VM instantânea
para levar um backup consistente de aplicativo da máquina virtual do Azure sem a necessidade de desligar a
VM. Extensão Linux de VM instantânea é publicada e suportada pela Microsoft como parte do serviço de Azure
Backup. Azure Backup irá instalar a extensão como parte do primeiro backup agendado disparado após habilitar
o backup. Este documento detalha as plataformas com opções de plataformas, configurações e implantação
com suporte para a extensão de VM Instantânea.
A extensão VMSnapshot aparece na portal do Azure somente para VMs não gerenciadas.
Pré-requisitos
Sistema operacional
Para obter uma lista dos sistemas operacionais suportados, por favor consulte Sistemas Operacionais com
suporte pelo Azure Backup
O JSON a seguir mostra o esquema para a extensão de VM instantânea. A extensão requer o ID de tarefa - isso
identifica o trabalho de backup que disparou instantâneo na VM, uri de blob de status - em que o status da
operação de instantâneo é gravado, hora de início agendada do instantâneo, uri - onde logs correspondente a
tarefa de instantâneo de blob de logs são gravadas, representação objstr de discos de VM e os metadados. Como
estas configurações devem ser tratadas como um dado confidencial, ela é armazenada em uma configuração
protegida. Os dados de configuração protegidos pela extensão da VM do Azure são criptografados, sendo
descriptografados apenas na máquina virtual de destino. Por favor note que estas configurações são
recomendadas para serem passadas do serviço do Azure Backup apenas como parte de um trabalho de Backup.
{
"name": "VMSnapshot",
"properties": {
"publisher": "Microsoft.RecoveryServices",
"type": "VMSnapshot",
"settings": {
"taskId":"<taskId used by Azure Backup service to communicate with extension>",
"commandToExecute": "snapshot",
"commandStartTimeUTCTicks": "<scheduled start time of the snapshot task>",
"vmType": "microsoft.compute/virtualmachines"
},
"objectStr": "<blob SAS uri representation of VM sent by Azure Backup service to extension>",
}
}
}
taskId e07354cf-041e-4370-929f- string

25a319ce8933_1
commandStartTimeUTCTicks 6.36458E+17 string

objectStr Codificação de sas uri matriz- string

"blobSASUri":
["https://sopattna5365.blob.core.windo
ws.net/vhds/vmubuntu1404ltsc20165
2903941.vhd?sv=2014-02-
14&sr=b&sig=TywkROXL1zvhXcLujtC
ut8g3jTpgbE6JpSWRLZxAdtA%3D&st=
2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw",
"https://sopattna8461.blob.core.windo
ws.net/vhds/vmubuntu1404ltsc-
20160629-122418.vhd?sv=2014-02-
14&sr=b&sig=5S0A6YDWvVwqPAkz
WXVy%2BS%2FqMwzFMbamT5upwx0
5v8Q%3D&st=2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw",
ws.net/bootdiagnostics-vmubuntu1-
deb58392-ed5e-48be-9228-
ff681b0cd3ee/vmubuntu1404ltsc-
20160629-122541.vhd?sv=2014-02-
14&sr=b&sig=X0Me2djByksBBMVXM
GIUrcycvhQSfjYvqKLeRA7nBD4%3D&s
t=2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw",
20160701-163922.vhd?sv=2014-02-
14&sr=b&sig=oXvtK2IXCNqWv7fpjc7
TAzFDpc1GoXtT7r%2BC%2BNIAork%3
D&st=2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw",
20170705-124311.vhd?sv=2014-02-
14&sr=b&sig=ZUM9d28Mvvm%2Ffrh
J71TFZh0Ni90m38bBs3zMl%2FQ9rs0
%3D&st=2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw"]

d45d8a1c-281e-4bc8-9d30-
sv=2014-02-
%3D&st=2017-11-
09T14%3A33%3A29Z&se=2017-11-
09T17%3A38%3A29Z&sp=rw

d45d8a1c-281e-4bc8-9d30-
sv=2014-02-
3D&st=2017-11-
09T14%3A33%3A29Z&se=2017-11-
09T17%3A38%3A29Z&sp=rw
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. No entanto, a
maneira recomendada de adicionar uma extensão de VM instantânea a uma máquina virtual é habilitando o
backup na máquina virtual. Isso pode ser obtido por meio de um modelo do Gerenciador de Recursos. Um
modelo do Gerenciador de Recursos de exemplo que habilita backup em uma máquina virtual pode ser
encontrado na Galeria de Início Rápido do Azure.

A CLI do Azure pode ser usada para habilitar backup em uma máquina virtual. Depois de habilitar o backup,
primeiro trabalho de backup agendado instalará a extensão de VM instantânea na VM.
az backup protection enable-for-vm \

--vault-name myRecoveryServicesVault \
--vm myVM \
--policy-name DefaultPolicy

Dados sobre o estado das implantações de extensão podem ser recuperados do Portal do Azure usando a CLI
do Azure. Para ver o estado da implantação das extensões de uma determinada VM, execute o comando a seguir
usando a CLI do Azure.
az vm extension list --resource-group myResourceGroup --vm-name myVM -o table
A saída de execução da extensão é registrada no seguinte arquivo:

Informações para resolução de problemas podem ser encontradas no Guia de solução de problemas de backup
em VM do Azure.
Suporte
Extensão de janelas de VM instantânea para Azure
Backup
O Backup do Azure oferece suporte para backup de cargas de trabalho do local para nuvem e fazendo backup
de recursos de nuvem para o cofre de Serviços de Recuperação. Azure Backup usa extensão de VM instantânea
para levar um backup consistente de aplicativo da máquina virtual do Azure sem a necessidade de desligar a
VM. Extensão de VM instantânea é publicada e suportada pela Microsoft como parte do serviço de Azure
Backup. Azure Backup irá instalar a extensão como parte do primeiro backup agendado disparado após habilitar
o backup. Este documento detalha as plataformas com opções de plataformas, configurações e implantação
com suporte para a extensão de VM Instantânea.
A extensão VMSnapshot aparece na portal do Azure somente para VMs não gerenciadas.
Pré-requisitos
Sistema operacional
Para obter uma lista dos sistemas operacionais suportados, consulte Sistemas Operacionais com suporte pelo
Azure Backup
O JSON a seguir mostra o esquema para a extensão de VM instantânea. A extensão requer o ID de tarefa - isso
identifica o trabalho de backup que disparou instantâneo na VM, uri de blob de status - em que o status da
operação de instantâneo é gravado, hora de início agendada do instantâneo, uri - onde logs correspondente a
tarefa de instantâneo de blob de logs são gravadas, representação objstr de discos de VM e os metadados. Como
estas configurações devem ser tratadas como um dado confidencial, ela é armazenada em uma configuração
protegida. Os dados de configuração protegidos pela extensão da VM do Azure são criptografados, sendo
descriptografados apenas na máquina virtual de destino. Note que estas configurações são recomendadas para
serem passadas do serviço do Azure Backup apenas como parte de um trabalho de Backup.
{
"name": "VMSnapshot",
"properties": {
"publisher": "Microsoft.Azure.RecoveryServices",
"type": "VMSnapshot",
"settings": {
"taskId":"<taskId used by Azure Backup service to communicate with extension>",
"commandToExecute": "snapshot",
"commandStartTimeUTCTicks": "<scheduled start time of the snapshot task>",
"vmType": "microsoft.compute/virtualmachines"
},
"objectStr": "<blob SAS uri representation of VM sent by Azure Backup service to extension>",
}
}
}
taskId e07354cf-041e-4370-929f- string

25a319ce8933_1
commandStartTimeUTCTicks 6.36458E+17 string

objectStr Codificação de sas uri matriz- string

"blobSASUri":
["https://sopattna5365.blob.core.windo
ws.net/vhds/vmwin1404ltsc20165290
3941.vhd?sv=2014-02-
14&sr=b&sig=TywkROXL1zvhXcLujtC
ut8g3jTpgbE6JpSWRLZxAdtA%3D&st=
2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw",
ws.net/vhds/vmwin1404ltsc-
20160629-122418.vhd?sv=2014-02-
14&sr=b&sig=5S0A6YDWvVwqPAkz
WXVy%2BS%2FqMwzFMbamT5upwx0
5v8Q%3D&st=2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw",
ws.net/bootdiagnostics-vmwintu1-
deb58392-ed5e-48be-9228-
ff681b0cd3ee/vmubuntu1404ltsc-
20160629-122541.vhd?sv=2014-02-
14&sr=b&sig=X0Me2djByksBBMVXM
GIUrcycvhQSfjYvqKLeRA7nBD4%3D&s
t=2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw",
20160701-163922.vhd?sv=2014-02-
14&sr=b&sig=oXvtK2IXCNqWv7fpjc7
TAzFDpc1GoXtT7r%2BC%2BNIAork%3
D&st=2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw",
20170705-124311.vhd?sv=2014-02-
14&sr=b&sig=ZUM9d28Mvvm%2Ffrh
J71TFZh0Ni90m38bBs3zMl%2FQ9rs0
%3D&st=2017-11-
09T14%3A23%3A28Z&se=2017-11-
09T17%3A38%3A28Z&sp=rw"]

d45d8a1c-281e-4bc8-9d30-
sv=2014-02-
%3D&st=2017-11-
09T14%3A33%3A29Z&se=2017-11-
09T17%3A38%3A29Z&sp=rw

d45d8a1c-281e-4bc8-9d30-
sv=2014-02-
3D&st=2017-11-
09T14%3A33%3A29Z&se=2017-11-
09T17%3A38%3A29Z&sp=rw
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. No entanto, a
maneira recomendada de adicionar uma extensão de VM instantânea a uma máquina virtual é habilitando o
backup na máquina virtual. Isso pode ser obtido por meio de um modelo do Gerenciador de Recursos. Um
modelo do Gerenciador de Recursos de exemplo que habilita backup em uma máquina virtual pode ser
encontrado na Galeria de Início Rápido do Azure.

A CLI do Azure pode ser usada para habilitar backup em uma máquina virtual. Depois de habilitar o backup,
primeiro trabalho de backup agendado instalará a extensão de VM instantânea na VM.
az backup protection enable-for-vm \

--vault-name myRecoveryServicesVault \
--vm myVM \
--policy-name DefaultPolicy

C:\Packages\Plugins\Microsoft.Azure.RecoveryServices.VMSnapshot

Informações para resolução de problemas podem ser encontradas no Guia de solução de problemas de backup
em VM do Azure.
Suporte
Extensão da máquina virtual do Agente do
Observador de Rede do Azure para Linux
Visão geral
Observador de Rede do Azure é um serviço de monitoramento de desempenho, diagnóstico e análise de rede
que permite o monitoramento de redes do Azure. A extensão de máquina virtual (VM) do Agente do
Observador de Rede é um requisito para alguns dos recursos do Observador de Rede em VMs do Azure para
capturar o tráfego de rede sob demanda e outras funcionalidades avançadas.
Este artigo detalha as plataformas e as opções de implantação com suporte para a extensão da VM do Agente
do Observador de Rede para Linux. A instalação do agente não interrompe a VM ou exige uma reinicialização
dela. É possível implantar a extensão em máquinas virtuais que você implanta. Se a máquina virtual for
implantada por um serviço do Azure, verifique a documentação do serviço para determinar se ele permite ou
não a instalação de extensões na máquina virtual.
Pré-requisitos
Sistema operacional
A extensão do Agente do Observador de Rede pode ser configurada para as seguintes distribuições do Linux:
DIST RIB UIÇ Ã O VERSÃ O
Ubuntu 12+
Debian 7e8
Red Hat 6e7
Oracle Linux 6.8+ e 7
SUSE Linux Enterprise Server 11 e 12
OpenSUSE Leap 42.3+
CentOS 6.5+ e 7
CoreOS 899.17.0+

Algumas das funcionalidades do Agente do Observador de Rede exigem que a VM esteja conectada à Internet.
Sem a capacidade de estabelecer conexões de saída, alguns dos recursos do Agente do Observador de Rede
podem apresentar problemas ou se tornar indisponíveis. Para obter mais informações sobre a funcionalidade
do Observador de Rede que requer o agente, consulte a documentação do Observador de Rede.
O JSON a seguir mostra o esquema para a extensão do Agente do Observador de Rede. A extensão não exige
ou oferecem suporte a todas as configurações fornecidas pelo usuário. A extensão depende de sua configuração
padrão.
{
"name": "Microsoft.Azure.NetworkWatcher",
"apiVersion": "[variables('apiVersion')]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.NetworkWatcher",
"type": "NetworkWatcherAgentLinux",
"autoUpgradeMinorVersion": true
}
}
NOME VA LO R/ EXEM P LO
apiVersion 2015-06-15
editor Microsoft.Azure.NetworkWatcher
tipo NetworkWatcherAgentLinux
typeHandlerVersion 1.4
Você pode implantar extensões de VM do Azure com um modelo do Azure Resource Manager. Para implantar a
extensão do Agente do Observador de Rede, use o esquema json anterior em seu modelo.
Implantação da CLI clássica do Azure

IMPORTANT
O exemplo a seguir implanta a extensão de VM de Agente do Observador de Rede para uma VM existente
implantada por meio do modelo de implantação clássico:
azure config mode asm

azure vm extension set myVM1 NetworkWatcherAgentLinux Microsoft.Azure.NetworkWatcher 1.4

O exemplo a seguir implanta a extensão de VM de Agente do Observador de Rede para uma VM existente
implantada por meio do Gerenciador de Recursos:
az vm extension set --resource-group myResourceGroup1 --vm-name myVM1 --name NetworkWatcherAgentLinux --

publisher Microsoft.Azure.NetworkWatcher --version 1.4

Você pode recuperar dados sobre o estado das implantações de extensão usando o portal do Azure ou a CLI do
Azure.
O exemplo a seguir mostra o estado de implantação da extensão NetworkWatcherAgentLinux para uma VM
implantada por meio do Resource Manager, usando a CLI do Azure:
az vm extension show --name NetworkWatcherAgentLinux --resource-group myResourceGroup1 --vm-name myVM1
Suporte
Se precisar de mais ajuda a qualquer momento neste artigo, você poderá consultar a documentação do
observador de redeou entrar em contato com os especialistas do Azure nos fóruns do azure e do Stack
Overflow do MSDN. Como alternativa, você pode registrar um incidente de suporte do Azure. Vá para o site de
suporte do Azure e selecione Obter supor te . Para saber mais sobre como usar o Suporte do Azure, consulte as
Perguntas frequentes sobre o suporte do Microsoft Azure.
Extensão da máquina virtual do Agente do
Observador de Rede para Windows
Visão geral
O Observador de Rede do Azure é um serviço de monitoramento de desempenho, diagnóstico e análise de rede
que permite o monitoramento de redes do Azure. A extensão de máquina virtual do Agente do Observador de
Rede é um requisito para capturar o tráfego de rede sob demanda e outras funcionalidades avançadas em
máquinas virtuais do Azure.
Este documento detalha as opções com suporte de plataformas e implantação para a extensão da máquina
virtual do Agente do Observador de Rede para Windows. A instalação do agente não interrompe nem requer
um reinício da máquina virtual. É possível implantar a extensão em máquinas virtuais que você implanta. Se a
máquina virtual for implantada por um serviço do Azure, verifique a documentação do serviço para determinar
se ele permite ou não a instalação de extensões na máquina virtual.
Pré-requisitos
Sistema operacional
A extensão do agente do observador de rede para Windows pode ser executada em versões do Windows Server
2008 R2, 2012, 2012 R2, 2016 e 2019. O Servidor Nano não é suportado neste momento.
Algumas das funcionalidades do Agente do Observador de Rede exigem que a máquina virtual de destino esteja
conectada à Internet. Sem a capacidade de estabelecer conexões de saída, o Agente do Observador de Rede não
poderá carregar as capturas de pacote para sua conta de armazenamento. Para obter mais detalhes, confira a
documentação do Observador de Rede.
O JSON a seguir mostra o esquema para a extensão do Agente do Observador de Rede. A extensão não requer
e não é compatível com nenhuma configuração fornecida pelo usuário e é baseada em uma configuração
padrão.
{
"name": "Microsoft.Azure.NetworkWatcher",
"dependsOn": [
],
"properties": {
"publisher": "Microsoft.Azure.NetworkWatcher",
"type": "NetworkWatcherAgentWindows",
}
}
editor Microsoft.Azure.NetworkWatcher
tipo NetworkWatcherAgentWindows
Você pode implantar extensões de VM do Azure com os modelos do Azure Resource Manager. Você pode usar o
esquema JSON detalhado na seção anterior em um modelo do Azure Resource Manager para executar a
extensão do Agente do Observador de Rede durante uma implantação de modelo do Azure Resource Manager.
Use o comando Set-AzVMExtension para implantar a extensão de máquina virtual do Agente do Observador de
Rede em uma máquina virtual existente:
Set-AzVMExtension `
-ResourceGroupName "myResourceGroup1" `
-Location "WestUS" `
-VMName "myVM1" `
-Name "networkWatcherAgent" `
-Publisher "Microsoft.Azure.NetworkWatcher" `
-Type "NetworkWatcherAgentWindows" `
-TypeHandlerVersion "1.4"

Você pode recuperar dados sobre o estado das implantações de extensão por meio do portal do Azure e do
PowerShell. Para ver o estado da implantação das extensões de uma determinada VM, execute o comando a
seguir usando o módulo do Azure PowerShell:
Get-AzVMExtension -ResourceGroupName myResourceGroup1 -VMName myVM1 -Name networkWatcherAgent
A saída de execução da extensão é registrada nos arquivos localizados no seguinte diretório:
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.NetworkWatcher.NetworkWatcherAgentWindows\
Suporte
Caso precise de mais ajuda em qualquer ponto deste artigo, veja a documentação Guia de Usuário do
Observador de Rede ou contate os especialistas do Azure nos fóruns do Azure e do Stack Overflow no MSDN.
Como alternativa, você pode registrar um incidente de suporte do Azure. Vá para o site de suporte do Azure e
selecione Obter suporte. Para saber mais sobre como usar o suporte do Azure, leia as Perguntas frequentes
sobre o suporte do Microsoft Azure.
Atualizar a extensão do observador de rede para a
versão mais recente
Visão geral
O observador de rede do Azure é um serviço de monitoramento, diagnóstico e análise de desempenho de rede
que monitora as redes do Azure. A extensão da máquina virtual (VM) do agente do observador de rede é um
requisito para capturar o tráfego de rede sob demanda e usar outras funcionalidades avançadas em VMs do
Azure. A extensão do observador de rede é usada por recursos como o monitor de conexão, o monitor de
conexão (versão prévia), a solução de problemas de conexão e a captura de pacotes.
Pré-requisitos
Este artigo pressupõe que você tenha a extensão do observador de rede instalada em sua VM.
Última versão
A versão mais recente da extensão do observador de rede é atualmente 1.4.1693.1 .
Atualizar sua extensão usando um script do PowerShell

Clientes com grandes implantações que precisam atualizar várias VMs de uma só vez. Para atualizar as VMs
selecionadas manualmente, consulte a próxima seção
<#
.SYNOPSIS
This script will scan all VMs in the provided subscription and upgrade any out of date
AzureNetworkWatcherExtensions
.DESCRIPTION
This script should be no-op if AzureNetworkWatcherExtensions are up to date
Requires Azure PowerShell 4.2 or higher to be installed (e.g. Install-Module AzureRM).
.EXAMPLE
.\UpdateVMAgentsInSub.ps1 -SubID F4BC4873-5DAB-491E-B713-1358EF4992F2 -NoUpdate
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true)]
[string] $SubID,
[Parameter(Mandatory=$false)]
[Switch] $NoUpdate = $false,
[Parameter(Mandatory=$false)]
[string] $MinVersion = "1.4.1654.1"
)
function NeedsUpdate($version)
{
if ($version -eq $MinVersion)
{
return $false
}
$lessThan = $true;
$versionParts = $version -split '\.';
$minVersionParts = $MinVersion -split '\.';
for ($i = 0; $i -lt $versionParts.Length; $i++)
{
if ([int]$versionParts[$i] -gt [int]$minVersionParts[$i])
{
$lessThan = $false;
break;
}
}
return $lessThan
}
Write-Host "Scanning all VMs in the subscription: $($SubID)"

Select-AzSubscription -SubscriptionId $SubID;
$vms = Get-AzVM;
$foundVMs = $false;
Write-Host "Starting VM search, this may take a while"
foreach ($vmName in $vms)

{
# Get Detailed VM info
$vm = Get-AzVM -ResourceGroupName $vmName.ResourceGroupName -Name $vmName.name -Status;
$isWindows = $vm.OsVersion -match "Windows";
foreach ($extension in $vm.Extensions)
{
if ($extension.Name -eq "AzureNetworkWatcherExtension")
{
if (NeedsUpdate($extension.TypeHandlerVersion))
{
$foundVMs = $true;
if (-not ($NoUpdate))
{
Write-Host "Found VM that needs to be updated:
subscriptions/$($SubID)/resourceGroups/$($vm.ResourceGroupName)/providers/Microsoft.Compute/virtualMachines/
$($vm.Name) -> Updating " -NoNewline
Remove-AzVMExtension -ResourceGroupName $vm.ResourceGroupName -VMName $vm.Name -Name
"AzureNetworkWatcherExtension" -Force
Write-Host "... " -NoNewline
$type = if ($isWindows) { "NetworkWatcherAgentWindows" } else {
"NetworkWatcherAgentLinux" };
Set-AzVMExtension -ResourceGroupName $vm.ResourceGroupName -Location $vmName.Location -
VMName $vm.Name -Name "AzureNetworkWatcherExtension" -Publisher "Microsoft.Azure.NetworkWatcher" -Type $type
-typeHandlerVersion "1.4"
Write-Host "Done"
}
else
{
Write-Host "Found $(if ($isWindows) {"Windows"} else {"Linux"}) VM that needs to be
updated:
subscriptions/$($SubID)/resourceGroups/$($vm.ResourceGroupName)/providers/Microsoft.Compute/virtualMachines/
$($vm.Name)"
}
}
}
}
}
if ($foundVMs)
{
Write-Host "Finished $(if ($NoUpdate) {"searching"} else {"updating"}) out of date
AzureNetworkWatcherExtension on VMs"
}
else
{
Write-Host "All AzureNetworkWatcherExtensions up to date"
}
}
Atualizar sua extensão manualmente

Para atualizar sua extensão, você precisa saber a versão da extensão.
Verifique sua versão de extensão
Você pode verificar a versão da extensão usando o portal do Azure, o CLI do Azure ou o PowerShell.
Usar o portal do Azure
1. Vá para o painel extensões de sua VM no portal do Azure.
2. Selecione a extensão AzureNetworkWatcher para ver o painel de detalhes.
3. Localize o número de versão no campo versão .
Usar a CLI do Azure
Execute o seguinte comando em um prompt de CLI do Azure:
az vm get-instance-view --resource-group "SampleRG" --name "Sample-VM"
Localize "AzureNetworkWatcherExtension" na saída e identifique o número de versão do campo

"TypeHandlerVersion" na saída. Observação: as informações sobre a extensão aparecem várias vezes na saída
JSON. Examine o bloco "extensões" e você verá o número de versão completo da extensão.
Você verá algo semelhante ao seguinte:
Usar o PowerShell
Execute os seguintes comandos em um prompt do PowerShell:
Get-AzVM -ResourceGroupName "SampleRG" -Name "Sample-VM" -Status
Localize a extensão do observador de rede do Azure na saída e identifique o número de versão do campo
"TypeHandlerVersion" na saída.
Você verá algo parecido com o seguinte:
Atualizar sua extensão

Se sua versão estiver abaixo da versão mais recente mencionada acima, atualize sua extensão usando qualquer
uma das opções a seguir.
Opção 1: usar o PowerShell
Execute os seguintes comandos:
#Linux command
Set-AzVMExtension -ResourceGroupName "myResourceGroup1" -Location "WestUS" -VMName "myVM1" -Name
"AzureNetworkWatcherExtension" -Publisher "Microsoft.Azure.NetworkWatcher" -Type "NetworkWatcherAgentLinux"
#Windows command
Set-AzVMExtension -ResourceGroupName "myResourceGroup1" -Location "WestUS" -VMName "myVM1" -Name
"NetworkWatcherAgentWindows" -Publisher "Microsoft.Azure.NetworkWatcher" -Type "NetworkWatcherAgentWindows"
-ForceRerun "True"
Se isso não funcionar. Remova e instale a extensão novamente, usando as etapas abaixo. Isso adicionará
automaticamente a versão mais recente.
Removendo a extensão
#Same command for Linux and Windows

Remove-AzVMExtension -ResourceGroupName "SampleRG" -VMName "Sample-VM" -Name "AzureNetworkWatcherExtension"
Instalando a extensão novamente
#Linux command
Set-AzVMExtension -ResourceGroupName "SampleRG" -Location "centralus" -VMName "Sample-VM" -Name
"AzureNetworkWatcherExtension" -Publisher "Microsoft.Azure.NetworkWatcher" -Type "NetworkWatcherAgentLinux"
-typeHandlerVersion "1.4"
#Windows command
Set-AzVMExtension -ResourceGroupName "SampleRG" -Location "centralus" -VMName "Sample-VM" -Name
"AzureNetworkWatcherExtension" -Publisher "Microsoft.Azure.NetworkWatcher" -Type
"NetworkWatcherAgentWindows" -typeHandlerVersion "1.4"
Opção 2: usar o CLI do Azure

Forçar uma atualização.
#Linux command
az vm extension set --resource-group "myResourceGroup1" --vm-name "myVM1" --name "NetworkWatcherAgentLinux"
--publisher "Microsoft.Azure.NetworkWatcher" --force-update
#Windows command
az vm extension set --resource-group "myResourceGroup1" --vm-name "myVM1" --name
"NetworkWatcherAgentWindows" --publisher "Microsoft.Azure.NetworkWatcher" --force-update
Se isso não funcionar, remova e instale a extensão novamente e siga estas etapas para adicionar
automaticamente a versão mais recente.
Remova a extensão.
#Same for Linux and Windows

az vm extension delete --resource-group "myResourceGroup1" --vm-name "myVM1" -n
"AzureNetworkWatcherExtension"
Instale a extensão novamente.

#Linux command
az vm extension set --resource-group "DALANDEMO" --vm-name "Linux-01" --name "NetworkWatcherAgentLinux" --
publisher "Microsoft.Azure.NetworkWatcher"
#Windows command
az vm extension set --resource-group "DALANDEMO" --vm-name "Linux-01" --name "NetworkWatcherAgentWindows" --
publisher "Microsoft.Azure.NetworkWatcher"
Opção 3: reinicialize suas VMs

Se você tiver a atualização automática definida como true para a extensão do observador de rede, reinicialize a
instalação da VM para a extensão mais recente.
Suporte
Se precisar de mais ajuda a qualquer momento neste artigo, consulte a documentação de extensão do
observador de rede para Linux ou Windows. Você também pode contatar os especialistas do Azure nos fóruns
do Azure e do Stack Overflow do MSDN. Como alternativa, arquivo de um incidente de suporte do Azure. Vá
para o site de suporte do Azuree selecione obter supor te . Para saber mais sobre como usar o suporte do
Extensão de driver InfiniBand para Linux
Essa extensão instala os drivers InfiniBand OFED nas VMs InfiniBand e SR-IOV (' r ' tamanhos) das séries H e N-
Series que executam o Linux. Dependendo da família de VMs, a extensão instala os drivers apropriados para a
NIC Connect-X.
As instruções sobre a instalação manual dos drivers do OFED estão disponíveis aqui.
Uma extensão também está disponível para instalar os drivers InfiniBand para VMs do Windows.
Pré-requisitos
Sistema operacional
Esta extensão é compartível com as seguintes distribuições do sistema operacional, dependendo do suporte do
driver para uma versão específica do sistema operacional.
Linux: Ubuntu 16, 4 LTS, 18, 4 LTS, 20, 4 LTS
Linux: CentOS 7,4, 7,5, 7,6, 7,7, 8,1, 8, 2
Linux: Red Hat Enterprise Linux 7,4, 7,5, 7,6, 7,7, 8,1, 8, 2

A extensão de Microsoft Azure para drivers InfiniBand requer que a VM de destino esteja conectada ao e tenha
acesso à Internet.
O JSON a seguir mostra o esquema para a extensão.
{
"name": "<myExtensionName>",
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <myVM>)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "InfiniBandDriverLinux",
"settings": {
}
}
}
Propriedades
publicador Microsoft.HpcCompute string
type InfiniBandDriverLinux string
Implantação
ideais ao implantar uma ou mais máquinas virtuais que exigem configuração pós-implantação.
O exemplo a seguir pressupõe que a extensão está aninhada dentro do recurso de máquina virtual. Ao aninhar
o recurso de extensão, o JSON é colocado no objeto "resources": [] da máquina virtual.
{
"name": "myExtensionName",
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', myVM)]"
],
"properties": {
"type": "InfiniBandDriverLinux",
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-VMName "myVM" `
-Location "southcentralus" `
-Publisher "Microsoft.HpcCompute" `
-ExtensionName "InfiniBandDriverLinux" `
-ExtensionType "InfiniBandDriverLinux" `
-SettingString '{ `
}'
CLI do Azure
--vm-name myVM \
--name InfiniBandDriverLinux \
--publisher Microsoft.HpcCompute \
--version 1.1
Adicionar extensão a um conjunto de dimensionamento de máquinas virtuais

O exemplo a seguir instala a extensão mais recente da versão 1,1 do InfiniBandDriverLinux em todas as VMs
compatíveis com RDMA em um conjunto de dimensionamento de máquinas virtuais existente chamado
myVMSS implantado no grupo de recursos chamado MyResource Group:
$VMSS = Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myVMSS"

Add-AzVmssExtension -VirtualMachineScaleSet $VMSS -Name "InfiniBandDriverLinux" -Publisher
"Microsoft.HpcCompute" -Type "InfiniBandDriverLinux" -TypeHandlerVersion "1.1"
Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "MyVMSS" -VirtualMachineScaleSet $VMSS
Update-AzVmssInstance -ResourceGroupName "myResourceGroup" -VMScaleSetName "myVMSS" -InstanceId "*"

Azure PowerShell e a CLI do Azure. Para ver o estado da implantação das extensões de uma determinada VM,
execute o comando a seguir.
Get-AzVMExtension -ResourceGroupName myResourceGroup -VMName myVM -Name myExtensionName
A saída de execução de extensão é registrada no arquivo a seguir. Consulte esse arquivo para acompanhar o
status da instalação, bem como para solucionar quaisquer falhas.
/var/log/azure/ib-vmext-status
Códigos de saída
A tabela a seguir descreve o significado e a ação recomendada com base nos códigos de saída do processo de
instalação da extensão.
C Ó DIGO DE SA ÍDA SIGN IF IC A DO A Ç Ã O P O SSÍVEL
0 Operação concluída com êxito
1 Uso incorreto de extensão Verifique o log de saída de execução
10 Serviços de integração do Linux para Verificação de saída de Ispci

Hyper-V e o Azure não disponível ou
instalado
11 O InfiniBand de Mellanox não foi Use um tamanho da VM e sistema

encontrado neste tamanho de VM operacional com suporte
12 Oferta de imagem não suportada
13 Tamanho de VM não suportado Usar uma VM da série n e série

n-Series habilitadas para InfiniBand (' r
') para implantar
14 Operação falhou Verifique o log de saída de execução
Suporte
fóruns do Azure e do Stack Overflow no MSDN. Como alternativa, você pode arquivar um incidente de suporte
por meio do site de suporte do Azure. Para saber mais sobre como usar o suporte do Azure, leia as Perguntas
frequentes sobre o suporte do Microsoft Azure.
Próximas etapas
Para obter mais informações sobre os tamanhos habilitados para InfiniBand (' r '), consulte VMs da série H e
série N .
Saiba mais sobre os recursos e extensões de VMs do Linux
Extensão de driver InfiniBand para Windows
Essa extensão instala os drivers InfiniBand ND (para os drivers não habilitados para SR-IOV) e OFED (para SR-
IOV-habilitado) (' r ' tamanhos) das VMs série H e série N que executam o Windows. Dependendo da família de
VMs, a extensão instala os drivers apropriados para a NIC Connect-X.
Uma extensão também está disponível para instalar os drivers InfiniBand para VMs do Linux.
Pré-requisitos
Sistema operacional
driver para uma versão específica do sistema operacional. Observe a NIC InfiniBand apropriada para os
tamanhos de VM da série H e N de interesse.
DIST RIB UIÇ Ã O DRIVERS DE N IC IN F IN IB A N D
Windows 10 CX5, CX6
Windows Server 2019 CX5, CX6
Windows Server 2016 CX3-pro, CX5, CX6
Windows Server 2012 R2 CX3-pro, CX5, CX6
Windows Server 2012 CX3-pro, CX5, CX6

A extensão de Microsoft Azure para drivers InfiniBand requer que a VM de destino esteja conectada ao e tenha
acesso à Internet.
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "InfiniBandDriverWindows",
"settings": {
}
}
}
Propriedades
type InfiniBandDriverWindows string
Implantação
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "InfiniBandDriverWindows",
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-VMName "myVM" `
-ExtensionName "InfiniBandDriverWindows" `
-ExtensionType "InfiniBandDriverWindows" `
-SettingString '{ `
}'
CLI do Azure
--vm-name myVM \
--name InfiniBandDriverWindows \
--version 1.2
Adicionar extensão a um conjunto de dimensionamento de máquinas virtuais

O exemplo a seguir instala a extensão mais recente da versão 1,2 do InfiniBandDriverWindows em todas as VMs
compatíveis com RDMA em um conjunto de dimensionamento de máquinas virtuais existente chamado
myVMSS implantado no grupo de recursos chamado MyResource Group:
$VMSS = Get-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "myVMSS"

Add-AzVmssExtension -VirtualMachineScaleSet $VMSS -Name "InfiniBandDriverWindows" -Publisher
"Microsoft.HpcCompute" -Type "InfiniBandDriverWindows" -TypeHandlerVersion "1.2"
Update-AzVmss -ResourceGroupName "myResourceGroup" -VMScaleSetName "MyVMSS" -VirtualMachineScaleSet $VMSS
Update-AzVmssInstance -ResourceGroupName "myResourceGroup" -VMScaleSetName "myVMSS" -InstanceId "*"

status da instalação, bem como para solucionar quaisquer falhas.
C:\WindowsAzure\Logs\Plugins\Microsoft.HpcCompute.InfiniBandDriverWindows\
Códigos de saída
A tabela a seguir descreve o significado e a ação recomendada com base nos códigos de saída do processo de
instalação da extensão.
3010 Operação concluída com êxito. É

necessário reiniciar.
100 Operação sem suporte ou não pôde Possíveis causas: versão do PowerShell
ser concluída. sem suporte, o tamanho da VM não é
uma VM habilitada para InfiniBand,
falha ao baixar dados. Verifique os
arquivos de log para determinar a
causa do erro.
240, 840 Tempo limite da operação. Operação de teste.
-1 Exceção ocorreu. Verifique os arquivos de log para

determinar a causa da exceção.
Suporte
fóruns do Azure e do Stack Overflow no MSDN. Como alternativa, você pode arquivar um incidente de suporte
por meio do site de suporte do Azure. Para saber mais sobre como usar o suporte do Azure, leia as Perguntas
frequentes sobre o suporte do Microsoft Azure.
Próximas etapas
Para obter mais informações sobre os tamanhos habilitados para InfiniBand (' r '), consulte VMs da série H e
série N .
Saiba mais sobre os recursos e extensões de VMs do Linux
Extensão de Driver NVIDIA GPU para Linux
Visão geral
Essa extensão instala drivers de GPU NVIDIA em VMs série N do Linux. Dependendo da família VM, a extensão
instala drivers CUDA ou grade. Quando você instalar drivers NVIDIA usando esta extensão, estará aceitando e
concordando com os termos do Contrato de Licença de Usuário Final da NVIDIA. Durante o processo de
instalação, a VM pode ser reinicializada para concluir a configuração do driver.
Instruções sobre a instalação manual dos drivers e as versões atuais com suporte estão disponíveis aqui. Uma
extensão também está disponível para instalar drivers NVIDIA GPU em VMs da série N do Windows.
Pré-requisitos
Sistema operacional
driver para uma versão específica do sistema operacional.
Linux: Ubuntu 16.04 LTS, 18.04 LTS
Linux: Red Hat Enterprise Linux 7,3, 7,4, 7,5, 7,6, 7,7, 7,8
Linux: CentOS 7,3, 7,4, 7,5, 7,6, 7,7, 7,8

A extensão do Microsoft Azure para drivers de GPU NVIDIA requer que a VM de destino esteja conectada à
Internet e tenha acesso.
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "NvidiaGpuDriverLinux",
"settings": {
}
}
}
Propriedades
type NvidiaGpuDriverLinux string
Configurações
Todas as configurações são opcionais. O comportamento padrão é não atualizar o kernel se não for necessário
para a instalação do driver, instale o driver mais recente com suporte e o CUDA toolkit (conforme aplicável).
NOME DESC RIÇ Ã O VA LO R PA DRÃ O VA LO RES VÁ L IDO S T IP O DE DA DO S
updateOS Atualize o kernel, false verdadeiro, falso booleano

mesmo que não seja
necessário para
instalação do driver
driverVersion NV: versão do driver mais recente Lista de versões de string

GRID driver com suporte
NC/ND: versão do Kit
de ferramentas
CUDA. Os drivers
mais recentes para o
CUDA escolhido são
instalados
automaticamente.
installCUDA Instale o kit de true verdadeiro, falso booleano

ferramentas CUDA.
Só é relevante para
as VMs da série
NC/ND.
Implantação
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "NvidiaGpuDriverLinux",
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-VMName "myVM" `
-ExtensionName "NvidiaGpuDriverLinux" `
-ExtensionType "NvidiaGpuDriverLinux" `
-SettingString '{ `
}'
CLI do Azure
O exemplo a seguir espelha os exemplos de Azure Resource Manager e PowerShell acima.
--vm-name myVM \
--name NvidiaGpuDriverLinux \
--version 1.3
O exemplo a seguir também adiciona duas configurações personalizadas opcionais como um exemplo para
instalação de driver não padrão. Especificamente, ele atualiza o kernel do sistema operacional para o mais
recente e instala um driver de versão do CUDA Toolkit específico. Novamente, observe que '--Settings ' são
opcionais e default. Observe que a atualização do kernel pode aumentar os tempos de instalação da extensão.
Além disso, escolher uma versão específica (mais antiga) do CUDA tolkit pode nem sempre ser compatível com
os kernels mais recentes.
--vm-name myVM \
--name NvidiaGpuDriverLinux \
--version 1.3 \
--settings '{ \
"updateOS": true, \
"driverVersion": "10.0.130" \
}'
status de instalação de (qualquer execução longa), bem como para solucionar quaisquer falhas.
/var/log/azure/nvidia-vmext-status
Códigos de saída
1 Uso incorreto de extensão Verifique o log de saída de execução
10 Serviços de integração do Linux para Verificação de saída de Ispci

Hyper-V e o Azure não disponível ou
instalado
11 GPU NVIDIA não encontrado nesse Use um tamanho da VM e sistema

tamanho de VM operacional com suporte
12 Oferta de imagem não suportada
13 Tamanho de VM não suportado Usar uma VM da série N para

implantar
14 Operação falhou Verifique o log de saída de execução
Suporte
Próximas etapas
Para obter mais informações sobre extensões, consulte Recursos e extensões da máquina virtual para Linux.
Para obter mais informações sobre VMs série N, consulte tamanhos de máquinas virtuais otimizados para GPU.
Extensão de Driver NVIDIA GPU para Windows
Visão geral
Essa extensão instala drivers de GPU NVIDIA em VMs série N do Windows. Dependendo da família VM, a
extensão instala drivers CUDA ou grade. Quando você instalar drivers NVIDIA usando esta extensão, estará
aceitando e concordando com os termos do Contrato de Licença de Usuário Final da NVIDIA. Durante o
processo de instalação, a VM pode ser reinicializada para concluir a configuração do driver.
Instruções sobre a instalação manual dos drivers e as versões atuais com suporte estão disponíveis aqui. Uma
extensão também está disponível para instalar drivers NVIDIA GPU em VMs da série N do Linux.
Pré-requisitos
Sistema operacional
A Extensão suporta os seguintes OS:
Windows 10 Núcleo
Windows Server 2016 Núcleo
Windows Server 2012 R2 Núcleo

A extensão do Microsoft Azure para drivers de GPU NVIDIA requer que a VM de destino esteja conectada à
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "NvidiaGpuDriverWindows",
"settings": {
}
}
}
Propriedades
type NvidiaGpuDriverWindows string
Implantação
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "NvidiaGpuDriverWindows",
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-VMName "myVM" `
-ExtensionName "NvidiaGpuDriverWindows" `
-ExtensionType "NvidiaGpuDriverWindows" `
-SettingString '{ `
}'
CLI do Azure
--vm-name myVM \
--name NvidiaGpuDriverWindows \
--version 1.3 \
--settings '{ \
}'

A saída de execução da extensão é registrada no seguinte local:
C:\WindowsAzure\Logs\Plugins\Microsoft.HpcCompute.NvidiaGpuDriverWindows\
Códigos do Erro

100 Operação sem suporte ou não pôde Possíveis causas: não há suporte para
ser concluída. a versão do PowerShell, o tamanho da
VM não é uma VM da série N, Falha ao
fazer download de dados. Verifique os
causa do erro.

-5x Operação foi interrompida devido a Reinicializar VM. Instalação continuará

reinicialização pendente. após a reinicialização. Desinstalação
deve ser invocada manualmente.
Suporte
Próximas etapas
Para obter mais informações sobre extensões, consulte Recursos e extensões da máquina virtual para Windows.
Extensão de driver de GPU AMD para Windows
Este artigo fornece uma visão geral da extensão de VM para implantar drivers de GPU AMD em VMs da série
NVv4 do Windows. Ao instalar os drivers AMD usando essa extensão, você estará aceitando e concordando com
os termos do contrato de licença do amd End-User. Durante o processo de instalação, a VM pode ser
reinicializada para concluir a configuração do driver.
Instruções sobre a instalação manual dos drivers e as versões atuais com suporte estão disponíveis aqui.
Pré-requisitos
Sistema operacional
A Extensão suporta os seguintes OS:
EMS do Windows 10 Build 1903
Windows 10 Build 1809

A extensão de Microsoft Azure para drivers de GPU AMD requer que a VM de destino esteja conectada à
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "AmdGpuDriverWindows",
"settings": {
}
}
}
Propriedades
type AmdGpuDriverWindows string
Implantação
{
"apiVersion": "2015-06-15",
"dependsOn": [
],
"properties": {
"type": "AmdGpuDriverWindows",
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-VMName "myVM" `
-ExtensionName "AmdGpuDriverWindows" `
-ExtensionType "AmdGpuDriverWindows" `
-SettingString '{ `
}'
CLI do Azure
az vm extension set `
--resource-group myResourceGroup `
--vm-name myVM `
--name AmdGpuDriverWindows `
--publisher Microsoft.HpcCompute `
--version 1.0 `
--settings '{ `
}'

A saída de execução da extensão é registrada no seguinte local:
C:\WindowsAzure\Logs\Plugins\Microsoft.HpcCompute.AmdGpuDriverMicrosoft\
Códigos do Erro

100 Operação sem suporte ou não pôde Possíveis causas: não há suporte para
ser concluída. a versão do PowerShell, o tamanho da
VM não é uma VM da série N, Falha ao
fazer download de dados. Verifique os
causa do erro.

-5x Operação foi interrompida devido a Reinicializar VM. Instalação continuará

reinicialização pendente. após a reinicialização. Desinstalação
deve ser invocada manualmente.
Suporte
Próximas etapas
Para obter mais informações sobre extensões, consulte Recursos e extensões da máquina virtual para Windows.
Instalar o agente de Azure Monitor (versão prévia)
Este artigo fornece as diferentes opções disponíveis no momento para instalar o agente de Azure monitor em
máquinas virtuais do Azure e em servidores habilitados para Arc do Azure e também as opções para criar
associações com regras de coleta de dados que definem quais dados o agente deve coletar.
Pré-requisitos
Os pré-requisitos a seguir são necessários antes de instalar o agente de Azure Monitor.
A identidade do sistema gerenciado deve ser habilitada em máquinas virtuais do Azure. Isso não é
necessário para os servidores habilitados para Arc do Azure. A identidade do sistema será habilitada
automaticamente se o agente for instalado como parte do processo de criação e atribuição de uma regra de
coleta de dados usando o portal do Azure.
A marca de serviço AzureResourceManager deve ser habilitada na rede virtual para a máquina virtual.
Detalhes da extensão da máquina virtual

O agente de Azure Monitor é implementado como uma extensão de VM do Azure com os detalhes na tabela a
seguir. Ele pode ser instalado usando qualquer um dos métodos para instalar extensões de máquina virtual,
incluindo as descritas neste artigo.
P RO P RIEDA DE W IN DO W S L IN UX
Publisher Microsoft. Azure. monitor Microsoft. Azure. monitor
Tipo AzureMonitorWindowsAgent AzureMonitorLinuxAgent
TypeHandlerVersion 1.0 1.5
Instalação com o portal do Azure

Para instalar o agente de Azure Monitor usando o portal do Azure, siga o processo para criar uma regra de
coleta de dados no portal do Azure. Isso permite que você associe a regra de coleta de dados a uma ou mais
máquinas virtuais do Azure ou a servidores habilitados para Arc do Azure. O agente será instalado em qualquer
uma dessas máquinas virtuais que ainda não o possuem.
Instalar com o modelo do Resource Manager

Você pode usar modelos do Resource Manager para instalar o agente de Azure Monitor em máquinas virtuais
do Azure e em servidores habilitados para Arc do Azure e para criar uma associação com regras de coleta de
dados. Você deve criar qualquer regra de coleta de dados antes de criar a associação.
Obtenha modelos de exemplo para instalar o agente e criar a associação a partir do seguinte:
Modelo para instalar o agente de Azure Monitor (Azure e Azure ARC)
Modelo para criar associação com a regra de coleta de dados
Instale os modelos usando qualquer método de implantação para modelos do Resource Manager , como os
comandos a seguir.
PowerShell
CLI
New-AzResourceGroupDeployment -ResourceGroupName "<resource-group-name>" -TemplateFile "<template-

filename.json>" -TemplateParameterFile "<parameter-filename.json>"
Instalar com o PowerShell

Você pode instalar o agente de Azure Monitor em máquinas virtuais do Azure e em servidores habilitados para
Arc do Azure usando o comando do PowerShell para adicionar uma extensão de máquina virtual.
Máquinas virtuais do Azure
Use os comandos do PowerShell a seguir para instalar o agente de Azure Monitor em máquinas virtuais do
Azure.
Windows
Linux
Set-AzVMExtension -Name AMAWindows -ExtensionType AzureMonitorWindowsAgent -Publisher

Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name> -VMName <virtual-machine-name> -Location
<location>
Servidores habilitados para Azure Arc

Use os comandos do PowerShell a seguir para instalar os servidores habilitados para Arc do Azure Monitor
Agent.
Windows
Linux
New-AzConnectedMachineExtension -Name AMAWindows -ExtensionType AzureMonitorWindowsAgent -Publisher

Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name> -MachineName <virtual-machine-name> -
Location <location>
CLI do Azure
Você pode instalar o agente de Azure Monitor em máquinas virtuais do Azure e em servidores habilitados para
Arc do Azure usando o comando CLI do Azure para adicionar uma extensão de máquina virtual.
Máquinas virtuais do Azure
Use os comandos da CLI a seguir para instalar o agente de Azure Monitor em máquinas virtuais do Azure.
Windows
Linux
az vm extension set --name AzureMonitorWindowsAgent --publisher Microsoft.Azure.Monitor --ids <vm-resource-

id>
Servidores habilitados para Azure Arc

Use os comandos da CLI a seguir para instalar os servidores habilitados para Arc do Azure Monitor Agent.
Windows
Linux
az connectedmachine machine-extension create --name AzureMonitorWindowsAgent --publisher

Microsoft.Azure.Monitor --ids <vm-resource-id>
Próximas etapas
Crie uma regra de coleta de dados para coletar dados do agente e enviá-los para Azure monitor.
Extensão da máquina virtual do Log Analytics para
Linux
Visão geral
Os Logs do Azure Monitor fornecem recursos de monitoramento, alertas e correção de alertas em ativos locais
e de nuvem. A Microsoft publica e oferece suporte à extensão da máquina virtual do Log Analytics para Linux. A
extensão instala o agente do Log Analytics em máquinas virtuais do Azure e registra máquinas virtuais em um
espaço de trabalho do Log Analytics existente. Este documento detalha as plataformas com opções de
plataformas, configurações e implantação com suporte para a extensão da máquina virtual do Log Analytics
para Linux.
NOTE
Como parte da transição contínua do Microsoft OMS (Operations Management Suite) para o Azure Monitor, o Agente do
OMS para Windows ou Linux será chamado de agente do Log Analytics para Windows e agente do Log Analytics para
Linux.
NOTE
Este artigo foi atualizado recentemente para usar o termo logs do Azure Monitor em vez de Log Analytics. Os dados de
log ainda são armazenados em um espaço de trabalho do Log Analytics e ainda são coletados e analisados pelo mesmo
serviço do Log Analytics. Estamos atualizando a terminologia para refletir melhor a função dos logs no Azure Monitor.
Confira as alterações de terminologia do Azure Monitor para obter detalhes.
Pré-requisitos
Sistema operacional
Para obter detalhes sobre as distribuições do Linux com suporte, consulte o artigo visão geral do Azure monitor
Agents .
Versão do Agente e da Extensão de VM
A tabela a seguir fornece um mapeamento da versão da extensão de VM do Log Analytics e o pacote do agente
do Log Analytics para cada versão. Há um link para as notas de versão da versão do pacote do agente do Log
Analytics. As notas de versão incluem detalhes sobre correções de bug e novos recursos disponíveis para uma
determinada liberação de agente.
VERSÃ O DA EXT EN SÃ O DE VM DO L IN UX DO LO G
A N A LY T IC S VERSÃ O DO PA C OT E DO A GEN T E DO LO G A N A LY T IC S
1.13.33 1.13.33
1.13.27 1.13.27
1.13.15 1.13.9-0
VERSÃ O DA EXT EN SÃ O DE VM DO L IN UX DO LO G
A N A LY T IC S VERSÃ O DO PA C OT E DO A GEN T E DO LO G A N A LY T IC S
1.12.25 1.12.15-0
1.11.15 1.11.0-9
1.10.0 1.10.0-1
1.9.1 1.9.0-0
1.8.11 1.8.1-256
1.8.0 1.8.0-256
1.7.9 1.6.1-3
1.6.42.0 1.6.0-42
1.4.60.2 1.4.4-210
1.4.59.1 1.4.3-174
1.4.58.7 14.2-125
1.4.56.5 1.4.2-124
1.4.55.4 1.4.1-123
1.4.45.3 1.4.1-45
1.4.45.2 1.4.0-45
1.3.127.5 1.3.5-127
1.3.127.7 1.3.5-127
1.3.18.7 1.3.4-15

A Central de Segurança do Azure provisiona o agente do Log Analytics e o conecta a um espaço de trabalho do
Log Analytics criado pela ASC na sua assinatura do Azure automaticamente. Se você estiver usando a Central de
Segurança do Azure, não execute as etapas neste documento. Isso substitui o workspace configurado e
interrompe a conexão com a Central de Segurança do Azure.
A extensão do Agente do Log Analytics para Linux requer que a máquina virtual de destino esteja conectada à
Internet.
O JSON a seguir mostra o esquema para a extensão do Agente do Log Analytics. A extensão requer a ID do
espaço de trabalho e a chave do espaço de trabalho no espaço de trabalho do Log Analytics de destino. Esses
valores podem ser encontrados no seu espaço de trabalho do Log Analytics no portal do Azure. Como a chave
do workspace deve ser tratada como um dado confidencial, ela é armazenada em uma configuração protegida.
Os dados de configuração protegidos pela extensão da VM do Azure são criptografados, sendo
descriptografados apenas na máquina virtual de destino. Observe que workspaceId e workspaceKey
diferenciam maiúsculas de minúsculas.
{
"name": "OMSExtension",
"apiVersion": "2018-06-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vm-name>)]"
],
"properties": {
"type": "OmsAgentForLinux",
"settings": {
"workspaceId": "myWorkspaceId"
},
"workspaceKey": "myWorkSpaceKey"
}
}
}
NOTE
O esquema acima assume que ele será colocado no nível raiz do modelo. Se você colocá-lo dentro do recurso de máquina
virtual no modelo, as propriedades type e name deverão ser alteradas, conforme descrito abaixo.
publicador Microsoft.EnterpriseCloud.Monitoring
type OmsAgentForLinux
workspaceId (por exemplo) 6f680a37-00c6-41c7-a93f-1437e3462574
workspaceKey (por exemplo) z4bU3p1/GrnWpQkky4gdabWXAhbWSTz70hm4m2Xt92XI+

rSRgE8qVvRhsGo9TXffbrTahyrwv35W0pOqQAU7uQ==
NOTE
Determinados componentes da extensão de VM Log Analytics também são fornecidos na extensão de VM de diagnóstico.
Devido a essa arquitetura, os conflitos podem surgir se ambas as extensões forem instanciadas no mesmo modelo do
ARM. Para evitar esses conflitos de tempo de instalação, use a dependsOn diretiva para garantir que as extensões sejam
instaladas sequencialmente. As extensões podem ser instaladas em qualquer ordem.
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. Esses modelos
são ideais para implantação de uma ou mais máquinas virtuais que exigem configuração pós-implantação, tal
como integração aos Logs do Azure Monitor. Um exemplo de modelo do Resource Manager que inclui a
extensão de VM do Agente do Log Analytics pode ser encontrado na Galeria de Início Rápido do Azure.
O exemplo a seguir pressupõe que a extensão de VM está aninhada dentro do recurso de máquina virtual. Ao
aninhar o recurso de extensão, o JSON é colocado no objeto "resources": [] da máquina virtual.
{
"apiVersion": "2018-06-01",
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}
Ao inserir o JSON da extensão na raiz do modelo, o nome do recurso inclui uma referência na máquina virtual
pai e o tipo reflete a configuração aninhada.
{
"name": "<parentVmResource>/OMSExtension",
"apiVersion": "2018-06-01",
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}

A CLI do Azure pode ser usado para implantar a extensão da VM do Agente do Log Analytics para uma máquina
virtual existente. Substitua o valor myWorkspaceKey abaixo por sua chave do workspace e o valor
myWorkspaceId pela ID do workspace. Esses valores podem ser encontrados no portal do Azure, no workspace
do Log Analytics, em Configurações avançadas.
--vm-name myVM \
--name OmsAgentForLinux \
--publisher Microsoft.EnterpriseCloud.Monitoring \
--protected-settings '{"workspaceKey":"myWorkspaceKey"}' \
--settings '{"workspaceId":"myWorkspaceId"}'

/opt/microsoft/omsagent/bin/stdout

9 Habilitar chamado prematuramente Atualize o Agente Linux do Azure para

a versão mais recente disponível.
10 A VM já está conectada a um espaço Para conectar a VM ao workspace

de trabalho do Log Analytics especificado no esquema de extensão,
defina stopOnMultipleConnections
como falso nas configurações públicas
ou remova esta propriedade. Essa VM
é cobrada uma vez para cada
workspace ao qual está conectada.
11 Configuração inválida fornecida para a Siga os exemplos anteriores para

extensão definir todos os valores de propriedade
necessários para a implantação.
17 Falha na instalação do pacote do Log

Analytics
19 Falha da instalação do pacote OMI
20 Falha da instalação do pacote SCX
51 Não há suporte para essa extensão no

sistema operacional da VM
52 Esta extensão falhou devido a uma Verifique a saída e os logs para obter
dependência ausente mais informações sobre qual
dependência está faltando.
53 Esta extensão falhou devido a Verifique a saída e os logs para obter

parâmetros de configuração ausentes mais informações sobre o que deu
ou errados errado. Além disso, verifique a exatidão
da ID do espaço de trabalho e
verifique se a máquina está conectada
à Internet.
55 Não é possível se conectar ao serviço Verifique se o sistema tem acesso à

Azure Monitor. Os pacotes necessários Internet ou se um proxy HTTP válido
estão ausentes ou o gerenciador de foi fornecido. Além disso, verifique a
pacotes dpkg está bloqueado exatidão da ID do espaço de trabalho e
verifique se os utilitários de rotação e
tar estão instalados.
Informações adicionais podem ser encontradas no Guia de solução de problemas do Log Analytics-Agent-for-
Linux.
Suporte
Extensão da máquina virtual do Log Analytics para
Windows
Os logs de Azure Monitor fornecem recursos de monitoramento em ativos de nuvem e locais. A extensão de
máquina virtual do agente Log Analytics para Windows é publicada e suportada pela Microsoft. A extensão
instala o agente do Log Analytics em máquinas virtuais do Azure e registra máquinas virtuais em um espaço de
trabalho do Log Analytics existente. Este documento detalha as plataformas com opções de plataformas,
configurações e implantação com suporte para a extensão da máquina virtual do Log Analytics para Windows.
Pré-requisitos
Sistema operacional
Para obter detalhes sobre os sistemas operacionais Windows com suporte, consulte o artigo visão geral do
Azure monitor Agents .
Versão do Agente e da Extensão de VM
A tabela a seguir fornece um mapeamento da versão da extensão de VM do Windows Log Analytics e do pacote
de Log Analytics agente para cada versão.
LO G A N A LY T IC S VERSÃ O LO G A N A LY T IC S VERSÃ O
DO PA C OT E DO A GEN T E DO DA EXT EN SÃ O DE VM DO
W IN DO W S W IN DO W S DATA DE L A N Ç A M EN TO N OTA S DE VERSÃ O
10.20.18053 1.0.18053.0 Outubro de 2020 Novo solucionador

de problemas do
agente
Atualizações de
como o agente lida
com as alterações de
certificado nos
serviços do Azure
10.20.18040 1.0.18040.2 Agosto de 2020 Resolve um

problema no arco
do Azure
10.20.18038 1.0.18038 Abril de 2020 Habilita a

conectividade sobre
o link privado
usando Azure
Monitor escopos de
link privado
Adiciona limitação
de ingestão para
evitar um influxo
repentino e
acidental na
ingestão para um
espaço de trabalho
Adiciona suporte
para nuvens e
regiões adicionais do
Azure
governamental
Resolve um bug em
que
HealthService.exe
falhou
10.20.18029 1.0.18029 Março de 2020 Adiciona suporte à

assinatura de código
SHA-2
Melhora a instalação
e o gerenciamento
da extensão de VM
Resolve um bug no
Azure ARC para
integração de
servidores
Adiciona uma
ferramenta de
solução de
problemas interna
para atendimento
ao cliente
Adiciona suporte
para regiões
adicionais do Azure
governamental
10.20.18018 1.0.18018 Outubro de 2019 Correções de bugs e

melhorias de
estabilização
secundárias
10.20.18011 1.0.18011 Julho de 2019 Correções de bugs e

melhorias de
estabilização
secundárias
Aumento de
MaxExpressionDept
h para 10000
10.20.18001 1.0.18001 Junho de 2019 Correções de bugs e

melhorias de
estabilização
secundárias
Capacidade adicional
de desabilitar as
credenciais padrão
ao fazer a conexão
proxy (suporte para
WINHTTP_AUTOLO
GON_SECURITY_LEV
EL_HIGH)
10.19.13515 1.0.13515 Março de 2019 Correções

secundárias de
estabilização
10.19.10006 N/D Dec 2018 Correções

secundárias de
estabilização
8.0.11136 N/D Setembro de 2018 Suporte adicionado

para detectar a
alteração da ID de
recurso na
movimentação da
VM
Adicionado suporte
para relatar a ID de
recurso ao usar a
instalação sem
extensão
8.0.11103 N/D Abril de 2018
8.0.11081 1.0.11081 2017 de novembro
8.0.11072 1.0.11072 2017 de setembro
8.0.11049 1.0.11049 Fevereiro de 2017

A central de segurança do Azure provisiona automaticamente o agente de Log Analytics e o conecta com o
espaço de trabalho de Log Analytics padrão da assinatura do Azure. Se você estiver usando a Central de
Segurança do Azure, não execute as etapas neste documento. Isso substituiria o workspace configurado e
interromperia a conexão com a Central de Segurança do Azure.
A extensão do agente Log Analytics para Windows requer que a máquina virtual de destino esteja conectada à
Internet.
O seguinte JSON mostra o esquema para a extensão do agente do Log Analytics. A extensão requer a ID do
espaço de trabalho e a chave do espaço de trabalho do destino Log Analytics espaço de trabalho. Esses podem
ser encontrado nas configurações para o workspace no portal do Azure. Como a chave do workspace deve ser
tratada como um dado confidencial, ela é armazenada em uma configuração protegida. Os dados de
configuração protegidos pela extensão da VM do Azure são criptografados, sendo descriptografados apenas na
máquina virtual de destino. Observe que workspaceId e workspaceKey diferenciam maiúsculas de
minúsculas.
{
"dependsOn": [
],
"properties": {
"type": "MicrosoftMonitoringAgent",
"settings": {
"workspaceId": "myWorkSpaceId"
},
"workspaceKey": "myWorkspaceKey"
}
}
}
publicador Microsoft.EnterpriseCloud.Monitoring
type MicrosoftMonitoringAgent
workspaceId (por exemplo)* 6f680a37-00c6-41c7-a93f-1437e3462574
workspaceKey (por exemplo) z4bU3p1/GrnWpQkky4gdabWXAhbWSTz70hm4m2Xt92XI+

rSRgE8qVvRhsGo9TXffbrTahyrwv35W0pOqQAU7uQ==
* A workspaceId é chamada de consumerId na API do Log Analytics.

NOTE
Para obter mais propriedades, consulte Azure Connect Windows computers to Azure monitor.
extensão do agente do Log Analytics durante uma implantação de modelo do Azure Resource Manager. Um
modelo de exemplo que inclui a extensão de VM do agente Log Analytics pode ser encontrado na Galeria de
início rápido do Azure.
NOTE
O modelo não dá suporte à especificação de mais de uma ID de espaço de trabalho e da chave do espaço de trabalho
quando você deseja configurar o agente para relatar para vários espaços de trabalho. Para configurar o agente para
relatar para vários espaços de trabalho, consulte adicionando ou removendo um espaço de trabalho.
O JSON para uma extensão da máquina virtual pode ser aninhado dentro do recurso de máquina virtual ou
localizado no nível de raiz ou superior de um modelo JSON do Resource Manager. O posicionamento do JSON
afeta o valor do tipo e nome do recurso. Para obter mais informações, consulte Definir o nome e o tipo de
recursos filho.
O exemplo a seguir pressupõe que a extensão Log Analytics esteja aninhada dentro do recurso de máquina
virtual. Ao aninhar o recurso de extensão, o JSON é colocado no objeto "resources": [] da máquina virtual.
{
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}
{
"name": "<parentVmResource>/OMSExtension",
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}
O Set-AzVMExtension comando pode ser usado para implantar a extensão de máquina virtual do agente do Log
Analytics em uma máquina virtual existente. Antes de executar o comando, as configurações públicas e privadas
precisam ser armazenadas em uma tabela de hash do PowerShell.
$PublicSettings = @{"workspaceId" = "myWorkspaceId"}

$ProtectedSettings = @{"workspaceKey" = "myWorkspaceKey"}
Set-AzVMExtension -ExtensionName "MicrosoftMonitoringAgent" `

-VMName "myVM" `
-Publisher "Microsoft.EnterpriseCloud.Monitoring" `
-ExtensionType "MicrosoftMonitoringAgent" `
-Settings $PublicSettings `
-ProtectedSettings $ProtectedSettings `
-Location WestUS

o comando a seguir usando o módulo do Azure PowerShell.
C:\WindowsAzure\Logs\Plugins\Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent\
Suporte
Extensão de máquina virtual de dependência do
Azure Monitor para Linux
O recurso Mapa do Azure Monitor para VMs obtém seus dados do Microsoft Dependency Agent. A extensão da
máquina virtual do agente de dependência da VM do Azure para Linux é publicada e recebe suporte da
Microsoft. A extensão instala o agente de dependência em máquinas virtuais do Azure. Este documento
especifica as opções de plataformas, de configurações e de implantação com suporte para a extensão da
máquina virtual do agente de dependência da VM do Azure.
Pré-requisitos
Sistema operacional
A extensão do agente de dependência da VM do Azure para Linux pode ser executada nos sistemas operacionais
com suporte listados na seção Sistemas operacionais com suporte do artigo de implantação do Azure Monitor
para VMs.
O JSON a seguir mostra o esquema da extensão do agente de dependência de VM do Azure em uma VM para
Linux do Azure.
{
"parameters": {
"vmName": {
"type": "string",
"metadata": {
"description": "The name of existing Linux Azure VM."
}
}
},
"variables": {
"vmExtensionsApiVersion": "2017-03-30"
},
"resources": [
{
"name": "[concat(parameters('vmName'),'/DAExtension')]",
"apiVersion": "[variables('vmExtensionsApiVersion')]",
"dependsOn": [
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentLinux",
}
}
],
"outputs": {
}
}
publicador Microsoft.Azure.Monitoring.DependencyAgent
type DependencyAgentLinux
typeHandlerVersion 9,5
Você pode implantar extensões de VM do Azure com os modelos do Azure Resource Manager. Você pode usar o
extensão do agente de dependência de VM do Azure durante uma implantação de modelo do Azure Resource
Manager.
O JSON de uma extensão de máquina virtual pode ser aninhado no recurso de máquina virtual. Como
alternativa, você pode colocá-lo no nível raiz ou superior de um modelo JSON do Resource Manager. O
posicionamento do JSON afeta o valor do tipo e nome do recurso. Para obter mais informações, consulte Definir
o nome e o tipo de recursos filho.
O exemplo a seguir pressupõe que a extensão do agente de dependência está aninhada no recurso de máquina
virtual. Quando você aninha o recurso de extensão, o JSON é colocado no objeto "resources": [] da máquina
virtual.
{
"name": "DAExtension",
"dependsOn": [
],
"properties": {
}
}
Ao colocar a extensão JSON na raiz do modelo, o nome do recurso inclui uma referência à máquina virtual pai.
O tipo reflete a configuração aninhada.
{
"name": "<parentVmResource>/DAExtension",
"dependsOn": [
],
"properties": {
}
}

Você pode usar o CLI do Azure para implantar a extensão de VM do agente de dependência em uma máquina
virtual existente.
--vm-name myVM \
--name DependencyAgentLinux \
--publisher Microsoft.Azure.Monitoring.DependencyAgent \
--version 9.5

do Azure. Para ver o estado da implantação das extensões de uma determinada VM, execute o seguinte
comando usando a CLI do Azure:
/opt/microsoft/dependency-agent/log/install.log
Suporte
Caso precise de mais ajuda a qualquer momento neste artigo, entre em contato com os especialistas do Azure
nos fóruns do Azure e do Stack Overflow no MSDN. Como alternativa, você pode registrar um incidente de
suporte do Azure. Vá para o site de suporte do Azure e selecione Obter supor te . Para saber mais sobre como
usar o suporte do Azure, leia as Perguntas frequentes sobre o suporte do Microsoft Azure.
Extensão de máquina virtual de dependência Azure
Monitor para Windows
O recurso Mapa do Azure Monitor para VMs obtém seus dados do Microsoft Dependency Agent. A extensão da
máquina virtual do agente de dependência de VM do Azure para Windows é publicada e tem suporte da
Microsoft. A extensão instala o agente de dependência em máquinas virtuais do Azure. Este documento detalha
as plataformas com suporte, as configurações e as opções de implantação para a extensão de máquina virtual
do agente de dependência de VM do Azure para Windows.
Sistema operacional
A extensão do agente de dependência de VM do Azure para Windows pode ser executada nos sistemas
operacionais com suporte listados na seção sistemas operacionais com suporte no artigo Azure monitor para
VMs implantação.
O JSON a seguir mostra o esquema para a extensão do agente de dependência de VM do Azure em uma VM do
Windows do Azure.
{
"parameters": {
"vmName": {
"type": "string",
"metadata": {
"description": "The name of existing Azure VM. Supported Windows Server versions: 2008 R2 and above
(x64)."
}
}
},
"variables": {
"vmExtensionsApiVersion": "2017-03-30"
},
"resources": [
{
"name": "[concat(parameters('vmName'),'/DAExtension')]",
"apiVersion": "[variables('vmExtensionsApiVersion')]",
"dependsOn": [
],
"properties": {
"type": "DependencyAgentWindows",
}
}
],
"outputs": {
}
}
publicador Microsoft.Azure.Monitoring.DependencyAgent
type DependencyAgentWindows
typeHandlerVersion 9,5
Você pode implantar as extensões de VM do Azure com modelos de Azure Resource Manager. Você pode usar o
extensão do agente de dependência de VM do Azure durante uma implantação de modelo do Azure Resource
Manager.
O JSON de uma extensão de máquina virtual pode ser aninhado no recurso de máquina virtual. Como
alternativa, você pode colocá-lo no nível raiz ou superior de um modelo JSON do Resource Manager. O
posicionamento do JSON afeta o valor do tipo e nome do recurso. Para obter mais informações, consulte Definir
o nome e o tipo de recursos filho.
O exemplo a seguir pressupõe que a extensão do agente de dependência está aninhada no recurso de máquina
virtual. Quando você aninha o recurso de extensão, o JSON é colocado no objeto "resources": [] da máquina
virtual.
{
"name": "DAExtension",
"dependsOn": [
],
"properties": {
}
}
Ao colocar a extensão JSON na raiz do modelo, o nome do recurso inclui uma referência à máquina virtual pai.
O tipo reflete a configuração aninhada.
{
"name": "<parentVmResource>/DAExtension",
"dependsOn": [
],
"properties": {
}
}
Você pode usar o Set-AzVMExtension comando para implantar a extensão da máquina virtual do agente de
dependência em uma máquina virtual existente. Antes de executar o comando, as configurações públicas e
privadas precisam ser armazenadas em uma tabela de hash do PowerShell.
Set-AzVMExtension -ExtensionName "Microsoft.Azure.Monitoring.DependencyAgent" `

-VMName "myVM" `
-Publisher "Microsoft.Azure.Monitoring.DependencyAgent" `
-ExtensionType "DependencyAgentWindows" `
-Location WestUS

Os dados sobre o estado das implantações de extensão podem ser recuperados do portal do Azure e usando o
módulo Azure PowerShell. Para ver o estado de implantação das extensões de uma determinada VM, execute o
seguinte comando usando o módulo Azure PowerShell:
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Monitoring.DependencyAgent\
Suporte
do Azure. Vá para o site de suporte do Azure e selecione Obter supor te . Para saber mais sobre como usar o
Introdução ao manipulador de extensão de Desired
State Configuration do Azure
O agente de VM do Azure e as extensões associadas são parte dos serviços de infraestrutura do Microsoft
Azure. Extensões de VM são componentes de software que estendem a funcionalidade da VM e simplificam
várias operações de gerenciamento de VM.
O caso de uso primário para a extensão DSC (configuração de estado desejado) do Azure é inicializar uma VM
para o serviço de configuração de estado da automação do Azure (DSC). O serviço fornece benefícios que
incluem o gerenciamento contínuo da configuração da VM e a integração com outras ferramentas operacionais,
como o monitoramento do Azure. Usar a extensão para registrar VMs no serviço fornece uma solução flexível
que até funciona em assinaturas do Azure.
Você pode usar a extensão de DSC, independentemente do serviço de DSC de Automação. No entanto, isso
enviará por push apenas uma configuração para a VM. Nenhum relatório contínuo está disponível, a não ser
localmente na VM.
Este artigo fornece informações sobre cenários: usar a extensão DSC para integração da Automação e usar a
extensão de DSC como uma ferramenta para atribuir configurações a VMs usando o SDK do Azure.
Pré-requisitos
Computador local : Para interagir com a extensão de VM do Azure, você deve usar o Portal do Azure ou o
SDK do Azure PowerShell.
Agente convidado : A VM do Azure que é configurada pela configuração do DSC deve ter um sistema
operacional compatível com Windows Management Framework (WMF) 4.0 ou posterior. Para a lista
completa de versões com suporte do sistema operacional, consulte o Histórico de versões da extensão de
DSC.
Termos e conceitos
Este guia presume familiaridade com os seguintes conceitos:
Configuração : um documento de configuração DSC.
Nó : um destino para uma configuração DSC. Neste documento, o nó sempre se refere a uma VM do Azure.
Dados de configuração : Um arquivo .psd1 que tem dados ambientais de uma configuração.
Arquitetura
A extensão de DSC do Azure usa a estrutura do Agente de VM do Azure para entregar, aplicar e gerar relatórios
sobre configurações da DSC executadas em VMs do Azure. A extensão de DSC aceita um documento de
configuração e um conjunto de parâmetros. Se nenhum arquivo for fornecido, um script de configuração
padrão é inserido com a extensão. O script de configuração padrão é usado somente para definir metadados no
Local Configuration Manager.
Quando a extensão é chamada pela primeira vez, ela instala uma versão do WMF usando a lógica a seguir:
Se o sistema operacional da VM do Azure for o Windows Server 2016, nenhuma ação é executada. O
Windows Server 2016 já possui a versão mais recente do PowerShell instalada.
Se a propriedade wmfVersion for especificada, essa versão do WMF é instalada, a menos que essa versão
não seja compatível com o sistema operacional da VM.
Se nenhuma propriedade wmfVersion for especificada, a versão mais recente de WMF aplicável é instalada.
Instalar o WMF requer uma reinicialização. Após a reinicialização, a extensão faz o download do arquivo .zip que
é especificado na propriedade modulesUrl , se fornecido. Se esse local estiver no armazenamento de blobs do
Azure, você pode especificar um token SAS na propriedade sasToken para acessar o arquivo. Depois que o. zip
é baixado e desempacotado, a função de configuração definida em configurationFunction é executada para
gerar um arquivo. mof (Managed Object Format). Em seguida, a extensão executa
Start-DscConfiguration -Force usando o arquivo .mof gerado. A extensão captura a saída e a grava no canal de
status do Azure.
Script de configuração padrão
A extensão de DSC do Azure inclui um script de configuração padrão que é destinado a ser usado quando você
carrega uma VM ao serviço de DSC de Automação do Azure. Os parâmetros do script estão alinhados com as
propriedades configuráveis do Gerenciador de Configurações Locais. Para parâmetros de script, consulte Script
de configuração padrão na extensão de Desired State Configuration com modelos do Azure Resource Manager.
Para o script completo, consulte o modelo de início rápido do Azure no GitHub.
Informações para registrar com o serviço de configuração de estado

da automação do Azure (DSC)
Ao usar a extensão de DSC para registrar um nó com o serviço de configuração de estado, será necessário
fornecer três valores.
RegistrationUrl-o endereço https da conta de automação do Azure
RegistrationKey-um segredo compartilhado usado para registrar nós com o serviço
NodeConfigurationName-o nome da configuração de nó (MOF) a ser extraída do serviço para configurar a
função de servidor
Essas informações podem ser vistas na portal do Azure ou você pode usar o PowerShell.
(Get-AzAutomationRegistrationInfo -ResourceGroupName <resourcegroupname> -AutomationAccountName

<accountname>).Endpoint
(Get-AzAutomationRegistrationInfo -ResourceGroupName <resourcegroupname> -AutomationAccountName
<accountname>).PrimaryKey
Para o nome da configuração do nó, verifique se a configuração do nó existe na configuração de estado do

Azure. Caso contrário, a implantação da extensão retornará uma falha. Verifique também se você está usando o
nome da configuração do nó e não a configuração. Uma configuração é definida em um script que é usado para
compilar a configuração de nó (arquivo MOF). O nome será sempre a configuração seguida por um ponto . e
um localhost nome de computador específico.
Extensão de DSC nos modelos do Resource Manager

Na maioria dos cenários, os modelos de implantação do Azure Resource Manager (ARM) são a forma esperada
de trabalhar com a extensão de DSC. Para obter mais informações e exemplos sobre como incluir a extensão de
DSC em modelos de implantação do Resource Manager, consulte Extensão de Desired State Configuration com
modelos do Azure Resource Manager.
Cmdlets do PowerShell de Extensão de DSC

Os cmdlets do PowerShell que são usados para gerenciar a extensão de DSC são melhor usados em cenários de
solução de problemas interativa e coleta de informações. Você pode usar os cmdlets para empacotar, publicar e
monitorar implantações de extensão de DSC. Os cmdlets para a extensão de DSC ainda não foram atualizados
para funcionar com o Script de Configuração Padrão.
O cmdlet Publish-AzVMDscConfiguration recebe um arquivo de configuração, verifica o arquivo para ver se
há recursos de DSC dependentes e, em seguida, cria um arquivo .zip. O arquivo. zip contém a configuração e
recursos de DSC que são necessários para aplicar a configuração. O cmdlet também pode criar o pacote
localmente usando o parâmetro -OutputArchivePath. Caso contrário, o cmdlet publica o arquivo .zip no
armazenamento de Blobs e o protege com um token SAS.
O script de configuração .ps1 criado por esse cmdlet é um arquivo .zip na raiz da pasta de arquivamento. A
pasta de módulo é colocada na pasta de arquivamento em recursos.
O cmdlet Set-AzVMDscExtension injeta as configurações que a extensão de DSC do PowerShell exige em um
objeto de configuração de VM.
O cmdlet Get-AzVMDscExtension recupera o status da extensão de DSC de uma VM específica.
O cmdlet Get-AzVMDscExtensionStatus recupera o status da configuração de DSC que é imposta pelo
manipulador de extensões de DSC. Essa ação pode ser executada em uma única VM ou em um grupo de VMs.
O cmdlet Remove-AzVMDscExtension remove o manipulador de extensões de uma VM específica. Esse
cmdlet não remove a configuração, desinstala o WMF ou altera as configurações aplicadas na máquina virtual.
Apenas remove o manipulador de extensão.
Informações importantes sobre os cmdlets de extensão de DSC do Resource Manager:
Os cmdlets do Azure Resource Manager são síncronos.
Os parâmetros ResourceGroupName, VMName, ArchiveStorageAccountName, Version e Location são
obrigatórios.
ArchiveResourceGroupName é um parâmetro opcional. Você pode especificar esse parâmetro quando sua
conta de armazenamento pertencer a um grupo de recursos diferente daquele no qual a VM foi criada.
Use a opção AutoUpdate para atualizar automaticamente do manipulador de extensão para a versão mais
recente quando estiver disponível. Este parâmetro tem o potencial de causar reinicializações na VM quando
uma nova versão de WMF for lançada.
Introdução aos cmdlets
A extensão de DSC do Azure pode usar documentos de configuração DSC para configurar diretamente VMs do
Azure durante a implantação. Essa etapa não registra o nó para Automação. O nó não é gerenciado
centralmente.
O exemplo a seguir mostra um exemplo simples de configuração. Salve a configuração localmente como
iisInstall.ps1.
configuration IISInstall
{
node "localhost"
{
WindowsFeature IIS
{
Ensure = "Present"
Name = "Web-Server"
}
}
}
Os comandos a seguir colocam o script iisInstall.ps1 na VM especificada. Os comandos também executar a

configuração e, em seguida, reportam o status.
$resourceGroup = 'dscVmDemo'
$vmName = 'myVM'
$storageName = 'demostorage'
#Publish the configuration script to user storage
Publish-AzVMDscConfiguration -ConfigurationPath .\iisInstall.ps1 -ResourceGroupName $resourceGroup -
StorageAccountName $storageName -force
#Set the VM to run the DSC configuration
Set-AzVMDscExtension -Version '2.76' -ResourceGroupName $resourceGroup -VMName $vmName -
ArchiveStorageAccountName $storageName -ArchiveBlobName 'iisInstall.ps1.zip' -AutoUpdate -ConfigurationName
'IISInstall'

O CLI do Azure pode ser usado para implantar a extensão de DSC em uma máquina virtual existente.
Para uma máquina virtual que executa o Windows:
--vm-name myVM \
--name Microsoft.Powershell.DSC \
--publisher Microsoft.Powershell \
--version 2.77 --protected-settings '{}' \
--settings '{}'
Para uma máquina virtual que executa o Linux:
--vm-name myVM \
--name DSCForLinux \
--publisher Microsoft.OSTCExtensions \
--version 2.7 --protected-settings '{}' \
--settings '{}'
Funcionalidade do portal do Azure

Para configurar o DSC no portal:
1. Ir para uma VM.
2. Em Configurações , selecione Extensões .
3. Na nova página que é criada, selecione + Adicionar e, em seguida, selecione Desired State
Configuration do PowerShell .
4. Clique em Criar , na parte inferior da página de informações.
O portal coleta a seguinte entrada:
Módulos de Configuração ou Script : este campo é obrigatório (o formulário não foi atualizado para
o script de configuração padrão). Módulos de configuração e scripts exigem um arquivo. ps1 que tem um
script de configuração ou um arquivo. zip com um script de configuração. ps1 na raiz. Se você usar um
arquivo. zip, todos os recursos dependentes devem ser incluídos em pastas de módulo no. zip. Você pode
criar o arquivo. zip usando o cmdlet Publish-AzureVMDscConfiguration - -OutputArchivePath que
está incluído no SDK do PowerShell do Azure. O arquivo .zip será carregado em seu armazenamento de
blobs de usuário protegido por um token SAS.
Nome qualificado do módulo da configuração : você pode incluir várias funções de configuração
em um arquivo. ps1. Insira o nome do script .ps1 de configuração seguido por \ e o nome da função de
configuração. Por exemplo, se o seu script .ps1 tiver o nome configuration.ps1 e se a configuração for
IisInstall , insira configuration.ps1\IisInstall .
Argumentos de configuração : se a função de configuração leva argumentos, insira-os aqui no
formato argumentName1=value1,argumentName2=value2 . Observe que esse formato é diferente
daquele como argumentos de configuração são aceitos nos cmdlets do PowerShell ou modelos do
Resource Manager.
Arquivo de PSD1 de dados de configuração : se sua configuração exigir um arquivo de dados de
configuração no .psd1 , use esse campo para selecionar o arquivo de dados e carregá-lo no
armazenamento de BLOBs do usuário. O arquivo de dados de configuração é protegido por um token
SAS no armazenamento de blob.
Versão WMF : Especifica a versão do Windows Management Framework (WMF) que deve ser instalada
em sua VM. Configurar essa propriedade como mais recente instala a versão mais recente de WMF.
Atualmente, os únicos valores possíveis para essa propriedade são 4.0, 5.0, 5.1, e a mais recente. Esses
valores possíveis estão sujeitos a atualizações. O valor padrão é latest .
Coleta de Dados : Determina se a extensão coletará temetria. Para obter mais informações, consulte
coleta de dados de extensão de DSC do Azure.
Versão : Especifica a versão da extensão DSC para instalar. Para informações sobre as versões, veja
histórico de versão da extensão DSC.
Versão Menor de Autoatualização : Este campo mapeia para a troca AutoUpdate nos cmdlets e
habilita a extensão para automaticamente atualizar para a última versão durante a instalação. SIm
instruirá o manipulador de extensão a usar a última versão disponível e Não forçará a Versão específica
ser instalada. Não selecionar nem Sim nem Não é o mesmo que selecionar Não .
Logs
Logs para a extensão são armazenados no seguinte local:
C:\WindowsAzure\Logs\Plugins\Microsoft.Powershell.DSC\<version number>
Próximas etapas
Para obter mais informações sobre o DSC do PowerShell, vá até o Centro de documentação do PowerShell.
Examine o modelo do Resource Manager para a extensão de DSC.
Para mais funcionalidade que você pode gerenciar usando o DSC do PowerShell e para obter mais recursos
de DSC, procure na Galeria do PowerShell.
Para obter detalhes sobre como passar parâmetros confidenciais em configurações, consulte Gerenciar
credenciais com segurança com o manipulador de extensão de DSC.
Extensão de DSC para Linux (Microsoft.
OSTCExtensions. DSCForLinux)
A DSC (configuração de estado desejado) é uma plataforma de gerenciamento que você pode usar para
gerenciar sua infraestrutura de ti e de desenvolvimento com a configuração como código.
NOTE
A extensão de DSC para Linux e a extensão de máquina virtual log Analytics para Linux atualmente apresentam um
conflito e não tem suporte em uma configuração lado a lado. Não use as duas soluções juntas na mesma VM.
A extensão DSCForLinux é publicada e tem suporte da Microsoft. A extensão instala o agente OMI e DSC em
máquinas virtuais do Azure. A extensão de DSC também pode executar as seguintes ações:
Registre a VM do Linux em uma conta de automação do Azure para efetuar pull das configurações do serviço
de automação do Azure (registrar Extensionaction).
Envie por push configurações do MOF para a VM do Linux (extensão Pushaction).
Aplique a configuração do metamof à VM do Linux para configurar um servidor de pull para efetuar pull da
configuração do nó (extensão Pullaction).
Instale módulos DSC personalizados para a VM do Linux (instalar Extensionaction).
Remova os módulos DSC personalizados da VM do Linux (remover Extensionaction).
Pré-requisitos
Sistema operacional
Para nós que executam o Linux, a extensão de DSC do Linux dá suporte a todas as distribuições do Linux listadas
na documentação do DSC do PowerShell.
A extensão DSCForLinux requer que a máquina virtual de destino esteja conectada à Internet. Por exemplo, a
extensão de registro requer conectividade com o serviço de automação. Para outras ações como pull, pull, install
requer conectividade com o armazenamento do Azure e o GitHub. Depende das configurações fornecidas pelo
cliente.
Configuração pública
Aqui estão todos os parâmetros de configuração pública com suporte:
FileUri : (opcional, Cadeia de caracteres) o URI do arquivo MOF, meta do arquivo MOF ou arquivo zip de
recurso personalizado.
ResourceName : (opcional, Cadeia de caracteres) o nome do módulo de recurso personalizado.
ExtensionAction : (opcional, cadeia de caracteres) Especifica o que faz uma extensão. Os valores válidos são
registrar, enviar por push, efetuar pull, instalar e remover. Se não for especificado, ele será considerado uma
ação de envio por Push por padrão.
NodeConfigurationName : (opcional, Cadeia de caracteres) o nome de uma configuração de nó a ser aplicada.
RefreshFrequencyMins : (opcional, int) especifica com que frequência (em minutos) o DSC tenta obter a
configuração do servidor de pull. Se a configuração no servidor de pull for diferente da atual no nó de
destino, ela será copiada para a loja pendente e aplicada.
ConfigurationMode : (opcional, cadeia de caracteres) Especifica como DSC deve aplicar a configuração. Os
valores válidos são ApplyOnly, ApplyAndMonitor e ApplyAndAutoCorrect.
ConfigurationModeFrequencyMins : (opcional, int) Especifica a frequência (em minutos) DSC garante que a
configuração está no estado desejado.
NOTE
Se você usar uma versão anterior à 2,3, o parâmetro mode será o mesmo que Extensionaction. O modo parece ser um
termo sobrecarregado. Para evitar confusão, Extensionaction é usado da versão 2,3 em diante. Para compatibilidade com
versões anteriores, a extensão dá suporte ao modo e ExtensionAction.
Configuração protegida
Aqui estão todos os parâmetros de configuração protegidos com suporte:
StorageAccountName : (opcional, Cadeia de caracteres) o nome da conta de armazenamento que contém o
arquivo
StorageAccountKey : (opcional, Cadeia de caracteres) a chave da conta de armazenamento que contém o
arquivo
RegistrationUrl : (opcional, Cadeia de caracteres) a URL da conta de automação do Azure
RegistrationKey : (opcional, Cadeia de caracteres) a chave de acesso da conta de automação do Azure
Cenários
Registrar uma conta de automação do Azure
protected.json
{
"RegistrationUrl": "<azure-automation-account-url>",
"RegistrationKey": "<azure-automation-account-key>"
}
public.json
{
"ExtensionAction" : "Register",
"NodeConfigurationName" : "<node-configuration-name>",
"RefreshFrequencyMins" : "<value>",
"ConfigurationMode" : "<ApplyAndMonitor | ApplyAndAutoCorrect | ApplyOnly>",
"ConfigurationModeFrequencyMins" : "<value>"
}
Formato do PowerShell
$privateConfig = '{
"RegistrationUrl": "<azure-automation-account-url>",
"RegistrationKey": "<azure-automation-account-key>"
}'
$publicConfig = '{
"ExtensionAction" : "Register",
"NodeConfigurationName": "<node-configuration-name>",
"RefreshFrequencyMins": "<value>",
"ConfigurationMode": "<ApplyAndMonitor | ApplyAndAutoCorrect | ApplyOnly>",
"ConfigurationModeFrequencyMins": "<value>"
}'
Aplicar um arquivo de configuração MOF (em uma conta de armazenamento do Azure ) à VM

protected.json
{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}
public.json
{
"FileUri": "<mof-file-uri>",
"ExtensionAction": "Push"
}
$privateConfig = '{
}'
$publicConfig = '{
"FileUri": "<mof-file-uri>",
"ExtensionAction": "Push"
}'
Aplicar um arquivo de configuração MOF (no armazenamento público ) à VM

public.json
{
"FileUri": "<mof-file-uri>"
}
$publicConfig = '{
}'
Aplicar um arquivo de configuração meta MOF (em uma conta de armazenamento do Azure ) à VM
protected.json
{
}
public.json
{
"ExtensionAction": "Pull",
"FileUri": "<meta-mof-file-uri>"
}
$privateConfig = '{
}'
$publicConfig = '{
"ExtensionAction": "Pull",
"FileUri": "<meta-mof-file-uri>"
}'
Aplicar um arquivo de configuração do MOF meta (no armazenamento público ) à VM

public.json
{
"FileUri": "<meta-mof-file-uri>",
"ExtensionAction": "Pull"
}
$publicConfig = '{
"FileUri": "<meta-mof-file-uri>",
"ExtensionAction": "Pull"
}'
Instalar um módulo de recurso personalizado (um arquivo zip em uma conta de armazenamento do Azure )
para a VM
protected.json
{
}
public.json
{
"ExtensionAction": "Install",
"FileUri": "<resource-zip-file-uri>"
}
$privateConfig = '{
}'
$publicConfig = '{
}'
Instalar um módulo de recurso personalizado (um arquivo zip no armazenamento público ) para a VM
public.json
{
}
$publicConfig = '{
}'
Remover um módulo de recurso personalizado de VM

public.json
{
"ResourceName": "<resource-name>",
"ExtensionAction": "Remove"
}
$publicConfig = '{
"ResourceName": "<resource-name>",
"ExtensionAction": "Remove"
}'
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. Os modelos são
ideais quando você implanta uma ou mais máquinas virtuais que exigem a configuração pós-implantação,
como a integração à automação do Azure.
É o modelo do Resource Manager 201-dsc-linux-azure-storage-on-ubuntu e 201-dsc-linux-public-storage-on-
ubuntu.
Para obter mais informações sobre o modelo de Azure Resource Manager, consulte criando modelos de Azure
Resource Manager.
Usar [CLI do Azure ] [Azure -CLI ]
Antes de implantar a extensão DSCForLinux, configure seu public.json e protected.json de acordo com os
diferentes cenários na seção 3.
Clássico
IMPORTANT
O modo de implantação clássico também é chamado de modo de gerenciamento de serviços do Azure. Você
pode alternar para ele, executando:
$ azure config mode asm
Você pode implantar a extensão DSCForLinux executando:
$ azure vm extension set <vm-name> DSCForLinux Microsoft.OSTCExtensions <version> \

--private-config-path protected.json --public-config-path public.json
Para saber a versão mais recente da extensão disponível, execute:
$ azure vm extension list
Gerenciador de Recursos
Você pode mudar para o modo do Gerenciador de Recursos do Azure executando:
$ azure config mode arm
$ azure vm extension set <resource-group> <vm-name> \

DSCForLinux Microsoft.OSTCExtensions <version> \
--private-config-path protected.json --public-config-path public.json
NOTE
No modo de Azure Resource Manager, o azure vm extension list não está disponível por enquanto.
Usar [Azure PowerShell] [Azure -PowerShell]

Clássico
Você pode entrar em sua conta do Azure no modo de gerenciamento de serviços do Azure executando:
Add-AzureAccount
E implante a extensão DSCForLinux executando:
$vmname = '<vm-name>'
$vm = Get-AzureVM -ServiceName $vmname -Name $vmname
$extensionName = 'DSCForLinux'
$publisher = 'Microsoft.OSTCExtensions'
$version = '< version>'
Altere o conteúdo de $privateConfig e $publicConfig de acordo com diferentes cenários na seção anterior.
$privateConfig = '{
}'
$publicConfig = '{
"ExtensionAction": "Push",
}'
Set-AzureVMExtension -ExtensionName $extensionName -VM $vm -Publisher $publisher `

-Version $version -PrivateConfiguration $privateConfig `
-PublicConfiguration $publicConfig | Update-AzureVM
Você pode entrar em sua conta do Azure no modo de Azure Resource Manager executando:
Login-AzAccount
Para saber mais sobre como usar Azure PowerShell com Azure Resource Manager, consulte gerenciar recursos
do Azure usando Azure PowerShell.
$rgName = '<resource-group-name>'
$vmName = '<vm-name>'
$location = '< location>'
$extensionName = 'DSCForLinux'
$publisher = 'Microsoft.OSTCExtensions'
$version = '< version>'
Altere o conteúdo de $privateConfig e $publicConfig de acordo com diferentes cenários na seção anterior.
$privateConfig = '{
}'
$publicConfig = '{
"ExtensionAction": "Push",
}'
Set-AzVMExtension -ResourceGroupName $rgName -VMName $vmName -Location $location `
-Name $extensionName -Publisher $publisher -ExtensionType $extensionName `
-TypeHandlerVersion $version -SettingString $publicConfig -ProtectedSettingString $privateConfig

do Azure. Para ver o estado de implantação das extensões de uma determinada VM, execute o seguinte
comando usando o CLI do Azure.
/var/log/azure/<extension-name>/<version>/extension.log file.
Código de erro: 51 representa a distribuição sem suporte ou a ação de extensão sem suporte. Em alguns casos,
a extensão do DSC do Linux falha ao instalar o OMI quando uma versão mais recente do OMI já existe no
computador. [resposta de erro: não permitido de Downgrade (000003)]
Suporte
Caso precise de mais ajuda a qualquer momento neste artigo, entre em contato com os especialistas do Azure
nos fóruns do Azure e do Stack Overflow no MSDN. Como alternativa, você pode arquivar um incidente de
suporte do Azure. Vá para o site de suporte do Azuree selecione obter supor te . Para obter informações sobre
como usar o suporte do Azure, leia as perguntas frequentes sobre suporte do Microsoft Azure.
Próximas etapas
Para obter mais informações sobre extensões, consulte Recursos e extensões da máquina virtual para Linux.
Extensão de DSC do PowerShell
Visão geral
A extensão DSC PowerShell para Windows é publicada e recebe suporte da Microsoft. A extensão atualiza e
aplica uma configuração de DSC do PowerShell em uma VM do Azure. A extensão de DSC chama a DSC do
PowerShell para aplicar a configuração DSC recebida na VM. Este documento detalha as plataformas com
opções de plataformas, configurações e implantação com suporte para a extensão da máquina virtual do DSC
para Windows.
Pré-requisitos
Sistema operacional
A Extensão DSC suporta os seguintes OS
Windows Server 2019, Windows Server 2016, Windows Server 2012R2, Windows Server 2012, Windows
Server 2008 R2 SP1, Windows Client 7/8.1/10
A extensão de DSC para Windows requer que a máquina virtual de destino seja capaz de se comunicar com o
Azure e o local do pacote de configuração (arquivo. zip) se ele estiver armazenado em um local fora do Azure.
O JSON a seguir mostra o esquema que serve para a parte das configurações da extensão DSC em um modelo
do Azure Resource Manager.
{
"name": "Microsoft.Powershell.DSC",
"apiVersion": "2018-10-01",
"properties": {
"publisher": "Microsoft.Powershell",
"type": "DSC",
"settings": {
"wmfVersion": "latest",
"configuration": {
"url": "http://validURLToConfigLocation",
"script": "ConfigurationScript.ps1",
"function": "ConfigurationFunction"
},
"configurationArguments": {
"argument1": "Value1",
"argument2": "Value2"
},
"configurationData": {
"url": "https://foo.psd1"
},
"privacy": {
"dataCollection": "enable"
},
"advancedOptions": {
"forcePullAndApply": false,
"downloadMappings": {
"specificDependencyKey": "https://myCustomDependencyLocation"
}
}
},
"parameterOfTypePSCredential1": {
"userName": "UsernameValue1",
"password": "PasswordValue1"
},
}
},
"configurationUrlSasToken": "?g!bber1sht0k3n",
"configurationDataUrlSasToken": "?dataAcC355T0k3N"
}
}
}
publicador Microsoft.Powershell.DSC string
type DSC string

Valores da Propriedade de Configurações
NOME T IP O DE DA DO S DESC RIÇ Ã O
settings.wmfVersion string Especifica a versão do Windows

Management Framework que deve ser
instalada em sua VM. Configurar essa
propriedade como 'latest' instalará a
versão mais atualizada do WMF. Os
únicos valores possíveis atualmente
para essa propriedade são ‘4.0’, ‘5.0’, e
a mais recente. Esses valores possíveis
estão sujeitos a atualizações. O valor
padrão é ‘latest’.
settings.configuration.url string Especifica o local da URL de onde

baixar o arquivo zip configuração DSC.
Se a URL fornecida exigir um token
SAS para acesso, será necessário definir
a propriedade
protectedSettings.configurationUrlSasT
oken como o valor do token de SAS.
Esta propriedade será necessária se
settings.configuration.script e/ou
settings.configuration.function
estiverem definidas.
settings.configuration.script string Especifica o nome do arquivo do script

que contém a definição de sua
configuração DSC. Esse script deve
estar na pasta raiz do arquivo zip
baixado da URL especificada pela
propriedade configuration.url. Esta
propriedade é necessária se
settings.configuration.url e/ou
settings.configuration.script estiverem
definidas.
settings.configuration.function string Especifica o nome da configuração

DSC. A configuração denominada deve
estar contida no script definido por
configuration.script. Esta propriedade
será necessária se
settings.configuration.script.url e/ou
estiverem definidas.
settings.configurationArguments Coleção Define os parâmetros que você deseja

passar para a configuração de DSC.
Esta propriedade não será
criptografada.
settings.configurationData.url string Especifica a URL de onde baixar o

arquivo de dados de configuração
(.pds1) para usar como entrada para a
sua configuração de DSC. Se a URL
fornecida exigir um token SAS para
acesso, será necessário definir a
propriedade
protectedSettings.configurationDataUrl
SasToken como o valor do token de
SAS.
settings.privacy.dataEnabled string Habilita ou desabilita a coleta de

telemetria. Os únicos valores possíveis
para essa propriedade são ‘Enable’,
‘Disable’, ”, ou $null. Deixar esta
propriedade em branco ou nulo
permitirá telemetria
settings.advancedOptions.forcePullAnd Bool Essa configuração foi projetada para

Apply aprimorar a experiência de trabalhar
com a extensão para registrar nós com
o DSC de Automação do Azure. Se o
valor for $true , a extensão
aguardará a primeira execução da
configuração extraída do serviço antes
de retornar êxito/falha. Se o valor for
definido como $false, o status
retornado pela extensão somente fará
referência a se o nó foi registrado com
êxito na configuração de estado da
automação do Azure e a configuração
do nó não será executada durante o
registro.
settings.advancedOptions.downloadM Coleção Define locais alternativos para fazer o

appings download de dependências como
WMF e .NET
Valores da Propriedade de Configurações Protegidos

protectedSettings.configurationArgum string Define os parâmetros que você deseja

ents passar para a configuração de DSC.
Esta propriedade será criptografada.
protectedSettings.configurationUrlSasT string Especifica o token SAS para acessar a

oken URL definida por configuration.url. Esta
propriedade será criptografada.
protectedSettings.configurationDataUr string Especifica o token SAS para acessar a

lSasToken URL definida por configurationData.url.
Esta propriedade será criptografada.
ideais ao implantar uma ou mais máquinas virtuais que exigem configuração pós-implantação. Um modelo do
Resource Manager de exemplo que inclui a extensão de DSC para Windows pode ser encontrado na Galeria de
início rápido do Azure.

Pacote de extensão é baixado e implantado para esse local na VM do Azure
C:\Packages\Plugins\{Extension_Name}\{Extension_Version}
O arquivo de status de extensão contém os códigos de status de êxito/erro de subseqüentes, juntamente com o
erro detalhado e a descrição para cada execução de extensão.
C:\Packages\Plugins\{Extension_Name}\{Extension_Version}\Status\{0}.Status -> {0} being the sequence number
Logs de saída de extensão são registrados no seguinte diretório:
C:\WindowsAzure\Logs\Plugins\{Extension_Name}\{Extension_Version}

1000 Erro genérico A mensagem de erro é fornecida pela

exceção específica em logs de extensão
52 Erro de Instalação da Extensão A mensagem de erro é fornecida pela

exceção específica
1002 Erro de instalação Wmf Erro ao instalar WMF.
1004 Pacote Zip Inválido Zip inválido ; Erro ao desempacotar o

zip
1100 Erro de Argumento Indica um problema na entrada

fornecida pelo usuário. A mensagem
de erro é fornecida pela exceção
específica
Suporte
Pssar credenciais para o manipulador de extensões
DSC do Azure
Este artigo aborda a extensão Configuração de Estado Desejado (DSC) do Azure. Para obter uma visão geral do
manipulador de extensões DSC, consulte Introdução ao manipulador de extensões Configuração de Estado
Desejado do Azure.
Passar credenciais
Como parte do processo de configuração, talvez seja necessário configurar contas de usuário, acessar serviços
ou instalar um programa em um contexto de usuário. Para fazer isso, você precisa fornecer credenciais.
Você pode usar a DSC para definir as configurações parametrizadas. Em uma configuração parametrizada, as
credenciais são passadas na configuração e seguramente armazenadas em arquivos MOF. O manipulador de
extensões do Azure simplifica o gerenciamento de credenciais fornecendo gerenciamento automático de
certificados.
O seguinte script de configuração da DSC cria uma conta de usuário local com a senha especificada:
configuration Main
{
param(
[Parameter(Mandatory=$true)]
[ValidateNotNullorEmpty()]
[PSCredential]
$Credential
)
Node localhost {
User LocalUserAccount
{
Username = $Credential.UserName
Password = $Credential
Disabled = $false
Ensure = "Present"
FullName = "Local User Account"
Description = "Local User Account"
PasswordNeverExpires = $true
}
}
}
É importante incluir node localhost como parte da configuração. O manipulador de extensão procura
especificamente a instrução node localhost . Se essa instrução estiver ausente, as etapas a seguir não
funcionam. Também é importante incluir a conversão de tipo [PsCredential] . Esse tipo específico dispara a
extensão para criptografar as credenciais.
Para publicar esse script no armazenamento de blobs do Azure:
Publish-AzVMDscConfiguration -ConfigurationPath .\user_configuration.ps1
Para definir a extensão DSC do Azure e fornecer a credencial:

$configurationName = 'Main'
$configurationArguments = @{ Credential = Get-Credential }
$configurationArchive = 'user_configuration.ps1.zip'
$vm = Get-AzVM -Name 'example-1'
$vm = Set-AzVMDscExtension -VMName $vm -ConfigurationArchive $configurationArchive -ConfigurationName

$configurationName -ConfigurationArgument @configurationArguments
$vm | Update-AzVM
Como uma credencial é protegida

Executar esse código solicita uma credencial. Depois que a credencial é fornecida, ela é armazenada brevemente
na memória. Quando a credencial é publicada usando o cmdlet Set-AzVMDscExtension , ela é transmitida por
HTTPS para a VM. Na VM, o Azure armazena a credencial criptografada no disco usando o certificado local da
VM. A credencial é brevemente descriptografada na memória e, em seguida, criptografada novamente para
passá-la à DSC.
Esse processo é diferente de usar configurações seguras sem o manipulador de extensões. O ambiente do Azure
oferece uma forma de transmitir dados de configuração com segurança por meio de certificados. Ao usar o
manipulador de extensão DSC, não é necessário fornecer $Cer tificatePath ou uma entrada $Cer tificateID /
$Thumbprint em ConfigurationData .
Próximas etapas
Obtenha uma introdução ao manipulador de extensões DSC do Azure.
Examine o modelo do Azure Resource Manager para a extensão de DSC.
Para mais funcionalidade que você pode gerenciar usando o DSC do PowerShell e para obter mais recursos
de DSC, procure na Galeria do PowerShell.
Extensão de configuração de estado desejado com
os modelos do Azure Resource Manager
Este artigo descreve o modelo do Azure Resource Manager para o manipulador de extensão da Configuração de
Estado Desejado (DSC). Muitos dos exemplos usam RegistrationURL (fornecido como uma cadeia de
caracteres) e RegistrationKey (fornecido como um PSCredential para integração com a automação do Azure.
Consulte os detalhes para obtenção desses valores em Integração de computadores para gerenciamento pela
Configuração de Estado de Automação do Azure – registro seguro.
NOTE
Você pode encontrar exemplos de esquema ligeiramente diferente. A alteração no esquema ocorreu na versão de outubro
de 2016. Para obter detalhes, confira Atualizar de um formato anterior.
Exemplo de modelo para uma VM do Windows

O snippet a seguir vai na seção Recursos do modelo. A extensão de DSC herda propriedades de extensão
padrão. Para obter mais informações, consulte a classe VirtualMachineExtension.
{
"name": "[concat(parameters('VMName'), '/Microsoft.Powershell.DSC')]",
"apiVersion": "2018-06-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', parameters('VMName'))]"
],
"properties": {
"type": "DSC",
"Items": {
"registrationKeyPrivate": "[listKeys(resourceId('Microsoft.Automation/automationAccounts/',
parameters('automationAccountName')), '2018-06-30').Keys[0].value]"
}
},
"settings": {
"Properties": [
{
"Name": "RegistrationKey",
"Value": {
"UserName": "PLACEHOLDER_DONOTUSE",
"Password": "PrivateSettingsRef:registrationKeyPrivate"
},
"TypeName": "System.Management.Automation.PSCredential"
},
{
"Name": "RegistrationUrl",
"Value": "[reference(concat('Microsoft.Automation/automationAccounts/',
parameters('automationAccountName'))).registrationUrl]",
"TypeName": "System.String"
},
{
"Name": "NodeConfigurationName",
"Value": "[parameters('nodeConfigurationName')]",
}
]
}
}
}
Exemplo de modelo para conjunto de dimensionamento de máquinas

virtuais do Windows
Um nó de conjunto de dimensionamento de máquinas virtuais tem uma seção propriedades com um atributo
Vir tualMachineProfile, extensionProfile. Em extensões , adicione os detalhes para a extensão de DSC.
A extensão de DSC herda propriedades de extensão padrão. Para obter mais informações, consulte a classe
VirtualMachineScaleSetExtension.
"extensionProfile": {
"extensions": [
{
"name": "Microsoft.Powershell.DSC",
"properties": {
"type": "DSC",
"Items": {
"registrationKeyPrivate": "[listKeys(resourceId('Microsoft.Automation/automationAccounts/',
}
},
"settings": {
"Properties": [
{
"Name": "RegistrationKey",
"Value": {
"UserName": "PLACEHOLDER_DONOTUSE",
"Password": "PrivateSettingsRef:registrationKeyPrivate"
},
"TypeName": "System.Management.Automation.PSCredential"
},
{
"Name": "RegistrationUrl",
"Value": "[reference(concat('Microsoft.Automation/automationAccounts/',
},
{
"Name": "NodeConfigurationName",
"Value": "[parameters('nodeConfigurationName')]",
}
]
}
}
}
]
}
Informações de configuração detalhadas

Use o esquema a seguir na seção configurações da extensão de DSC do Azure em um modelo do Resource
Manager.
Para obter uma lista de argumentos disponíveis para o script de configuração padrão, consulte Script de
configuração padrão.
"settings": {
"wmfVersion": "latest",
"configuration": {
"url": "http://validURLToConfigLocation",
"script": "ConfigurationScript.ps1",
"function": "ConfigurationFunction"
},
"argument1": "Value1",
"argument2": "Value2"
},
"configurationData": {
"url": "https://foo.psd1"
},
"privacy": {
"dataCollection": "enable"
},
"advancedOptions": {
"downloadMappings": {
"customWmfLocation": "http://myWMFlocation"
}
}
},
},
}
},
"configurationUrlSasToken": "?g!bber1sht0k3n",
"configurationDataUrlSasToken": "?dataAcC355T0k3N"
}
Detalhes
N O M E DA P RO P RIEDA DE TYPE DESC RIÇ Ã O
settings.wmfVersion string Especifica a versão do Windows

Management Framework (WMF) que
deve ser instalada em sua VM.
Configurar essa propriedade como
latest instala a versão mais recente de
WMF. Atualmente, os únicos valores
possíveis para essa propriedade são
4.0 , 5.0 , 5.1 e o mais recente . Esses
valores possíveis estão sujeitos a
atualizações. O valor padrão é latest .
settings.configuration.url string Especifica o local da URL de onde

baixar seu arquivo .zip de configuração
DSC. Se a URL fornecida exigir um
token SAS para acesso, defina a
propriedade
protectedSettings.configurationU
rlSasToken como o valor do seu
token de SAS. Esta propriedade será
necessária se
settings.configuration.script ou
estiverem definidas. Se nenhum valor
for fornecido para essas propriedades,
a extensão chama o script de
configuração padrão para definir os
metadados do LCM (Location
Configuration Manager) e os
argumentos devem ser fornecidos.
settings.configuration.script string Especifica o nome do arquivo do script

que contém a definição de sua
configuração DSC. Esse script deve
estar na pasta raiz do arquivo .zip que
é baixado da URL especificada pela
propriedade
settings.configuration.url. Esta
propriedade é necessária se
settings.configuration.url ou
settings.configuration.script
metadados do LCM e os argumentos
devem ser fornecidos.
settings.configuration.function string Especifica o nome da configuração

DSC. A configuração que é
denominada deve estar contida no
script definido por
settings.configuration.script . Esta
propriedade será necessária se
settings.configuration.script.url
ou settings.configuration.function
metadados do LCM e os argumentos
devem ser fornecidos.
settings.configurationArguments Coleção Define os parâmetros que você deseja

passar para a configuração de DSC.
Essa propriedade não é criptografada.
settings.configurationData.url string Especifica a URL de onde baixar o

arquivo de dados de configuração
(.psd1) para usar como entrada para a
sua configuração de DSC. Se a URL
fornecida exigir um token SAS para
acesso, defina a propriedade
protectedSettings.configurationD
ataUrlSasToken como o valor do seu
token de SAS.
settings.privacy.dataCollection string Habilita ou desabilita a coleta de

telemetria. Os únicos valores possíveis
para essa propriedade são Enable ,
Disable , '' ou $null. Deixar esta
propriedade em branco ou nulo
permite telemetria. O valor padrão é ''
. Para obter mais informações, consulte
coleta de dados de extensão de DSC
do Azure.
settings.advancedOptions.downloadM Coleção Define os locais alternativos de onde

appings baixar o WMF. Para obter mais
informações, consulte extensão de DSC
do Azure 2.8 e como mapear
downloads das dependências de
extensão para seu próprio local.
protectedSettings.configurationArgum Coleção Define os parâmetros que você deseja

ents passar para a configuração de DSC.
Essa propriedade é criptografada.
protectedSettings.configurationUrlSasT string Especifica o token SAS a usar para

oken acessar a URL definida por
settings.configuration.url. Essa
propriedade é criptografada.
protectedSettings.configurationDataUr string Especifica o token SAS a usar para

lSasToken acessar a URL definida por
settings.configurationData.url.
Essa propriedade é criptografada.
Script de configuração padrão

Para obter mais informações sobre os seguintes valores, consulte Configurações Básicas do Local Configuration
Manager. Você pode usar o script de configuração padrão de extensão DSC para configurar apenas as
propriedades do LCM que são listadas na tabela a seguir.

protectedSettings.configurationArgum PSCredential Propriedade exigida. Especifica a chave

ents.RegistrationKey que é usada para um nó para registrar
com o serviço de Automação do Azure
como a senha de um objeto de
credencial do PowerShell. Esse valor
pode ser descoberto automaticamente
usando o método listkeys em relação
à conta de Automação. Veja o exemplo.
settings.configurationArguments.Regis string Propriedade exigida. Especifica a URL

trationUrl do ponto de extremidade de
Automação em que o nó tenta
registrar. Esse valor pode ser
descoberto automaticamente usando
o método de referência em relação à
conta de Automação.
settings.configurationArguments.Node string Propriedade exigida. Especifica a

ConfigurationName configuração de nó na conta de
Automação para atribuir ao nó.
settings.configurationArguments.Confi string Especifica o modo para o LCM. As

gurationMode opções válidas incluem ApplyOny ,
ApplyandMonitior e
ApplyandAutoCorrect . O valor
padrão é ApplyandMonitor .
settings.configurationArguments.Refre uint32 Especifica com que frequência o LCM

shFrequencyMins tenta verificar a conta de automação
para atualizações. O valor padrão é 30 .
O valor mínimo é 15 .
settings.configurationArguments.Confi uint32 Especifica com que frequência o LCM

gurationModeFrequencyMins valida a configuração atual. O valor
padrão é 15 . O valor mínimo é 15 .
settings.configurationArguments.Rebo booleano Especifica se um nó pode ser

otNodeIfNeeded reinicializado automaticamente se uma
operação de DSC solicitar. O valor
padrão é false .
settings.configurationArguments.Actio string Especifica o que acontece após uma

nAfterReboot reinicialização ao aplicar uma
configuração. As opções válidas são
ContinueConfiguration e
StopConfiguration . O valor padrão é
ContinueConfiguration .
settings.configurationArguments.Allow booleano Especifica se o LCM substitui os

ModuleOverwrite módulos existentes no nó. O valor
padrão é false .
settings vs.protectedSettings
Todas as configurações foram salvas em um arquivo de texto de configurações na VM. Propriedades listadas em
Configurações são propriedades públicas. Propriedades públicas não são criptografadas no arquivo de texto
de configurações. Propriedades em protectedSettings são criptografadas com um certificado e não são
mostradas em texto sem formatação no arquivo de configurações na VM.
Se a configuração precisar de credenciais, você pode incluir as credenciais em protectedSettings :
}
}
}
Exemplo de script de configuração

O exemplo a seguir mostra o comportamento padrão para a extensão de DSC, que é fornecer configurações de
metadados para o LCM e registrar com o serviço de DSC de Automação. Os argumentos de configuração são
necessários. Os argumentos de configuração são passados para o script de configuração padrão para definir
metadados do LCM.
"settings": {
"RegistrationUrl" : "[parameters('registrationUrl1')]",
"NodeConfigurationName" : "nodeConfigurationNameValue1"
}
},
"RegistrationKey": {
"userName": "NOT_USED",
"Password": "registrationKey"
}
}
}
Exemplo usando o script de configuração no Armazenamento do

Azure
O exemplo a seguir é da visão geral de manipulador de extensão de DSC. Este exemplo usa modelos do
Resource Manager, em vez de cmdlets para implantar a extensão. Salve a configuração de IisInstall.ps1, coloque-
a em um arquivo .zip (exemplo: iisinstall.zip ) e carregue-o em uma URL acessível. Este exemplo usa o
Armazenamento de Blobs do Azure, mas você pode baixar os arquivos .zip de qualquer local aleatório.
No modelo do Resource Manager, o código a seguir instrui a VM a baixar o arquivo correto e, em seguida,
executar a função apropriada do PowerShell:
"settings": {
"configuration": {
"url": "https://demo.blob.core.windows.net/iisinstall.zip",
"script": "IisInstall.ps1",
"function": "IISInstall"
}
},
"configurationUrlSasToken": "odLPL/U1p9lvcnp..."
}
Exemplo usando os valores de registro referenciados da Automação
do Azure
O exemplo a seguir obtém a RegistrationUrl e a RegistrationKey referenciando as propriedades da conta de
Automação do Azure e usando o método listkeys para recuperar a Chave Primária (0). Neste exemplo, os
parâmetros automationAccountName e NodeConfigName foram fornecidos ao modelo.
"settings": {
"RegistrationUrl" : "[reference(concat('Microsoft.Automation/automationAccounts/',
"NodeConfigurationName" : "[parameters('NodeConfigName')]"
},
"Password": "[listKeys(resourceId('Microsoft.Automation/automationAccounts/',
}
}
}
Atualizar de um formato anterior

Todas as configurações em um formato anterior da extensão (e que têm as propriedades públicas ModulesUrl ,
ModuleSource , ModuleVersion , ConfigurationFunction , SasToken ou Proper ties ) serão adaptadas
automaticamente ao formato atual da extensão. Elas são executadas como antes.
O esquema a seguir mostra como se parecia o esquema de configurações anterior:
"settings": {
"WMFVersion": "latest",
"ModulesUrl": "https://UrlToZipContainingConfigurationScript.ps1.zip",
"SasToken": "SAS Token if ModulesUrl points to private Azure Blob Storage",
"ConfigurationFunction": "ConfigurationScript.ps1\\ConfigurationFunction",
"Properties": {
"ParameterToConfigurationFunction1": "Value1",
"ParameterToConfigurationFunction2": "Value2",
"ParameterOfTypePSCredential1": {
"UserName": "UsernameValue1",
"Password": "PrivateSettingsRef:Key1"
},
"ParameterOfTypePSCredential2": {
"UserName": "UsernameValue2",
"Password": "PrivateSettingsRef:Key2"
}
}
},
"Items": {
"Key1": "PasswordValue1",
"Key2": "PasswordValue2"
},
"DataBlobUri": "https://UrlToConfigurationDataWithOptionalSasToken.psd1"
}
Veja como formato anterior se adapta ao formato atual:

N O M E DA P RO P RIEDA DE AT UA L EQ UIVA L EN T E A O ESQ UEM A A N T ERIO R
settings.wmfVersion settings.wmfVersion
settings.configuration.url settings.ModulesUrl
settings.configuration.script Primeira parte de settings.ConfigurationFunction (antes de

\\)
settings.configuration.function Segunda parte de settings.ConfigurationFunction (depois de

\\)
settings.configuration.module.name settings.ModuleSource
settings.configuration.module.version settings.ModuleVersion
settings.configurationArguments settings.Properties
settings.configurationData.url protectedSettings.DataBlobUri (sem token SAS)
settings.privacy.dataCollection settings.Privacy.dataCollection
settings.advancedOptions.downloadMappings settings.advancedOptions.downloadMappings
protectedSettings.configurationArguments protectedSettings.Properties
protectedSettings.configurationUrlSasToken settings.SasToken
protectedSettings.configurationDataUrlSasToken Token SAS de protectedSettings.DataBlobUri
Confira alguns erros que você pode encontrar e como corrigi-los.
Valores inválidos
"Privacy.dataCollection é '{0}'. Os únicos valores possíveis são '', 'Enable' e 'Disable'". "WmfVersion é '{0}'. Únicos
valores possíveis são... e 'latest'".
Problema : um valor fornecido não é permitido.
Solução : Altere o valor inválido para um valor válido. Para saber mais, consulte a tabela em Detalhes.
URL inválida
"ConfigurationData.url é '{0}'. Essa não é uma URL válida" "DataBlobUri é '{0}'. Essa não é uma URL válida"
"Configuration.url é '{0}'. Essa não é uma URL válida"
Problema : uma URL fornecida não é válida.
Solução : Verifique todas as URLs fornecidas. Certifique-se de que todas as URLs resolvem para locais válidos
que a extensão pode acessar no computador remoto.
Tipo RegistrationKey inválido
“Tipo inválido para o parâmetro RegistrationKey do tipo PSCredential.”
Problema : o valor RegistrationKey em protectedSettings.configurationArguments só pode ser fornecido como
o tipo PSCredential.
Solução : Altere a entrada protectedSettings.configurationArguments de RegistrationKey para um tipo
PSCredential usando o seguinte formato:
"Password": "RegistrationKey"
}
}
Tipo ConfigurationArgument inválido

"Tipo configurationArgument inválido {0}"
Problema : a propriedade ConfigurationArguments não pode ser resolvida para um objeto de tabela de hash .
Solução : Torne a propriedade ConfigurationArguments uma tabela de hash . Siga o formato fornecido no
exemplo anterior. Fique atento às chaves, vírgulas e aspas.
ConfigurationArguments duplicado
"Argumentos '{0}' duplicados encontrados em configurationArguments públicos e protegidos"
Problema : ConfigurationArguments nas configurações públicas e ConfigurationArguments nas configurações
protegidas têm propriedades com o mesmo nome.
Solução : Remova uma das propriedades duplicadas.
Propriedades ausentes
“settings.Configuration.function requer a especificação de settings.configuration.url ou de
settings.configuration.module”
“settings.Configuration.url requer a especificação de settings.configuration.script”
“settings.Configuration.script requer a especificação de settings.configuration.url”
“settings.Configuration.url requer a especificação de settings.configuration.function”
“protectedSettings.ConfigurationUrlSasToken requer a especificação de settings.configuration.url”
“protectedSettings.ConfigurationDataUrlSasToken requer a especificação de settings.configurationData.url”
Problema : uma propriedade definida precisa de outra propriedade, que está ausente.
Soluções :
Forneça a propriedade ausente.
Remova a propriedade que precisa da propriedade ausente.
Próximas etapas
Saiba mais sobre Uso de conjuntos de dimensionamento de máquinas virtuais com a extensão de DSC do
Azure.
Encontre mais detalhes sobre Gerenciamento de credenciais seguras do DSC.
Obtenha uma introdução ao manipulador de extensões DSC do Azure.
Gerenciar usuários administrativos, SSH e verificar
ou reparar discos em VMs Linux do usando a
extensão VMAccess com a CLI do Azure
Visão geral
O disco em sua VM do Linux está mostrando erros. De alguma forma, você redefiniu a senha raiz para sua VM
do Linux ou excluiu acidentalmente sua chave privada SSH. Se isso tiver ocorrido na época do datacenter, você
precisará ir até lá e abrir o KVM para acessar o console do servidor. Considere a Extensão VMAccess do Azure
como o comutador KVM que permite que você acesse o console para redefinir o acesso para o Linux ou para
realizar a manutenção no nível de disco.
Este artigo mostra como usar a extensão VMAccess do Azure para verificar ou reparar um disco, redefinir o
acesso do usuário, gerenciar contas de usuário administrativo ou atualizar a configuração do SSH no Linux
quando eles estão sendo executados como máquinas virtuais do Azure Resource Manager. Se precisar gerenciar
máquinas virtuais Clássicas, você poderá seguir as instruções encontradas na documentação de VM clássica.
NOTE
Se você usar a extensão VMAccess para redefinir a senha da sua VM depois de instalar a extensão de logon do AAD, será
preciso executar novamente a extensão de logon do AAD para habilitar novamente o logon do AAD para seu
computador.
Pré-requisitos
Sistema operacional
A extensão de Acesso de VM pode ser executada nessas distribuições do Linux:
Ubuntu 16.04 LTS, 14.04 LTS e 12.04 LTS
Debian Debian 7.9+, 8.2+
Red Hat RHEL 6.7+, 7.1+
Oracle Linux 6.4+, 7.0+
Suse 11 e 12
OpenSuse openSUSE Leap 42.2+
CentOS CentOS 6.3+, 7.0+
CoreOS 494.4.0+
Modos de usar a extensão VMAccess
Há duas maneiras de usar a extensão VMAccess em VMs Linux:
Use a CLI do Azure e os parâmetros necessários.
Use os arquivos JSON brutos processados pela Extensão VMAccess e depois tome atitudes em relação a eles.
Os exemplos seguintes usam comandos az vm user. Para realizar essas etapas, é preciso ter a CLI do Azure mais
recente instalada e conectada a uma conta do Azure usando az login.
Atualizar chave SSH

O exemplo a seguir atualiza a chave SSH para o usuário azureuser na VM denominada myVM :
az vm user update \
--name myVM \
--username azureuser \
OBSERVAÇÃO: O comando az vm user update acrescenta o novo texto de chave pública ao arquivo
~/.ssh/authorized_keys para o usuário administrador na VM. Isso não substitui ou remove quaisquer
chaves SSH existentes. Isso não removerá as chaves anteriores definidas no momento da implantação ou
atualizações subsequentes através da extensão VMAccess.
Redefinir senha
O exemplo a seguir redefine a senha para o usuário azureuser na VM denominada myVM :
az vm user update \
--name myVM \
--username azureuser \
--password myNewPassword
Reiniciar o SSH
O exemplo a seguir reiniciará o daemon SSH e redefine a configuração de SSH para valores padrão em uma VM
denominada myVM :
az vm user reset-ssh \
--name myVM
Criar um usuário administrativo/sudo

O exemplo a seguir cria um usuário chamado myNewUser com permissões sudo . A conta usa uma chave SSH
para autenticação na VM denominada myVM . Esse método foi projetado para ajudá-lo a recuperar o acesso a
uma VM caso as credenciais atuais sejam perdidas ou esquecidas. Como melhor prática, contas com permissões
sudo devem ser limitadas.
az vm user update \
--name myVM \
--username myNewUser \
Excluir um usuário
O exemplo a seguir exclui um usuário chamado myNewUser na VM denominada myVM :
az vm user delete \
--name myVM \
--username myNewUser
Usar arquivos JSON e a extensão VMAccess

Os exemplos a seguir usam arquivos JSON brutos. Use az vm extension set para chamar seus arquivos JSON.
Esses arquivos JSON também podem ser chamados dos modelos do Azure.
Redefinir o acesso do usuário
Se você tiver perdido o acesso à raiz em sua VM do Linux, poderá iniciar um script da VMAccess para atualizar a
senha ou a chave SSH de um usuário.
Para atualizar a chave pública SSH de um usuário, crie um arquivo chamado update_ssh_key.json e adicione as
configurações no seguinte formato. Substitua seus próprios valores para os parâmetros username e ssh_key :
{
"username":"azureuser",
"ssh_key":"ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAACAQCZ3S7gGp3rcbKmG2Y4vGZFMuMZCwoUzZNGxxxxxx2XV2x9FfAhy8iGD+lF8UdjFX3t5ebMm6BnnMh8
fHwkTRdOt3LDQq8o8ElTBrZaKPxZN2thMZnODs5Hlemb2UX0oRIGRcvWqsd4oJmxsXa/Si98Wa6RHWbc9QZhw80KAcOVhmndZAZAGR+Wq6ys
lNo5TMOr1/ZyQAook5C4FtcSGn3Y+WczaoGWIxG4ZaWk128g79VIeJcIQqOjPodHvQAhll7qDlItVvBfMOben3GyhYTm7k4YwlEdkONm4yV/
UIW0la1rmyztSBQIm9sZmSq44XXgjVmDHNF8UfCZ1ToE4r2SdwTmZv00T2i5faeYnHzxiLPA3Enub7xxxxxxwFArnqad7MO1SY1kLemhX9eF
jLWN4mJe56Fu4NiWJkR9APSZQrYeKaqru4KUC68QpVasNJHbuxPSf/PcjF3cjO1+X+4x6L1H5HTPuqUkyZGgDO4ynUHbko4dhlanALcriF7t
IfQR9i2r2xOyv5gxJEW/zztGqWma/d4rBoPjnf6tO7rLFHXMt/DVTkAfn5wxxtLDwkn5FMyvThRmex3BDf0gujoI1y6cOWLe9Y5geNX0oj+M
Xg/W0cXAtzSFocstV1PoVqy883hNoeQZ3mIGB3Q0rIUm5d9MA2bMMt31m1g3Sin6EQ== azureuser@myVM"
}
Execute o script VMAccess com:
--vm-name myVM \
--name VMAccessForLinux \
--version 1.4 \
--protected-settings update_ssh_key.json
Para redefinir uma senha de usuário, crie um arquivo chamado reset_user_password.json e adicione
configurações no formato a seguir. Substitua seus próprios valores para os parâmetros username e password :
{
"username":"azureuser",
"password":"myNewPassword"
}
--vm-name myVM \
--version 1.4 \
--protected-settings reset_user_password.json
Reiniciar o SSH
Para reiniciar o daemon SSH e redefinir a configuração de SSH para valores padrão, crie um arquivo chamado
reset_sshd.json . Adicione o seguinte conteúdo:
{
"reset_ssh": true
}
--vm-name myVM \
--version 1.4 \
--protected-settings reset_sshd.json
Gerenciar usuários administrativos

Para criar um usuário com permissões sudo que usa uma chave SSH para autenticação, crie um arquivo
chamado create_new_user.json e adicione as configurações no formato a seguir. Substitua os valores dos
parâmetros username e ssh_key pelos seus próprios. Esse método foi projetado para ajudá-lo a recuperar o
acesso a uma VM caso as credenciais atuais sejam perdidas ou esquecidas. Como melhor prática, contas com
permissões sudo devem ser limitadas.
{
"username":"myNewUser",
"ssh_key":"ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAACAQCZ3S7gGp3rcbKmG2Y4vGZFMuMZCwoUzZNG1vHY7P2XV2x9FfAhy8iGD+lF8UdjFX3t5ebMm6BnnMh8
fHwkTRdOt3LDQq8o8ElTBrZaKPxZN2thMZnODs5Hlemb2UX0oRIGRcvWqsd4oJmxsXa/Si98Wa6RHWbc9QZhw80KAcOVhmndZAZAGR+Wq6ys
lNo5TMOr1/ZyQAook5C4FtcSGn3Y+WczaoGWIxG4ZaWk128g79VIeJcIQqOjPodHvQAhll7qDlItVvBfMOben3GyhYTm7k4YwlEdkONm4yV/
UIW0la1rmyztSBQIm9sZmSq44XXgjVmDHNF8UfCZ1ToE4r2SdwTmZv00T2i5faeYnHzxiLPA3Enub7iUo5IdwFArnqad7MO1SY1kLemhX9eF
jLWN4mJe56Fu4NiWJkR9APSZQrYeKaqru4KUC68QpVasNJHbuxPSf/PcjF3cjO1+X+4x6L1H5HTPuqUkyZGgDO4ynUHbko4dhlanALcriF7t
IfQR9i2r2xOyv5gxJEW/zztGqWma/d4rBoPjnf6tO7rLFHXMt/DVTkAfn5woYtLDwkn5FMyvThRmex3BDf0gujoI1y6cOWLe9Y5geNX0oj+M
Xg/W0cXAtzSFocstV1PoVqy883hNoeQZ3mIGB3Q0rIUm5d9MA2bMMt31m1g3Sin6EQ== myNewUser@myVM",
"password":"myNewUserPassword"
}

--vm-name myVM \
--version 1.4 \
--protected-settings create_new_user.json
Para excluir um usuário, crie um arquivo chamado delete_user.json e adicione o conteúdo a seguir. Substitua
seu próprio valor para o parâmetro remove_user :
{
"remove_user":"myNewUser"
}
--vm-name myVM \
--version 1.4 \
--protected-settings delete_user.json
Verificar ou reparar o disco

Usar o VMAccess você pode verificar e reparar um disco que você adicionou à VM Linux.
Para verificar e reparar o disco, crie um arquivo chamado disk_check_repair.json e adicione as configurações
no seguinte formato. Substitua seu próprio valor para o nome do repair_disk :
{
"check_disk": "true",
"repair_disk": "true, mydiskname"
}
--vm-name myVM \
--version 1.4 \
--protected-settings disk_check_repair.json

Suporte
Extensão para VM do Chef para Linux e Windows
O Chef Software fornece uma plataforma de automação DevOps para Linux e Windows que permite o
gerenciamento das configurações físicas e virtuais do servidor. A extensão para VM do Chef é uma extensão que
habilita o Chef em máquinas virtuais.
Pré-requisitos
Sistema operacional
Há suporte para a extensão para VM do Chef em todos os sistemas operacionais com suporte para a extensão
no Azure.
A extensão para VM do Chef exige que a máquina virtual de destino esteja conectada à Internet a fim de
recuperar o payload do cliente do Chef da CDN (rede de distribuição de conteúdo).
O JSON a seguir mostra o esquema para a extensão para VM do Chef. A extensão exige, no mínimo, a URL do
servidor do Chef, o nome do cliente de validação e a chave de validação para o servidor do Chef; esses valores
podem ser encontrados no arquivo knife.rb no starter-kit.zip cujo download é feito quando você instala o
Chef Automate ou um servidor do Chef independente. Como a chave de validação deve ser tratada como dados
confidenciais, é necessário configurá-la sob o elemento protectedSettings , o que significa que ela só será
descriptografada na máquina virtual de destino.
{
"name": "[concat(variables('vmName'),'/', parameters('chef_vm_extension_type'))]",
"apiVersion": "2017-12-01",
"dependsOn": [
],
"properties": {
"publisher": "Chef.Bootstrap.WindowsAzure",
"type": "[parameters('chef_vm_extension_type')]",
"settings": {
"bootstrap_options": {
"chef_server_url": "[parameters('chef_server_url')]",
"validation_client_name": "[parameters('chef_validation_client_name')]"
},
"runlist": "[parameters('chef_runlist')]"
},
"validation_key": "[parameters('chef_validation_key')]"
}
}
}
Valores de propriedades principais

apiVersion 2017-12-01 string (date)
editor Chef.Bootstrap.WindowsAzure string
type LinuxChefClient (Linux), string

ChefClient (Windows)
typeHandlerVersion 1210.13 string (double)
Configurações
NOME VA LO R/ EXEM P LO T IP O DE DA DO S N EC ESSÁ RIO ?
settings/bootstrap_options/ string (url)

https://api.chef.io/organizations/myorg S
chef_server_url
settings/bootstrap_options/ myorg-validator string S

validation_client_name
settings/runlist recipe[mycookbook::default] string S
Configurações protegidas
NOME EXEM P LO T IP O DE DA DO S N EC ESSÁ RIO ?
protectedSettings/validation -----BEGIN RSA PRIVATE string S

_key KEY-----\nKEYDATA\n---
--END RSA PRIVATE KEY-
----
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. Modelos podem
ser usados para implantar uma ou mais máquinas virtuais, instalar o cliente do Chef, conectar-se ao servidor do
Chef e executar a configuração inicial no servidor, conforme definido pela lista de execução
Um modelo do Resource Manager de exemplo que inclui a extensão de VM chefe pode ser encontrado na
Galeria de início rápido do Azure.

A CLI do Azure pode ser usada para implantar a extensão para VM do Chef em uma VM existente. Substitua a
validation_key pelo conteúdo da sua chave de validação (esse arquivo como uma extensão .pem ). Substitua
validation_client_name , chef_ser ver_url e run_list pelos valores do arquivo knife.rb no seu kit de início.
--vm-name myExistingVM \
--name LinuxChefClient \
--publisher Chef.Bootstrap.WindowsAzure \
--version 1210.13 --protected-settings '{"validation_key": "<validation_key>"}' \
--settings '{ "bootstrap_options": { "chef_server_url": "<chef_server_url>", "validation_client_name": "
<validation_client_name>" }, "runlist": "<run_list>" }'

az vm extension list --resource-group myResourceGroup --vm-name myExistingVM -o table

Linux
/var/lib/waagent/Chef.Bootstrap.WindowsAzure.LinuxChefClient
Windows
C:\Packages\Plugins\Chef.Bootstrap.WindowsAzure.ChefClient\

51 Não há suporte para essa extensão no

sistema operacional da VM
Informações adicionais sobre solução de problemas podem ser encontradas no Leiame da extensão para VM do
Chef.
NOTE
Para qualquer outra coisa diretamente relacionada ao chefe, entre em contato com o suporte do chefe.
Próximas etapas
Extensão do Agente Linux de Stackify Retrace
Visão geral
O Stackify fornece produtos que acompanham os detalhes sobre o seu aplicativo para ajudar a localizar e
corrigir problemas rapidamente. Para as equipes de desenvolvedores, o Retrace é uma potência de super de
desempenho do aplicativo totalmente integrada, com vários ambientes. Ele combina várias ferramentas que
cada equipe de desenvolvimento precisa.
O Retrace é a ÚNICA ferramenta que fornece todos os recursos a seguir em todos os ambientes em uma única
plataforma.
Gerenciamento de desempenho do aplicativo (APM)
Aplicativo e registro de log do servidor
Monitoramento e controle de erro
Servidor, aplicativo e métricas personalizadas
Sobre a Extensão do Agente Linux de Stackify
Esta extensão fornece um caminho de instalação para o agente Linux para Retrace.
Pré-requisitos
Sistema operacional
O agente do Retrace pode ser executada com essas distribuições Linux
Ubuntu 16.04 LTS, 14.04 LTS, 16.10 e 17.04
Debian 7.9+ e 8.2+, 9
Red Hat 7.9+ and 8.2+, 9
CentOS 6.3+, 7.0+

A extensão do Agente do Stackify para Linux requer que a máquina virtual de destino esteja conectada à
Internet.
Você talvez precise ajustar sua configuração de rede para permitir conexões com Stackify, consulte
https://support.stackify.com/hc/en-us/articles/207891903-Adding-Exceptions-to-a-Firewall.
O JSON a seguir mostra o esquema para a extensão do Agente Stackify Retrace. A extensão requer environment
e activationKey .
{
"name": "StackifyExtension",
"dependsOn": [
"[resourceId('Microsoft.Compute/virtualMachines',variables('vmName'))]"
],
"properties": {
"publisher": "Stackify.LinuxAgent.Extension",
"type": "StackifyLinuxAgentExtension",
"settings": {
"environment": "myEnvironment"
},
"activationKey": "myActivationKey"
}
}
}
extensão do Agente do Linux para o Stackify Retrace durante uma implantação de modelo do Azure Resource
Manager.
O JSON para uma extensão da máquina virtual pode ser aninhado dentro do recurso de máquina virtual ou
localizado no nível de raiz ou superior de um modelo JSON do Resource Manager. O posicionamento do JSON
afeta o valor do tipo e nome do recurso. Para obter mais informações, consulte Definir o nome e o tipo de
recursos filho.
O exemplo a seguir pressupõe que a extensão do Linux Stackify Retrace está aninhada dentro do recurso de
máquina virtual. Ao aninhar o recurso de extensão, o JSON é colocado no objeto “recursos”: [] objeto da
máquina virtual.
A extensão requer environment e activationKey .
{
"name": "StackifyExtension",
"dependsOn": [
"[resourceId('Microsoft.Compute/virtualMachines',variables('vmName'))]"
],
"properties": {
"settings": {
},
}
}
}
{
"name": "<parentVmResource>/StackifyExtension",
"dependsOn": [
],
"properties": {
"settings": {
},
}
}
}
O comando Set-AzVMExtension pode ser usado para implantar a extensão da máquina virtual do agente Linux
do Stackify Retrace para uma máquina virtual existente. Antes de executar o comando, as configurações públicas
e privadas precisam ser armazenadas em uma tabela de hash do PowerShell.
$PublicSettings = @{"environment" = "myEnvironment"}

$ProtectedSettings = @{"activationKey" = "myActivationKey"}
Set-AzVMExtension -ExtensionName "Stackify.LinuxAgent.Extension" `

-VMName "myVM" `
-Publisher "Stackify.LinuxAgent.Extension" `
-ExtensionType "StackifyLinuxAgentExtension" `
-Settings $PublicSettings `
-ProtectedSettings $ProtectedSettings `
-Location WestUS `

A ferramenta da CLI do Azure pode ser usada para implantar a extensão da máquina virtual do Agente Linux do
Stackify Retrace.
az vm extension set --publisher 'Stackify.LinuxAgent.Extension' --version 1.0 --name

'StackifyLinuxAgentExtension' --protected-settings '{"activationKey":"myActivationKey"}' --settings
'{"environment":"myEnvironment"}' --resource-group 'myResourceGroup' --vm-name 'myVmName'

Códigos do Erro
10 Erro de instalação wget é obrigatório
20 Erro de instalação phython é obrigatório.
30 Erro de instalação sudo é obrigatório
40 Erro de instalação activationKey é obrigatório
51 Erro de instalação Distribuição de sistema operacional

não compatível
60 Erro de instalação ambiente é obrigatório
70 Erro de instalação Desconhecido
80 Ero de habilitação Falha na configuração de serviço
90 Ero de habilitação Falha na configuração de serviço
100 Desabilitar o erro Falha na interrupção do serviço
110 Desabilitar o erro Falha na interrupção do serviço
120 Erro de desinstalação Falha na interrupção do serviço
Se precisar de mais ajuda, entre em contato com a Stackify em https://support.stackify.com.

Como instalar e configurar o Symantec Endpoint
Protection em uma VM do Windows
IMPORTANT
O Azure tem dois modelos de implantação diferentes para criar e trabalhar com recursos: Resource Manager e
Clássico. Este artigo aborda o uso do modelo de implantação Clássica. A Microsoft recomenda que a maioria
das implantações novas use o modelo do Gerenciador de Recursos.
Este artigo mostra como instalar e configurar o cliente do Symantec Endpoint Protection em uma VM (máquina
virtual) existente com o Windows Server. Este cliente completo inclui serviços como proteção contra vírus e
spyware, firewall e prevenção contra intrusão. O cliente é instalado como uma extensão de segurança usando-se
o Agente de VM.
Se tiver uma assinatura da Symantec para uma solução local, você poderá usá-la para proteger as máquinas
virtuais do Azure. Se ainda não for cliente, você poderá se inscrever em uma assinatura de avaliação. Para obter
mais informações sobre essa solução, consulte Symantec Endpoint Protection na plataforma Azure da Microsoft.
Essa página também fornece links para informações de licenciamento e instruções para instalar o cliente se você
já for um cliente da Symantec.
Instalar o Symantec Endpoint Protection em uma VM existente

Antes de começar, você precisa do seguinte:
O módulo Azure PowerShell, versão 0.8.2 ou mais recente, em seu computador de trabalho. Você pode
verificar a versão do PowerShell do Azure instalado com o comando Get-Module azure | format-table
version . Para obter instruções e um link para a versão mais recente, veja Como instalar e configurar o Azure
PowerShell. Faça logon em sua assinatura do Azure usando Add-AzureAccount .
O Agente de VM em execução na Máquina Virtual do Azure.
Primeiro, verifique se o Agente de VM já está instalado na máquina virtual. Preencha o nome do serviço de
nuvem e o nome da máquina virtual e, em seguida, execute os seguintes comandos em um prompt de comando
do Azure PowerShell com nível de administrador. Substitua tudo entre aspas, incluindo os caracteres < e >.
TIP
Se você não souber o nome da máquina virtual e do serviço de nuvem, execute Get-AzureVM para listar os nomes de
todas as máquinas virtuais em sua assinatura atual.
$CSName = "<cloud service name>"
$VMName = "<virtual machine name>"
$vm = Get-AzureVM -ServiceName $CSName -Name $VMName
write-host $vm.VM.ProvisionGuestAgent
Se o comando write-host exibir True , o agente de VM está instalado. Se ele exibir False , veja as instruções e
um link para download na postagem do blog do Azure Agente de VM e Extensões Parte 2.
Se o Agente de VM Agent estiver instalado, execute estes comandos para instalar o agente Symantec Endpoint
Protection.
$Agent = Get-AzureVMAvailableExtension -Publisher Symantec -ExtensionName SymantecEndpointProtection
Set-AzureVMExtension -Publisher Symantec –Version $Agent.Version -ExtensionName SymantecEndpointProtection \

-VM $vm | Update-AzureVM
Para verificar se a extensão de segurança Symantec foi instalada e está atualizada:

1. Faça logon na máquina virtual. Para obter instruções, veja Como fazer logon em uma máquina virtual que
executa o Windows Server.
2. Para Windows Server 2008 R2, clique em Iniciar > Symantec Endpoint Protection . Para o Windows
Server 2012 ou Windows Server 2012 R2, na tela inicial, digite Symantec e, em seguida, clique em
Symantec Endpoint Protection .
3. Na guia Status da janela de Status-Symantec Endpoint Protection , aplique atualizações ou reinicie se
necessário.
Recursos adicionais
Como fazer logon em uma máquina virtual que executa o Windows Server
Recursos e extensões de VM do Azure
Usar a política do Azure para restringir a instalação
de extensões nas VMs do Linux
Se você quiser impedir o uso ou a instalação de determinadas extensões em suas VMs do Linux, poderá criar
uma definição de Azure Policy usando a CLI para restringir as extensões para VMs em um grupo de recursos.
Este tutorial usa o CLI dentro da Cloud Shell do Azure, que é constantemente atualizada para a versão mais
recente. Se você deseja executar a CLI do Azure localmente, você precisa instalar a versão 2.0.26 ou posterior.
Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar, consulte Instalar a CLI do
Azure.
Criar um arquivo de regras

Para restringir quais extensões podem ser instaladas, você precisa ter uma regra para fornecer a lógica para
identificar a extensão.
Este exemplo mostra como negar as extensões de instalação publicadas por 'Microsoft.OSTCExtensions' criando
um arquivo de regras na Cloud Shell do Azure, mas se você estiver trabalhando localmente na CLI, você
também pode criar um arquivo local e substituir o caminho (~/clouddrive) pelo caminho para o arquivo local no
seu computador.
Em uma Cloud Shel de bash, digite:
vim ~/clouddrive/azurepolicy.rules.json
Copie e cole o seguinte .json no arquivo.
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.OSTCExtensions/virtualMachines/extensions"
},
{
"field": "Microsoft.OSTCExtensions/virtualMachines/extensions/publisher",
"equals": "Microsoft.OSTCExtensions"
},
{
"field": "Microsoft.OSTCExtensions/virtualMachines/extensions/type",
"in": "[parameters('notAllowedExtensions')]"
}
]
},
"then": {
"effect": "deny"
}
}
Quando terminar, aperte Esc e, em seguida, digite : wq para salvar e fechar o arquivo.
Criar um arquivo de parâmetros

Você também precisa de um arquivo de parâmetros que cria uma estrutura para usar para passar uma lista de
extensões para bloquear.
Este exemplo mostra como criar um arquivo de parâmetros para VMs do Linux na Cloud Shell, mas se você
estiver trabalhando localmente na CLI, você também pode criar um arquivo local e substituir o caminho
(~/clouddrive) pelo caminho para o arquivo local no seu computador.
Na Cloud Shel de bash, digite:
vim ~/clouddrive/azurepolicy.parameters.json
{
"notAllowedExtensions": {
"type": "Array",
"metadata": {
"description": "The list of extensions that will be denied. Example: CustomScriptForLinux,
VMAccessForLinux etc.",
"displayName": "Denied extension"
}
}
}
Quando terminar, aperte Esc e, em seguida, digite : wq para salvar e fechar o arquivo.
Criar a política
Uma definição de política é um objeto usado para armazenar a configuração que você deseja usar. A definição
de política usa os arquivos de regras e parâmetros para definir a política. Criar a definição de política usando
criar definição de política az.
Neste exemplo, os parâmetros e as regras de política são os arquivos criados e armazenados como arquivos.
.json na sua cloud shell.
az policy definition create \

--name 'not-allowed-vmextension-linux' \
--display-name 'Block VM Extensions' \
--description 'This policy governs which VM extensions that are blocked.' \
--rules '~/clouddrive/azurepolicy.rules.json' \
--params '~/clouddrive/azurepolicy.parameters.json' \
--mode All
Atribuir a política
Este exemplo atribui a política a um grupo de recursos usandocriar atribuição da política az. Qualquer VM criada
no grupo de recursos myResourceGroup não será capaz de instalar o Acesso VM do LInux ou as extensões de
Scrip personalizadas para o Linux. O grupo de recursos deve existir antes que você possa atribuir a política.
Use lista de contas az para obter sua ID de assinatura para usar daquele no exemplo.
az policy assignment create \
--name 'not-allowed-vmextension-linux' \
--scope /subscriptions/<subscription Id>/resourceGroups/myResourceGroup \
--policy "not-allowed-vmextension-linux" \
--params '{
"value": [
"VMAccessForLinux",
"CustomScriptForLinux"
]
}
}'
Testar a política
Teste a política criando uma nova VM e tente adicionar um novo usuário.
az vm create \
--name myVM \
--image UbuntuLTS \
--generate-ssh-keys
Tente criar um novo usuário chamado myNewUser usando a extensão de acesso da VM.
az vm user update \
--name myVM \
--username myNewUser \
--password 'mynewuserpwd123!'
Remover a atribuição
az policy assignment delete --name 'not-allowed-vmextension-linux' --resource-group myResourceGroup
Remover a política
az policy definition delete --name 'not-allowed-vmextension-linux'
Próximas etapas
Para saber mais, veja Azure Policy.
Usar a Azure Policy para restringir a instalação de
extensões nas VMs do Windows
Se você quiser impedir o uso ou a instalação de determinadas extensões em suas VMs do Windows, poderá
criar uma definição de Azure Policy usando o PowerShell para restringir as extensões para VMs em um grupo de
recursos.
Este tutorial usa o Azure PowerShell na Cloud Shell, que é constantemente atualizada para a versão mais
recente.
Criar um arquivo de regras

Para restringir quais extensões podem ser instaladas, você precisa ter uma regra para fornecer a lógica para
identificar a extensão.
Este exemplo mostra como negar extensões publicadas por 'Microsoft. Compute' criando um arquivo de regras
na Cloud Shell do Azure, mas se você estiver trabalhando localmente no PowerShell, você também pode criar
um arquivo local e substituir o caminho ($home/clouddrive) pelo caminho para o arquivo local no seu
computador.
Em um Cloud Shell, digite:
nano $home/clouddrive/rules.json
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines/extensions"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/publisher",
"equals": "Microsoft.Compute"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/type",
"in": "[parameters('notAllowedExtensions')]"
}
]
},
"then": {
"effect": "deny"
}
}
Quando terminar, pressione o Ctrl + O e Enter para salvar o arquivo. Aperte Ctrl + X para fechar o arquivo e
saia.
Criar um arquivo de parâmetros

Você também precisa de um arquivo de parâmetros que cria uma estrutura para usar para passar uma lista de
extensões para bloquear.
Este exemplo mostra como criar um arquivo de parâmetros para VMs no Cloud Shell, mas se você estiver
trabalhando localmente no PowerShell, você também pode criar um arquivo local e substituir o caminho
($home/clouddrive) pelo caminho para o arquivo local no seu computador.
Em um Cloud Shell, digite:
nano $home/clouddrive/parameters.json
{
"type": "Array",
"metadata": {
"description": "The list of extensions that will be denied.",
"displayName": "Denied extension"
}
}
}
Quando terminar, pressione o Ctrl + O e Enter para salvar o arquivo. Aperte Ctrl + X para fechar o arquivo e
saia.
Criar a política
Uma definição de política é um objeto usado para armazenar a configuração que você deseja usar. A definição
de política usa os arquivos de regras e parâmetros para definir a política. Crie uma definição de política usando
o cmdlet New-AzPolicyDefinition.
Os parâmetros e as regras de política são os arquivos criados e armazenados como arquivos. .json no seu cloud
shell.
$definition = New-AzPolicyDefinition `
-Name "not-allowed-vmextension-windows" `
-DisplayName "Not allowed VM Extensions" `
-description "This policy governs which VM extensions that are explicitly denied." `
-Policy 'C:\Users\ContainerAdministrator\clouddrive\rules.json' `
-Parameter 'C:\Users\ContainerAdministrator\clouddrive\parameters.json'
Atribuir a política
Este exemplo atribui a política a um grupo de recursos usando New-AzPolicyAssignment. Qualquer VM criada
no grupo de recursos myResourceGroup não será capaz de instalar as extensões do agente de VM de acesso
ou Script personalizado.
Use o cmdlet do Get-AzSubscription | Format-Table para obter sua ID de assinatura para usar no lugar no
exemplo.
$scope = "/subscriptions/<subscription id>/resourceGroups/myResourceGroup"
$assignment = New-AzPolicyAssignment `
-Name "not-allowed-vmextension-windows" `
-Scope $scope `
-PolicyDefinition $definition `
-PolicyParameter '{
"value": [
"VMAccessAgent",
"CustomScriptExtension"
]
}
}'
$assignment
Testar a política
Para testar a política, tente usar a extensão de acesso da VM. O seguinte deve falhar com a mensagem "Set-
AzVMAccessExtension: o recurso ' myVMAccess ' não foi permitido pela política."
Set-AzVMAccessExtension `
-VMName "myVM" `
-Name "myVMAccess" `
-Location EastUS
No portal, a alteração da senha deve falhar com "A implantação do modelo falhou por causa de violação de
política". .
Remover a atribuição
Remove-AzPolicyAssignment -Name not-allowed-vmextension-windows -Scope $scope
Remover a política
Remove-AzPolicyDefinition -Name not-allowed-vmextension-windows
Próximas etapas
Para saber mais, veja Azure Policy.
Como atualizar o Agente Linux do Azure em uma
VM
Para atualizar seu agente Linux do Azure em uma VM do Linux no Azure, você já deve ter:
uma VM do Linux em execução no Azure.
uma conexão com essa VM do Linux usando o SSH.
Primeiro, você sempre deve verificar um pacote no repositório de distribuição de Linux. É possível que o pacote
disponível não seja a versão mais recente, no entanto, habilitar a atualização automática garantirá que o Agente
do Linux sempre obterá a atualização mais recente. Se você tiver problemas de instalação a partir dos
gerenciadores de pacotes, procure o suporte do fornecedor de distribuição.
NOTE
Para obter mais informações, consulte distribuições do Linux endossadas no Azure
Verifique o Suporte mínimo da versão para agentes de máquina virtual no Azure antes de continuar.
Ubuntu
Verificar a versão atual do pacote
apt list --installed | grep walinuxagent
Cache do pacote de atualização
sudo apt-get -qq update
Instalar a versão mais recente do pacote
sudo apt-get install walinuxagent
Verifique se a atualização automática está habilitada. Primeiro, verifique se está habilitada:
cat /etc/waagent.conf
Localize 'AutoUpdate.Enabled'. Se você vir esta saída, ela estará habilitada:
# AutoUpdate.Enabled=y
Para habilitar a execução:
sudo sed -i 's/# AutoUpdate.Enabled=n/AutoUpdate.Enabled=y/g' /etc/waagent.conf

Reiniciar o serviço waagengt para 14, 4
initctl restart walinuxagent
Reiniciar o serviço waagent para 16, 4/17, 4
systemctl restart walinuxagent.service
Red Hat / CentOS

RHEL/CentOS 6
sudo yum list WALinuxAgent
Verificar as atualizações disponíveis
sudo yum check-update WALinuxAgent
sudo yum install WALinuxAgent
Verificar se a atualização automática está habilitada

Primeiro, verifique se está habilitada:
sudo sed -i 's/\# AutoUpdate.Enabled=y/AutoUpdate.Enabled=y/g' /etc/waagent.conf
Reinicie o serviço do waagent
sudo service waagent restart
RHEL/CentOS 7
sudo yum list WALinuxAgent

sudo yum check-update WALinuxAgent
sudo systemctl restart waagent.service
SUSE SLES
SUSE SLES 11 SP4
zypper info python-azure-agent
Verifique as atualizações disponíveis. A saída acima mostrará se o pacote está atualizado.

sudo zypper install python-azure-agent

sudo /etc/init.d/waagent restart
SUSE SLES 12 SP2

zypper info python-azure-agent

A saída acima mostrará se o pacote está atualizado.
sudo zypper install python-azure-agent

sudo systemctl restart waagent.service
Debian
Debian 7 "Jesse"/Debian 7 "Stretch"
dpkg -l | grep waagent

sudo apt-get install waagent
Habilitar atualização automática do agente esta versão do Debian não tem uma versão >= 2.0.16, portanto, o
AutoUpdate não está disponível para ele. A saída do comando acima mostrará se o pacote está atualizado.
Debian 8 "Jessie"/Debian 9 "Stretch"
apt list --installed | grep waagent
sudo apt-get install waagent
Verifique se a atualização automática está habilitada primeiro, verifique se ela está habilitada:

Restart the waagent service
sudo systemctl restart walinuxagent.service
Oracle Linux 6 e Oracle Linux 7

Para Oracle Linux, verifique se o repositório Addons está habilitado. Escolha editar o arquivo
/etc/yum.repos.d/public-yum-ol6.repo (Oracle Linux 6) ou /etc/yum.repos.d/public-yum-ol7.repo (Oracle Linux) e
altere a linha enabled=0 para enabled=1 em [ol6_addons] ou [ol7_addons] nesse arquivo.
Em seguida, para instalar a versão mais recente do agente Linux do Azure e digite:
Caso você não encontre o repositório de complementos, basta adicionar essas linhas no final do arquivo .repo
de acordo com sua versão do Oracle Linux:
Para máquinas virtuais do Oracle Linux 6:
[ol6_addons]
name=Add-Ons for Oracle Linux $releasever ($basearch)
baseurl=https://public-yum.oracle.com/repo/OracleLinux/OL6/addons/x86_64
gpgkey=https://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6
gpgcheck=1
enabled=1
Para máquinas virtuais do Oracle Linux 7:
[ol7_addons]
name=Oracle Linux $releasever Add ons ($basearch)
baseurl=http://public-yum.oracle.com/repo/OracleLinux/OL7/addons/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1
Em seguida, digite:
sudo yum update WALinuxAgent
Normalmente, isso é tudo de que você precisa. Porém, se por algum motivo for necessário instalá-lo no
https://github.com diretamente, use as etapas a seguir.
Atualizar o Agente do Linux quando não existir qualquer pacote de

agente para distribuição
Instale o wget (existem algumas distribuições que não o instalam por padrão, como Red Hat, CentOS e Oracle
Linux versões 6.4 e 6.5) digitando sudo yum install wget na linha de comando.
1. Baixar a última versão
Abra a versão do Agente Linux do Azure no GitHub em uma página da Web e encontre o número de versão
mais recente. (Você pode localizar sua versão atual digitando waagent --version .)
Para a versão 2.2. x ou posterior, digite:
wget https://github.com/Azure/WALinuxAgent/archive/v2.2.x.zip
unzip v2.2.x.zip
cd WALinuxAgent-2.2.x
A linha a seguir usa a versão 2.2.0 como exemplo:
wget https://github.com/Azure/WALinuxAgent/archive/v2.2.14.zip
unzip v2.2.14.zip
cd WALinuxAgent-2.2.14
2. instalar o agente Linux do Azure

Para a versão 2.2. x, use: Talvez seja necessário instalar o pacote setuptools primeiro--veja aqui. Em seguida,
execute:
sudo python setup.py install

3. Reinicie o serviço waagent

Para a maioria das distribuições do Linux:
sudo service waagent restart
Para o Ubuntu, use:
sudo service walinuxagent restart
Para o CoreOS, use:
sudo systemctl restart waagent
4. Confirme a versão do agente Linux do Azure
waagent -version
Para o CoreOS, o comando acima pode não funcionar.

Você verá que a versão do Agente Linux do Azure foi atualizada para a nova versão.
Para obter mais informações sobre o Agente Linux do Azure, consulte Azure Linux Agent README(LEIAME do
Agente Linux do Azure).
Exportar Grupos de Recursos que contêm extensões
de VM
Os Grupos de Recursos do Azure podem ser exportados para um novo modelo do Resource Manager que,
depois, pode ser reimplantado. O processo de exportação interpreta os recursos existentes e cria um modelo do
Resource Manager que, quando implantado, resulta em um Grupo de Recursos semelhante. Ao usar a opção de
exportação do Grupo de Recursos em um Grupo de Recursos que contém extensões da máquina virtual, vários
itens devem ser considerados, como a compatibilidade da extensão e configurações protegidas.
Este documento detalha como o processo de exportação do Grupo de Recursos funciona com relação às
extensões da máquina virtual, incluindo uma lista de extensões com suporte e detalhes sobre a manipulação de
dados protegidos.
Extensões da máquina virtual com suporte

Há muitas extensões da máquina virtual disponíveis. Nem todas as extensões podem ser exportadas para um
modelo do Resource Manager usando o recurso "Script de Automação". Se não houver suporte para uma
extensão da máquina virtual, será necessário colocá-la manualmente de volta no modelo exportado.
As extensões a seguir podem ser exportadas com o recurso de script de automação.
Backup do Acronis, Acronis de backup do Linux, BG info, BMC CTM Agent Linux, BMC CTM Agent Windows,
chefe Client, script personalizado, extensão de script personalizado, script personalizado para Linux, Datadog
Linux Agent, Datadog Windows Agent, extensão do Docker, extensão de DSC, dynaTrace Linux, dynaTrace
Windows, HPE Security Application defender, o antimalware de IaaS, diagnóstico de IaaS, cliente do Azure
chefe, diagnóstico do Linux, patch do so para Linux, agente Puppet, site 24x7 , Site 24x7 Linux Server, local
24x7 Windows Server, Trend Micro DSA, Trend Micro DSA Linux, acesso à VM para Linux, acesso à VM para
Linux, instantâneo de VM, instantâneo de VM Linux
Exportar o Grupo de Recursos

Para exportar um Grupo de Recursos em um modelo reutilizável, execute as seguintes etapas:
1. Entre no Portal do Azure
2. No menu Hub, clique em Grupos de Recursos
3. Selecione o grupo de recursos de destino na lista
4. Na folha Grupo de Recursos, clique em Script de Automação
O script de automação do Azure Resource Manager produz um modelo do Resource Manager, um arquivo de
parâmetros e vários exemplos de scripts de implantação, como o PowerShell e a CLI do Azure. Neste ponto, o
modelo exportado pode ser baixado usando o botão de download, adicionado como um novo modelo à
biblioteca de modelos ou reimplantado usando o botão implantar.
Definir as configurações protegidas

Muitas extensões da máquina virtual do Azure incluem uma definição de configurações protegidas que
criptografa dados confidenciais, como credenciais e cadeias de configuração. As configurações protegidas não
são exportadas com o script de automação. Se for necessário, as configurações protegidas precisam ser
reinseridas no modelo exportado.
Etapa 1: Remover o parâmetro de modelo
Após a exportação do Grupo de Recursos, um único parâmetro de modelo é criado para fornecer um valor às
configurações protegidas exportadas. Esse parâmetro pode ser removido. Para remover o parâmetro, examine a
lista de parâmetros e exclua o parâmetro semelhante a este exemplo de JSON.
"extensions_extensionname_protectedSettings": {
"defaultValue": null,
"type": "SecureObject"
}
Etapa 2: Obter as propriedades das configurações protegidas

Como cada configuração protegida tem um conjunto de propriedades exigidas, é preciso obter uma lista dessas
propriedades. Cada parâmetro da definição de configurações protegidas pode ser encontrado no Esquema do
Azure Resource Manager no GitHub. Esse esquema inclui apenas os conjuntos de parâmetro para as extensões
listadas na seção de visão geral deste documento.
De dentro do repositório de esquemas, pesquise a extensão desejada; para este exemplo é a IaaSDiagnostics .
Após a localização do objeto protectedSettings das extensões, anote cada parâmetro. No exemplo da extensão
IaasDiagnostic , os parâmetros exigidos são storageAccountName , storageAccountKey e storageAccountEndPoint .
"type": "object",
"properties": {
"type": "string"
},
"storageAccountKey": {
"type": "string"
},
"storageAccountEndPoint": {
"type": "string"
}
},
"required": [
"storageAccountName",
"storageAccountKey",
"storageAccountEndPoint"
]
}
Etapa 3: Criar novamente a configuração protegida

No modelo exportado, procure protectedSettings e substitua o objeto de configuração protegida exportado
por um novo que inclua os parâmetros de extensão obrigatórios e um valor para cada um.
No exemplo da extensão IaasDiagnostic , a nova definição de configuração protegida seria semelhante ao
exemplo a seguir:
"storageAccountName": "[parameters('storageAccountName')]",
"storageAccountKey": "[parameters('storageAccountKey')]",
"storageAccountEndPoint": "https://core.windows.net"
}
O recurso de extensão final é semelhante ao exemplo de JSON a seguir:

{
"name": "Microsoft.Insights.VMDiagnosticsSettings",
"dependsOn": [
],
"tags": {
"displayName": "AzureDiagnostics"
},
"properties": {
"publisher": "Microsoft.Azure.Diagnostics",
"type": "IaaSDiagnostics",
"settings": {
"xmlCfg": "[base64(concat(variables('wadcfgxstart'), variables('wadmetricsresourceid'),
variables('vmName'), variables('wadcfgxend')))]",
"storageAccount": "[parameters('existingdiagnosticsStorageAccountName')]"
},
"storageAccountName": "[parameters('storageAccountName')]",
"storageAccountKey": "[parameters('storageAccountKey')]",
"storageAccountEndPoint": "https://core.windows.net"
}
}
}
Se você usar parâmetros de modelo para fornecer valores de propriedade, será necessário criá-los. Ao criar
parâmetros de modelo para valores de configuração protegida, use o tipo de parâmetro SecureString para que
os valores confidenciais sejam protegidos. Para saber mais sobre como usar parâmetros, confira Criação de
modelos do Azure Resource Manager.
No exemplo da extensão IaasDiagnostic , os parâmetros a seguir seriam criados na seção de parâmetros do
"type": "SecureString"
},
"storageAccountKey": {
"type": "SecureString"
}
Neste ponto, o modelo pode ser implantado usando qualquer método de implantação de modelo.
Solucionando problemas de falhas da extensão da
VM do Windows no Azure
Visão geral dos modelos do Gerenciador de Recursos do Azure

Os modelos do Azure Resource Manager permitem especificar de forma declarativa a infraestrutura IaaS do
Azure na linguagem JSON definindo as dependências entre os recursos.
Consulte criando modelos de extensão para saber mais sobre como criar modelos para usar extensões.
Neste artigo, aprenderemos a solucionar algumas das falhas comuns da extensão de VM.
Exibindo o status da extensão

Os modelos do Azure Resource Manager podem ser executados no Azure PowerShell. Depois que o modelo for
executado, o status da extensão poderá ser exibido no Gerenciador de Recursos do Azure ou nas ferramentas de
linha de comando.
Veja um exemplo:
Azure PowerShell:
Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status
Veja o exemplo de saída:
Extensions: {
"ExtensionType": "Microsoft.Compute.CustomScriptExtension",
"Name": "myCustomScriptExtension",
"SubStatuses": [
{
"Code": "ComponentStatus/StdOut/succeeded",
"DisplayStatus": "Provisioning succeeded",
"Level": "Info",
"Message": " Directory: C:\\temp\\n\\n\\nMode LastWriteTime Length Name
\\n---- ------------- ------ ---- \\n-a---
9/1/2015 2:03 AM 11
test.txt \\n\\n",
"Time": null
},
{
"Code": "ComponentStatus/StdErr/succeeded",
"DisplayStatus": "Provisioning succeeded",
"Level": "Info",
"Message": "",
"Time": null
}
]
}
Solução de problemas de falhas da extensão

Executar novamente a extensão na VM
Se estiver executando scripts na VM usando a Extensão de Script Personalizado, às vezes, você poderá se
deparar com um erro em que a VM foi criada com êxito, mas o script falhou. Nessas condições, a maneira
recomendada de se recuperar desse erro é remover a extensão e executar o modelo novamente. Observação: no
futuro, essa funcionalidade será aprimorada para eliminar a necessidade de desinstalar a extensão.
Remover a extensão do Azure PowerShell
Remove-AzVMExtension -ResourceGroupName $RGName -VMName $vmName -Name "myCustomScriptExtension"
Depois que a extensão tiver sido removida, o modelo poderá ser executado novamente para executar os scripts
na VM.
Disparar uma nova metastate para a VM
Você pode observar que uma extensão não foi executada ou está falhando na execução por causa de um
"gerador de certificado do Microsoft Azure CRP" (esse certificado é usado para proteger o transporte das
configurações protegidas da extensão). Esse certificado será regenerado automaticamente reiniciando o agente
convidado do Windows de dentro da máquina virtual:
Abrir o Gerenciador de tarefas
Ir para a guia detalhes
Localizar o processo de WindowsAzureGuestAgent.exe
Clique com o botão direito do mouse e selecione "Finalizar tarefa". O processo será reiniciado
automaticamente
Você também pode disparar uma nova metastate para a VM, executando uma "VM reapply". Reaplicar VM é
uma API introduzida em 2020 para reaplicar o estado de uma VM. É recomendável fazer isso por vez, quando
você puder tolerar um curto tempo de inatividade da VM. Embora a reaplicação em si não cause uma
reinicialização da VM e a grande maioria dos tempos que chamam a reaplicação não reinicia a VM, há um risco
muito pequeno de que alguma outra atualização pendente para o modelo de VM seja aplicada quando reaplicar
dispara um novo estado de meta e que outra alteração pode exigir uma reinicialização.
Portal do Azure:
No portal, selecione a VM e, no painel esquerdo, em supor te + solução de problemas , selecione
reimplantar + aplicar novamente e, em seguida, selecione reaplicar .
Azure PowerShell (substitua o nome RG e o nome da VM pelos valores):
Set-AzVM -ResourceGroupName <RG Name> -Name <VM Name> -Reapply
CLI do Azure (substitua o nome RG e o nome da VM pelos valores):
az vm reapply -g <RG Name> -n <VM Name>
Se uma "VM reaplicar" não funcionou, você pode adicionar um novo disco de dados vazio à VM da Portal de
Gerenciamento do Azure e, em seguida, removê-lo mais tarde, depois que o certificado tiver sido adicionado de
volta.
Problemas ao usar extensões de VM em sistemas de
máquinas virtuais Linux do Azure habilitadas para
Python 3
NOTE
A Microsoft incentiva os usuários a adotar o Python 3. x em seus sistemas, a menos que sua carga de trabalho exija
suporte a Python 2. x . Exemplos desse requisito podem incluir scripts de administração herdados ou extensões como
Azure Disk Encr yption e Azure monitor .
Antes de instalar o Python 2. x em produção, considere a questão do suporte a longo prazo do Python 2. x,
particularmente sua capacidade de receber atualizações de segurança. Como produtos, incluindo parte da extensão
mencionada, atualização com suporte a Python 3,8 , você deve descontinuar o uso do Python 2. x.
Algumas distribuições do Linux passaram para o Python 3,8 e removidam o ponto de entrada herdado
/usr/bin/python para o Python completamente. Essa transição afeta a implantação automatizada e pronta para
uso de determinadas extensões de VM (máquina virtual) com estas duas condições:
Extensões que ainda estão em transição para o suporte do Python 3. x
Extensões que usam o ponto de entrada herdado /usr/bin/python
Os usuários de distribuição do Linux que fizeram a transição para o Python 3. x devem garantir que o ponto de
entrada herdado /usr/bin/python exista antes de tentar implantar essas extensões em suas VMs. Caso
contrário, a implantação da extensão poderá falhar.
As distribuições do Linux endossadas que são afetadas incluem o Ubuntu Ser ver 20, 4 LTS e o
Ubuntu pro 20, 4 LTS .
As extensões de VM afetadas incluem Azure Disk Encr yption , log Analytics , acesso à VM (usado
para redefinição de senha) e diagnósticos de convidado (usados para contadores de desempenho
adicionais).
As atualizações in-loco, como a atualização do ubuntu 18, 4 LTS para o Ubuntu 20, 4 LTS , devem manter o
/usr/bin/python symlink e permanecer inalteradas.
Resolução
Considere estas recomendações gerais antes de implantar extensões nos cenários conhecidos afetados descritos
anteriormente no Resumo:
1. Antes de implantar a extensão, reinstale o /usr/bin/python symlink usando o método fornecido pelo
fornecedor de distribuição do Linux.
Por exemplo, para Python 2,7 , use: sudo apt update && sudo apt install python-is-python2
2. Essa recomendação é para os clientes do Azure e não tem suporte no Azure Stack:
Se você já tiver implantado uma instância que exibe esse problema, use a funcionalidade executar
comando na folha da VM para executar os comandos mencionados acima. A própria extensão de
comando de execução não é afetada pela transição para Python 3,8.
3. Se você estiver implantando uma nova instância e precisar definir uma extensão no tempo de
provisionamento, use dados de usuário de inicialização de nuvem para instalar os pacotes
mencionados acima.
Por exemplo, para Python 2,7:
# create cloud-init config

cat > cloudinitConfig.json <<EOF
#cloud-config
package_update: true
runcmd:
- sudo apt update
- sudo apt install python-is-python2
EOF
# create VM
az vm create \
--resource-group <resourceGroupName> \
--name <vmName> \
--image <Ubuntu 20.04 Image URN> \
--admin-username azadmin \
--ssh-key-value "<sshPubKey>" \
--custom-data ./cloudinitConfig.json
4. Se os administradores de política da sua organização determinarem que as extensões não devem ser
implantadas em VMs, você poderá desabilitar o suporte de extensão no momento do provisionamento:
API REST
Para desabilitar e habilitar extensões quando você pode implantar uma VM com esta propriedade:
"osProfile": {
"allowExtensionOperations": false
},
Próximas etapas
Consulte outras alterações do sistema base desde 18, 4 LTS-Python 3 por padrão para obter informações
adicionais.
Migre seus recursos de IaaS para Azure Resource
Manager até 1º de março de 2023
Em 2014, lançamos a infraestrutura como um serviço (IaaS) em Azure Resource Manager. Já estamos
aprimorando os recursos desde então. Como Azure Resource Manager agora tem recursos completos de IaaS e
outros avanços, preterimos o gerenciamento de VMs (máquinas virtuais) IaaS por meio do Azure Service
Manager (ASM) em 28 de fevereiro de 2020. Essa funcionalidade será totalmente desativada em 1º de março de
2023.
Hoje, cerca de 90% das VMs de IaaS estão usando Azure Resource Manager. Se você usar recursos de IaaS por
meio do ASM, comece a planejar sua migração agora mesmo. Conclua-o até 1º de março de 2023 para
aproveitar a Azure Resource Manager.
As VMs criadas usando o modelo de implantação clássico seguirão a política moderna do ciclo de vida para
desativação.
Como isso me afeta?

A partir de 28 de fevereiro de 2020, os clientes que não utilizaram VMs IaaS por meio do ASM no mês de
fevereiro de 2020 não poderão mais criar VMs (clássicas).
Em 1º de março de 2023, os clientes não poderão mais iniciar as VMs de IaaS usando o ASM. Todos os que
ainda estiverem em execução ou alocados serão interrompidos e desalocados.
Em 1º de março de 2023, as assinaturas que não são migradas para Azure Resource Manager serão
informadas sobre as linhas do tempo para excluir as VMs restantes (clássicas).
Essa aposentadoria não afeta os seguintes serviços e funcionalidades do Azure:
Serviços de nuvem do Azure (clássico)
Contas de armazenamento não usadas por VMS (clássicas)
Redes virtuais não usadas por VMS (clássicas)
Outros recursos clássicos
Quais recursos estão disponíveis para essa migração?

Microsoft Q&A: Microsoft e suporte da Comunidade para migração.
Suporte à migração do Azure: equipe de suporte dedicada para assistência técnica durante a migração.
Os clientes sem suporte técnico podem usar o recurso de suporte gratuito fornecido especificamente
para essa migração.
Microsoft Fast Track: oFast Track pode ajudar clientes qualificados a planejar a execução de & para essa
migração. Indicado para o programa de migração de DC.
Se sua empresa/organização tiver parceria com a Microsoft ou trabalha com representantes da Microsoft
(como arquitetos de soluções de nuvem (CSAs) ou gerentes de contas técnicas (TAMs)), trabalhe com eles
para obter recursos adicionais para a migração.
Quais ações devo tomar?

Comece a planejar sua migração para Azure Resource Manager, hoje mesmo.
1. Faça uma lista de todas as VMs afetadas:
As VMs do tipo máquinas vir tuais (clássicas) no painel VM do portal do Azure são todas as VMs
afetadas na assinatura.
Você também pode consultar o grafo de recursos do Azure usando o portal ou o PowerShell para
exibir a lista de todas as VMs sinalizadas (clássicas) e informações relacionadas para as assinaturas
selecionadas.
Em 8 de fevereiro e 2 de setembro de 2020, enviamos emails com o assunto "Iniciar planejamento de
sua migração de VM IaaS para Azure Resource Manager" para proprietários de assinatura. O email
fornece uma lista de todas as máquinas virtuais e VMs (clássicas) de todas as assinaturas. Use-os para
criar essa lista.
2. Saiba mais sobre como migrar suas VMs Linux e Windows (clássicas) para Azure Resource Manager. Para
obter mais informações, consulte perguntas frequentes sobre a migração clássica para Azure Resource
Manager.
3. É recomendável iniciar o planejamento usando a ferramenta de migração de suporte à plataforma para
migrar suas VMs existentes com três etapas simples: validar, preparar e confirmar. A ferramenta foi
projetada para migrar suas VMs em um mínimo ou sem tempo de inatividade.
A primeira etapa, validar, não tem impacto sobre a implantação existente e fornece uma lista de todos
os cenários sem suporte para migração.
Percorra a lista de soluções alternativas para corrigir sua implantação e torná-la pronta para a
migração.
O ideal é que todos os erros de validação sejam corrigidos, você não deve encontrar nenhum
problema durante as etapas de preparação e confirmação. Depois que a confirmação for bem-
sucedida, sua implantação será migrada ao vivo para Azure Resource Manager e poderá ser
gerenciada por meio de novas APIs expostas por Azure Resource Manager.
Se a ferramenta de migração não for adequada para sua migração, você poderá explorar outras ofertas
de computação para a migração. Como há muitas ofertas de computação do Azure e elas são diferentes
uma da outra, não podemos fornecer um caminho de migração com suporte da plataforma para elas.
4. Para questões técnicas, problemas e ajuda com a adição de assinaturas à lista de permissões, contate o
suporte.
5. Conclua a migração o mais rápido possível para evitar o impacto nos negócios e aproveitar o
desempenho, a segurança e os novos recursos aprimorados do Azure Resource Manager.
Migração de recursos de IaaS com suporte da
plataforma do clássico para o Azure Resource
Manager no Linux
IMPORTANT
Hoje, cerca de 90% das VMs de IaaS estão usando Azure Resource Manager. A partir de 28 de fevereiro de 2020, as VMs
clássicas foram preteridas e serão totalmente desativadas em 1º de março de 2023. Saiba mais sobre essa reprovação e
como ela afeta você.
Este artigo fornece uma visão geral sobre a ferramenta de migração com suporte da plataforma, como migrar
recursos do ASM (Service Manager do Azure), também conhecido como modelos de implantação clássicos para
o Gerenciador de recursos (ARM), e detalhes sobre como conectar recursos de dois modelos de implantação
que coexistem em sua assinatura usando gateways site a site da rede virtual. Você pode ler mais sobre Azure
Resource Manager recursos e benefícios.
O ASM dá suporte a dois produtos de computação diferentes, as máquinas virtuais do Azure (clássicas) também
conhecidas como VMs IaaS & serviços de nuvem do Azure (clássico) , conhecidos como VMs PaaS ou funções
Web/de trabalho. Este documento fala apenas sobre a migração de máquinas virtuais do Azure (clássico).
Meta de migração
O Gerenciador de Recursos possibilita implantar aplicativos complexos por meio de modelos, configurar
máquinas virtuais usando extensões de VM e incorporar o gerenciamento de acesso e a marcação. O Azure
Resource Manager inclui implantação paralela e escalonável para máquinas virtuais em conjuntos de
disponibilidade. O novo modelo também oferece gerenciamento de ciclo de vida de computação, rede e
armazenamento de maneira independente. Por fim, há um enfoque para habilitar a segurança por padrão com a
imposição de máquinas virtuais em uma rede virtual.
Há suporte para quase todos os recursos do modelo de implantação clássica referentes a computação, rede e
armazenamento no Azure Resource Manager. Para aproveitar os novos recursos no Azure Resource Manager,
você pode migrar as implantações existentes do modelo de implantação clássico.
Recursos com suporte & configurações para migração

Recursos com suporte para migração
Máquinas Virtuais
Conjuntos de Disponibilidade
Contas de Armazenamento
Redes Virtuais
Gateways VPN
Gateways de rota expressa (na mesma assinatura que apenas na rede virtual)
Grupos de segurança de rede
Tabelas de Rotas
IPs Reservados
Configurações com suporte para migração
Esses recursos de IaaS clássicos têm suporte durante a migração
SERVIÇ O C O N F IGURA Ç Ã O
Azure AD Domain Services Redes virtuais que contêm serviços do Azure AD Domain
Services
Escopos de migração com suporte

Há quatro maneiras diferentes para concluir a migração de recursos de computação, rede e armazenamento.
Migração de máquinas virtuais (NÃO em uma rede virtual)
Migração de máquinas virtuais (em uma rede virtual)
Migração de contas de armazenamento
Migração de recursos não anexados
Migração de máquinas virtuais (NÃO em uma rede virtual)
No modelo de implantação do Resource Manager, a segurança de seus aplicativos é imposta por padrão. Todas
as VMs precisam estar em uma rede virtual no modelo do Gerenciador de Recursos. As plataforma Azure
reinicia ( Stop , Deallocate , e Start ) as VMs como parte da migração. Você tem duas opções de redes virtuais
para as quais as Máquinas Virtuais serão migradas:
Você pode solicitar que a plataforma crie uma nova rede virtual e migre a máquina virtual para a nova rede
virtual.
Você pode migrar a máquina virtual para uma rede virtual existente no Gerenciador de Recursos.
NOTE
Nesse escopo de migração, as operações do “plano de gerenciamento” e do “plano de dados” podem não ser permitidas
por determinado período durante a migração.
Migração de máquinas virtuais (em uma rede virtual)

Para a maioria das configurações de VM, somente os metadados são migrados entre os modelos Clássico e o
Resource Manager. As VMs subjacentes estão em execução no mesmo hardware, na mesma rede e com o
mesmo armazenamento. As operações do plano de gerenciamento talvez não tenham permissão por
determinado período de tempo durante a migração. No entanto, o plano de dados continua funcionando. Ou
seja, os aplicativos em execução nas VMs (clássicas) não incorrem em tempo de inatividade durante a migração.
Atualmente, não há suporte para as seguintes configurações. Se for adicionado suporte a elas no futuro,
algumas VMs nessa configuração poderão incorrer em tempo de inatividade (passarão por operações de parar,
desalocar e reiniciar a VM).
Você tem mais de um conjunto de disponibilidade em um único serviço de nuvem.
Você tem um ou mais conjuntos de disponibilidade e as VMs que não estão em um conjunto de
disponibilidade em um único serviço de nuvem.
NOTE
Nesse escopo de migração, o plano de gerenciamento pode não ser permitido por determinado período durante a
migração. Para algumas configurações, conforme descrito acima, ocorre tempo de inatividade do plano de dados.
Migração de contas de armazenamento
Para permitir uma migração perfeita, você implantar VMs do Resource Manager em uma conta de
armazenamento clássico. Com essa funcionalidade, recursos de computação e rede podem e devem ser
migrados independentemente de contas de armazenamento. Depois de migrar suas Máquinas Virtuais e a Rede
Virtual, você precisa migrar suas contas de armazenamento para concluir o processo de migração.
Se a sua conta de armazenamento não tiver discos associados ou dados de Máquinas Virtuais e tiver apenas
blobs, arquivos, tabelas e filas, a migração para o Azure Resource Manager poderá ser feita como uma migração
independente, sem dependências.
NOTE
O modelo de implantação do Resource Manager não tem o conceito de discos e imagens clássicas. Quando a conta de
armazenamento é migrada, os discos e imagens clássicos não ficarão visíveis na pilha do Resource Manager, mas os VHDs
de backup permanecem na conta de armazenamento.
As capturas de tela a seguir mostram como atualizar uma conta de armazenamento clássico para uma conta de
armazenamento Azure Resource Manager usando portal do Azure:
2. Navegue para sua conta de armazenamento.
3. Na seção configurações , clique em migrar para o ARM .
4. Clique em validar para determinar a viabilidade de migração.
5. Se a validação for aprovada, clique em preparar para criar uma conta de armazenamento migrada.
6. Digite Sim para confirmar a migração e clique em confirmar para concluir a migração.
Migração de recursos não anexados
Contas de armazenamento sem discos associados ou dados de máquinas virtuais podem ser migradas
independentemente.
Grupos de Segurança de Rede, Tabelas de Rotas e IPs Reservados que não estão associadas a Máquinas Virtuais
e Redes Virtuais podem ser também migrados de forma independente.
Recursos e configurações sem suporte

Alguns recursos e configurações não são suportados atualmente; as seções a seguir descrevem nossas
recomendações em torno deles.
Recursos sem suporte
Atualmente, não há suporte para os seguintes recursos. Se preferir, você pode remover essas configurações,
migrar as VMs e, em seguida, habilitar as configurações novamente no modelo de implantação do Gerenciador
de Recursos.
P RO VEDO R DE REC URSO S REC URSO REC O M EN DA Ç Ã O

P RO VEDO R DE REC URSO S REC URSO REC O M EN DA Ç Ã O
Computação Discos de máquina virtual não Os blobs VHD por trás desses discos
associados. serão migrados quando a Conta de
Armazenamento for migrada
Computação Imagens de máquinas virtuais. Os blobs VHD por trás desses discos
serão migrados quando a Conta de
Armazenamento for migrada
Rede ACLs de ponto de extremidade. Remova as ACLs de Ponto de

Extremidade e repita a migração.
Rede Gateway de Aplicativo Remova o Gateway de Aplicativo antes

de iniciar a migração e crie novamente
o Gateway de Aplicativo após a
conclusão da migração.
Rede Redes virtuais usando Migre a Rede Virtual para o

Emparelhamento VNet. Gerenciador de Recursos e depois
emparelhe. Saiba mais sobre
Emparelhamento de VNet.
Configurações sem suporte

Atualmente, não há suporte para as seguintes configurações.
SERVIÇ O C O N F IGURA Ç Ã O REC O M EN DA Ç Ã O
Gerenciador de Recursos Controle de acesso de Role-Based Como o URI dos recursos é modificado
(RBAC) para recursos clássicos após a migração, é recomendável
planejar as atualizações da política de
RBAC que precisam ocorrer após a
migração.
Computação Várias sub-redes associadas a uma VM Atualize a configuração de sub-rede

para referenciar apenas uma sub-rede.
Isso poderá exigir que você remova
um NIC secundário (que está
referenciado a outra sub-rede) da
máquina virtual e anexá-lo novamente
depois que a migração for concluída.
Computação Máquinas virtuais que pertencem a Opcionalmente, você pode excluir a

uma rede virtual, mas que não têm VM.
uma sub-rede explícita atribuída
Computação Máquinas virtuais que têm alertas e A migração passa e essas

políticas de Escala Automática configurações serão descartadas. É
altamente recomendável que você
avalie seu ambiente antes de fazer a
migração. Se preferir, você pode
redefinir as configurações de alerta
após a conclusão da migração.
Computação Extensões de VM do XML (BGInfo 1.*, Isso não tem suporte. Recomendamos
Depurador, Implantação da Web e que você remova essas extensões da
Depuração Remota do Visual Studio) máquina virtual para continuar a
migração, ou elas serão eliminadas
automaticamente durante o processo
de migração.
Computação Diagnóstico de inicialização com o Desabilite o recurso de Diagnóstico de

armazenamento Premium Inicialização para as VMs antes de
continuar com a migração. Você pode
habilitar novamente o diagnóstico de
inicialização na pilha do Gerenciador de
Recursos após a migração ser
concluída. Além disso, os blobs que
estão sendo usados para captura de
tela e logs seriais devem ser excluídos
para que você não seja cobrado por
eles.
Computação Serviços de nuvem que contêm Não há suporte para esse recurso no
funções de trabalho/web momento.
Computação Serviços de nuvem que contêm mais Não há suporte para esse recurso no
de um conjunto de disponibilidade ou momento. Mova as Máquinas Virtuais
vários conjuntos de disponibilidade. para a mesmo conjunto de
disponibilidade antes de fazer a
migração.
Computação VM com a extensão de Central de A Central de Segurança do Azure

Segurança do Azure instala automaticamente extensões em
suas Máquinas Virtuais a fim de
monitorar a segurança e emitir alertas.
Essas extensões normalmente são
instaladas automaticamente se a
política da Central de Segurança do
Azure for habilitada na assinatura. Para
migrar as máquinas virtuais, desabilite
a política da central de segurança na
assinatura que removerá a extensão de
monitoramento da Central de
Segurança das máquinas virtuais.
Computação VM com extensão de backup ou Essas extensões são instaladas em uma

instantâneo máquina Virtual configurada com o
serviço de Backup do Azure. Enquanto
não houver suporte para a migração
dessas VMs, siga as diretrizes descritas
aqui para manter os backups feitos
antes da migração.
Computação VM com extensão Azure Site Recovery Essas extensões são instaladas em uma
máquina virtual configurada com o
serviço de Azure Site Recovery.
Enquanto a migração de
armazenamento usada com Site
Recovery funcionará, a replicação atual
será afetada. Você precisa desabilitar e
habilitar a replicação de VM após a
migração de armazenamento.
Rede Redes virtuais que contêm máquinas Não há suporte para esse recurso no
virtuais e funções de trabalho/web momento. Mova as funções
Web/Trabalho para as suas próprias
redes virtuais antes de fazer a
migração. Depois que a rede virtual
clássica for migrada, a rede virtual do
Azure Resource Manager pode ser
emparelhada com a rede virtual
clássica para obter uma configuração
semelhante como antes.
Rede Circuitos do ExpressRoute clássico Não há suporte para esse recurso no

momento. Esses circuitos precisam ser
migrados para o Azure Resource
Manager antes da migração do IaaS
ser iniciada. Para saber mais, consulte
Movimentação dos circuitos do
ExpressRoute do modelo de
implantação clássico para o Resource
Manager.
Serviço de aplicativo do Azure Redes virtuais que contêm ambientes Não há suporte para esse recurso no
do Serviço de Aplicativo momento.
Azure HDInsight Redes virtuais que contêm serviços do Não há suporte para esse recurso no
HDInsight momento.
Serviços de Ciclo de Vida do Microsoft Redes virtuais que contêm máquinas Não há suporte para esse recurso no
Dynamics virtuais gerenciadas pelos Serviços de momento.
Ciclo de Vida do Microsoft Dynamics
Gerenciamento de API do Azure Redes virtuais que contêm Não há suporte para esse recurso no
implantações do Gerenciamento de momento. Para migrar a VNET IaaS,
API do Azure altere a VNET da implantação do
Gerenciamento de API, que é uma
operação sem tempo de inatividade.
Próximas etapas
Análise técnica aprofundada sobre a migração com suporte da plataforma do clássico para o Azure Resource
Manager
Planejamento para a migração de recursos de IaaS do clássico para o Azure Resource Manager
Usar o PowerShell para migrar recursos de IaaS do clássico para o Azure Resource Manager
Usar a CLI para migrar recursos de IaaS do clássico para o Azure Resource Manager
Ferramentas da comunidade para ajudar com a migração de recursos de IaaS do clássico para o Azure
Resource Manager
Examinar os erros de migração mais comuns
Confira as perguntas mais frequentes sobre a migração de recursos de IaaS do clássico para o Azure
Resource Manager
Análise técnica aprofundada sobre a migração com
suporte da plataforma do clássico para o Azure
Resource Manager
IMPORTANT
Vamos fazer uma análise aprofundada da migração do modelo de implantação clássico do Azure para o modelo
de implantação do Azure Resource Manager. Nós vamos examinar os recursos no nível da funcionalidade e do
recurso para ajudá-lo a entender como a plataforma do Azure migra recursos entre os dois modelos de
implantação. Para obter mais informações, leia o artigo de comunicado do serviço - Migração de recursos de
IaaS com suporte da plataforma do clássico para o Azure Resource Manager.
Migrar recursos de IaaS do modelo de implantação clássico para o

Azure Resource Manager
Primeiro, é importante compreender a diferença entre as operações de plano de dados e de plano de
gerenciamento nos recursos de IaaS (infraestrutura como serviço).
O Plano de gerenciamento/controle descreve as chamadas que vão para o plano de gerenciamento/controle
ou para a API para modificar recursos. Por exemplo, operações como a criação de uma VM, reinicialização de
uma VM e atualização de uma rede virtual com uma nova sub-rede para gerenciar os recursos em execução.
Elas não afetam diretamente a conexão com as VMs.
Plano de dados (aplicativo) descreve o runtime do próprio aplicativo e envolve a interação com instâncias
que não passam pela API do Azure. Por exemplo, o acesso ao seu site ou o pull de dados de uma instância do
SQL Server ou servidor MongoDB em execução são plano de dados ou interação com o aplicativo. Outros
exemplos incluem copiar um blob de uma conta de armazenamento e acessar um endereço IP público para
usar o protocolo RDP ou SSH (Secure Shell) na máquina virtual. Essas operações mantêm o aplicativo em
execução entre computação, rede e armazenamento.
O plano de dados é o mesmo entre o modelo de implantação Clássico e a pilha do Gerenciador de Recursos. A
diferença é que, durante o processo de migração, a Microsoft converte a representação dos recursos do modelo
de implantação Clássico para aquela da pilha do Gerenciador de Recursos. Como resultado, você precisa usar
novas ferramentas, APIs e SDKs para gerenciar seus recursos na pilha do Gerenciador de Recursos.
NOTE
Em alguns cenários de migração, a plataforma Azure interrompe, desaloca e reinicia as máquinas virtuais. Isso causa um
breve tempo de inatividade de plano de dados.
A experiência de migração
Antes de iniciar a migração:
Certifique-se de que os recursos que você deseja migrar não usam nenhum recurso ou nenhuma
configuração sem suporte. Normalmente a plataforma detecta esses problemas e gera um erro.
Se você tiver VMs que não estão em uma rede virtual, elas serão interrompidas e desalocadas como parte da
operação de preparação. Se você não quiser perder o endereço IP público, procure reservar o endereço IP
antes de disparar a operação de preparação. Se as VMs estiverem em uma rede virtual, elas não serão
interrompidas ou desalocadas.
Planeje a migração fora do horário comercial para acomodar falhas inesperadas que possam ocorrer durante
a migração.
Baixe a configuração atual das VMs usando o PowerShell, os comandos da CLI (interface de linha de
comando) ou as APIs REST para facilitar a validação após a conclusão da etapa de preparação.
Atualize os scripts de automação e operacionalização para lidar com o modelo de implantação do
Gerenciador de Recursos antes de iniciar a migração. Se preferir, você poderá realizar operações GET quando
os recursos estiverem no estado preparado.
Avalie as políticas do Azure RBAC (controle de acesso baseado em função) que são configuradas nos
recursos de IaaS no modelo de implantação clássico e planeje após a conclusão da migração.
O fluxo de trabalho de migração está descrito abaixo:
NOTE
As operações descritas nas seções a seguir são todas idempotentes. Caso você tenha algum problema que não seja um
recurso sem suporte ou um erro de configuração, repita a operação de preparação, anulação ou confirmação. O Azure
tenta a ação novamente.
Validar
A operação de validação é a primeira etapa do processo de migração. O objetivo desta etapa é analisar o estado
dos recursos que você deseja migrar no modelo de implantação clássico. A operação avalia se os recursos
podem ser migrados (êxito ou falha).
Você seleciona a rede virtual ou o serviço de nuvem (se não for em uma rede virtual) que deseja validar para a
migração. Se o recurso não puder ser migrado, o Azure indicará os motivos.
As verificações não feitas na operação de validação
A operação de validação apenas analisa o estado dos recursos no modelo de implantação clássico. Ela pode
verificar todas as falhas e cenários sem suporte devido a diferentes configurações no modelo de implantação
clássico. Não é possível verificar todos os problemas que a pilha do Azure Resource Manager pode causar nos
recursos durante a migração. Esses problemas são verificados apenas quando os recursos são submetidos à
transformação na próxima etapa da migração (a operação de preparação). A tabela abaixo lista todos os
problemas que não são verificados na operação de validação:
VERIF IC A Ç Õ ES DE REDE Q UE N Ã O O C O RREM N A O P ERA Ç Ã O DE VA L IDA Ç Ã O
Uma rede virtual com gateways ER e VPN.
Uma conexão de gateway de rede virtual em estado desconectado.
Todos os circuitos ER são pré-migrados para a pilha do Azure Resource Manager.
A cota do Azure Resource Manager verifica recursos de rede. Por exemplo: IP público estático, IPs públicos dinâmicos,
balanceador de carga, grupos de segurança de rede, tabelas de rotas e adaptadores de rede.
Todas as regras de balanceador de carga são válidas na implantação e na rede virtual.
IPs privados em conflito entre a VMs paradas e desalocadas na mesma rede virtual.
Preparar
A operação de preparação é a segunda etapa do processo de migração. O objetivo dessa etapa é simular a
transformação dos recursos de IaaS do modelo de implantação clássico para os recursos do Gerenciador de
Recursos. Além disso, a operação de preparação apresenta esse lado a lado para que você possa visualizar.
NOTE
Os recursos no modelo de implantação clássico não são modificados durante esta etapa. É uma etapa segura a ser
executada se você estiver experimentando fazer uma migração.
Você seleciona a rede virtual ou o serviço de nuvem (se não for uma rede virtual) que deseja preparar para a
migração.
Se o recurso não for capaz de migração, o Azure interrompe o processo de migração e lista o motivo pelo
qual a operação de preparação falhou.
Se o recurso for capaz de fazer migração, o Azure bloqueará as operações do plano de gerenciamento para
os recursos em migração. Por exemplo, você não pode adicionar um disco de dados a uma VM em migração.
Em seguida, o Azure inicia a migração de metadados do modelo de implantação clássico para o Gerenciador de
Recursos em relação aos recursos em migração.
Assim que a operação de preparação for concluída, você tem a opção de visualizar os recursos no modelo de
implantação clássico e no Gerenciador de Recursos. Para todos os serviços de nuvem no modelo de implantação
clássica, a plataforma Azure cria um nome de grupo de recursos com o padrão cloud-service-name>-Migrated .
NOTE
Não é possível selecionar o nome de um grupo de recursos criado para recursos migrados (ou seja, "-Migrated"). No
entanto, após a conclusão da migração, você pode usar o recurso de movimentação do Azure Resource Manager para
mover os recursos para qualquer grupo de recursos desejado. Para saber mais, confira Mover recursos para um novo
grupo de recursos ou assinatura.
As duas telas a seguir mostram o resultado após uma operação de preparação bem-sucedida. A primeira
mostra um grupo de recursos que contém o serviço de nuvem original. A segunda mostra o novo grupo de
recursos “-Migrated” que contém os recursos equivalentes do Azure Resource Manager.
Aqui damos uma olhada nos bastidores dos seus recursos após a conclusão da fase de preparação. Observe que
o recurso no plano de dados é o mesmo. Ele é representado no plano de gerenciamento (modelo de
implantação clássico) e no plano de controle (Resource Manager).
NOTE
Máquinas virtuais que não estão em uma rede virtual no modelo de implantação clássico são interrompidas e
desalocadas nesta fase de migração.
Verificação (manual ou com scripts)

Nessa etapa de verificação, você pode optar por usar a configuração que baixou anteriormente a fim de validar
se a migração parece correta. Se preferir, você pode entrar no portal e verificar pontualmente as propriedades e
os recursos para validar se os metadados de migração parecem corretos.
Se estiver migrando uma rede virtual, a maior parte da configuração das máquinas virtuais não é reiniciada.
Para aplicativos nessas VMs, você pode validar que o aplicativo está ainda em execução.
Você pode testar seus scripts de monitoramento e operacionais para ver se as VMs estão funcionando conforme
o esperado e se os scripts atualizados funcionam corretamente. Somente as operações GET terão suporte
quando os recursos estiverem no estado preparado.
Não haverá uma janela de tempo definida antes da qual você precisará confirmar a migração. Você pode levar
tanto tempo quanto desejar nesse estado. No entanto, o plano de gerenciamento é bloqueado para esses
recursos até você anular ou confirmar.
Caso encontre problemas, sempre será possível anular a migração e voltar para o modelo de implantação
clássica. Depois que você voltar, o Azure abrirá as operações do plano de gerenciamento nos recursos, para que
você possa retomar as operações normais nessas VMs no modelo de implantação clássico.
Anular
Essa é uma etapa opcional se você quiser reverter as alterações para o modelo de implantação clássico e
interromper a migração. Essa operação exclui os metadados dos seus recursos no Gerenciador de Recursos
(criados na etapa de preparação).
NOTE
Essa operação não pode ser executada depois que a operação de confirmação é disparada.
Commit
Após a conclusão da validação, é possível confirmar a migração. Os recursos não aparecerão mais no modelo de
implantação clássico e estão disponíveis apenas no modelo de implantação do Gerenciador de Recursos. Os
recursos migrados só podem ser gerenciados no novo portal.
NOTE
Esta é uma operação idempotente. Se ela falhar, repita a operação. Se ele continuar falhando, crie um tíquete de suporte
ou crie um fórum em Página de P e R da Microsoft
Fluxograma de migração
Aqui está um fluxograma que mostra como proceder com a migração:
Conversão do modelo de implantação clássico para recursos do

Você pode encontrar o modelo de implantação clássico e representações do Resource Manager dos recursos na
tabela a seguir. Atualmente, não há suporte para outros recursos e funcionalidades.
REP RESEN TA Ç Ã O DO GEREN C IA DO R

REP RESEN TA Ç Ã O DO C L Á SSIC O DE REC URSO S O B SERVA Ç Õ ES
Nome do serviço de nuvem (nome do Nome DNS Durante a migração, um novo grupo
serviço hospedado) de recursos é criado para cada serviço
de nuvem com o padrão de
nomenclatura
<cloudservicename>-migrated . Esse
grupo de recursos contém todos os
seus recursos. O nome do serviço de
nuvem torna-se um nome DNS
associado ao endereço IP público.
Máquina virtual Máquina virtual As propriedades específicas da VM são

migradas sem alterações.
Determinadas informações de
osProfile, como nome do computador,
não foram armazenadas no modelo de
implantação clássica e permanecem
vazias após a migração.
Recursos de disco anexados à VM Discos implícitos anexados à VM Os discos não são modelados como
recursos de nível superior no modelo
de implantação do Gerenciador de
Recursos. Eles são migrados como
discos implícitos na VM. No momento,
há suporte apenas aos discos
anexados a uma VM. Agora, VMs do
Gerenciador de Recursos podem usar
contas de armazenamento no modelo
de implantação clássico, o que permite
que os discos sejam migrados
facilmente sem quaisquer atualizações.
Extensões de VM Extensões de VM Todas as extensões de recurso, exceto

as extensões XML, são migradas do
modelo de implantação clássica.
Certificados de máquina virtual Certificados no Cofre da Chave do Se um serviço de nuvem contiver

Azure certificados de serviço, a migração
criará um novo cofre de chaves do
Azure por serviço de nuvem e moverá
os certificados para o cofre de chaves.
As VMs são atualizadas para fazer
referência aos certificados por meio do
cofre de chaves.
Não exclua o cofre de chaves. Isso

pode fazer com que a VM entre em
estado de falha.
Configuração do WinRM Configuração do WinRM em osProfile A configuração do Gerenciamento

Remoto do Windows é movida sem
alterações, como parte da migração.
Propriedade do conjunto de Recurso do conjunto de disponibilidade A especificação do conjunto de

disponibilidade disponibilidade é uma propriedade da
VM no modelo de implantação
clássica. Os conjuntos de
disponibilidade se tornam um recurso
de nível superior como parte da
migração. Não há suporte para a
seguinte configuração: vários
conjuntos de disponibilidade por
serviço de nuvem ou um ou mais
conjuntos de disponibilidade junto
com VMs que não estão em nenhum
conjunto de disponibilidade em um
serviço de nuvem.
Configuração de rede em uma VM Interface de rede primária A configuração de rede em uma VM é

representada como o recurso de
interface de rede primária após a
migração. Para as VMs que não estão
em uma rede virtual, o endereço IP
interno é alterado durante a migração.
Várias interfaces de rede em uma VM Interfaces de rede Se uma VM tiver várias interfaces de
rede associadas, cada adaptador de
rede se tornará um recurso de nível
superior como parte da migração,
juntamente com todas as
propriedades.
Conjunto de pontos de extremidade Balanceador de carga No modelo de implantação clássica, a

com balanceamento de carga plataforma atribuía um balanceador de
carga implícito a cada serviço de
nuvem. Durante a migração, um novo
recurso de balanceador de carga é
criado e o conjunto de pontos de
extremidade com balanceamento de
carga se torna as regras do
balanceador de carga.
Regras NAT de entrada Regras NAT de entrada Os pontos de extremidade de entrada

definidos na VM são convertidos em
regras de conversão de endereços de
rede de entrada sob o balanceador de
carga durante a migração.
Endereço VIP Endereço IP público com o nome DNS O endereço IP virtual se torna um
endereço IP público e é associado ao
balanceador de carga. Um IP virtual só
pode ser migrado se houver um ponto
de extremidade de entrada atribuído a
ele.
Rede virtual Rede virtual A rede virtual é migrada com todas as

propriedades para o modelo de
implantação do Gerenciador de
Recursos. É criado um novo grupo de
recursos com o nome -migrated .
IPs Reservados Endereço IP público com método de Os IPs Reservados associados ao

alocação estático balanceador de carga são migrados,
juntamente com a migração do serviço
de nuvem ou da máquina virtual. Os
IPs reservados não associados podem
ser migrados usando move-
AzureReservedIP.
Endereço IP público por VM Endereço IP público com método de O endereço IP público associado à VM
alocação dinâmico é convertido como um recurso de
endereço IP público, com o método de
alocação definido como estático.
NSGs NSGs Os grupos de segurança de rede

associados a uma sub-rede são
clonados como parte da migração para
o modelo de implantação do
Gerenciador de Recursos. O NSG no
modelo de implantação clássica não é
removido durante a migração. No
entanto, as operações do plano de
gerenciamento referentes ao NSG
serão bloqueadas quando a migração
estiver em andamento. O NSGs não
associado pode ser migrado usando
Move-AzureNetworkSecurityGroup.
Servidores DNS Servidores DNS Os servidores DNS associados a uma

rede virtual ou à VM são migrados
como parte da migração do recurso
correspondente, juntamente com
todas as propriedades.
UDRs UDRs As rotas definidas pelo usuário

associados a uma sub-rede são
clonadas como parte da migração para
o modelo de implantação do
Gerenciador de Recursos. A UDR no
modelo de implantação clássica não é
removida durante a migração. As
operações do plano de gerenciamento
referentes à UDR serão bloqueadas
quando a migração estiver em
andamento. As UDRs não associadas
podem ser migradas usando Move-
AzureReservedIP.
Propriedade de encaminhamento IP Propriedade de encaminhamento IP na A propriedade de encaminhamento IP

em uma configuração de rede da VM NIC em uma VM é convertida em uma
propriedade na interface de rede
durante a migração.
Balanceador de carga com vários IPs Balanceador de carga com vários Cada IP público associado ao
recursos IP públicos balanceador de carga é convertido em
um recurso IP público e associado ao
balanceador de carga após a migração.
Nomes DNS internos na VM Nomes DNS internos na NIC Durante a migração, os sufixos DNS
internos das VMs são migrados para
uma propriedade somente leitura
chamada "InternalDomainNameSuffix"
no NIC. O sufixo permanece inalterado
após a migração, e a resolução da VM
deve continuar a funcionar como
antes.
Gateway de rede virtual Gateway de rede virtual As propriedades do gateway de rede

virtual são migradas sem alterações. O
VIP associado ao gateway também
não é alterado.
Site de rede local Gateway de rede local Propriedades do site de rede local são
migradas sem alterações para um
novo recurso chamado gateway de
rede local. Ele representa prefixos de
endereço local e o IP do gateway
remoto.
Referências de conexões Conexão As referências de conectividade entre o

gateway e o site de rede local na
configuração de rede são
representadas por um novo recurso
chamado Conexão. Todas as
propriedades de referência de
conectividade em arquivos de
configuração de rede são copiadas sem
alterações para o recurso Conexão. A
conectividade entre redes virtuais no
modelo de implantação clássico é feita
com a criação de dois túneis IPsec para
os sites de rede local que representam
as redes virtuais. Isso vira o tipo de
conexão rede virtual a rede virtual no
modelo do Gerenciador de Recursos,
sem exigir gateways de rede locais.
Alterações à automação e às ferramentas após a migração

Como parte da migração dos recursos do modelo de implantação clássico para o modelo de implantação do
Gerenciador de Recursos, você precisa atualizar sua automação ou ferramentas existentes para garantir que elas
continuem funcionando após a migração.
Próximas etapas
Visão geral da migração de recursos de IaaS com suporte da plataforma do clássico para o Azure Resource
Manager
Gateway de VPN clássico para migração do Resource Manager
Migrar circuitos do ExpressRoute e redes virtuais associadas do clássico para o modelo de implantação do
Resource Manager
Resource Manager
Resource Manager
Planejamento da migração de recursos de IaaS do
clássico para o Azure Resource Manager
IMPORTANT
Embora o Azure Resource Manager ofereça vários recursos incríveis, é fundamental planejar sua jornada de
migração para garantir que tudo ocorra sem problemas. Gastar tempo no planejamento garantirá que não
ocorram problemas durante a execução das atividades de migração.
NOTE
As diretrizes a seguir foram uma contribuição intensiva da equipe de Consultoria para Clientes do Azure e dos arquitetos
da Solução na Nuvem que trabalham com clientes para a migração de ambientes de grande porte. Assim, este
documento continuará sendo atualizado à medida que surgirem novos padrões de sucesso. Portanto, verifique se há
novas recomendações periodicamente.
Há quatro fases gerais da jornada de migração:
Plano
Considerações técnicas e compensações
Dependendo do tamanho dos requisitos técnicos, das regiões geográficas e das práticas operacionais, talvez
você deseje considerar:
1. Por que sua organização deseja usar o Azure Resource Manager? Quais são os motivos comerciais para uma
migração?
2. Quais são os motivos técnicos para o Azure Resource Manager? Quais serviços adicionais do Azure (se
houver) você gostaria de utilizar?
3. Qual aplicativo (ou conjuntos de máquinas virtuais) está incluído na migração?
4. Há suporte para quais cenários na API de migração? Examine os recursos e as configurações sem suporte.
5. As equipes operacionais agora darão suporte a aplicativos/VMs no Clássico e no Azure Resource Manager?
6. Como o Azure Resource Manager altera seus processos de implantação, gerenciamento, monitoramento e
relatório da VM (se houver)? Os scripts de implantação precisam ser atualizados?
7. Qual é o plano de comunicação para informar os stakeholders (usuários finais, proprietários do aplicativo e
proprietários da infraestrutura)?
8. Dependendo da complexidade do ambiente, deve haver um período de manutenção em que o aplicativo não
estará disponível para os usuários finais e os proprietários do aplicativo? Em caso afirmativo, por quanto
tempo?
9. Qual é o plano de treinamento para garantir que os stakeholders têm conhecimento e são proficientes no
Azure Resource Manager?
10. Qual é o plano de gerenciamento do programa ou do projeto para a migração?
11. Quais são as linhas do tempo para a migração do Azure Resource Manager e outros roteiros de tecnologia
relacionados? Eles estão alinhados corretamente?
Padrões de sucesso
Os clientes de sucesso têm planos detalhados para quando as perguntas anteriores são abordadas,
documentadas e controladas. Garanta que os planos de migração são comunicados em larga escala para os
patrocinadores e stakeholders. Esteja munido com o conhecimento sobre as opções de migração; é altamente
recomendável ler todo este conjunto de documentos sobre migração abaixo.
Manager
Manager
Resource Manager
Resource Manager
Armadilhas a serem evitadas
Falha no planejamento. As etapas de tecnologia desta migração são comprovadas e o resultado é previsível.
Pressuposto de que a API de migração com suporte na plataforma considerará todos os cenários. Leia
recursos e configurações sem suporte para entender para quais cenários há suporte.
Não planejar a possível interrupção do aplicativo para os usuários finais. Planeje ter um buffer suficiente para
avisar de forma adequada os usuários finais sobre o período durante o qual o aplicativo não estará
disponível.
Teste de laboratório
Replicar o ambiente e fazer uma migração de teste
NOTE
A replicação exata do ambiente existente é executada com uma ferramenta que é uma contribuição da comunidade, sem
suporte oficial do Suporte da Microsoft. Portanto, é uma etapa opcional, mas é a melhor maneira de descobrir
problemas sem interferir nos ambientes de produção. Se o uso de uma ferramenta que é uma contribuição da
comunidade não for uma opção, leia mais sobre a recomendação da Simulação Validar/Preparar/Anular abaixo.
Conduzir um teste de laboratório do cenário exato (computação, rede e armazenamento) é a melhor maneira de
garantir uma migração tranquila. Isso ajuda a garantir que:
Um laboratório totalmente separado ou um ambiente de não produção existente para o teste.
Recomendamos ter um laboratório totalmente separado que pode ser migrado repetidamente e
modificado de forma destrutiva. Os scripts para coletar/hidratar metadados das assinaturas reais são
listados abaixo.
É uma boa ideia criar o laboratório em uma assinatura separada. O motivo disso é que o laboratório será
destruído repetidamente e ter uma assinatura isolada e separada reduzirá a possibilidade de que algo
real seja acidentalmente excluído.
Isso pode ser feito com a ferramenta AsmMetadataParser. Leia mais sobre essa ferramenta aqui
Padrões de sucesso
Veja a seguir os problemas descobertos em muitas das migrações de maior porte. Esta não é uma lista
completa; consulte os recursos e as configurações sem suporte para obter mais detalhes. Você poderá ou não
ter estes problemas técnicos, mas se tiver, resolvê-los antes de tentar realizar a migração garantirá uma
experiência mais tranquila.
Fazer uma Simulação Validar/Preparar/Anular – essa é provavelmente a etapa mais importante
para garantir o sucesso da migração do Clássico para o Azure Resource Manager. A API de migração
apresenta três etapas principais: Validar, Preparar e Confirmar. A etapa Validar lerá o estado do ambiente
clássico e retornará um resultado de todos os problemas. No entanto, como talvez existam alguns
problemas na pilha do Azure Resource Manager, a etapa Validar não capturará tudo. A próxima etapa no
processo de migração, Preparar, ajudará a expor esses problemas. A etapa Preparar moverá os
metadados do Clássico para o Azure Resource Manager, mas não confirmará a movimentação e não
removerá nem alterará nada do lado do Clássico. A simulação envolve a preparação da migração e, em
seguida, a anulação (não confirmação ) da preparação da migração. O objetivo da simulação
Validar/Preparar/Anular é ver todos os metadados da pilha do Azure Resource Manager, examiná-los (de
forma programática ou no Portal), verificar se tudo é migrado corretamente e resolver os problemas
técnicos. Ela também lhe dará uma ideia da duração da migração, de forma que você possa planejar o
tempo de inatividade de acordo. Uma validação/preparação/anulação não causa nenhum tempo de
inatividade para o usuário; portanto, ela é não interruptiva para o uso do aplicativo.
Os itens abaixo precisarão ser resolvidos antes da simulação, mas uma simulação liberará com
segurança essas etapas de preparação caso elas não sejam executadas. Durante a migração
corporativa, descobrimos que a simulação é uma maneira segura e inestimável para garantir a
prontidão da migração.
Quando a etapa Preparar estiver em execução, o plano de controle (operações de gerenciamento do
Azure) será bloqueado para toda a rede virtual e, portanto, nenhuma alteração poderá ser feita nos
metadados da VM durante as etapas Validar/Preparar/Anular. Mas, de outro modo, a função de
qualquer aplicativo (RD, uso da VM, etc.) não será afetada. Os usuários das VMs não saberão que a
simulação está sendo executada.
Circuitos do ExpressRoute e VPN . Atualmente, os Gateways do ExpressRoute com links de
autorização não podem ser migrados sem tempo de inatividade. Para obter a solução desse problema,
consulte Migrar circuitos do ExpressRoute e as redes virtuais associadas do clássico para o modelo de
implantação do Resource Manager.
Extensões de VM – as extensões de Máquina Virtual são possivelmente um dos maiores obstáculos
para a migração de VMs em execução. A correção das Extensões de VM pode levar mais de 1 a 2 dias;
portanto, planeje de forma adequada. Um agente do Azure funcional é necessário para relatar novamente
o status da Extensão de VM das VMs em execução. Se o status for retornado inválido para uma VM em
execução, isso interromperá a migração. O próprio agente não precisa estar na ordem de trabalho para
permitir a migração, mas se existirem extensões na VM, um agente funcional E uma conectividade de
saída com a Internet (com DNS) serão necessários para continuar a migração.
Se a conexão a um servidor DNS for perdida durante a migração, todas as extensões de VM
(exceto BGInfo v1.*) deverão ser removidas primeira de cada VM antes da preparação da migração
e subsequentemente adicionadas de volta à VM após a migração do Azure Resource Manager. Isso
se refere apenas às VMs em execução. Se as VMs forem interrompidas desalocadas, as
Extensões de VM não precisarão ser removidas. Obser vação: várias extensões como o
diagnóstico do Azure e o monitoramento da central de segurança serão reinstalados
automaticamente após a migração e, portanto, removê-las não será um problema.
Além disso, verifique se os Grupos de Segurança de Rede não estão restringindo o acesso de saída
à Internet. Isso pode acontecer com as configurações de alguns Grupos de Segurança de Rede. O
acesso de saída à Internet (e o DNS) é necessário para que as Extensões de VM sejam migradas
para o Azure Resource Manager.
Há duas versões da extensão BGInfo: v1 e v2. Se a VM foi criada usando o portal do Azure ou o
PowerShell, provavelmente, ela terá a extensão v1. Essa extensão não precisa ser removida e será
ignorada (não migrada) pela API de migração. No entanto, se a VM Clássica foi criada com o novo
portal do Azure, provavelmente, ela terá a versão v2 baseada em JSON de BGInfo, que poderá ser
migrada para o Azure Resource Manager, desde que o agente esteja funcionando e tenha acesso
de saída à Internet (e DNS).
Opção de correção 1 . Se você souber que as VMs não terão acesso de saída à Internet, um
serviço DNS funcional e agentes funcionais do Azure nas VMs, desinstale todas as extensões de
VM como parte da migração antes da etapa Preparar e, depois, reinstale-as após a migração.
Opção de correção 2 . Se as extensões de VM forem muito problemáticas, outra opção é
desligar/desalocar todas as VMs antes da migração. Migre as VMs desalocadas e, depois, reinicie-
as no lado do Azure Resource Manager. A vantagem aqui é que as extensões de VM serão
migradas. A desvantagem é que todos os IPs Virtuais voltados ao público serão perdidos (isso
pode ser um não início), e, obviamente, as VMs serão desligada,s causando muito mais impacto
nos aplicativos em funcionamento.
NOTE
Se uma política da Central de Segurança do Azure estiver configurada nas VMs em execução que estão
sendo migradas, a política de segurança precisará ser interrompida antes da remoção das extensões; caso
contrário, a extensão de monitoramento de segurança será reinstalada automaticamente na VM depois de
removê-la.
Conjuntos de disponibilidade – para que uma VNET (rede virtual) seja migrada para o Azure
Resource Manager, todas as VMs recipientes da implantação Clássica (ou seja, o serviço de nuvem)
devem estar em um único conjunto de disponibilidade ou não devem estar em nenhum conjunto de
disponibilidade. Ter mais de um conjunto de disponibilidade no serviço de nuvem não é compatível com
o Azure Resource Manager e interromperá a migração. Além disso, não pode haver algumas VMs em um
conjunto de disponibilidade e outras VMs que não estão em um conjunto de disponibilidade. Para
resolver isso, você precisará corrigir ou reorganizar o serviço de nuvem. Planeje de forma adequada, pois
isso pode ser demorado.
Implantações de função web/de trabalho – Serviços de Nuvem que contém funções web e de
trabalho não podem migrar para o Azure Resource Manager. As funções web/de trabalho devem
primeiro ser removidas da rede virtual para que a migração possa ser iniciada. Uma solução típica é
apenas mover as instâncias de função web/de trabalho para uma rede virtual Clássica separada que
também está vinculada a um circuito do ExpressRoute ou migrar o código para Serviços de Aplicativo de
PaaS mais novos (essa discussão está além do escopo deste documento). No primeiro caso de
reimplantação, crie uma nova rede virtual Clássica, mova/reimplante as funções web/de trabalho nessa
nova rede virtual e, depois, exclua as implantações da rede virtual que está sendo movida. Não é
necessário alterar o código. A nova funcionalidade Emparelhamento de Rede Virtual pode ser usada para
emparelhar a rede virtual clássica que contém as funções web/de trabalho e outras redes virtuais na
mesma região do Azure, como a rede virtual que está sendo migrada (após a conclusão da migração
da rede vir tual, já que redes vir tuais emparelhadas não podem ser migradas ), fornecendo as
mesmas funcionalidades, sem perda de desempenho e sem penalidades de latência/largura de banda.
Considerando a adição do Emparelhamento de Rede Virtual, as implantações de função web/de trabalho
agora podem ser facilmente atenuadas e não impedem a migração para o Azure Resource Manager.
Cotas do Azure Resource Manager – as regiões do Azure têm cotas/limites separados para o Clássico
e o Azure Resource Manager. Mesmo que em um cenário de migração o novo hardware não esteja sendo
consumido (estamos trocando VMs existentes do Clássico para o Azure Resource Manager), as cotas do
Azure Resource Manager ainda precisam estar em vigor com capacidade suficiente antes que a migração
possa ser iniciada. Veja abaixo uma lista dos principais limites que observamos que causam problemas.
Abra um tíquete de suporte de cota para aumentar os limites.
NOTE
Esses limites precisam ser acionados na mesma região do ambiente atual a ser migrado.
Interfaces de Rede
Balanceadores de Carga
IPs Públicos
IPs Públicos Estáticos
Núcleos
Tabelas de Rotas
Você pode verificar suas cotas atuais do Azure Resource Manager usando os comandos a seguir
com a última versão da CLI do Azure.
Computação (Núcleos, Conjuntos de Disponibilidade)
az vm list-usage -l <azure-region> -o jsonc
Rede (Redes Virtuais, IPs Públicos Estáticos, IPs Públicos, Grupos de Segurança de Rede, Interfaces
de Rede, Balanceadores de Carga, Tabelas de Rotas)
az network list-usages -l <azure-region> -o jsonc
Armazenamento (Conta de Armazenamento)
az storage account show-usage
Limitação da API do Azure Resource Manager – caso você tenha um ambiente grande o suficiente
(por exemplo, > 400 VMs em uma VNET), poderá atingir a limitação padrão da API para gravações
(atualmente, 1.200 gravações/hora ) no Azure Resource Manager. Antes de iniciar a migração, você
deverá acionar um tíquete de suporte para aumentar esse limite para sua assinatura.
Status de VM O Provisionamento Atingiu o Tempo Limite – se uma VM tiver o status tempo
limite do provisionamento atingido , isso precisará ser resolvido antes da migração. A única maneira
de fazer isso é com o tempo de inatividade e cancelando o provisionamento e reprovisionando a VM
(excluí-la, manter o disco e recriar a VM).
Status de VM RoleStateUnknown – se a migração for interrompida devido a uma mensagem de erro
estado da função desconhecido , inspecione a VM usando o portal e verifique se ela está em
execução. Esse erro normalmente desaparecerá por si só (sem nenhuma correção necessária) após
alguns minutos e, em geral, é um tipo transitório que costuma ser observado durante as operações star t ,
stop e restar t de uma Máquina Virtual. Melhor prática: tente fazer a migração novamente após alguns
minutos.
O Fabric Cluster não existe – em alguns casos, determinadas VMs não podem ser migradas por vários
motivos incomuns. Um desses casos conhecidos é se a VM foi criada recentemente (na última semana ou
menos) e por acaso foi colocada em um cluster do Azure que ainda não está equipado para cargas de
trabalho do Azure Resource Manager. Você obterá um erro dizendo que o cluster da malha não existe
e a VM não poderá ser migrada. Em geral, aguardar alguns resolverá esse problema específico, pois, em
breve, o cluster habilitará o Azure Resource Manager. No entanto, uma solução alternativa imediata é
stop-deallocate a VM e, em seguida, continuar com a migração e iniciar o backup da VM no Azure
Resource Manager após a migração.
Não use atalhos nem omita as migrações de simulação Validar/Preparar/Anular.
A maioria, se não todos, os possíveis problemas ocorrerá durante as etapas Validar/Preparar/Anular.
Migração
Agora você está pronto porque resolveu os problemas conhecidos no ambiente.
Para as migrações reais, talvez você deseje considerar:
1. Planejar e agendar a rede virtual (a menor unidade de migração) com o aumento de prioridade. Fazer as
redes virtuais simples primeiro e prosseguir com as redes virtuais mais complicadas.
2. A maioria dos clientes terá ambientes de produção e de não produção. Agendar a produção por último.
3. (OPCIONAL) Agendar um tempo de inatividade de manutenção com uma grande quantidade de buffer
caso ocorram problemas inesperados.
4. Comunicar-se e alinhar com as equipes de suporte em caso de problemas.
Padrões de sucesso
As diretrizes técnicas da seção Laboratório de teste acima devem ser consideradas e atenuadas antes de uma
migração real. Com testes adequados, a migração é, na verdade, um não evento. Para ambientes de produção,
pode ser útil ter suporte adicional, como um parceiro confiável da Microsoft ou os serviços do Microsoft
Premier.
O teste parcial pode causar problemas e atraso na migração.
Além da migração
Agora que você está no Azure Resource Manager, maximize a plataforma. Leia a visão geral do Azure Resource
Manager para descobrir mais benefícios.
Itens a serem considerados:
Agrupe a migração com outras atividades. A maioria dos clientes opta por uma janela de manutenção do
aplicativo. Nesse caso, talvez você deseje usar esse tempo de inatividade para habilitar outras funcionalidades
do Azure Resource Manager como criptografia e migração para o Managed Disks.
Examine os motivos técnicos e comerciais para o Azure Resource Manager; habilite os serviços adicionais
disponíveis somente no Azure Resource Manager que se aplicam ao seu ambiente.
Modernize seu ambiente com os serviços de PaaS.
Padrões de sucesso
Determine quais serviços você deseja habilitar no Azure Resource Manager agora. Muitos clientes consideram os
itens abaixo interessantes para seus ambientes do Azure:
Controle de acesso baseado em função do Azure (RBAC do Azure).
Modelos do Azure Resource Manager para uma implantação mais fácil e mais controlada.
Marcas.
Controle de Atividades
Políticas do Azure
Lembre-se do motivo que fez você iniciar esta jornada de migração do Clássico para o Azure Resource Manager.
Quais foram os motivos comerciais originais? Você concretizou o motivo comercial?
Próximas etapas
Manager
Manager
Resource Manager
Resource Manager
Migrar recursos de IaaS do modelo clássico para o
Azure Resource Manager usando a CLI do Azure
IMPORTANT
Estas etapas mostram como usar a CLI (interface de linha de comando) do Azure para migrar recursos de IaaS
(infraestrutura como serviço) do modelo de implantação clássico para o modelo de implantação do Azure
Resource Manager. O artigo requer a CLI clássica do Azure. Como a CLI do Azure só é aplicável para recursos do
Azure Resource Manager, ela não pode ser usada para essa migração.
NOTE
Todas as operações descritas aqui são idempotentes. Caso você tenha algum problema que não seja um recurso sem
suporte ou um erro de configuração, recomendamos que repita a operação de preparação, anulação ou confirmação. Em
seguida, a plataforma repetirá a ação.
Este é um fluxograma para identificar a ordem em que as etapas precisam ser executadas durante um processo de
migração
Etapa 1: preparar para a migração

Veja a seguir algumas das práticas que recomendamos durante a avaliação de migração dos recursos de IaaS do
modelo clássico para o Gerenciador de Recursos:
Leia a lista de recursos ou de configurações sem suporte. Caso você tenha máquinas virtuais que usam
recursos ou configurações sem suporte, recomendamos que aguarde até que o suporte para o
recurso/configuração seja anunciado. Como alternativa, é possível remover esse recurso ou mudar a
configuração para habilitar a migração, caso ela atenda às suas necessidades.
Se você tiver scripts automatizados que implantam sua infraestrutura e aplicativos atualmente, tente criar
uma configuração de teste semelhante usando esses scripts para migração. Você também pode configurar
ambientes de exemplo usando o portal do Azure.
IMPORTANT
Atualmente não ha suporte para Gateways de Aplicativo para a migração do clássico para o Resource Manager. Para
migrar uma rede virtual clássica com um Gateway de Aplicativo, remova o gateway antes de executar uma operação de
Preparação para mover a rede. Depois de concluir a migração, reconecte o gateway no Azure Resource Manager.
Não é possível migrar automaticamente gateways de ExpressRoute conectando-se a circuitos de ExpressRoute em outra
assinatura. Nesses casos, remova o gateway de ExpressRoute, migre a rede virtual e recrie o gateway. Confira Migrar
circuitos de ExpressRoute e redes virtuais associadas do modelo de implantação clássico para o Resource Manager para
obter mais informações.
Etapa 2: Definir sua assinatura e registrar o provedor

Para cenários de migração, é necessário instalar seu ambiente tanto para o modelo clássico quanto para o
Gerenciador de Recursos. Instale a CLI do Azure e selecione sua assinatura.
Entre em sua conta.
azure login
Selecione a assinatura do Azure usando o seguinte comando.
azure account set "<azure-subscription-name>"
NOTE
O registro é uma etapa única, mas é preciso executá-lo uma vez antes de tentar a migração. Sem o registro, você verá a
seguinte mensagem de erro
BadRequest: a assinatura não está registrada para migração.
Registre-se no provedor de recursos de migração usando o comando a seguir. Observe que, em alguns casos,
esse comando atinge o tempo limite. No entanto, o registro será bem-sucedido.
azure provider register Microsoft.ClassicInfrastructureMigrate
Aguarde cinco minutos para concluir o registro. É possível verificar o status da aprovação usando o comando a
seguir. Verifique se RegistrationState é Registered antes de continuar.
azure provider show Microsoft.ClassicInfrastructureMigrate
Agora mude a CLI para o modo asm .

Etapa 3: verificar se você tem uma quantidade suficiente de vCPUs de

Máquina Virtual do Azure Resource Manager na região do Azure de
sua implantação atual ou da VNET
Nesta etapa, você precisará alternar para o modo arm . Faça isso com o seguinte comando.
azure config mode arm
Você pode usar o seguinte comando de CLI do PowerShell para verificar a quantidade atual de vCPUs no Azure
Resource Manager. Para saber mais sobre cotas de vCPUs, veja Limites e o Azure Resource Manager.
azure vm list-usage -l "<Your VNET or Deployment's Azure region"
Quando você terminar de verificar esta etapa, volte para o modo asm .
Etapa 4: Opção 1 – Migrar máquinas virtuais em um serviço de nuvem

Obtenha a lista de serviços de nuvem usando o comando a seguir e escolha o serviço de nuvem que deseja
migrar. Observe que, se as VMs no serviço de nuvem estiverem em uma rede virtual ou se tiverem funções
web/de trabalho, você receberá uma mensagem de erro.
azure service list
Execute a comando a seguir para obter o nome da implantação do serviço de nuvem por meio da saída
detalhada. Na maioria dos casos, o nome da implantação é igual ao nome do serviço de nuvem.
azure service show <serviceName> -vv
Primeiro, valide se você pode migrar o serviço de nuvem usando os seguintes comandos:
azure service deployment validate-migration <serviceName> <deploymentName> new "" "" ""
Prepare as máquinas virtuais no serviço de nuvem para migração. Você tem duas opções entre as quais
escolher.
Se quiser migrar as máquinas virtuais em uma rede virtual criada por plataforma, use o comando a seguir.
azure service deployment prepare-migration <serviceName> <deploymentName> new "" "" ""
Se quiser migrar para uma rede virtual existente no modelo de implantação do Gerenciador de Recursos, use o
comando a seguir.
azure service deployment prepare-migration <serviceName> <deploymentName> existing
<destinationVNETResourceGroupName> <subnetName> <vnetName>
Após uma operação de preparação bem-sucedida, você poderá examinar a saída detalhada para obter o estado
de migração das VMs e assegurar que as elas estejam no estado Prepared .
azure vm show <vmName> -vv
Verifique a configuração dos recursos preparados usando a CLI ou o portal do Azure. Se você não estiver pronto
para a migração e desejar voltar para o estado anterior, use o comando a seguir.
azure service deployment abort-migration <serviceName> <deploymentName>
Se a configuração preparada estiver correta, será possível continuar e confirmar os recursos usando o comando
a seguir.
azure service deployment commit-migration <serviceName> <deploymentName>
Etapa 4: Opção 2 – Migrar máquinas virtuais em uma rede virtual

Selecione a rede virtual que você deseja migrar. Observe que, se a rede virtual contiver funções web/de trabalho
ou VMs com configurações sem suporte, você receberá uma mensagem de erro de validação.
Obtenha todas as redes virtuais na assinatura usando o comando a seguir.
azure network vnet list
A saída será parecida com esta:
No exemplo acima, vir tualNetworkName é o nome inteiro “Grupo classicubuntu16 classicubuntu16” .

Primeiro, valide se você pode migrar a rede virtual usando o seguinte comando:
azure network vnet validate-migration <virtualNetworkName>
Prepare a rede virtual de sua preferência para migração usando o comando a seguir.
azure network vnet prepare-migration <virtualNetworkName>
Verifique a configuração para as máquinas virtuais preparadas usando a CLI ou o portal do Azure. Se você não
estiver pronto para a migração e desejar voltar para o estado anterior, use o comando a seguir.
azure network vnet abort-migration <virtualNetworkName>
a seguir.
azure network vnet commit-migration <virtualNetworkName>
Etapa 5: Migrar uma conta de armazenamento

Depois de concluir a migração das máquinas virtuais, recomendamos a migração da conta de armazenamento.
Prepare a conta de armazenamento para migração usando o comando a seguir
azure storage account prepare-migration <storageAccountName>
Verifique a configuração da conta de armazenamento preparada usando a CLI ou o Portal do Azure. Se você não
estiver pronto para a migração e desejar voltar para o estado anterior, use o comando a seguir.
azure storage account abort-migration <storageAccountName>
a seguir.
azure storage account commit-migration <storageAccountName>
Próximas etapas
Manager
Manager
Resource Manager
Resource Manager
Migrar recursos de IaaS do clássico para o Azure
Resource Manager usando o PowerShell
IMPORTANT
Estas etapas mostram como usar os comandos do Azure PowerShell para migrar os recursos de IaaS
(infraestrutura como serviço) do modelo de implantação clássico para o Modelo de implantação do Azure
Resource Manager.
Se desejar, você também pode migrar recursos usando o CLI do Azure.
Para obter informações sobre cenários de migração com suporte, confira Migração de recursos de IaaS com
suporte da plataforma do clássico ao Azure Resource Manager.
Para obter orientação e um passo a passo sobre a migração, confira Análise técnica aprofundada sobre a
migração com suporte da plataforma do clássico ao Azure Resource Manager.
Examine os erros de migração mais comuns.
Aqui está um fluxograma para identificar a ordem em que as etapas precisam ser executadas durante um processo
de migração.
Etapa 1: Planejar a migração

Aqui estão algumas práticas recomendadas que recomendamos à medida que você avaliar se deseja migrar os
recursos de IaaS do clássico para o Resource Manager:
Leia os recursos e configurações com e sem suporte. Se você tiver máquinas virtuais que usam recursos ou
configurações sem suporte, aguarde até que a configuração ou o suporte a recursos sejam anunciados.
Como alternativa, se isso atender às suas necessidades, remova esse recurso ou mude a configuração para
habilitar a migração.
Se você tiver scripts automatizados que implantam sua infraestrutura e aplicativos atualmente, tente criar
uma configuração de teste semelhante usando esses scripts para migração. Você também pode configurar
ambientes de exemplo usando o portal do Azure.
IMPORTANT
Atualmente, os gateways de aplicativo não têm suporte para migração do clássico para o Gerenciador de recursos. Para
migrar uma rede virtual com um gateway de aplicativo, remova o gateway antes de executar uma operação de
preparação para mover a rede. Depois de concluir a migração, reconecte o gateway no Azure Resource Manager.
Gateways do Azure ExpressRoute que se conectam a circuitos do ExpressRoute em outra assinatura não podem ser
migrados automaticamente. Nesses casos, remova o gateway de ExpressRoute, migre a rede virtual e recrie o gateway.
Para obter mais informações, consulte migrar circuitos de ExpressRoute e redes virtuais associadas do modelo de
implantação clássico para o Gerenciador de recursos.
Etapa 2: instalar a versão mais recente do PowerShell

Há duas opções principais para instalar o Azure PowerShell, a Galeria do PowerShell e o WebPI (Web Platform
Installer). WebPI recebe atualizações mensais. A Galeria do PowerShell receberá atualizações continuamente.
Este artigo tem base no Azure PowerShell versão 2.1.0.
Para obter instruções de instalação, consulte Como instalar e configurar o Azure PowerShell.
Etapa 3: Verifique se você é um administrador da assinatura

Para executar essa migração, você deve ser adicionado como um coadministrador para a assinatura no portal
do Azure.
2. No menu Hub , selecione assinatura . Caso não visualize essa opção, selecione Todos os ser viços .
3. Localize a entrada de assinatura apropriada e, em seguida, examine o campo minha função . Para um
coadministrador, o valor deve ser administrador da conta.
Se não for possível adicionar um coadministrador, entre em contato com um administrador de serviços ou
coadministrador da assinatura para se tornar adicionado.
Etapa 4: definir sua assinatura e inscrever-se para a migração

Primeiro, inicie um prompt do PowerShell. Para a migração, configure seu ambiente para o clássico e o Resource
Manager.
Entre em sua conta para o modelo do Gerenciador de Recursos.
Connect-AzAccount
Obtenha as assinaturas disponíveis usando o comando a seguir:
Get-AzSubscription | Sort Name | Select Name

Defina sua assinatura do Azure para a sessão atual. Este exemplo define o nome da assinatura padrão como
Minha Assinatura do Azure . Substitua o nome da assinatura de exemplo pelo nome da sua própria
assinatura.
Select-AzSubscription –SubscriptionName "My Azure Subscription"
NOTE
O registro é uma etapa única, mas você deve fazê-lo uma vez antes de tentar a migração. Sem o registro, você verá a
seguinte mensagem de erro:
BadRequest: a assinatura não está registrada para migração.
Registre-se no provedor de recursos de migração usando o comando a seguir:
Register-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
Aguarde cinco minutos para que o registro seja concluído. Verifique o status da aprovação usando o seguinte
comando:
Get-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate
Verifique se RegistrationState é Registered antes de continuar.

Antes de alternar para o modelo de implantação clássico, certifique-se de que você tenha Azure Resource
Manager de máquina virtual suficiente para o vCPUs na região do Azure da sua implantação atual ou rede
virtual. Você pode usar o seguinte comando do PowerShell para verificar a quantidade atual de vCPUs no Azure
Resource Manager. Para saber mais sobre cotas de vCPUs, veja Limites e o Azure Resource Manager.
Este exemplo verifica a disponibilidade na região Oeste dos EUA . Substitua o nome da região de exemplo pelo
nome da sua própria região.
Get-AzVMUsage -Location "West US"
Agora, entre em sua conta para o modelo de implantação clássico.
Add-AzureAccount
Obtenha as assinaturas disponíveis usando o comando a seguir:
Get-AzureSubscription | Sort SubscriptionName | Select SubscriptionName
Defina sua assinatura do Azure para a sessão atual. Este exemplo define a assinatura padrão como Minha
Assinatura do Azure . Substitua o nome da assinatura de exemplo pelo nome da sua própria assinatura.
Select-AzureSubscription –SubscriptionName "My Azure Subscription"
Etapa 5: Executar comandos para migrar os recursos de IaaS

Migrar VMs em um serviço de nuvem (não em uma rede virtual)
Migrar VMs em uma rede virtual
Migrar uma conta de armazenamento
NOTE
Todas as operações descritas aqui são idempotentes. Caso você tenha algum problema que não seja um recurso sem
suporte ou um erro de configuração, recomendamos que repita a operação de preparação, anulação ou confirmação. Em
seguida, a plataforma tentará novamente a ação.
Etapa 5,1: opção 1-migrar máquinas virtuais em um serviço de nuvem (não em uma rede virtual)
Obtenha a lista de serviços de nuvem usando o comando a seguir. Em seguida, escolha o serviço de nuvem que
você deseja migrar. Se as VMs no serviço de nuvem estiverem em uma rede virtual, ou se tiverem funções Web
ou de trabalho, o comando retornará uma mensagem de erro.
Get-AzureService | ft Servicename
Obtenha o nome da implantação do serviço de nuvem. Neste exemplo, o nome do serviço é Meu Ser viço .
Substitua o nome do serviço de exemplo pelo nome de seu próprio serviço.
$serviceName = "My Service"

$deployment = Get-AzureDeployment -ServiceName $serviceName
$deploymentName = $deployment.DeploymentName
Prepare as máquinas virtuais no serviço de nuvem para migração. Você tem duas opções entre as quais
escolher.
Opção 1: migre as VMs para uma rede vir tual criada por plataforma.
Primeiro, valide que você pode migrar o serviço de nuvem usando os seguintes comandos:
$validate = Move-AzureService -Validate -ServiceName $serviceName `

-DeploymentName $deploymentName -CreateNewVirtualNetwork
$validate.ValidationMessages
O comando a seguir exibe todos os avisos e erros que bloqueiam a migração. Se a validação for bem-
sucedida, você poderá passar para a etapa de preparação.
Move-AzureService -Prepare -ServiceName $serviceName `

-DeploymentName $deploymentName -CreateNewVirtualNetwork
Opção 2: migrar para uma rede vir tual existente no modelo de implantação do Gerenciador
de recursos.
Este exemplo define o nome do grupo de recursos como MyResource Group, o nome da rede virtual
como myVir tualNetwork e o nome da sub-rede como mysubnet . Substitua os nomes de exemplo
pelos nomes de seus próprios recursos.
$existingVnetRGName = "myResourceGroup"
$vnetName = "myVirtualNetwork"
$subnetName = "mySubNet"
Primeiro, valide que você pode migrar a rede virtual usando o seguinte comando:
$validate = Move-AzureService -Validate -ServiceName $serviceName `
-DeploymentName $deploymentName -UseExistingVirtualNetwork -VirtualNetworkResourceGroupName
$existingVnetRGName -VirtualNetworkName $vnetName -SubnetName $subnetName
$validate.ValidationMessages
O comando a seguir exibe todos os avisos e erros que bloqueiam a migração. Se a validação for bem-
sucedida, você poderá prosseguir com a seguinte etapa de preparação:
Move-AzureService -Prepare -ServiceName $serviceName -DeploymentName $deploymentName `

-UseExistingVirtualNetwork -VirtualNetworkResourceGroupName $existingVnetRGName `
-VirtualNetworkName $vnetName -SubnetName $subnetName
Após a operação de Preparação ser bem-sucedida com uma das opções anteriores, consulte o estado de
migração das VMs. Verifique se eles estão no Prepared estado.
Este exemplo define o nome da VM como myVM . Substitua o nome de exemplo pelo nome de sua própria VM.
$vmName = "myVM"
$vm = Get-AzureVM -ServiceName $serviceName -Name $vmName
$vm.VM.MigrationState
Verifique a configuração dos recursos preparados usando o PowerShell ou o Portal do Azure. Se você não
estiver pronto para a migração e quiser voltar ao estado antigo, use o seguinte comando:
Move-AzureService -Abort -ServiceName $serviceName -DeploymentName $deploymentName
a seguir:
Move-AzureService -Commit -ServiceName $serviceName -DeploymentName $deploymentName
Etapa 5,1: opção 2-migrar máquinas virtuais em uma rede virtual

Para migrar máquinas virtuais em uma rede virtual, migre a rede virtual. As máquinas virtuais são migradas
automaticamente com a rede virtual. Selecione a rede virtual que você deseja migrar.
NOTE
Migre uma única máquina virtual criada usando o modelo de implantação clássico criando uma nova máquina virtual do
Resource Manager com Managed disks usando os arquivos VHD (so e dados) da máquina virtual.
NOTE
O nome da rede virtual pode ser diferente do que é mostrado no novo Portal. O novo portal do Azure exibe o nome
como [vnet-name] , mas o nome real da rede virtual é do tipo Group [resource-group-name] [vnet-name] . Antes
de iniciar a migração, procure o nome da rede virtual real usando o comando
Get-AzureVnetSite | Select -Property Name ou exiba-o no portal do Azure antigo.
Este exemplo define o nome de rede virtual como myVnet . Substitua o nome de exemplo pelo nome da sua
própria rede virtual.
$vnetName = "myVnet"
NOTE
Se a rede virtual contiver funções Web ou de trabalho ou VMs com configurações sem suporte, você receberá uma
mensagem de erro de validação.
Primeiro, valide que você pode migrar a rede virtual usando o seguinte comando:
Move-AzureVirtualNetwork -Validate -VirtualNetworkName $vnetName
O comando a seguir exibe todos os avisos e erros que bloqueiam a migração. Se a validação for bem-sucedida,
você poderá prosseguir com a seguinte etapa de preparação:
Move-AzureVirtualNetwork -Prepare -VirtualNetworkName $vnetName
Verifique a configuração para as máquinas virtuais preparadas usando o Azure PowerShell ou o Portal do Azure.
Se você não estiver pronto para a migração e quiser voltar ao estado antigo, use o seguinte comando:
Move-AzureVirtualNetwork -Abort -VirtualNetworkName $vnetName
a seguir:
Move-AzureVirtualNetwork -Commit -VirtualNetworkName $vnetName
Etapa 5,2: migrar uma conta de armazenamento

Depois de terminar de migrar as máquinas virtuais, execute as seguintes verificações de pré-requisitos antes de
migrar as contas de armazenamento.
NOTE
Se sua conta de armazenamento não tiver discos associados ou dados de VM, você poderá pular diretamente para a
seção "validar contas de armazenamento e iniciar a migração". Observe também que a exclusão dos discos clássicos,
imagens de VM ou imagens do sistema operacional não remove os arquivos VHD de origem na conta de
armazenamento. No entanto, ele interrompe a concessão nesses arquivos VHD para que eles possam ser reutilizados para
criar discos ou imagens ARM após a migração.
As verificações de pré-requisitos se você migrou qualquer VM ou sua conta de armazenamento tem

recursos de disco:
Migre máquinas virtuais cujos discos estejam armazenados na conta de armazenamento.
O comando a seguir retorna as propriedades RoleName e diskname de todos os discos de VM na
conta de armazenamento. RoleName é o nome da máquina virtual à qual um disco está anexado.
Se esse comando retornar discos, verifique se as máquinas virtuais para as quais esses discos
estão anexados são migradas antes de migrar a conta de armazenamento.
$storageAccountName = 'yourStorageAccountName'
Get-AzureDisk | where-Object {$_.MediaLink.Host.Contains($storageAccountName)} | Select-
Object -ExpandProperty AttachedTo -Property `
DiskName | Format-List -Property RoleName, DiskName
Exclua os discos de VM desanexados armazenados na conta de armazenamento.

Localize discos de VM desconectados na conta de armazenamento usando o seguinte comando:
$storageAccountName = 'yourStorageAccountName'
Get-AzureDisk | where-Object {$_.MediaLink.Host.Contains($storageAccountName)} | Where-
Object -Property AttachedTo -EQ $null | Format-List -Property DiskName
Se o comando anterior retornar discos, exclua esses discos usando o seguinte comando:
Remove-AzureDisk -DiskName 'yourDiskName'
Exclua as imagens de VM armazenadas na conta de armazenamento.

O comando a seguir retorna todas as imagens de VM com discos de sistema operacional
armazenados na conta de armazenamento.
Get-AzureVmImage | Where-Object { $_.OSDiskConfiguration.MediaLink -ne $null -and

$_.OSDiskConfiguration.MediaLink.Host.Contains($storageAccountName)`
} | Select-Object -Property ImageName, ImageLabel
O comando a seguir retorna todas as imagens de VM com discos de dados armazenados na conta
de armazenamento.
Get-AzureVmImage | Where-Object {$_.DataDiskConfigurations -ne $null `

-and ($_.DataDiskConfigurations | Where-Object
{$_.MediaLink -ne $null -and $_.MediaLink.Host.Contains($storageAccountName)}).Count -gt 0 `
} | Select-Object -Property ImageName, ImageLabel
Exclua todas as imagens de VM retornadas pelos comandos anteriores usando este comando:
Remove-AzureVMImage -ImageName 'yourImageName'
Valide as contas de armazenamento e inicie a migração.

Valide cada conta de armazenamento para migração usando o comando a seguir. Neste exemplo, o nome
da conta de armazenamento é myStorageAccount . Substitua o nome de exemplo pelo nome da sua
própria conta de armazenamento.
$storageAccountName = "myStorageAccount"
Move-AzureStorageAccount -Validate -StorageAccountName $storageAccountName
A próxima etapa é preparar a conta de armazenamento para a migração.

$storageAccountName = "myStorageAccount"
Move-AzureStorageAccount -Prepare -StorageAccountName $storageAccountName
Verifique a configuração da conta de armazenamento preparada usando o Azure PowerShell ou o Portal

do Azure. Se você não estiver pronto para a migração e quiser voltar ao estado antigo, use o seguinte
comando:
Move-AzureStorageAccount -Abort -StorageAccountName $storageAccountName
Se a configuração preparada estiver correta, será possível continuar e confirmar os recursos usando o
comando a seguir:
Move-AzureStorageAccount -Commit -StorageAccountName $storageAccountName
Próximas etapas
Manager
Manager
Resource Manager
Resource Manager
Erros que normalmente ocorrem durante a
migração do clássico para Azure Resource Manager
IMPORTANT
Este artigo cataloga os erros e mitigações mais comuns durante a migração de recursos de IaaS do modelo de
implantação clássico do Azure para a pilha do Azure Resource Manager.
Lista de erros
C A DEIA DE C A RA C T ERES DE ERRO AT EN UA Ç Ã O
Erro interno do servidor Em alguns casos, isso é um erro transitório desaparece com
uma nova tentativa. Se ele persistir, entre em contato com o
suporte do Azure pois ele precisará de investigação dos logs
da plataforma.
OBSERVAÇÃO: não tente realizar nenhuma automitigação

depois que o incidente for controlado pela equipe de
suporte, pois isso poderá ter consequências indesejadas em
seu ambiente.
Não há suporte para migração para implantação Isso ocorre quando uma implantação contém uma função de
{nome_da_implantação} em {nome_do_serviço_hospedado} trabalho/Web. Uma vez que a migração tem suporte apenas
HostedService porque é uma implantação de PaaS para máquinas virtuais, remova a função Web/de trabalho
(Web/Trabalho). da implantação e tente novamente a migração.
Falha na implantação do modelo {nome_do_ modelo}. No back-end do serviço de migração, usamos modelos do
CorrelationId={guid} Azure Resource Manager para criar recursos na pilha do
Azure Resource Manager. Já que os modelos são
idempotentes, geralmente você pode realizar com segurança
novas tentativas da operação de migração para passar por
esse erro. Se esse erro persistir, faça entre em contato com o
suporte do Azure e dê a eles a CorrelationId.
OBSERVAÇÃO: não tente realizar nenhuma automitigação

depois que o incidente for controlado pela equipe de
suporte, pois isso poderá ter consequências indesejadas em
seu ambiente.
A rede virtual {nome_da_ rede_virtual} não existe. Isso poderá acontecer se você tiver criado a rede virtual no
novo Portal do Azure. O nome de rede virtual real segue o
padrão "Group * <VNET name>"
A VM {nome_da_VM} no HostedService Extensões XML como o BGInfo 1. * Não têm suporte no

{nome_do_serviço_hospedado} contém a Extensão Azure Resource Manager. Portanto, essas extensões não
{nome_da_extensão} para a qual não há suporte no Azure podem ser migradas. Se essas extensões forem deixadas
Resource Manager. É recomendável desinstalá-la da VM instaladas na máquina virtual, elas serão automaticamente
antes de continuar com a migração. desinstaladas antes da conclusão da migração.
A VM {nome_da_VM} no serviço hospedado Esse é o cenário em que a máquina virtual está configurada
{nome_do_serviço_hospedado} contém a Extensão para o Backup do Azure. Como atualmente este é um
VMSnapshot/VMSnapshotLinux, que atualmente não tem cenário sem suporte, siga a solução
suporte para Migração. Desinstale-a da VM e adicione-a https://aka.ms/vmbackupmigration
usando o Azure Resource Manager após a conclusão da
migração
A VM {nome_da_VM} no serviço hospedado O agente convidado do Azure e extensões de VM precisam

{nome_do_serviço_hospedado} contém a Extensão de acesso de saída à Internet para que seus status sejam
{nome_da_extensão}, cujo status não está sendo relatado da populados pela conta de armazenamento da VM. Causas
VM. Portanto, esta VM não pode ser migrada. Certifique-se comuns de falha de status incluem
de que o status da Extensão está sendo relatado ou um Grupo de Segurança de Rede que bloqueia o acesso
desinstale a extensão da VM e tente novamente realizar a de saída à Internet
migração. Se a VNET tiver servidores DNS locais e a conectividade de
DNS for perdida
A VM {nome_da_VM} no serviço hospedado
{nome_do_serviço_hospedado} contém a Extensão Se você continuar a ver um status sem suporte, você poderá
{nome_da_extensão} relatando o status do manipulador: desinstalar as extensões para ignorar essa verificação e
{status_do_manipulador}. Portanto, a VM não pode ser prosseguir com a migração.
migrada. Certifique-se de que o status do manipulador de
Extensões sendo relatado é {status_do_manipulador} ou
desinstale-o da VM e tente novamente realizar a migração.
Agente de VM para a VM {nome_da_VM} no serviço

hospedado {nome_do_serviço_hospedado} está relatando o
status geral do agente como Não Pronto. Portanto, se a VM
tiver uma extensão migrável, ela não poderá ser migrada.
Certifique-se de que o agente de VM esteja relatando o
status do agente geral como Pronto. Consulte
https://aka.ms/classiciaasmigrationfaqs.
Não há suporte para migração para implantação Atualmente, apenas os serviços hospedados com um ou
{nome_da_implantação} no serviço hospedado nenhum conjunto de disponibilidade podem ser migrados.
{nome_do_serviço_hospedado} porque ele tem vários Para contornar esse problema, mova os conjuntos de
conjuntos de disponibilidade. disponibilidade adicionais e as máquinas virtuais nesses
conjuntos de disponibilidade para um serviço hospedado
diferente.
Não há suporte para migração para a implantação A solução para esse cenário é para mover todas as máquinas
{nome_da_implantação} no serviço hospedado virtuais para um único conjunto de disponibilidade ou
{nome_do_serviço_hospedado} porque ela tem VMs que não remover todas as máquinas virtuais do conjunto de
são parte do conjunto de disponibilidade, embora o serviço disponibilidade no serviço hospedado.
hospedado contenha uma.
A conta de armazenamento/serviço hospedado/rede virtual Esse erro ocorre quando a operação de migração "Prepare"
{nome_da_rede_virtual} está no processo de migração e, foi concluída no recurso e uma operação que faça uma
portanto, não pode ser alterada alteração no recurso é disparada. Por causa do bloqueio no
plano de gerenciamento após a operação de "Prepare", as
alterações ao recurso são bloqueadas. Para desbloquear o
plano de gerenciamento, você pode executar a operação de
migração de "Commit" para concluir a migração ou a
operação de migração "Abort" para reverter a operação
"Prepare".
A migração não é permitida para o serviço hospedado A VM pode estar passando por uma transição de estado,
{nome_do_serviço_hospedado} porque ele tem a VM que geralmente ocorre quando durante uma operação de
{nome_da_vm} no estado: RoleStateUnknown. A migração é atualização no HostedService, como uma reinicialização, a
permitida somente quando a VM está em um dos seguintes instalação da extensão, etc. É recomendável que a operação
estados – Em execução, Parada, Interrompida, Desalocada. de atualização seja concluída no HostedService antes de
tentar a migração.
A implantação {deployment-name} em HostedService Esse erro ocorre se você redimensionar o blob VHD sem
{hosted-service-name} contém uma VM {vm-name} com atualizar o tamanho do modelo da API da VM. As etapas de
Disco de Dados {data-disk-name} cujo tamanho de blob atenuação detalhadas estão descritas abaixo.
físico de {size-of-the-vhd-blob-backing-the-data-disk} bytes
não corresponde ao tamanho lógico do Disco de Dados da
VM de {size-of-the-data-disk-specified-in-the-vm-api} bytes.
A migração continuará sem especificar um tamanho para o
disco de dados para a VM do Azure Resource Manager.
Ocorreu uma exceção de armazenamento ao validar o disco Esse erro poderá ocorrer se os discos da VM tiverem sido
de dados {nome do disco de dados} com link de mídia {Uri excluídos ou não estiverem mais acessíveis. Verifique se os
do disco de dados} para VM {nome da VM} no Serviço de discos para a VM existem.
Nuvem {nome do Serviço de Nuvem}. Assegure-se de que o
link de mídia VHD possa ser acessado para esta máquina
virtual
A VM {vm-name} em HostedService {cloud-service-name} Esse erro ocorre quando o nome do blob tem um "/" dentro
contém o Disco com MediaLink {vhd-uri} que tem o nome dele que não tem suporte no Provedor de Recursos de
do blob {vhd-blob-name}, que não é suportado no Azure Computação no momento.
Resource Manager.
A migração não é permitida para a Implantação {nome- Em 2014, o Azure anunciou que os recursos de rede seriam
implantação} no HostedService {nome-serviço-nuvem}, pois movidos de um escopo no nível do cluster para um escopo
não está no escopo regional. Consulte https: / regional. Consulte https://aka.ms/regionalscope para obter
/aka.ms/regionalscope para mover essa implantação para o mais detalhes. Esse erro ocorre quando a implantação sendo
escopo regional. migrada não teve uma operação de atualização que a move
automaticamente para um escopo regional. A melhor
solução alternativa é adicionar um ponto de extremidade a
uma VM ou um disco de dados à VM e, em seguida, tentar a
migração novamente.
Consulte Como configurar os pontos de extremidade em
uma máquina virtual clássica do Windows no Azure ou
Anexar um disco de dados a uma máquina virtual do
Windows criada com o modelo de implantação clássico
A migração não é compatível com a Rede Virtual {vnet- Esse erro ocorre quando você tem implantações PaaS de não
name} porque ela contém implantações e PaaS de não gateway como os serviços de gerenciamento de API ou
gateway. Gateway do aplicativo que estão conectados à Rede Virtual.
Atenuação detalhada
A VM com o Disco de Dados cujo tamanho de blob físico é de bytes não corresponde ao tamanho lógico do
Disco de Dados da VM de bytes.
Isso acontece quando o tamanho lógico do Disco de Dados perde a sincronia com o tamanho real do blob VHD.
Isso pode ser facilmente verificado usando os seguintes comandos:
Verificando o problema
# Store the VM details in the VM object
$vm = Get-AzureVM -ServiceName $servicename -Name $vmname
# Display the data disk properties

# NOTE the data disk LogicalDiskSizeInGB below which is 11GB. Also note the MediaLink Uri of the VHD blob as
we'll use this in the next step
$vm.VM.DataVirtualHardDisks
HostCaching : None
DiskLabel :
DiskName : coreosvm-coreosvm-0-201611230636240687
Lun : 0
LogicalDiskSizeInGB : 11
MediaLink : https://contosostorage.blob.core.windows.net/vhds/coreosvm-dd1.vhd
SourceMediaLink :
IOType : Standard
ExtensionData :
# Now get the properties of the blob backing the data disk above
# NOTE the size of the blob is about 15 GB which is different from LogicalDiskSizeInGB above
$blob = Get-AzStorageblob -Blob "coreosvm-dd1.vhd" -Container vhds
$blob
ICloudBlob : Microsoft.WindowsAzure.Storage.Blob.CloudPageBlob
BlobType : PageBlob
Length : 16106127872
ContentType : application/octet-stream
LastModified : 11/23/2016 7:16:22 AM +00:00
SnapshotTime :
ContinuationToken :
Context : Microsoft.WindowsAzure.Commands.Common.Storage.AzureStorageContext
Name : coreosvm-dd1.vhd
Atenuando o problema
# Convert the blob size in bytes to GB into a variable which we'll use later
$newSize = [int]($blob.Length / 1GB)
# See the calculated size in GB

$newSize
15
# Store the disk name of the data disk as we'll use this to identify the disk to be updated
$diskName = $vm.VM.DataVirtualHardDisks[0].DiskName
# Identify the LUN of the data disk to remove

$lunToRemove = $vm.VM.DataVirtualHardDisks[0].Lun
# Now remove the data disk from the VM so that the disk isn't leased by the VM and it's size can be updated
Remove-AzureDataDisk -LUN $lunToRemove -VM $vm | Update-AzureVm -Name $vmname -ServiceName $servicename
OperationDescription OperationId OperationStatus

-------------------- ----------- ---------------
Update-AzureVM 213xx1-b44b-1v6n-23gg-591f2a13cd16 Succeeded
# Verify we have the right disk that's going to be updated

Get-AzureDisk -DiskName $diskName
AffinityGroup :
AttachedTo :
IsCorrupted : False
Label :
Location : East US
DiskSizeInGB : 11
DiskSizeInGB : 11
SourceImageName :
OS :
IOType : Standard
OperationDescription : Get-AzureDisk
OperationId : 0c56a2b7-a325-123b-7043-74c27d5a61fd
OperationStatus : Succeeded
# Now update the disk to the new size

Update-AzureDisk -DiskName $diskName -ResizedSizeInGB $newSize -Label $diskName

-------------------- ----------- ---------------
Update-AzureDisk cv134b65-1b6n-8908-abuo-ce9e395ac3e7 Succeeded
# Now verify that the "DiskSizeInGB" property of the disk matches the size of the blob
Get-AzureDisk -DiskName $diskName
AffinityGroup :
AttachedTo :
IsCorrupted : False
Label : coreosvm-coreosvm-0-201611230636240687
Location : East US
DiskSizeInGB : 15
SourceImageName :
OS :
IOType : Standard
OperationDescription : Get-AzureDisk
OperationId : 1v53bde5-cv56-5621-9078-16b9c8a0bad2
OperationStatus : Succeeded
# Now we'll add the disk back to the VM as a data disk. First we need to get an updated VM object
$vm = Get-AzureVM -ServiceName $servicename -Name $vmname
Add-AzureDataDisk -Import -DiskName $diskName -LUN 0 -VM $vm -HostCaching ReadWrite | Update-AzureVm -Name
$vmname -ServiceName $servicename

-------------------- ----------- ---------------
Update-AzureVM b0ad3d4c-4v68-45vb-xxc1-134fd010d0f8 Succeeded
Como mover uma VM para uma assinatura diferente após a conclusão da migração
Depois de concluir o processo de migração, talvez você queira mover a VM para outra assinatura. No entanto, se
você tiver um segredo/certificado na VM que faça referência a um recurso do Key Vault, a movimentação
atualmente não tem suporte. As instruções abaixo lhe permitirão contornar o problema.
PowerShell
$vm = Get-AzVM -ResourceGroupName "MyRG" -Name "MyVM"

Remove-AzVMSecret -VM $vm
Update-AzVM -ResourceGroupName "MyRG" -VM $vm
CLI do Azure
az vm update -g "myrg" -n "myvm" --set osProfile.Secrets=[]
Próximas etapas
Manager
Manager
Resource Manager
Resource Manager
Ferramentas da comunidade para migrar recursos
de IaaS do clássico para o Azure Resource Manager
IMPORTANT
Este artigo cataloga as ferramentas que foram fornecidas pela comunidade para auxiliar com a migração dos
recursos de IaaS do modelo de implantação clássico para o modelo de implantação do Azure Resource Manager.
NOTE
Não há suporte oficial para essas ferramentas no Suporte da Microsoft. Portanto, são software livre no GitHub e
aceitamos PRs para correções ou cenários adicionais. Para relatar um problema, use o recurso de problemas do GitHub.
A migração com essas ferramentas causará tempo de inatividade de sua Máquina Virtual clássica. Se você estiver
buscando uma migração da plataforma com suporte, visite
Platform supported migration of IaaS resources from Classic to Azure Resource Manager stack (Migração de recursos
de IaaS com suporte da plataforma da pilha Clássica para o Azure Resource Manager)
Análise técnica aprofundada sobre a migração com suporte da plataforma do Clássico para o Azure Resource Manager
Migrar recursos de IaaS do Clássico para o Azure Resource Manager usando o Azure PowerShell
AsmMetadataParser
Trata-se de uma coleção de ferramentas auxiliares criadas como parte de migrações empresariais do
Gerenciamento de Serviços do Azure para o Azure Resource Manager. Essa ferramenta permite replicar sua
infraestrutura para outra assinatura, o que pode ser usado para testar a migração e solucionar problemas antes
de executar a migração em sua assinatura de produção.
Link para a documentação da ferramenta
migAz
migAz é uma opção adicional para migrar um conjunto completo de recursos de IaaS clássicos para recursos de
IaaS do Azure Resource Manager. A migração pode ocorrer na mesma assinatura ou entre assinaturas e tipos de
assinatura diferentes (por ex.: assinaturas do CSP).
Link para a documentação da ferramenta
Próximas etapas
Manager
Manager
Resource Manager
Perguntas frequentes sobre a migração clássica para
a migração do Azure Resource Manager
IMPORTANT
O que é o Service Manager do Azure e o que isso significa por

clássico?
A palavra "clássico" na VM IaaS (clássica) refere-se a VMs gerenciadas pelo ASM (Service Manager do Azure). O
ASM (Service Manager do Azure) é o antigo plano de controle do Azure responsável por criar, gerenciar, excluir
VMs e executar outras operações de plano de controle.
O que é o Azure Resource Manager?

Azure Resource Manager é o plano de controle mais recente do Azure responsável por criar, gerenciar, excluir
VMs e executar outras operações de plano de controle.
Qual é o tempo necessário para a migração?

O planejamento e a execução da migração dependem muito da complexidade da arquitetura e pode levar
alguns meses.
Qual é a definição de um novo cliente em VMs de IaaS (clássicas)?

Os clientes que não tiverem VMs IaaS (clássicas) em suas assinaturas no mês de fevereiro de 2020 (um mês
antes da reprovação iniciada) serão considerados como novos clientes.
Qual é a definição de um cliente existente em Máquinas Virtuais de

IaaS (clássicas)?
Os clientes que tinham VMs de IaaS (clássicas) ativas ou paradas, mas alocadas, em suas assinaturas no mês de
fevereiro de 2020 são considerados como clientes existentes. Somente esses clientes tem até 1º de março de
2023 para migrar suas VMs do Azure Service Manager para o Azure Resource Manager.
Por que estou recebendo um erro informando

"NewClassicVMCreationNotAllowedForSubscription"?
Como parte do processo de desativação, a VM de IaaS (clássica) não está mais disponível para novos clientes.
Identificamos você como novo cliente e, portanto, sua operação não foi autorizada. É altamente recomendável
usar Azure Resource Manager. Se você não puder usar as VMs do Azure usando Azure Resource Manager, entre
em contato com o suporte para adicionar sua assinatura à lista de permissões.
Este plano de migração afeta qualquer um de meus serviços
existentes ou aplicativos executados em máquinas virtuais do Azure?
Não até 1º de março de 2023 para VMs de IaaS (clássicas). As VMs de IaaS (clássicas) são serviços com suporte
total na disponibilidade geral. É possível continuar usando esses recursos para expandir seu volume no
Microsoft Azure. Em 1º de março de 2023, essas VMs serão totalmente desativadas e todas as VMs ativas ou
alocadas serão interrompidas e desalocadas.
Não haverá nenhum impacto para outros recursos clássicos, como Serviços de Nuvem (clássicos), Contas de
Armazenamento (clássicas) etc.
O que acontecerá com minhas VMs se eu não planejar a migração no

futuro próximo?
Em 1º de março de 2023, as VMs de IaaS (clássicas) serão totalmente desativadas e todas as VMs ativas ou
alocadas serão interrompidas e desalocadas. Para evitar o impacto nos negócios, nós recomentamos começar a
planejar sua migração hoje mesmo e concluí-la antes de 1º de março de 2023. Não estamos preterindo as APIs,
os Serviços de Nuvem e o modelo de recursos clássicos existentes. Queremos simplificar a migração,
considerando os recursos avançados disponíveis no modelo de implantação do Gerenciador de Recursos.
Recomendamos que você comece a planejar a migração desses recursos para o Azure Resource Manager.
O que este plano de migração significa para minhas ferramentas

existentes?
Atualizar suas ferramentas para o modelo de implantação do Gerenciador de Recursos é uma das alterações
mais importantes que você precisa considerar em seus planos de migração.
O tempo de inatividade do plano de gerenciamento será de quanto

tempo?
Isso depende do número de recursos que estão sendo migrados. Para implantações menores (algumas dezenas
de VMs), a migração inteira deverá levar menos de uma hora. Para implantações de larga escala (centenas de
VMs), a migração poderá levar algumas horas.
Poderei reverter depois que meus recursos de migração forem

confirmados no Gerenciador de Recursos?
É possível anular a migração, desde que os recursos estejam no estado preparado. Não há suporte para
reversão depois que os recursos forem migrados com êxito por meio da operação de confirmação.
Poderei reverter minha migração se a operação de confirmação

falhar?
Não será possível anular a migração se a operação de confirmação falhar. Todas as operações de migração,
incluindo a operação de confirmação, são idempotentes. Portanto, recomendamos que você repita a operação
após um curto período. Se você ainda encontrar um erro, crie um tíquete de suporte.
Será necessário comprar outro circuito de Rota Expressa se eu

precisar aproveitar usar a IaaS no Gerenciador de Recursos?
Não. Habilitamos recentemente a movimentação dos circuitos da ExpressRoute do clássico para o modelo de
implantação do Gerenciador de Recursos. Você não precisará comprar um novo circuito de ExpressRoute se já
tiver um.
E se eu tiver configurado políticas de controle de acesso baseado em

função do Azure para meus recursos clássicos de IaaS?
Durante a migração, os recursos se transformam do clássico para o Gerenciador de Recursos. Portanto,
recomendamos que você planeje as atualizações de política do RBAC do Azure que precisam ocorrer após a
migração.
Fiz backup de minhas VMs clássicas em um cofre. Posso migrar

minhas VMs de modo clássico para modo do Resource Manager e
protegê-los em um cofre dos Serviços de Recuperação?
Quando você mover uma VM do modo clássico para o modo do Resource Manager, os backups feitos antes da
migração não serão migrados para a VM recém-migrada do Resource Manager. No entanto, caso deseje manter
os backups das VMs clássicas, siga estas etapas antes da migração.
1. No cofre dos serviços de recuperação, vá para a folha itens de backup e selecione a VM.
2. Clique em parar backup. Selecione "reter dados de backup" no menu suspenso.
NOTE
Esta opção impedirá que todos os trabalhos de backup futuros protejam sua VM. No entanto, o serviço de backup do
Azure manterá os pontos de recuperação que foram armazenados em backup. Você precisará pagar para manter os
pontos de recuperação no cofre (consulte preços de backup do Azure para obter detalhes). Você poderá restaurar a VM,
se necessário. Se você decidir retomar a proteção da VM, poderá usar a opção retomar backup .
Para migrar a máquina virtual para o modo do Resource Manager,

1. Exclua a extensão de backup/instantâneo da VM.
2. Migre a máquina virtual do modo clássico para o modo do Gerenciador de Recursos. As informações de
armazenamento e de rede correspondentes à máquina virtual também precisam ser migradas para o modo
do Resource Manager.
Além disso, caso deseje fazer backup da VM migrada, acesse a folha de gerenciamento da Máquina Virtual para
habilitar o backup.
Posso validar minha assinatura ou meus recursos para ver se eles

podem fazer a migração?
Sim. Na opção de migração com suporte de plataforma, a primeira etapa para preparar a migração é validar se
os recursos podem fazer a migração. Caso a operação de validação falhe, você recebe todas as mensagens
relativas a todos os motivos pelos quais a migração não pode ser concluída.
O que acontecerá se eu encontrar um erro de cota ao preparar os

recursos de IaaS para migração?
É recomendável anular a migração e, em seguida, registrar uma solicitação de suporte para aumentar as cotas
na região onde você está migrando as VMs. Depois que a solicitação de cota for aprovada, você poderá iniciar a
execução das etapas de migração novamente.
Como faço para relatar um problema?
Poste suas perguntas e dúvidas sobre migração em nossa Página de P e R da Microsoft para VM, com a palavra-
chave ClassicIaaSMigration. É recomendável postar todas as suas dúvidas neste fórum. Caso você tenha um
contrato de suporte, será possível registrar um tíquete de suporte.
E se eu não gostar dos nomes dos recursos que a plataforma

escolheu durante a migração?
Todos os recursos para os quais você fornecer nomes explicitamente no modelo de implantação clássica são
retidos durante a migração. Em alguns casos, novos recursos são criados. Por exemplo: uma interface de rede é
criada para cada VM. No momento, não há suporte para a capacidade de controlar os nomes dos novos
recursos criados durante a migração. Registre seus votos para esse recurso no fórum de comentários do Azure.
Posso migrar circuitos de ExpressRoute usados em assinaturas com

links de autorização?
Os circuitos de ExpressRoute que usam links de autorização entre assinaturas não podem ser migrados
automaticamente sem tempo de inatividade. Temos orientações sobre como eles podem ser migrados usando
as etapas manuais. Confira Migrar circuitos de ExpressRoute e redes virtuais associadas do modelo de
implantação clássico para o Resource Manager para obter etapas e mais informações.
Recebi a mensagem "A VM está informando o status geral do agente

como Não Pronto. Portanto, a VM não pode ser migrada. Certifique-
se de que o Agente da VM esteja informando o status geral do
agente como Pronto" ou "A VM contém uma Extensão cujo status não
está sendo informado. Portanto, esta VM não pode ser migrada."
Essa mensagem é recebida quando a VM não tem conectividade de saída com a Internet. O agente de VM utiliza
conectividade de saída para acessar a conta de armazenamento do Azure para atualizar o status do agente a
cada cinco minutos.
Próximas etapas
Para Linux:
Manager
Manager
Resource Manager
Para Windows:
Manager
Manager
Resource Manager
Tutorial: Saiba mais sobre o gerenciamento de
máquinas virtuais do Linux com a CLI do Azure
Ao implantar recursos para o Azure, você terá uma enorme flexibilidade para decidir quais tipos de recursos
implantar, onde estarão localizados e como configurá-los. No entanto, essa flexibilidade pode abrir mais opções
que você desejaria permitir na sua organização. Ao considerar a implantação de recursos para o Azure, você
deve estar se perguntando:
Como atender aos requisitos legais para a soberania de dados em determinados países/regiões?
Como controlar os custos?
Como garantir que alguém não altere inadvertidamente um sistema crítico?
Como fazer para rastrear os custos de recurso e cobrá-los com precisão?
Este artigo aborda essas questões. Especificamente, você:
Atribui usuários a funções e atribui funções a um escopo, de modo que os usuários tenham permissão para
executar as ações esperadas, mas não ações adicionais.
Aplica políticas que prescrevem convenções para recursos em sua assinatura.
Bloqueia recursos que sejam críticos ao sistema.
Marca recursos para que possam ser rastreados por meio dos valores adequados à sua organização.
Este artigo concentra-se nas tarefas realizadas para implementar governança. Para uma discussão mais
abrangente sobre os conceitos, consulte Governança no Azure.
Pré-requisitos

Este tutorial requer a versão 2.0.30 ou posterior da CLI do Azure. Se você está usando o Azure Cloud Shell, a
Compreender o escopo
Antes de criar qualquer item, vamos revisar o conceito de escopo. O Azure fornece quatro níveis de
gerenciamento: grupos de gerenciamento, assinatura, grupo de recursos e recursos. Grupos de gerenciamento
estão em uma versão prévia. A imagem a seguir mostra um exemplo dessas camadas.
As configurações de gerenciamento são aplicadas em qualquer desses níveis de escopo. O nível que você
seleciona determina o quão amplamente a configuração é aplicada. Os níveis inferiores herdam as
configurações de níveis superiores. Ao aplicar uma configuração à assinatura, essa configuração será aplicada a
todos os grupos de recursos e recursos em sua assinatura. Ao aplicar uma configuração no grupo de recursos,
essa configuração será aplicada ao grupo de recursos e a todos os recursos. No entanto, outro grupo de
recursos não possuirá essa configuração.
Normalmente, é adequado aplicar configurações críticas em níveis superiores e requisitos específicos do projeto
em níveis inferiores. Por exemplo, você pode querer garantir que todos os recursos para sua organização sejam
implantados em determinadas regiões. Para cumprir esse requisito, aplique uma política à assinatura que
especifica as localizações permitidas. Na medida em que outros usuários em sua organização adicionarem
novos recursos e grupos de recursos, as localizações permitidas serão aplicadas automaticamente.
Neste tutorial, você aplica todas as configurações de gerenciamento a um grupo de recursos, de modo que seja
possível remover facilmente essas configurações quando terminar.
Vamos criar esse grupo de recursos.
az group create --name myResourceGroup --location "East US"
Atualmente, o grupo de recursos está vazio.
Controle de acesso baseado em função do Azure

Você deseja certificar-se de que os usuários em sua organização têm o nível certo de acesso a esses recursos.
Você não deseja conceder acesso ilimitado a usuários, mas também precisa certificar-se de que eles podem
fazer o trabalho deles. O Azure RBAC (controle de acesso baseado em função do Azure) permite que você
gerencie quais usuários têm permissão para executar ações específicas em um escopo.
Para criar e remover as atribuições de função, os usuários devem ter Microsoft.Authorization/roleAssignments/*
acesso. Esse acesso deve ser concedido pelas funções Proprietário ou Administrador de Acesso do Usuário.
Para gerenciar soluções de máquinas virtuais, há três funções específicas do recurso que fornecem acesso
comum:
Colaborador de Máquina Virtual
Colaborador de rede
Colaborador da Conta de Armazenamento
Em vez de atribuir funções a usuários individuais, muitas vezes é mais fácil usar um grupo do Azure Active
Directory que tenha usuários que precisam realizar ações semelhantes. E, em seguida, atribuir esse grupo à
função apropriada. Neste artigo, use um grupo existente para gerenciar a máquina virtual ou use o portal para
criar um grupo do Azure Active Directory.
Após criar um novo grupo ou encontrar um existente, use o comando az role assignment create para atribuir o
novo grupo do Azure Active Directory à função de Colaborador da Máquina Virtual para o grupo de recursos.
adgroupId=$(az ad group show --group <your-group-name> --query objectId --output tsv)
az role assignment create --assignee-object-id $adgroupId --role "Virtual Machine Contributor" --resource-
group myResourceGroup
Se você receber um erro informando Entidade de segurança <guid> não existe no diretório , o novo
grupo ainda não foi propagado em todo o Azure Active Directory. Tente executar o comando novamente.
Normalmente, você repete o processo para Colaborador de Rede e Colaborador da Conta de Armazenamento,
visando certificar-se de que os usuários serão designados para gerenciar os recursos implantados. Neste artigo,
você pode ignorar essas etapas.
Azure Policy
O Azure Policy ajuda a garantir que todos os recursos da assinatura atendam aos padrões corporativos. Sua
assinatura já possui várias definições de políticas. Para ver as definições de política disponíveis, use o comando
az policy definition list:
az policy definition list --query "[].[displayName, policyType, name]" --output table
Você vê as definições de políticas existentes. O tipo de política é BuiltIn ou Personalizada . Procure as

definições para aqueles que descrevem uma condição que você quer atribuir. Neste artigo, você atribui políticas
que:
Limitam os locais para todos os recursos.
Limitam as SKUs para máquinas virtuais.
Auditam máquinas virtuais que não utilizam discos gerenciados.
No exemplo a seguir, você pode recuperar três definições de política com base no nome de exibição. Você usa o
comando az policy assignment create para atribuir essas definições ao grupo de recursos. Para algumas
políticas, você deve fornecer valores de parâmetro para especificar os valores permitidos.
# Get policy definitions for allowed locations, allowed SKUs, and auditing VMs that don't use managed disks
locationDefinition=$(az policy definition list --query "[?displayName=='Allowed locations'].name | [0]" --
output tsv)
skuDefinition=$(az policy definition list --query "[?displayName=='Allowed virtual machine SKUs'].name |
[0]" --output tsv)
auditDefinition=$(az policy definition list --query "[?displayName=='Audit VMs that do not use managed
disks'].name | [0]" --output tsv)
# Assign policy for allowed locations

az policy assignment create --name "Set permitted locations" \
--policy $locationDefinition \
--params '{
"listOfAllowedLocations": {
"value": [
"eastus",
"eastus2"
]
}
}'
# Assign policy for allowed SKUs

az policy assignment create --name "Set permitted VM SKUs" \
--policy $skuDefinition \
--params '{
"listOfAllowedSKUs": {
"value": [
"Standard_DS1_v2",
"Standard_E2s_v2"
]
}
}'
# Assign policy for auditing unmanaged disks

az policy assignment create --name "Audit unmanaged disks" \
--policy $auditDefinition
O exemplo anterior pressupõe que você já conhece os parâmetros para uma política. Se precisar exibir os
parâmetros, use:
az policy definition show --name $locationDefinition --query parameters
Implantar a máquina virtual

Você atribuiu funções e políticas, entãoestá pronto para implantar a solução. O tamanho padrão é
Standard_DS1_v2, que é uma das suas SKUs permitidas. O comando cria chaves SSH, se elas ainda não
existirem em um local padrão.
az vm create --resource-group myResourceGroup --name myVM --image UbuntuLTS --generate-ssh-keys
Após a conclusão da implantação, será necessário aplicar mais configurações de gerenciamento à solução.
Bloquear recursos
Bloqueios de recursos impedem que os usuários em sua organização acidentalmente excluam ou modifiquem
recursos críticos. Ao contrário do controle de acesso baseado em função, bloqueios de recurso aplicam uma
restrição a todos os usuários e funções. É possível definir o nível de bloqueio como CanNotDelete ou ReadOnly.
Para criar ou excluir bloqueios de gerenciamento, você deve ter acesso às ações
Microsoft.Authorization/locks/* . Das funções internas, somente Proprietário e Administrador do Acesso
de Usuário recebem essas ações.
Para bloquear a máquina virtual e o grupo de segurança de rede, use o comando az lock create:
# Add CanNotDelete lock to the VM

az lock create --name LockVM \
--lock-type CanNotDelete \
--resource-name myVM \
--resource-type Microsoft.Compute/virtualMachines
# Add CanNotDelete lock to the network security group

az lock create --name LockNSG \
--lock-type CanNotDelete \
--resource-name myVMNSG \
--resource-type Microsoft.Network/networkSecurityGroups
Para testar os bloqueios, tente executar o comando a seguir:
Você vê um erro informando que a operação de exclusão não pode ser concluída devido a um bloqueio. O
grupo de recursos poderá ser excluído apenas se você remover especificamente os bloqueios. Essa etapa é
apresentada em Limpar os recursos.
Recursos de marca
Você pode aplicar marcas para os recursos do Azure para organizá-los logicamente por categorias. Cada marca
consiste em um nome e em um valor. Por exemplo, você pode aplicar o nome "Ambiente" e o valor "Produção" a
todos os recursos na produção.
Para adicionar duas marcas a um grupo de recursos, use o comando az group update:
az group update -n myResourceGroup --set tags.Environment=Test tags.Dept=IT
Vamos supor que você quer adicionar uma terceira marca. Execute o comando novamente com a nova marca.
Ele é adicionado às marcas existentes.
az group update -n myResourceGroup --set tags.Project=Documentation
Os recursos não herdam as marcas do grupo de recursos. Atualmente, o grupo de recursos tem três marcas,
mas os recursos não têm nenhuma marca. Para aplicar todas as marcas de um grupo de recursos a seus
recursos e reter as marcas existentes nos recursos, use o script a seguir:
# Get the tags for the resource group
jsontag=$(az group show -n myResourceGroup --query tags)
# Reformat from JSON to space-delimited and equals sign

t=$(echo $jsontag | tr -d '"{},' | sed 's/: /=/g')
# Get the resource IDs for all resources in the resource group
r=$(az resource list -g myResourceGroup --query [].id --output tsv)
# Loop through each resource ID

for resid in $r
do
# Get the tags for this resource
jsonrtag=$(az resource show --id $resid --query tags)

rt=$(echo $jsonrtag | tr -d '"{},' | sed 's/: /=/g')
# Reapply the updated tags to this resource

az resource tag --tags $t$rt --id $resid
done
Como alternativa, você pode aplicar as marcas do grupo de recursos aos recursos sem manter as marcas
existentes:
# Get the tags for the resource group

jsontag=$(az group show -n myResourceGroup --query tags)

t=$(echo $jsontag | tr -d '"{},' | sed 's/: /=/g')
# Get the resource IDs for all resources in the resource group
r=$(az resource list -g myResourceGroup --query [].id --output tsv)
# Loop through each resource ID

for resid in $r
do
# Apply tags from resource group to this resource
az resource tag --tags $t --id $resid
done
Para combinar vários valores em uma única marca, use uma cadeia de caracteres JSON.
az group update -n myResourceGroup --set tags.CostCenter='{"Dept":"IT","Environment":"Test"}'
Para remover todas as marcas em um grupo de recursos, use:
az group update -n myResourceGroup --remove tags
Para aplicar marcas a uma máquina virtual, use o comando az resource tag. Nenhuma marca existente no
recurso é mantida.
az resource tag -n myVM \

-g myResourceGroup \
--tags Dept=IT Environment=Test Project=Documentation \
--resource-type "Microsoft.Compute/virtualMachines"
Localizar recursos por marca

Para localizar recursos com um nome e valor da marca, use o comando az resource list:
az resource list --tag Environment=Test --query [].name
É possível utilizar os valores retornados para tarefas de gerenciamento, como parar todas as máquinas virtuais
com um valor de marca.
az vm stop --ids $(az resource list --tag Environment=Test --query "[?

type=='Microsoft.Compute/virtualMachines'].id" --output tsv)
Exibir custos por valores de marca

Após aplicar as marcas aos recursos, será possível exibir os custos dos recursos com essas marcas. Demora um
tempo para que a análise de custo mostre o uso mais recente, portanto, talvez ainda não seja possível exibir os
custos. Quando os custos estiverem disponíveis, você poderá visualizá-los nos grupos de recursos em sua
assinatura. Para visualizar os custos, os usuários deverão ter acesso no nível da assinatura para informações de
cobrança.
Para exibir custos por marca no portal, selecione sua assinatura e, em seguida, Análise de Custo .
Em seguida, filtre pelo valor de marca e selecione Aplicar .
Também é possível usar a Visão geral da API de consumo do Azure para exibir os custos de maneira
programática.
Limpar os recursos
O grupo de segurança de rede bloqueado não poderá ser excluído até que o bloqueio seja removido. Para
remover o bloqueio, recuperar as IDs dos bloqueios e fornecê-los para o comando az lock delete:
vmlock=$(az lock show --name LockVM \

--resource-type Microsoft.Compute/virtualMachines \
--resource-name myVM --output tsv --query id)
nsglock=$(az lock show --name LockNSG \
--resource-type Microsoft.Network/networkSecurityGroups \
--resource-name myVMNSG --output tsv --query id)
az lock delete --ids $vmlock $nsglock
a VM e todos os recursos relacionados. Saia da sessão SSH para sua VM e então exclua os recursos da seguinte
maneira:
Próximas etapas
Atribuir usuários a uma função
Aplicar políticas que impõem padrões
Proteger recursos críticos com bloqueios
Recursos de marca de cobrança e gerenciamento
Passe para o próximo tutorial para aprender a identificar alterações e a gerenciar atualizações de pacote em
uma máquina virtual.
Gerenciar máquinas virtuais
Tutorial: Saiba mais sobre o gerenciamento de
máquina virtual do Windows com o Azure
PowerShell
Ao implantar recursos para o Azure, você terá uma enorme flexibilidade para decidir quais tipos de recursos
implantar, onde estarão localizados e como configurá-los. No entanto, essa flexibilidade pode abrir mais opções
que você desejaria permitir na sua organização. Ao considerar a implantação de recursos para o Azure, você
deve estar se perguntando:
Como atender aos requisitos legais para a soberania de dados em determinados países/regiões?
Como controlar os custos?
Como garantir que alguém não altere inadvertidamente um sistema crítico?
Como fazer para rastrear os custos de recurso e cobrá-los com precisão?
Este artigo aborda essas questões. Especificamente, você:
Atribui usuários a funções e atribui funções a um escopo, de modo que os usuários tenham permissão para
executar as ações esperadas, mas não ações adicionais.
Aplica políticas que prescrevem convenções para recursos em sua assinatura.
Bloqueia recursos que sejam críticos ao sistema.
Marca recursos para que possam ser rastreados por meio dos valores adequados à sua organização.
Este artigo concentra-se nas tarefas realizadas para implementar governança. Para uma discussão mais
abrangente sobre os conceitos, consulte Governança no Azure.

Compreender o escopo
Antes de criar qualquer item, vamos revisar o conceito de escopo. O Azure fornece quatro níveis de
gerenciamento: grupos de gerenciamento, assinatura, grupo de recursos e recursos. Grupos de gerenciamento
estão em uma versão prévia. A imagem a seguir mostra um exemplo dessas camadas.
As configurações de gerenciamento são aplicadas em qualquer desses níveis de escopo. O nível que você
seleciona determina o quão amplamente a configuração é aplicada. Os níveis inferiores herdam as
configurações de níveis superiores. Ao aplicar uma configuração à assinatura, essa configuração será aplicada a
todos os grupos de recursos e recursos em sua assinatura. Ao aplicar uma configuração no grupo de recursos,
essa configuração será aplicada ao grupo de recursos e a todos os recursos. No entanto, outro grupo de
recursos não possuirá essa configuração.
Normalmente, é adequado aplicar configurações críticas em níveis superiores e requisitos específicos do projeto
em níveis inferiores. Por exemplo, você pode querer garantir que todos os recursos para sua organização sejam
implantados em determinadas regiões. Para cumprir esse requisito, aplique uma política à assinatura que
especifica as localizações permitidas. Na medida em que outros usuários em sua organização adicionarem
novos recursos e grupos de recursos, as localizações permitidas serão aplicadas automaticamente.
Neste tutorial, você aplica todas as configurações de gerenciamento a um grupo de recursos, de modo que seja
possível remover facilmente essas configurações quando terminar.
Vamos criar esse grupo de recursos.
New-AzResourceGroup -Name myResourceGroup -Location EastUS
Atualmente, o grupo de recursos está vazio.

Você deseja certificar-se de que os usuários em sua organização têm o nível certo de acesso a esses recursos.
Você não deseja conceder acesso ilimitado a usuários, mas também precisa certificar-se de que eles podem
fazer o trabalho deles. O Azure RBAC (controle de acesso baseado em função do Azure) permite que você
gerencie quais usuários têm permissão para executar ações específicas em um escopo.
Para criar e remover as atribuições de função, os usuários devem ter Microsoft.Authorization/roleAssignments/*
acesso. Esse acesso deve ser concedido pelas funções Proprietário ou Administrador de Acesso do Usuário.
Para gerenciar soluções de máquinas virtuais, há três funções específicas do recurso que fornecem acesso
comum:
Colaborador de Máquina Virtual
Colaborador de rede
Colaborador da Conta de Armazenamento
Em vez de atribuir funções a usuários individuais, muitas vezes é mais fácil usar um grupo do Azure Active
Directory que tenha usuários que precisam realizar ações semelhantes. E, em seguida, atribuir esse grupo à
função apropriada. Neste artigo, use um grupo existente para gerenciar a máquina virtual ou use o portal para
criar um grupo do Azure Active Directory.
Após criar um novo grupo ou encontrar um existente, use o comando New-AzRoleAssignment para atribuir o
grupo do Azure Active Directory à função de Colaborador da Máquina Virtual do grupo de recursos.
$adgroup = Get-AzADGroup -DisplayName <your-group-name>
New-AzRoleAssignment -ObjectId $adgroup.id `

-ResourceGroupName myResourceGroup `
-RoleDefinitionName "Virtual Machine Contributor"
Se você receber um erro informando Entidade de segurança <guid> não existe no diretório , o novo
grupo ainda não foi propagado em todo o Azure Active Directory. Tente executar o comando novamente.
Normalmente, você repete o processo para Colaborador de Rede e Colaborador da Conta de Armazenamento,
visando certificar-se de que os usuários serão designados para gerenciar os recursos implantados. Neste artigo,
você pode ignorar essas etapas.
Azure Policy
O Azure Policy ajuda a garantir que todos os recursos da assinatura atendam aos padrões corporativos. Sua
assinatura já possui várias definições de políticas. Para ver as definições de política disponíveis, use o comando
Get-AzPolicyDefinition:
(Get-AzPolicyDefinition).Properties | Format-Table displayName, policyType
Você vê as definições de políticas existentes. O tipo de política é BuiltIn ou Personalizada . Procure as

definições para aqueles que descrevem uma condição que você quer atribuir. Neste artigo, você atribui políticas
que:
Limitam os locais para todos os recursos.
Limitam as SKUs para máquinas virtuais.
Auditam máquinas virtuais que não utilizam discos gerenciados.
No exemplo a seguir, você pode recuperar três definições de política com base no nome de exibição. Use o
comando New-AzPolicyAssignment para atribuir essas definições ao grupo de recursos. Para algumas políticas,
você deve fornecer valores de parâmetro para especificar os valores permitidos.
# Values to use for parameters
$locations ="eastus", "eastus2"
$skus = "Standard_DS1_v2", "Standard_E2s_v2"
# Get the resource group

$rg = Get-AzResourceGroup -Name myResourceGroup
# Get policy definitions for allowed locations, allowed SKUs, and auditing VMs that don't use managed disks
$locationDefinition = Get-AzPolicyDefinition | where-object {$_.properties.displayname -eq "Allowed
locations"}
$skuDefinition = Get-AzPolicyDefinition | where-object {$_.properties.displayname -eq "Allowed virtual
machine size SKUs"}
$auditDefinition = Get-AzPolicyDefinition | where-object {$_.properties.displayname -eq "Audit VMs that do
not use managed disks"}
# Assign policy for allowed locations

New-AzPolicyAssignment -Name "Set permitted locations" `
-Scope $rg.ResourceId `
-PolicyDefinition $locationDefinition `
-listOfAllowedLocations $locations
# Assign policy for allowed SKUs

New-AzPolicyAssignment -Name "Set permitted VM SKUs" `
-PolicyDefinition $skuDefinition `
-listOfAllowedSKUs $skus
# Assign policy for auditing unmanaged disks

New-AzPolicyAssignment -Name "Audit unmanaged disks" `
-PolicyDefinition $auditDefinition
Implantar a máquina virtual

Você atribuiu funções e políticas, entãoestá pronto para implantar a solução. O tamanho padrão é
Standard_DS1_v2, que é uma das suas SKUs permitidas. Ao executar esta etapa, credenciais serão solicitadas de
você. Os valores que você insere são configurados como o nome de usuário e senha para a máquina virtual.
New-AzVm -ResourceGroupName "myResourceGroup" `

-Name "myVM" `
-OpenPorts 80,3389
Após a conclusão da implantação, será necessário aplicar mais configurações de gerenciamento à solução.
Bloquear recursos
Bloqueios de recursos impedem que os usuários em sua organização acidentalmente excluam ou modifiquem
recursos críticos. Ao contrário do controle de acesso baseado em função, bloqueios de recurso aplicam uma
restrição a todos os usuários e funções. É possível definir o nível de bloqueio como CanNotDelete ou ReadOnly.
Para bloquear a máquina virtual e o grupo de segurança de rede, use o comando New-AzResourceLock:
# Add CanNotDelete lock to the VM
New-AzResourceLock -LockLevel CanNotDelete `
-LockName LockVM `
-ResourceName myVM `
-ResourceType Microsoft.Compute/virtualMachines `
# Add CanNotDelete lock to the network security group

New-AzResourceLock -LockLevel CanNotDelete `
-LockName LockNSG `
-ResourceName myNetworkSecurityGroup `
-ResourceType Microsoft.Network/networkSecurityGroups `
Para testar os bloqueios, tente executar o comando a seguir:
Você vê um erro informando que a operação de exclusão não pode ser concluída devido a um bloqueio. O
grupo de recursos poderá ser excluído apenas se você remover especificamente os bloqueios. Essa etapa é
apresentada em Limpar os recursos.
Recursos de marca
Você pode aplicar marcas para os recursos do Azure para organizá-los logicamente por categorias. Cada marca
consiste em um nome e em um valor. Por exemplo, você pode aplicar o nome "Ambiente" e o valor "Produção" a
todos os recursos na produção.
Para adicionar duas marcas a um grupo de recursos, use o comando Set-AzResourceGroup:
Set-AzResourceGroup -Name myResourceGroup -Tag @{ Dept="IT"; Environment="Test" }
Vamos supor que você quer adicionar uma terceira marca. Ao aplicar marcas a um recurso ou grupo de
recursos, você pode substituir as marcas existentes nesse recurso ou grupo de recursos. Para adicionar uma
nova marca sem perder as marcas existentes, você precisará recuperar as marcas existentes, adicionar uma nova
marca e aplicar a coleção de marcas novamente:
# Get existing tags and add a new tag

$tags = (Get-AzResourceGroup -Name myResourceGroup).Tags
$tags.Add("Project", "Documentation")
# Reapply the updated set of tags

Set-AzResourceGroup -Tag $tags -Name myResourceGroup
Os recursos não herdam as marcas do grupo de recursos. Atualmente, o grupo de recursos tem três marcas,
mas os recursos não têm nenhuma marca. Para aplicar todas as marcas de um grupo de recursos a seus
recursos e reter as marcas existentes nos recursos que não são duplicados, use o seguinte script:
$group = Get-AzResourceGroup myResourceGroup
if ($group.Tags -ne $null) {

# Get the resources in the resource group
$resources = Get-AzResource -ResourceGroupName $group.ResourceGroupName
# Loop through each resource

foreach ($r in $resources)
{
# Get the tags for this resource
$resourcetags = (Get-AzResource -ResourceId $r.ResourceId).Tags
# If the resource has existing tags, add new ones

if ($resourcetags)
{
foreach ($key in $group.Tags.Keys)
{
if (-not($resourcetags.ContainsKey($key)))
{
$resourcetags.Add($key, $group.Tags[$key])
}
}
# Reapply the updated tags to the resource

Set-AzResource -Tag $resourcetags -ResourceId $r.ResourceId -Force
}
else
{
Set-AzResource -Tag $group.Tags -ResourceId $r.ResourceId -Force
}
}
}
Como alternativa, você pode aplicar as marcas do grupo de recursos aos recursos sem manter as marcas
existentes:

$g = Get-AzResourceGroup -Name myResourceGroup
# Find all the resources in the resource group, and for each resource apply the tags from the resource group
Get-AzResource -ResourceGroupName $g.ResourceGroupName | ForEach-Object {Set-AzResource -ResourceId
$_.ResourceId -Tag $g.Tags -Force }
Para combinar vários valores em uma única marca, use uma cadeia de caracteres JSON.
Set-AzResourceGroup -Name myResourceGroup -Tag @{ CostCenter="{`"Dept`":`"IT`",`"Environment`":`"Test`"}" }
Para adicionar uma nova marca com vários valores sem perder as marcas existentes, recupere as marcas
existentes, use uma cadeia de caracteres JSON para a nova marca e reaplique a coleção de marcas:
# Get existing tags and add a new tag

$ResourceGroup = Get-AzResourceGroup -Name myResourceGroup
$Tags = $ResourceGroup.Tags
$Tags.Add("CostCenter", "{`"Dept`":`"IT`",`"Environment`":`"Test`"}")
# Reapply the updated set of tags

$ResourceGroup | Set-AzResourceGroup -Tag $Tags
Para remover todas as marcas, passe uma tabela de hash vazia.

Set-AzResourceGroup -Name myResourceGroup -Tag @{ }
Para aplicar marcas a uma máquina virtual, use o comando Set-AzResource:
# Get the virtual machine

$r = Get-AzResource -ResourceName myVM `
-ResourceType Microsoft.Compute/virtualMachines
# Apply tags to the virtual machine

Set-AzResource -Tag @{ Dept="IT"; Environment="Test"; Project="Documentation" } -ResourceId $r.ResourceId -
Force
Localizar recursos por marca

Para localizar recursos com um nome e valor da tag, use o comando Get-AzResource:
(Get-AzResource -Tag @{ Environment="Test"}).Name
É possível utilizar os valores retornados para tarefas de gerenciamento, como parar todas as máquinas virtuais
com um valor de marca.
Get-AzResource -Tag @{ Environment="Test"} | Where-Object {$_.ResourceType -eq

"Microsoft.Compute/virtualMachines"} | Stop-AzVM
Exibir custos por valores de marca

Após aplicar as marcas aos recursos, será possível exibir os custos dos recursos com essas marcas. Demora um
tempo para que a análise de custo mostre o uso mais recente, portanto, talvez ainda não seja possível exibir os
custos. Quando os custos estiverem disponíveis, você poderá visualizá-los nos grupos de recursos em sua
assinatura. Para visualizar os custos, os usuários deverão ter acesso no nível da assinatura para informações de
cobrança.
Para exibir custos por marca no portal, selecione sua assinatura e, em seguida, Análise de Custo .
Em seguida, filtre pelo valor de marca e selecione Aplicar .

Também é possível usar a Visão geral da API de consumo do Azure para exibir os custos de maneira
programática.
Limpar os recursos
O grupo de segurança de rede bloqueado não poderá ser excluído até que o bloqueio seja removido. Para
remover o bloqueio, use o comando Remove-AzResourceLock:
Remove-AzResourceLock -LockName LockVM `

-ResourceType Microsoft.Compute/virtualMachines `
Remove-AzResourceLock -LockName LockNSG `
-ResourceName myNetworkSecurityGroup `
-ResourceType Microsoft.Network/networkSecurityGroups `
Quando não forem mais necessários, você poderá usar o comando Remove-AzResourceGroup para remover o
grupo de recursos, a VM e todos os recursos relacionados.
Gerenciar os custos
Os serviços do Azure custam dinheiro. O Gerenciamento de Custos do Azure ajuda você a definir orçamentos e
configurar alertas para manter os gastos sob controle. Analise, gerencie e otimize seus custos do Azure com o
Gerenciamento de Custos. Para saber mais, confira o guia de início rápido sobre como analisar seus custos.
Próximas etapas
Atribuir usuários a uma função
Aplicar políticas que impõem padrões
Proteger recursos críticos com bloqueios
Recursos de marca de cobrança e gerenciamento
Passe para o próximo tutorial para aprender a identificar alterações e a gerenciar atualizações de pacote em
uma máquina virtual do Linux.
Gerenciar máquinas virtuais
Sincronização de tempo para VMs Linux no Azure
A sincronização de Data/Hora é importante para segurança e correlação de eventos. Às vezes, é usada para
implementação de transações distribuídas. A precisão da hora entre vários sistemas de computador é obtida por
meio da sincronização. A sincronização pode ser afetada por vários motivos, incluindo reinicializações e tráfego
entre a fonte de tempo e o computador buscando a hora.
O Azure é apoiado pela infraestrutura que executa o Windows Server 2016. O Windows Server 2016 aprimorou
os algoritmos usados para corrigir a hora e condicionar o relógio local a sincronizar com o UTC. O recurso
Windows Server 2016 Accurate Time melhorou muito a forma como o serviço VMICTimeSync controla as VMs
com o host para o tempo exato. Os aprimoramentos incluem um tempo inicial mais preciso no início da VM ou
na restauração da VM e interrupção da correção de latência.
NOTE
Para obter uma visão geral rápida do Serviço de Horário do Windows, assista a este vídeo de visão geral de alto nível.
Para obter mais informações, consulte Hora precisa para Windows Server 2016.
Visão geral
A precisão de um relógio de computador é medida na proximidade do relógio do computador com o padrão de
hora UTC (Tempo Universal Coordenado). O UTC é definido por uma amostra multinacional de relógios
atômicos precisos que só pode ser desligada em um segundo em 300 anos. Mas ler o UTC diretamente requer
um hardware especializado. Em vez disso, os servidores de horário são sincronizados com o UTC e acessados de
outros computadores para fornecer escalabilidade e robustez. Todo computador tem o serviço de sincronização
de tempo em execução que sabe a que horas os servidores devem ser usados e verifica periodicamente se o
relógio do computador precisa ser corrigido e ajusta o tempo, se necessário.
Os hosts do Azure são sincronizados para servidores de horário internos da Microsoft que usam dispositivos da
Microsoft da Stratum 1, com antenas de GPS. As máquinas virtuais no Azure podem depender do host para
passar a hora exata (hora do host) para a VM ou a VM pode obter a hora diretamente de um servidor de horário
ou uma combinação de ambos.
No hardware autônomo, o sistema operacional Linux só lê o relógio de hardware do host na inicialização.
Depois disso, o relógio é mantido usando o timer de interrupção no kernel do Linux. Nesta configuração, o
relógio se deslocará com o tempo. Em distribuições mais recentes do Linux no Azure, as VMs podem usar o
provedor VMICTimeSync, incluído nos serviços de integração do Linux (LIS), para consultar atualizações de
relógio do host com mais frequência.
As interações da máquina virtual com o host também podem afetar o relógio. Durante a manutenção de
memória preservando a manutenção, as VMs são pausadas por até 30 segundos. Por exemplo, antes de iniciar a
manutenção, o relógio da VM exibe as 10:00:00 e dura 28 segundos. Depois que a VM for retomada, o relógio
na VM ainda mostrará 10:00:00 AM, o que seria 28 segundos de folga. Para corrigir isso, o serviço
VMICTimeSync monitora o que está acontecendo no host e solicita que as alterações ocorram nas VMs para
compensar.
Sem a sincronização de data/hora, o relógio na VM acumularia erros. Quando há apenas uma VM, o efeito pode
não ser significativo, a menos que a carga de trabalho exija uma cronometragem altamente precisa. Mas na
maioria dos casos, temos várias VMs interconectadas que usam o tempo para rastrear transações, e a hora
precisa ser consistente durante toda a implantação. Quando a hora entre as VMs for diferente, você poderá ver
os seguintes efeitos:
A autenticação falhará. Protocolos de segurança como Kerberos ou tecnologia dependente de certificado
requerem que a hora esteja consistente em todos os sistemas.
É muito difícil descobrir o que aconteceu em um sistema se os logs (ou outros dados) não corresponderem
com a hora. O mesmo evento poderia parecer que ocorreu em momentos diferentes, dificultando a
correlação.
Se o relógio estiver desligado, a cobrança poderá ser calculada incorretamente.
Opções de configuração
Geralmente, há três maneiras de configurar a sincronização de horário para suas VMs Linux hospedadas no
Azure:
A configuração padrão das imagens do Azure Marketplace usa tempo NTP e tempo de host VMICTimeSync.
Somente host usando o VMICTimeSync.
Use outro servidor de horário externo com ou sem o uso do tempo de host VMICTimeSync.
Usar o padrão
Por padrão, a maioria das imagens do Azure Marketplace para Linux é configurada para sincronização de duas
origens:
NTP como primário, que recebe tempo de um servidor NTP. Por exemplo, as imagens do Ubuntu 16.04 LTS
Marketplace usam ntp.ubuntu.com .
O serviço VMICTimeSync como secundário, usado para comunicar o horário do host para as VMs e fazer
correções após a VM ser pausada para manutenção. Os hosts do Azure usam dispositivos Stratum 1 da
Microsoft para manter a hora exata.
Em distribuições mais recentes do Linux, o serviço VMICTimeSync fornece uma fonte de relógio de hardware de
protocolo PTP, mas as distribuições anteriores podem não fornecer essa fonte de relógio e voltarão ao NTP para
obter tempo do host.
Para confirmar que o NTP está sincronizando corretamente, execute o comando ntpq -p .
Somente do host
Como os servidores NTP como time.windows.com e ntp.ubuntu.com são públicos, sincronizar o tempo com eles
requer o envio de tráfego pela Internet. Os atrasos de pacotes variados podem afetar negativamente a
qualidade da sincronização de tempo. A remoção do NTP alternando para a sincronização somente de host
pode às vezes melhorar o tempo de sincronização dos resultados.
Alternar para a sincronização de data/hora somente do host será viável se você tiver problemas de
sincronização de data/hora usando a configuração padrão. Experimente a sincronização somente do host para
ver se isso melhoraria a sincronização de tempo na sua VM.
Servidor de horário externo
Se você tiver requisitos específicos de sincronização de data/hora, também haverá uma opção de usar
servidores de horário externos. Servidores de horário externos podem fornecer hora específica, o que pode ser
útil para cenários de teste, garantindo uniformidade de hora com máquinas hospedadas em datacenters que
não sejam da Microsoft ou lidando com segundos bissextos de uma maneira especial.
Você pode combinar um servidor de horário externo com o serviço VMICTimeSync para fornecer resultados
semelhantes à configuração padrão. A combinação de um servidor de horário externo com o VMICTimeSync é a
melhor opção para lidar com problemas que podem ser causados quando as VMs são pausadas para
manutenção.
Ferramentas e recursos
Há alguns comandos básicos para verificar sua configuração de sincronização de tempo. A documentação para
distribuição do Linux terá mais detalhes sobre a melhor maneira de configurar a sincronização de horário para
essa distribuição.
Serviços de integração
Verifique se o serviço de integração (hv_utils) está carregado.
lsmod | grep hv_utils
Você deve ver algo semelhante a isto:
hv_utils 24418 0
hv_vmbus 397185 7
hv_balloon,hyperv_keyboard,hv_netvsc,hid_hyperv,hv_utils,hyperv_fb,hv_storvsc
Veja se o daemon de serviços de integração do Hyper-V está sendo executado.
ps -ef | grep hv
Você deve ver algo semelhante a isto:
root 229 2 0 17:52 ? 00:00:00 [hv_vmbus_con]

root 391 2 0 17:52 ? 00:00:00 [hv_balloon]
Verificar origem do relógio PTP

Com versões mais recentes do Linux, uma fonte de relógio do Precision Time Protocol (PTP) está disponível
como parte do provedor VMICTimeSync. Em versões mais antigas do Red Hat Enterprise Linux ou CentOS 7.x, o
Linux Integration Services pode ser baixado e usado para instalar o driver atualizado. Quando a origem do
relógio do PTP estiver disponível, o dispositivo Linux será do formato/dev/PTPx.
Veja quais fontes de relógio PTP estão disponíveis.
ls /sys/class/ptp
Neste exemplo, o valor retornado é ptp0, portanto, usamos isso para verificar o nome do relógio. Para verificar
o dispositivo, verifique o nome do relógio.
cat /sys/class/ptp/ptp0/clock_name
Isso deve retornar hyperv .

chrony
No Ubuntu 19,10 e versões posteriores, Red Hat Enterprise Linux e CentOS 8. x, o chrony é configurado para
usar um relógio de origem do PTP. Em vez de chrony, as versões mais antigas do Linux usam o daemon de
protocolo NTP (ntpd), que não dá suporte a fontes PTP. Para habilitar o PTP nessas versões, chrony deve ser
instalado e configurado manualmente (em chrony. conf) usando o seguinte código:
refclock PHC /dev/ptp0 poll 3 dpoll -2 offset 0

Para obter mais informações sobre o Ubuntu e o NTP, consulte sincronização de horário.
Para obter mais informações sobre o Red Hat e o NTP, consulte Configurar o NTP.
Para obter mais informações sobre chrony, consulte usando o chrony.
Se as fontes chrony e VMICTimeSync forem habilitadas simultaneamente, você poderá marcar uma como
preferir , que define a outra fonte como um backup. Como os serviços NTP não atualizam o relógio para
grandes distorções, exceto após um longo período, o VMICTimeSync recuperará o relógio de eventos de VM
pausados muito mais rapidamente do que as ferramentas baseadas em NTP.
Por padrão, o chronyd acelera ou reduz o relógio do sistema para corrigir qualquer descompasso de tempo. Se
o descompasso se tornar muito grande, o chrony falhará ao corrigir o descompasso. Para superar isso, o
makestep parâmetro em /etc/chrony.conf pode ser alterado para forçar uma sincronização de horário se a
descompasso exceder o limite especificado.
makestep 1.0 -1
Aqui, o chrony forçará uma atualização de tempo se a descompasso for maior que 1 segundo. Para aplicar as
alterações, reinicie o serviço chronyd:
systemctl restart chronyd
systemd
Em versões SUSE e Ubuntu anteriores a 19,10, a sincronização de horário é configurada usando o sistema. Para
obter mais informações sobre o Ubuntu, consulte sincronização de horário. Para obter mais informações sobre
o SUSE, consulte a seção 4.5.8 em notas de versão do SUSE Linux Enterprise Server 12 SP3.
Próximas etapas
Sincronização de Data/Hora para VMs do Windows
no Azure
A sincronização de Data/Hora é importante para segurança e correlação de eventos. Às vezes, é usada para
implementação de transações distribuídas. A precisão da hora entre vários sistemas de computador é obtida por
meio da sincronização. A sincronização pode ser afetada por vários motivos, incluindo reinicializações e tráfego
entre a fonte de tempo e o computador buscando a hora.
O Azure agora é apoiado pela infraestrutura que executa o Windows Server 2016. O Windows Server 2016
aprimorou os algoritmos usados para corrigir a hora e condicionar o relógio local a sincronizar com o UTC. O
Windows Server 2016 também aprimorou o serviço VMICTimeSync, que determina como as VMs são
sincronizadas com o host para uma hora precisa. Os aprimoramentos incluem um tempo inicial mais preciso no
início da VM ou na restauração da VM e interrupção da correção de latência para exemplos fornecidos para o
Horário do Windows (W32Time).
NOTE
Para obter uma visão geral rápida do Serviço de Horário do Windows, assista a este vídeo de visão geral de alto nível.
Visão geral
A precisão de um relógio de computador é medida na proximidade do relógio do computador com o padrão de
hora UTC (Tempo Universal Coordenado). O UTC é definido por uma amostra multinacional de relógios
atômicos precisos que só pode ser desligada em um segundo em 300 anos. Mas ler o UTC diretamente requer
um hardware especializado. Em vez disso, os servidores de horário são sincronizados com o UTC e acessados de
outros computadores para fornecer escalabilidade e robustez. Todo computador tem o serviço de sincronização
de tempo em execução que sabe a que horas os servidores devem ser usados e verifica periodicamente se o
relógio do computador precisa ser corrigido e ajusta o tempo, se necessário.
Os hosts do Azure são sincronizados para servidores de horário internos da Microsoft que usam dispositivos da
Microsoft da Stratum 1, com antenas de GPS. As máquinas virtuais no Azure podem depender do host para
passar a hora exata (hora do host) para a VM ou a VM pode obter a hora diretamente de um servidor de horário
ou uma combinação de ambos.
As interações da máquina virtual com o host também podem afetar o relógio. Durante a manutenção de
memória preservando a manutenção, as VMs são pausadas por até 30 segundos. Por exemplo, antes de iniciar a
manutenção, o relógio da VM exibe as 10:00:00 e dura 28 segundos. Depois que a VM for retomada, o relógio
na VM ainda mostrará 10:00:00 AM, o que seria 28 segundos de folga. Para corrigir isso, o serviço
VMICTimeSync monitora o que está acontecendo no host e solicita que as alterações ocorram nas VMs para
compensar.
O serviço VMICTimeSync opera no modo de amostra ou de sincronização e só influenciará o relógio para frente.
No modo de amostra, que requer a execução do W32time, o serviço VMICTimeSync pesquisa o host a cada 5
segundos e fornece amostras de tempo para o W32time. Aproximadamente a cada 30 segundos, o serviço
W32time pega a última amostra de tempo e a utiliza para influenciar o relógio do hóspede. O modo de
sincronização é ativado se um convidado for retomado ou se o relógio de um visitante se deslocar mais de 5
segundos após o relógio do host. Nos casos em que o serviço W32time está sendo executado corretamente, o
último caso nunca deve acontecer.
Sem a sincronização de data/hora, o relógio na VM acumularia erros. Quando há apenas uma VM, o efeito pode
não ser significativo, a menos que a carga de trabalho exija uma cronometragem altamente precisa. Mas na
maioria dos casos, temos várias VMs interconectadas que usam o tempo para rastrear transações, e a hora
precisa ser consistente durante toda a implantação. Quando a hora entre as VMs for diferente, você poderá ver
os seguintes efeitos:
A autenticação falhará. Protocolos de segurança como Kerberos ou tecnologia dependente de certificado
requerem que a hora esteja consistente em todos os sistemas.
É muito difícil descobrir o que aconteceu em um sistema se os logs (ou outros dados) não corresponderem
com a hora. O mesmo evento poderia parecer que ocorreu em momentos diferentes, dificultando a
correlação.
Se o relógio estiver desligado, a cobrança poderá ser calculada incorretamente.
Os melhores resultados para implantações do Windows são obtidos usando o Windows Server 2016 como o
sistema operacional convidado, o que garante que você possa usar os últimos aprimoramentos na
sincronização de data/hora.
Opções de configuração
Há três opções para configurar a sincronização de data/hora nas VMs do Windows hospedadas no Azure:
Hora do host e time.windows.com. Essa é a configuração padrão usada nas imagens do Azure Marketplace.
Somente do host.
Use outro servidor de horário externo com ou sem o uso de hora do host.
Usar o padrão
Por padrão, as imagens de VM do Sistema Operacional do Windows são configuradas para que o w32time
sincronize a partir de duas origens:
O provedor NtpClient, que obtém informações de time.windows.com.
O serviço VMICTimeSync, usado para comunicar a hora do host para as VMs e fazer correções após a VM ser
pausada para manutenção. Os hosts do Azure usam dispositivos Stratum 1 da Microsoft para manter a hora
exata.
O w32time preferiria o provedor de horário na seguinte ordem de prioridade: nível de camada, atraso de raiz,
dispersão de raiz, diferença de horário. Na maioria dos casos, o W32Time em uma VM do Azure prefere o
tempo de host devido à avaliação que ele faria para comparar ambas as fontes de tempo.
Para máquinas ingressadas no domínio, o domínio em si estabelece a hierarquia de sincronização de data/hora,
mas a raiz da floresta ainda exigiria tempo de algum lugar e as seguintes considerações ainda seriam
verdadeiras.
Somente do host
Como o time.windows.com é um servidor NTP público, o tempo de sincronização com ele requer o envio de
tráfego pela Internet, os atrasos de pacotes variados podem afetar negativamente a qualidade da sincronização
de tempo. A remoção de time.windows.com alternando para sincronização somente de host pode às vezes
melhorar o tempo de sincronização dos resultados.
Alternar para a sincronização de data/hora somente do host será viável se você tiver problemas de
sincronização de data/hora usando a configuração padrão. Experimente a sincronização somente do host para
ver se melhoraria a sincronização de data/hora na VM.
Servidor de horário externo
Se você tiver requisitos específicos de sincronização de data/hora, também haverá uma opção de usar
servidores de horário externos. Servidores de horário externos podem fornecer hora específica, o que pode ser
útil para cenários de teste, garantindo uniformidade de hora com máquinas hospedadas em datacenters que
não sejam da Microsoft ou lidando com segundos bissextos de uma maneira especial.
É possível combinar servidores externos com o serviço VMICTimeSync e o VMICTimeProvider para fornecer
resultados semelhantes à configuração padrão.
Verificar a configuração
Verifique se o provedor de horário NtpClient está configurado para usar servidores NTP explícitos (NTP) ou
sincronização de data/hora de domínio (NT5DS).
w32tm /dumpreg /subkey:Parameters | findstr /i "type"
Se a VM estiver usando NTP, você verá a seguinte saída:
Value Name Value Type Value Data

Type REG_SZ NTP
Para ver o servidor de horário que o provedor de horário NtpClient está usando, em um prompt de comando
com privilégios elevados digite:
w32tm /dumpreg /subkey:Parameters | findstr /i "ntpserver"
Se a VM estiver usando o padrão, a saída será semelhante a:
NtpServer REG_SZ time.windows.com,0x8
Para ver qual provedor de horário está sendo usado atualmente.
w32tm /query /source
Aqui está a saída que você pode ver e o que significaria:

time.windows.com - na configuração padrão, w32time obteria a hora do time.windows.com. A qualidade
da sincronização de data/hora depende da conectividade com a Internet e é afetada por atrasos de pacotes.
Essa é a saída usual que você obteria em um computador físico.
Provedor de sincronização de data/hora de IC da VM - a VM está sincronizando a hora do host. Essa é
a saída usual que você obteria em uma máquina virtual em execução no Azure.
Seu servidor de domínio - a máquina atual está em um domínio e o domínio define a hierarquia de
sincronização de data/hora.
Algum outro servidor - O w32time foi explicitamente configurado para obter a hora desse outro servidor. A
qualidade da sincronização de data/hora depende dessa qualidade do servidor de horário.
Relógio CMOS local - relógio não está sincronizado. É possível obter essa saída se o w32time não tiver
tido tempo suficiente para iniciar após um reinício ou quando todas as fontes de tempo configuradas não
estiverem disponíveis.
Optar pela sincronização de data/hora somente do host

O Azure está constantemente trabalhando para melhorar a sincronização de data/hora nos hosts e pode
garantir que toda a infraestrutura de sincronização de data/hora seja colocada em datacenters de propriedade
da Microsoft. Se você tiver problemas de sincronização de data/hora com a configuração padrão que prefere
usar o time.windows.com como a fonte de hora principal, você pode usar os seguintes comandos para ativar a
sincronização de data/hora somente do host.
Marque o provedor VMIC como habilitado.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\VMICTimeProvider /v

Enabled /t REG_DWORD /d 1 /f
Marque o provedor NTPClient como desabilitado.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\TimeProviders\NtpClient /v Enabled /t

REG_DWORD /d 0 /f
Reinicie o serviço w32time.
net stop w32time && net start w32time
VMs do Windows Server 2012 e R2

O Windows Server 2012 e o Windows Server 2012 R2 têm configurações padrão diferentes para a
sincronização de horário. O W32Time, por padrão, é configurado de forma que prefira uma baixa sobrecarga do
serviço em relação ao tempo preciso.
Se você quiser mover as implantações do Windows Server 2012 e 2012 R2 para usar os padrões mais recentes
que preferem hora precisa, aplique as configurações a seguir.
Atualize a pesquisa do w32time e atualize os intervalos para que correspondam às configurações do Windows
Server 2016.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v MinPollInterval /t REG_DWORD

/d 6 /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v MaxPollInterval /t REG_DWORD
/d 10 /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w32time\Config /v UpdateInterval /t REG_DWORD
/d 100 /f
w32tm /config /update
Para que o W32Time possa usar os novos intervalos de sondagem, o NtpServers precisa ser marcado como
usando-os. Se os servidores forem anotados com máscara 0x1 bitflag, isso substituirá esse mecanismo e o
w32time usaria SpecialPollInterval. Certifique-se de que os servidores NTP especificados estejam usando o
sinalizador 0x8 ou nenhum sinalizador:
Verifique quais sinalizadores estão sendo usados para os servidores NTP utilizados.
w32tm /dumpreg /subkey:Parameters | findstr /i "ntpserver"
Próximas etapas
Abaixo, são apresentados links para mais detalhes sobre a sincronização de data/hora:
Ferramentas e configurações do Serviço de Tempo do Windows
Aprimoramentos do Windows Server 2016
Tempo preciso para o Windows Server 2016
Limite de suporte para configurar o Serviço de Horário do Windows para ambientes de alta precisão
Usar a Versão 2 da Extensão de Script
Personalizado do Azure com máquinas virtuais do
Linux
A Versão 2 da Extensão de Script Personalizado baixa e executa scripts em máquinas virtuais do Azure. Essa
extensão é útil para a configuração de implantação de postagem, instalação de software ou qualquer outra
configuração/tarefa de gerenciamento. Você pode fazer o download de scripts a partir do Armazenamento do
Microsoft Azure ou outro local acessível da internet, ou você pode fornecê-los para o runtime da extensão.
A extensão de Script personalizado se integra com os modelos do Azure Resource Manager. Você também pode
executá-la usando a CLI do Azure, o PowerShell, o portal do Azure ou a API de REST de máquinas virtuais do
Azure.
Este artigo fornece detalhes sobre como usar a extensão de Script personalizado da CLI do Azure, e como
executar a extensão usando um modelo do Azure Resource Manager. Este artigo também fornece as etapas de
solução de problemas para os sistemas do Linux.
Há duas Extensões do Script Personalizado do Linux:
Versão 1 - Microsoft.OSTCExtensions.CustomScriptForLinux
Versão 2 - Microsoft.Azure.Extensions.CustomScript
Alterne entre implantações novas e existentes para usar a nova versão 2. A nova versão tem o objetivo de ser
uma substituição perfeita. Assim, a migração é tão fácil quanto alterar o nome e versão. Você não precisa alterar
a configuração de extensão.
Sistema operacional
A extensão de script personalizado para Linux será executada na extensão do so de extensão com suporte, para
obter mais informações, consulte este artigo.
Local do script
Você pode utilizar a extensão para usar suas credenciais do Armazenamento de Blobs do Azure para acessar
esse armazenamento. Como alternativa, o local do script pode ser qualquer lugar, desde que a VM possa rotear
para esse ponto de extremidade, como GitHub, servidor de arquivos interno, etc.
será necessário abrir portas adicionais do firewall ou do Grupo de Segurança de Rede. Por exemplo, se o seu
script estiver localizado no armazenamento do Azure, você poderá permitir o acesso usando as marcas do
serviço NSG do Azure para armazenamento.
Se o script estiver em um servidor local, ainda poderá ser necessário abrir portas adicionais do firewall ou do
Dicas e truques
falha.
Escreva scripts idempotentes, para que se forem executados mais de uma vez por acidente, eles não causem
alterações no sistema.
Verifique se os scripts não exigem entrada do usuário quando são executados.
É permitido que o script seja executado em até 90 minutos. Um período mais longo resultará em falha na
Não coloque reinicializações no script, pois isso causará problemas com outras extensões que estão sendo
instaladas e, após a reinicialização, a extensão será interrompida.
deixar a extensão em um estado de transição e levar a um tempo limite.
Se você tiver um script que causará uma reinicialização, instale aplicativos e execute scripts, etc. Você deve
agendar a reinicialização usando um trabalho cron ou usando ferramentas como DSC, ou chefe, Puppet
Extensions.
A extensão executará um script somente uma vez. Se quiser executar um script em cada inicialização, então
você poderá usar imagem de inicialização de nuvem e um módulo Scripts Por Inicialização. Como alternativa,
você pode usar o script para criar uma unidade de serviço do sistema.
Você só pode ter uma versão de uma extensão aplicada à VM. Para executar um segundo script
personalizado, você pode atualizar a extensão existente com a nova configuração. Como alternativa, você
pode remover a extensão de script personalizado e reaplicá-la novamente com o script atualizado.
Se quiser agendar quando um script será executado, você deverá usar a extensão para criar um trabalho
Cron.
CLI. Se quiser atualizações de status mais frequentes de um script em execução, você precisará criar sua
própria solução.
uma ferramenta de transferência de arquivo que dá suporte a servidores proxy em seu script, como
ondulação.
Lembre-se de locais de diretório não padrão nos quais seus scripts ou comandos podem confiar e ter lógica
para lidar com isso.
Ao implantar o script personalizado em instâncias de VMSS de produção, é recomendável implantar por
meio do modelo JSON e armazenar sua conta de armazenamento de script onde você tem controle sobre o
token SAS.
{
"type": "Extensions",
"apiVersion": "2019-03-01",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
"skipDos2Unix":false,
},
"script": "<base64-script-to-execute>",
"storageAccountName": "<storage-account-name>",
"storageAccountKey": "<storage-account-key>",
"fileUris": ["https://.."],
"managedIdentity" : "<managed-identity-identifier>"
}
}
}
NOTE
storageAccountKey
publicador Microsoft.Compute.Extensions string
type CustomScript string
fileUris (por exemplo) matriz

https://github.com/MyProject/Archive/MyPythonScript.py
commandToExecute (por exemplo) MyPythonScript.py Python <my- string

param1>
Script IyEvYmluL3NoCmVjaG8gIlVwZGF0aW string

5nIHBhY2thZ2VzIC4uLiIKYXB0IHVwZ
GF0ZQphcHQgdXBncmFkZSAteQo=
skipDos2Unix (exemplo) false booleano



4240-a7ff-d85fb6cd7232" } ou {
"objectId": "12dd289c-0583-46e5-
b9b4-115d5c19ef4b" }

apiVersion : O apiVersion mais atualizado pode ser encontrado usando o Gerenciador de recursos ou de CLI
do Azure usando o comando a seguir az provider list -o json
skipDos2Unix : (opcional, booliano) ignore a conversão de dos2unix das URLs de arquivos baseado no script
ou do script.
timestamp (opcional, inteiro de 32 bits) use este campo somente para disparar uma nova execução do script
ao alterar o valor desse campo. Qualquer valor inteiro é aceitável. Só deve ser diferente do valor anterior.
commandToExecute (obrigatório se o script não for definido, cadeia de caracteres) o script de ponto de
entrada a ser executado. Use este campo se o comando tiver segredos, como senhas.
script : (necessário se commandToExecute não for definido, cadeia de caracteres) um script codificado em
Base64 (e opcionalmente compactado com Gzip) executado pelo /bin/sh.
nas públicas.
commandToExecute
script
fileUris
Usar as configurações públicas pode ser útil para depuração, mas é altamente recomendável usar as
configurações protegidas.
configurações são salvas na VM no estado em que foram enviadas, ou seja, se foram criptografadas, elas serão
salvas criptografadas na VM. O certificado usado para descriptografar os valores criptografados é armazenado
na VM e usado para descriptografar as configurações (se necessário) no runtime.
Propriedade: skipDos2Unix
O valor padrão é false, o que significa que a conversão de dos2unix foi executada.
A versão anterior do CustomScript, Microsoft.OSTCExtensions.CustomScriptForLinux, seria converter
automaticamente arquivos DOS para arquivos do UNIX ao traduzir \r\n para \n . Essa translação ainda existe
e está ativada por padrão. Essa conversão é aplicada a todos os arquivos baixados do fileUris ou à configuração
de script com base em qualquer um dos critérios a seguir.
Se a extensão for uma dos .sh , .txt , .py ou .pl , ela será convertida. A configuração de script sempre
corresponderá a esse critério, pois ele é considerado um script executado com /bin/sh e é salvo como
script.sh na VM.
Se o arquivo começar com #! .
A conversão de dos2unix poderá ser ignorada ao definir o skipDos2Unix como true.
{
"fileUris": ["<url>"],
"skipDos2Unix": true
}
Propriedade: script
CustomScript dá suporte à execução de um script definido pelo usuário. As configurações de script para
combinar commandToExecute e fileUris em uma única configuração. Em vez de ter que configurar um arquivo
para download do armazenamento do Azure ou do gist do GitHub, você pode simplesmente codificar o script
como uma configuração. O script pode ser usado para commandToExecute e fileUris substituídos.
O script deve ser codificado em Base64. O script pode, opcionalmente , ser compactado com Gzip. A
configuração de script pode ser usada nas configurações públicas ou protegidas. O tamanho máximo dos dados
do parâmetro do script é 256 KB. Se o script exceder esse tamanho, não será executado.
Por exemplo, considerando o seguinte script salvo no arquivo /script.sh/.
#!/bin/sh
echo "Updating packages ..."
apt update
apt upgrade -y
A configuração correta do script de CustomScript deve ser construída ao utilizar a saída do comando a seguir.
cat script.sh | base64 -w0
{
"script": "IyEvYmluL3NoCmVjaG8gIlVwZGF0aW5nIHBhY2thZ2VzIC4uLiIKYXB0IHVwZGF0ZQphcHQgdXBncmFkZSAteQo="
}
O script pode, opcionalmente, ser compactado com Gzip para reduzir o tamanho (na maioria dos casos).
(CustomScript detecta automaticamente o uso de compactação gzip.)
cat script | gzip -9 | base64 -w 0
CustomScript usa o algoritmo a seguir para executar um script.

1. declarar que o comprimento do valor do script não excede 256 KB.
2. Base64 decodifica o valor do script
3. tentativa de efetuar gunzip no valor decodificado em Base64
4. gravar o valor decodificado (e opcionalmente descompactado) para o disco (/var/lib/waagent/custom-
script/#/script.sh)
5. execute o script usando _/bin/sh -c /var/lib/waagent/custom-script/#/script.sh.
NOTE
O CustomScript (versão 2,1 em diante) dá suporte à identidade gerenciada para baixar arquivo (s) de URLs
fornecidas na configuração "fileuris". Ele permite que o CustomScript acesse contêineres ou blobs privados do
armazenamento.
Exemplo:
{
}
Exemplos:
{
}
{
}
NOTE
storageAccountKey
Extensão de Script Personalizado durante uma implantação de modelo do Azure Resource Manager. Um modelo
de exemplo que inclui a Extensão de Script Personalizado pode ser encontrado aqui, GitHub.
{
"apiVersion": "2019-03-01",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
},
"commandToExecute": "sh hello.sh <param2>",
"fileUris": ["https://github.com/MyProject/Archive/hello.sh"
]
}
}
}
NOTE
CLI do Azure
Quando você estiver usando a CLI do Azure para executar a extensão de Script personalizado, crie um arquivo
ou arquivos de configuração. No mínimo, você deve ter 'commandToExecute'.
--protected-settings ./script-config.json
Opcionalmente, você pode especificar as configurações no comando como uma cadeia de caracteres do formato
JSON. Isso permite especificar a configuração durante a execução e sem um arquivo de configuração separado.
--resource-group exttest \
--vm-name exttest \
--protected-settings '{"fileUris": ["https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-
templates/master/dotnet-core-music-linux/scripts/config-music.sh"],"commandToExecute": "./config-music.sh"}'
Exemplos de CLI do Azure

Configuração pública com o arquivo de script
{
music-linux/scripts/config-music.sh"],
"commandToExecute": "./config-music.sh"
}
Configuração pública sem arquivo de script
{
"commandToExecute": "apt-get -y update && apt-get install -y apache2"
}
Arquivos de configuração protegida e pública

Você usa um arquivo de configuração pública para especificar o URI do arquivo de script. Você usa um arquivo
de configuração protegida para especificar o comando a ser executado.
Arquivo de configuração pública:
{
music-linux/scripts/config-music.sh"]
}
Arquivo de configuração protegida:
{
"commandToExecute": "./config-music.sh <param1>"
}
--vm-name myVM \
--settings ./script-config.json \
--protected-settings ./protected-config.json
Quando a extensão de script personalizado é executada, o script é criado ou baixado em um diretório
semelhante ao exemplo a seguir. A saída do comando também é salva nesse diretório nos arquivos stdout e
stderr .
/var/lib/waagent/custom-script/download/0/
Para solucionar problemas, primeiro verifique o Log de Agente do Linux, confira a extensão executada, verifique:
Você deve procurar a execução da extensão, a exibição será algo assim:
2018/04/26 17:47:22.110231 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] [Enable] current handler

state is: notinstalled
2018/04/26 17:47:22.306407 INFO Event: name=Microsoft.Azure.Extensions.customScript, op=Download,
message=Download succeeded, duration=167
2018/04/26 17:47:22.339958 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] Initialize extension
directory
2018/04/26 17:47:22.368293 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] Update settings file:
0.settings
2018/04/26 17:47:22.394482 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] Install extension
[bin/custom-script-shim install]
2018/04/26 17:47:23.432774 INFO Event: name=Microsoft.Azure.Extensions.customScript, op=Install,
message=Launch command succeeded: bin/custom-script-shim install, duration=1007
2018/04/26 17:47:23.476151 INFO [Microsoft.Azure.Extensions.customScript-2.0.6] Enable extension
[bin/custom-script-shim enable]
2018/04/26 17:47:24.516444 INFO Event: name=Microsoft.Azure.Extensions.customScript, op=Enable,
message=Launch command succeeded: bin/custom-sc
Alguns pontos a serem observados:

1. Habilitar é quando o comando é iniciado.
2. O download está relacionado ao download do pacote de extensão CustomScript do Azure, não aos arquivos
de script especificados no fileUris.
A extensão de script do Azure produz um log, que pode ser encontrado aqui:
/var/log/azure/custom-script/handler.log
Você deve procurar a execução individual; ela terá uma aparência semelhante a:
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=start
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=pre-check
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="comparing seqnum"
path=mrseq
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="seqnum saved"
path=mrseq
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="reading
configuration"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="read configuration"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="validating json
schema"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="json schema valid"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="parsing
configuration json"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="parsed
configuration json"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="validating
configuration logically"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="validated
configuration"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="creating output
directory" path=/var/lib/waagent/custom-script/download/0
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="created output
directory"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 files=1
start"
complete" output=/var/lib/waagent/custom-script/download/0
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="executing command"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="executing protected
commandToExecute" output=/var/lib/waagent/custom-script/download/0
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event="executed command"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=enabled
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=end
Aqui, você pode ver:

O início do comando Habilitar é este log
As configurações passadas para a extensão
A extensão baixando o arquivo e o resultado disso.
O comando em execução e o resultado.
Você também pode recuperar o estado de execução da extensão de script personalizado, incluindo os
argumentos reais passados como o commandToExecute usando CLI do Azure:
az vm extension list -g myResourceGroup --vm-name myVM
A saída se parece com o seguinte texto:

[
{
"id":
nsions/customscript",
"settings": {
"commandToExecute": "sh script.sh > ",
"fileUris": [
"https://catalogartifact.azureedge.net/publicartifacts/scripts/script.sh",
"https://catalogartifact.azureedge.net/publicartifacts/scripts/script.sh"
]
},
"tags": null,
"virtualMachineExtensionType": "CustomScript"
},
{
"id":
nsions/OmsAgentForLinux",
"instanceView": null,
"name": "OmsAgentForLinux",
"protectedSettings": null,
"settings": {
"workspaceId": "workspaceid"
},
"tags": null,
"virtualMachineExtensionType": "OmsAgentForLinux"
}
]
Próximas etapas
Para ver o código, os problemas atuais e as versões, consulte custom-script-extension-linux repo.
Extensão de script personalizado para o Windows
A extensão de script personalizado baixa e executa scripts em máquinas virtuais do Azure. Essa extensão é útil
para a configuração de pós-implantação, instalação de software ou qualquer outra configuração ou tarefas de
Portal do Azure no tempo de execução da extensão. A Extensão de Script Personalizado se integra com modelos
do Azure Resource Manager e pode ser executada usando a CLI do Azure, o PowerShell, o portal do Azure ou a
API REST da máquina virtual do Azure.
Este documento detalha como usar a Extensão de Script Personalizado usando o módulo do Azure PowerShell e
modelos do Azure Resource Manager, além de detalhar as etapas da solução de problemas em sistemas
Windows.
Pré-requisitos
NOTE
Não use a Extensão de Script Personalizado para executar Update-AzVM com a mesma VM como seu parâmetro, pois ela
aguardará por si própria.
Sistema operacional
A Extensão de Script Personalizado para Windows executará nos SOs de extensão compatíveis da extensão.
Windows
Windows Server 2012
Windows 10
Windows Server 2016
Windows Server 2019
Local do script
Você pode configurar a extensão para usar suas credenciais do Armazenamento de Blobs do Azure para acessar
esse armazenamento. A localização do script pode estar em qualquer lugar, desde que a VM possa rotear para
esse ponto de extremidade, como o GitHub ou um servidor de arquivos interno.
será necessário abrir portas adicionais do firewall e do Grupo de Segurança de Rede. Por exemplo, se o script
estiver localizado no Armazenamento do Azure, você poderá permitir acesso usando Marcas de Serviço do NSG
do Azure para Armazenamento.
Observe que a extensão CustomScript não tem nenhuma maneira de ignorar a validação do certificado.
Portanto, se você estiver baixando de um local seguro com por exemplo. um certificado autoassinado, você
pode acabar com erros como "o certificado remoto é inválido de acordo com o procedimento de validação".
Certifique-se de que o certificado esteja instalado corretamente no repositório "autoridades de certificação raiz
confiáveis" na máquina virtual.
Se o script estiver em um servidor local, ainda poderá ser necessário abrir portas adicionais do firewall e do
Dicas e truques
falha.
Escreva scripts idempotentes. Isso garante que, se eles forem executados novamente por acidente, não
causarão alterações no sistema.
Assegure-se de que os scripts não exigirão a entrada do usuário quando forem executados.
É permitido que o script seja executado em até 90 minutos e um período mais longo resultará em falha na
Não coloque reinicializações dentro do script, pois essa ação causará problemas com outras extensões que
estão sendo instaladas. Após a reinicialização, a extensão não continuará depois de reiniciar.
Se você tiver um script que causará uma reinicialização, instalará aplicativos e executará scripts, você poderá
agendar a reinicialização usando uma Tarefa Agendada do Windows ou usar ferramentas como as extensões
DSC, Chef ou Puppet.
deixar a extensão em um estado de transição, levando a um tempo limite.
A extensão executará um script somente uma vez. Se você quiser executar um script em cada inicialização,
use a extensão pra criar uma Tarefa Agendada do Windows.
Se você quiser agendar quando um script será executado, use a extensão para criar uma Tarefa Agendada do
Windows.
CLI. Se quiser atualizações de status mais frequentes de um script em execução, será necessário criar sua
própria solução.
uma ferramenta de transferência de arquivo que dá suporte a servidores proxy em seu script, como Invoke-
WebRequest
Esteja ciente dos locais de diretório não padrão nos quais os scripts ou comandos podem confiar e mantenha
uma lógica para lidar com essa situação.
A extensão de script personalizado será executada na conta LocalSystem
Se você planeja usar as propriedades storageAccountName e storageAccountKey , essas propriedades
deverão ser posicionadas no protectedSettings.
{
"apiVersion": "2018-06-01",
"name": "virtualMachineName/config-app",
"dependsOn": [
],
"tags": {
},
"properties": {
"settings": {
"fileUris": [
"script location"
],
},
"commandToExecute": "myExecutionCommand",
"storageAccountName": "myStorageAccountName",
"storageAccountKey": "myStorageAccountKey",
}
}
}
NOTE
storageAccountKey
NOTE
Somente uma versão de uma extensão pode ser instalada em uma VM em um determinado momento. A especificação de
um script personalizado duas vezes no mesmo modelo do Resource Manager para a mesma VM falhará.
NOTE
Podemos usar esse esquema dentro do recurso VirtualMachine ou como um recurso autônomo. O nome do recurso
precisará estar neste formato: "nomeDaMáquinaVirtual/nomeDaExtensão", se essa extensão for usada como um recurso
autônomo no modelo do ARM.

publicador Microsoft.Compute string
type CustomScriptExtension string
fileUris (por exemplo) https://raw.githubusercontent.com/Mic matriz

rosoft/dotnet-core-sample-
templates/master/dotnet-core-music-
windows/scripts/configure-music-
app.ps1
commandToExecute (por exemplo) powershell -ExecutionPolicy string

Unrestricted -File configure-music-
app.ps1


4240-a7ff-d85fb6cd7232" } ou {
"objectId": "12dd289c-0583-46e5-
b9b4-115d5c19ef4b" }
NOTE

commandToExecute : (necessária , cadeia de caracteres) o script de ponto de entrada a ser executado. Use esse
campo se o comando contiver segredos, como senhas, ou se os fileUris diferenciarem maiúsculas de
minúsculas.
timestamp (opcional, inteiro de 32 bits) use esse campo apenas para disparar uma nova execução do script,
alterando o valor desse campo. Qualquer valor inteiro é aceitável. Só deve ser diferente do valor anterior.
nas públicas.
commandToExecute
Usar configurações públicas talvez seja útil para depuração, mas é recomendável usar configurações protegidas.
configurações são salvas na VM conforme são enviadas, ou seja, se as configurações forem criptografadas, elas
serão salvas criptografadas na VM. O certificado usado para descriptografar os valores criptografados é
armazenado na VM e usado para descriptografar as configurações (se necessário) no runtime.
NOTE
O CustomScript (versão 1.10 em diante) é compatível com identidade gerenciada para baixar arquivos de URLs
fornecidas na configuração "fileUris". Ele permite que o CustomScript acesse contêineres ou blobs privados do
armazenamento.
Exemplo:
{
}
Exemplos:
{
}
{
}
NOTE
storageAccountKey
Extensões de VM do Azure podem ser implantadas com modelos do Azure Resource Manager. O esquema
JSON, detalhado na seção anterior, pode ser usado em um modelo do Azure Resource Manager para executar a
Extensão de Script Personalizado durante uma implantação. Os exemplos a seguir mostram como usar a
extensão de Script personalizado:
Tutorial: Implantar extensões de máquina virtual com modelos do Azure Resource Manager
Implante o aplicativo de duas camadas no Windows e no banco de dados SQL do Azure
O comando Set-AzVMCustomScriptExtension pode ser usado para adicionar a Extensão de Script Personalizado a
uma máquina virtual existente. Para obter mais informações, confira Set-AzVMCustomScriptExtension.
Set-AzVMCustomScriptExtension -ResourceGroupName <resourceGroupName> `

-VMName <vmName> `
-Location myLocation `
-FileUri <fileUrl> `
-Run 'myScript.ps1' `
-Name DemoScriptExtension
Mais exemplos
Usando vários scripts
Neste exemplo, você tem três scripts que são usados para criar seu servidor. O commandToExecute chama o
primeiro script e, em seguida, você tem opções sobre como os outros são chamados. Por exemplo, você pode
ter um script mestre que controla a execução, com o tratamento de erro, o registro em log e o gerenciamento de
estado corretos. Os scripts são baixados no computador local para execução. Por exemplo, em 1_Add_Tools.ps1 ,
você chamaria 2_Add_Features.ps1 adicionando .\2_Add_Features.ps1 ao script e repetiria esse processo para
os outros scripts definidos em $settings .
$fileUri = @("https://xxxxxxx.blob.core.windows.net/buildServer1/1_Add_Tools.ps1",
"https://xxxxxxx.blob.core.windows.net/buildServer1/2_Add_Features.ps1",
"https://xxxxxxx.blob.core.windows.net/buildServer1/3_CompleteInstall.ps1")
$settings = @{"fileUris" = $fileUri};
$storageAcctName = "xxxxxxx"
$storageKey = "1234ABCD"
$protectedSettings = @{"storageAccountName" = $storageAcctName; "storageAccountKey" = $storageKey;
"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File 1_Add_Tools.ps1"};
#run command
-VMName <vmName> `
-Name "buildserver1" `
-Settings $settings `
-ProtectedSettings $protectedSettings;
Executando scripts de um compartilhamento local

Neste exemplo, talvez você queira usar um servidor SMB local para a localização do script. Se fizer isso, você
não precisará fornecer outras configurações, exceto commandToExecute .
$protectedSettings = @{"commandToExecute" = "powershell -ExecutionPolicy Unrestricted -File

\\filesvr\build\serverUpdate1.ps1"};

-VMName <vmName> `
-Name "serverUpdate"
-ProtectedSettings $protectedSettings
Como executar o script personalizado mais de uma vez com a CLI

Se você quiser executar a extensão do script personalizado mais de uma vez, poderá executar essa ação
somente sob estas condições:
O parâmetro Name da extensão é o mesmo que o da implantação anterior da extensão.
Atualize a configuração, caso contrário, o comando não executará novamente. É possível adicionar uma
propriedade dinâmica ao comando, como um carimbo de data/hora.
Como alternativa, você pode definir a propriedade ForceUpdateTag como true .
Como usar Invoke-WebRequest
Se você estiver usando Invoke-WebRequest em seu script, precisará especificar o parâmetro -UseBasicParsing
ou, caso contrário, receberá o seguinte erro ao verificar o status detalhado:
The response content cannot be parsed because the Internet Explorer engine is not available, or Internet
Explorer's first-launch configuration is not complete. Specify the UseBasicParsing parameter and try again.
Conjuntos de Dimensionamento de Máquinas Virtuais

Para implantar a extensão de script personalizado em um conjunto de dimensionamento, confira Add-
AzVmssExtension
VMs clássicas
IMPORTANT
Para implantar a extensão de script personalizado em VMs clássicas, você pode usar o portal do Azure ou os
cmdlets clássicos do Azure PowerShell.
Portal do Azure
Navegue até o recurso de VM clássica. Em Configurações , selecione Extensões .
Clique em + Adicionar e, na lista de recursos, escolha Extensão de Script Personalizado .
Na página Instalar a extensão , selecione o arquivo local do PowerShell, preencha eventuais argumentos e
clique em Ok .
PowerShell
Use o cmdlet Set-AzureVMCustomScriptExtension para adicionar a extensão de script personalizado a uma
máquina virtual existente.
# define your file URI

$fileUri = 'https://xxxxxxx.blob.core.windows.net/scripts/Create-File.ps1'
# create vm object
$vm = Get-AzureVM -Name <vmName> -ServiceName <cloudServiceName>
# set extension
Set-AzureVMCustomScriptExtension -VM $vm -FileUri $fileUri -Run 'Create-File.ps1'
# update vm
$vm | Update-AzureVM

o comando a seguir:
Get-AzVMExtension -ResourceGroupName <resourceGroupName> -VMName <vmName> -Name myExtensionName
A saída da extensão é registrada nos arquivos localizados na pasta a seguir, na máquina virtual de destino.
C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension
Os arquivos especificados são baixados na pasta a seguir, na máquina virtual de destino.
C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.*\Downloads\<n>
em que <n> é um inteiro decimal que pode ser alterado entre as execuções da extensão. O valor 1.*
corresponde ao valor typeHandlerVersion atual e real da extensão. Por exemplo, o diretório real pode ser
C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloads\2 .
Ao executar o comando commandToExecute , a extensão definirá esse diretório (por exemplo, ...\Downloads\2 )
como o diretório de trabalho atual. Esse processo permite o uso de caminhos relativos para localizar os arquivos
baixados por meio da propriedade fileURIs . Veja a tabela abaixo para obter exemplos.
Como o caminho absoluto do download pode variar ao longo do tempo, é melhor optar por caminhos de
arquivo/script relativos na cadeia de caracteres commandToExecute , sempre que possível. Por exemplo:
"commandToExecute": "powershell.exe . . . -File \"./scripts/myscript.ps1\""
As informações de caminho após o primeiro segmento do URI são retidas para os arquivos baixados por meio
da lista de propriedades fileUris . Conforme mostrado na tabela a seguir, os arquivos baixados são mapeados
em subdiretórios de download para refletir a estrutura dos valores fileUris .
Exemplos de Arquivos Baixados
URI N O F IL EURIS LO C A L IZ A Ç Ã O B A IXA DA REL AT IVA LO C A L IZ A Ç Ã O B A IXA DA A B SO L UTA 1
https://someAcct.blob.core.windows.net/aContainer/scripts/myscript.ps1
./scripts/myscript.ps1 C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloads\2\scr
https://someAcct.blob.core.windows.net/aContainer/topLevel.ps1
./topLevel.ps1 C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.8\Downloads\2\top
1 Os caminhos de diretório absolutos são alterados durante o tempo de vida da VM, mas não em uma execução
da extensão CustomScript.
Suporte
fóruns do Azure e do Stack Overflow no MSDN. Você também pode registrar um incidente de Suporte do Azure.
Vá para o site de suporte do Azure e selecione Obter suporte. Para saber mais sobre como usar o suporte do
Executar scripts de shell em sua VM Linux usando o
recurso Executar Comando
O recurso Executar Comando usa o agente da máquina virtual (VM) para executar scripts de shell dentro de
uma VM Linux do Azure. Use esses scripts para o gerenciamento geral de máquinas ou aplicativos. Eles podem
ajudá-lo a diagnosticar e corrigir rapidamente problemas de rede e acesso à VM e colocar a VM em um bom
estado.
Benefícios
Acesse as máquinas virtuais de várias maneiras. O recurso Executar Comando pode executar scripts nas
máquinas virtuais remotamente usando o agente de VM. Use o comando Executar por meio do portal do Azure,
API REST ou CLI do Azure para VMs do Linux.
Esse recurso é útil em todos os cenários em que você deseja executar um script em uma máquina virtual. É uma
das únicas maneiras de solucionar problemas e corrigir uma máquina virtual que não tem a porta RDP ou SSH
aberta devido à configuração imprópria da rede ou do usuário administrativo.
Restrições
As seguintes restrições se aplicam ao usar o recurso Executar Comando:
A saída está limitada aos últimos 4.096 bytes.
O tempo mínimo para executar um script é de cerca de 20 segundos.
Scripts executados por padrão como um usuário com privilégios elevados no Linux.
É possível executar um script por vez.
Scripts que solicitam informações (modo interativo) não têm suporte.
Não é possível cancelar um script em execução.
O tempo máximo que um script pode ser executado é 90 minutos. Depois disso, o script atingirá o tempo
limite.
A conectividade de saída da VM é necessária para retornar os resultados do script.
NOTE
Para funcionar corretamente, Executar Comando requer conectividade (porta 443) a endereços IP públicos do Azure. Se a
extensão não tiver acesso a esses pontos de extremidade, os scripts poderão ser executados com êxito, mas não
retornarão os resultados. Se você estiver bloqueando o tráfego na máquina virtual, poderá usar marcas de serviço para
permitir o tráfego para os endereços IP públicos do Azure usando a marca AzureCloud .
Comandos disponíveis
Esta tabela mostra a lista de comandos disponíveis para VMs Linux. Use o comando RunShellScript para
executar qualquer script personalizado que desejar. Quando você estiver usando a CLI do Azure ou o PowerShell
para executar um comando, o valor fornecido para o parâmetro --command-id ou -CommandId deve ser um dos
seguintes valores listados. Quando especifica um valor que não é um comando disponível, recebe este erro:
The entity was not found in this Azure location
NOME DESC RIÇ Ã O
RunShellScript Executa um script de shell do Linux.
ifconfig Obtém a configuração de todas as interfaces de rede.
CLI do Azure
O exemplo a seguir usa o comando az vm run-command para executar um script de shell em uma VM Linux do
Azure.
az vm run-command invoke -g myResourceGroup -n myVm --command-id RunShellScript --scripts "apt-get update &&
apt-get install -y nginx"
NOTE
Para executar comandos como um usuário diferente, insira sudo -u para especificar uma conta de usuário.
Portal do Azure
Acesse uma VM no portal do Azure e selecione Executar comando em OPERAÇÕES . Você vê uma lista dos
comandos disponíveis a serem executados na VM.
Escolha um comando a ser executado. Alguns dos comandos podem ter parâmetros de entrada obrigatórios ou
opcionais. Para esses comandos, os parâmetros são apresentados como campos de texto para você fornecer os
valores de entrada. Para cada comando, é possível exibir o script que está em execução expandindo Exibir
script . RunShellScript é diferente dos outros comandos, uma vez que permite a você fornecer seu próprio
script personalizado.
NOTE
Os comandos internos não podem ser editados.
Depois de escolher o comando, selecione Executar para executar o script. Quando o script for concluído, ele
retornará a saída e os erros na janela de saída. A captura de tela a seguir mostra um exemplo de saída da
execução do comando ifconfig .
PowerShell
O exemplo a seguir usa o cmdlet Invoke-AzVMRunCommand para executar um script do PowerShell em uma
VM do Azure. O cmdlet espera que o script referenciado no parâmetro -ScriptPath seja o local onde o cmdlet é
executado.
Invoke-AzVMRunCommand -ResourceGroupName '<myResourceGroup>' -Name '<myVMName>' -CommandId 'RunShellScript'

-ScriptPath '<pathToScript>' -Parameter @{"arg1" = "var1";"arg2" = "var2"}
Limitando o acesso ao recurso Executar Comando

Listar os comandos de execução ou mostrar os detalhes de um comando requer a permissão
Microsoft.Compute/locations/runCommands/read . A função Leitor interna e os níveis superiores têm essa
permissão.
A execução de um comando requer a permissão Microsoft.Compute/virtualMachines/runCommand/action . A função
Colaborador de Máquina Virtual e os níveis superiores têm essa permissão.
Use uma das funções internas ou crie uma função personalizada para usar o recurso Executar Comando.
Próximas etapas
Para conhecer outras maneiras de executar scripts e comandos remotamente em sua VM, consulte Executar
scripts em sua VM Linux.
Executar scripts do PowerShell na VM Windows
usando o recurso Executar Comando
O recurso Executar Comando usa o agente da máquina virtual (VM) para executar scripts do PowerShell dentro
de uma VM Windows do Azure. Use esses scripts para o gerenciamento geral de máquinas ou aplicativos. Eles
podem ajudá-lo a diagnosticar e corrigir rapidamente problemas de rede e acesso à VM e colocar a VM em um
bom estado.
Benefícios
Acesse as máquinas virtuais de várias maneiras. O recurso Executar Comando pode executar scripts nas
máquinas virtuais remotamente usando o agente de VM. Use Executar Comando por meio do portal do Azure,
da API REST, ou do PowerShell para VMs do Windows.
Esse recurso é útil em todos os cenários em que você deseja executar um script em uma máquina virtual. É uma
das únicas maneiras de solucionar problemas e corrigir uma máquina virtual que não tem a porta RDP ou SSH
aberta devido à configuração imprópria da rede ou do usuário administrativo.
Restrições
As seguintes restrições se aplicam ao usar o recurso Executar Comando:
A saída está limitada aos últimos 4.096 bytes.
O tempo mínimo para executar um script é de cerca de 20 segundos.
Os scripts são executados como sistema no Windows.
É possível executar um script por vez.
Scripts que solicitam informações (modo interativo) não têm suporte.
Não é possível cancelar um script em execução.
O tempo máximo que um script pode ser executado é 90 minutos. Depois disso, ele atingirá o tempo limite.
A conectividade de saída da VM é necessária para retornar os resultados do script.
permitir a extensão em um estado de transição, levando a um tempo limite.
NOTE
Para funcionar corretamente, Executar Comando requer conectividade (porta 443) a endereços IP públicos do Azure. Se a
extensão não tiver acesso a esses pontos de extremidade, os scripts poderão ser executados com êxito, mas não
retornarão os resultados. Se você estiver bloqueando o tráfego na máquina virtual, poderá usar marcas de serviço para
permitir o tráfego para os endereços IP públicos do Azure usando a marca AzureCloud .
Comandos disponíveis
Esta tabela mostra a lista de comandos disponíveis para VMs Windows. Use o comando RunPowerShellScript
para executar qualquer script personalizado que desejar. Quando você estiver usando a CLI do Azure ou o
PowerShell para executar um comando, o valor fornecido para o parâmetro --command-id ou -CommandId deve
ser um dos seguintes valores listados. Quando especifica um valor que não é um comando disponível, recebe
este erro:
The entity was not found in this Azure location
NOME DESC RIÇ Ã O
RunPowerShellScript Executa um script do PowerShell.
EnableRemotePS Configura o computador para habilitar o PowerShell remoto.
EnableAdminAccount Verifica se a conta de administrador local está desabilitada e,

em caso positivo, a habilita.
IPConfig Mostra informações detalhadas do endereço IP, da máscara

de sub-rede e do gateway padrão de cada adaptador
associado ao TCP/IP.
RDPSettings Verifica as configurações do registro e de política de domínio.

Sugere as ações de política se o computador fizer parte de
um domínio ou modifica as configurações para os valores
padrão.
ResetRDPCer t Remove o certificado TSL/SSL associado ao ouvinte RDP e

restaura a segurança dele para o padrão. Use este script se
houver algum problema com o certificado.
SetRDPPor t Define o padrão ou o número da porta do usuário

especificado para conexões de Área de Trabalho Remota.
Habilita as regras de firewall para acesso de entrada à porta.
CLI do Azure
O exemplo a seguir usa o comando az vm run-command para executar um script de shell em uma VM Windows
do Azure.
# script.ps1
# param(
# [string]$arg1,
# [string]$arg2
# )
# Write-Host This is a sample script with parameters $arg1 and $arg2
az vm run-command invoke --command-id RunPowerShellScript --name win-vm -g my-resource-group \

--scripts @script.ps1 --parameters "arg1=somefoo" "arg2=somebar"
Portal do Azure
Acesse uma VM no portal do Azure e selecione Executar comando em OPERAÇÕES . Você vê uma lista dos
comandos disponíveis a serem executados na VM.
Escolha um comando a ser executado. Alguns dos comandos podem ter parâmetros de entrada obrigatórios ou
opcionais. Para esses comandos, os parâmetros são apresentados como campos de texto para você fornecer os
valores de entrada. Para cada comando, é possível exibir o script que está em execução expandindo Exibir
script . RunPowerShellScript é diferente dos outros comandos, uma vez que permite a você fornecer seu
próprio script personalizado.
NOTE
Os comandos internos não podem ser editados.
Depois de escolher o comando, selecione Executar para executar o script. Quando o script for concluído, ele
retornará a saída e os erros na janela de saída. A captura de tela a seguir mostra um exemplo de saída da
execução do comando RDPSettings .
PowerShell
O exemplo a seguir usa o cmdlet Invoke-AzVMRunCommand para executar um script do PowerShell em uma
VM do Azure. O cmdlet espera que o script referenciado no parâmetro -ScriptPath seja o local onde o cmdlet é
executado.
Invoke-AzVMRunCommand -ResourceGroupName '<myResourceGroup>' -Name '<myVMName>' -CommandId

'RunPowerShellScript' -ScriptPath '<pathToScript>' -Parameter @{"arg1" = "var1";"arg2" = "var2"}
Limitando o acesso ao recurso Executar Comando

Listar os comandos de execução ou mostrar os detalhes de um comando requer a
Microsoft.Compute/locations/runCommands/read permissão no nível de assinatura. A função Leitor interna e os
níveis superiores têm essa permissão.
A execução de um comando requer a permissão Microsoft.Compute/virtualMachines/runCommand/action . A função
Colaborador de Máquina Virtual e os níveis superiores têm essa permissão.
Use uma das funções internas ou crie uma função personalizada para usar o recurso Executar Comando.
Próximas etapas
Para conhecer outras maneiras de executar scripts e comandos remotamente em sua VM, consulte Executar
scripts na VM do Windows.
Visão geral do Hybrid Runbook Worker
Os runbooks na Automação do Azure talvez não tenham acesso aos recursos em outras nuvens ou no seu
ambiente local por serem executados na plataforma de nuvem do Azure. Você pode usar o recurso Hybrid
Runbook Worker da automação do Azure para executar runbooks diretamente no computador que está
hospedando a função e em recursos no ambiente para gerenciar esses recursos locais. Os Runbooks são
armazenados e gerenciados na automação do Azure e entregues a um ou mais computadores atribuídos.
Tipos de trabalho do runbook

Há dois tipos de runbook Workers-System e User. A tabela a seguir descreve a diferença entre eles.
T IP O DESC RIÇ Ã O
System O oferece suporte a um conjunto de runbooks ocultos

usados pelo recurso de Gerenciamento de Atualizações que
foram criados para instalar atualizações especificadas pelo
usuário em computadores Windows e Linux.
Esse tipo de Hybrid Runbook Worker não é um membro de
um grupo de Hybrid Runbook Worker e, portanto, não
executa runbooks direcionados a um grupo de runbook
Worker.
Usuário Dá suporte a runbooks definidos pelo usuário destinados a

serem executados diretamente no computador Windows e
Linux que são membros de um ou mais grupos do runbook
Worker.
Um Hybrid Runbook Worker pode ser executado no sistema operacional Windows ou Linux, e essa função
depende do agente de log Analytics reportando para um espaço de trabalho Azure monitor log Analytics. O
espaço de trabalho não é apenas para monitorar o computador para o sistema operacional com suporte, mas
também para baixar os componentes necessários para instalar o Hybrid Runbook Worker.
Quando a Gerenciamento de atualizações de automação do Azure estiver habilitada, qualquer computador
conectado ao seu espaço de trabalho do log Analytics será automaticamente configurado como um Hybrid
runbook Worker do sistema. Para configurá-lo como um usuário do Windows Hybrid Runbook Worker, consulte
implantar um windows Hybrid runbook Worker e para Linux, consulte implantar um Hybrid runbook Worker do
Linux.
Como ele funciona?

Cada usuário Hybrid Runbook Worker é um membro de um grupo de Hybrid Runbook Worker que você
especifica ao instalar o trabalho. Um grupo pode incluir um único trabalho, mas você pode incluir vários
trabalhadores em um grupo para alta disponibilidade. Cada computador pode hospedar um Hybrid Runbook
Worker relatórios para uma conta de automação; Você não pode registrar o Hybrid Worker em várias contas de
automação. Um Hybrid Worker só pode escutar trabalhos de uma única conta de automação. Para
computadores que hospedam o Hybrid runbook Worker do sistema gerenciado pelo Gerenciamento de
Atualizações, eles podem ser adicionados a um grupo de Hybrid Runbook Worker. Mas você deve usar a mesma
conta de automação para Gerenciamento de Atualizações e a associação de grupo de Hybrid Runbook Worker.
Ao iniciar um runbook em um Hybrid Runbook Worker de usuário, você especifica o grupo em que ele é
executado. Cada operador no grupo de sonda de automação do Azure para ver se todos os trabalhos estão
disponíveis. Se um trabalho estiver disponível, o primeiro funcionário a obter o trabalho o fará. O tempo de
processamento da fila de tarefas depende do perfil e da carga do hardware do trabalho híbrido. Você não pode
especificar um trabalhador específico. O Hybrid Worker funciona em um mecanismo de sondagem (a cada 30
segundos) e segue uma ordem de primeiro a entrar, primeiro a servir. Dependendo de quando um trabalho foi
enviado por push, qualquer trabalho híbrido efetua ping do serviço de automação seleciona o trabalho. Um
único operador híbrido pode, em geral, pegar quatro trabalhos por ping (ou seja, a cada 30 segundos). Se a taxa
de trabalhos de envio por push for maior que quatro por 30 segundos, haverá uma grande possibilidade de
outro operador híbrido no grupo de Hybrid Runbook Worker que selecionou o trabalho.
Uma Hybrid Runbook Worker não tem muitos dos limites de recursos de área restrita do Azure no espaço em
disco, memória ou soquetes de rede. Os limites em um Hybrid Worker estão relacionados apenas aos recursos
próprios do trabalho e não são limitados pelo limite de tempo de compartilhamento justo que as áreas restritas
do Azure têm.
Para controlar a distribuição de runbooks em Hybrid runbook Workers e quando ou como os trabalhos são
disparados, você pode registrar o Hybrid Worker em diferentes grupos de Hybrid Runbook Worker dentro de
sua conta de automação. Direcione os trabalhos para o grupo ou grupos específicos para dar suporte à sua
organização de execução.
Instalar Hybrid Runbook Worker

O processo para instalar um usuário Hybrid Runbook Worker depende do sistema operacional. A tabela a seguir
define os tipos de implantação.
SIST EM A O P ERA C IO N A L T IP O DE IM P L A N TA Ç Ã O
Windows Automatizado
Manual
Linux Manual
O método de instalação recomendado para um computador Windows é usar um runbook de automação do

Azure para automatizar completamente o processo de configurá-lo. Se isso não for viável, você poderá seguir
um procedimento passo a passo para instalar e configurar manualmente a função. Para máquinas Linux, você
executa um script Python para instalar o agente na máquina.
Planejamento de rede
Verifique a configuração da rede de automação do Azure para obter informações detalhadas sobre as portas,
URLs e outros detalhes de rede necessários para o Hybrid runbook Worker.
Uso do servidor proxy
Se você usar um servidor proxy para a comunicação entre a automação do Azure e as máquinas que executam
o agente de Log Analytics, verifique se os recursos apropriados estão acessíveis. O tempo limite para
solicitações dos serviços Hybrid Runbook Worker e Automação é de 30 segundos. Após três tentativas, a
solicitação falha.
Uso de firewall
Se você usar um firewall para restringir o acesso à Internet, deverá configurar o firewall para permitir o acesso.
Se estiver usando o gateway do Log Analytics como proxy, verifique se ele está configurado para Hybrid
Runbook Workers. Consulte Configurar o gateway de log Analytics para Hybrid runbook Workers de
automação.
Marcas de serviço
A automação do Azure dá suporte a marcas de serviço de rede virtual do Azure, começando com a marca de
serviço GuestAndHybridManagement. Você pode usar marcas de serviço para definir os controles de acesso à
rede em grupos de segurança de rede ou no Firewall do Azure. As marcas de serviço podem ser usadas no lugar
de endereços IP específicos quando você cria regras de segurança. Ao especificar o nome da marca de serviço
GuestAndHybridManagement no campo de origem ou de destino apropriado de uma regra, você pode
permitir ou negar o tráfego para o serviço de automação. Essa marca de serviço não dá suporte à permissão de
controle mais granular restringindo intervalos de IP para uma região específica.
A marca de serviço para o serviço de automação do Azure fornece somente IPs usados para os seguintes
cenários:
Disparar WebHooks de dentro de sua rede virtual
Permitir que os Hybrid runbook Workers ou os agentes de configuração de estado em sua VNet se
comuniquem com o serviço de automação
NOTE
A marca de serviço GuestAndHybridManagement atualmente não dá suporte à execução de trabalho de runbook em
uma área restrita do Azure, somente diretamente em um Hybrid runbook Worker.
Suporte para impacto nível 5 (IL5)

A Hybrid Runbook Worker de automação do Azure pode ser usada no Azure governamental para dar suporte a
cargas de trabalho de impacto nível 5 em uma das duas seguintes configurações:
Máquina virtual isolada. Quando implantados, eles consomem todo o host físico para esse computador,
fornecendo o nível necessário de isolamento necessário para dar suporte a cargas de trabalho do IL5.
Os hosts dedicados do Azure, que fornecem servidores físicos capazes de hospedar uma ou mais
máquinas virtuais, dedicados a uma assinatura do Azure.
NOTE
O isolamento de computação por meio da função Hybrid Runbook Worker está disponível para nuvens comerciais do
Azure e do governo dos EUA.
Endereços de Gerenciamento de Atualizações para Hybrid Runbook Worker

Além dos endereços padrão e das portas necessárias para o Hybrid Runbook Worker, Gerenciamento de
Atualizações tem outros requisitos de configuração de rede descritos na seção planejamento de rede .
State Configuration da Automação do Azure em um Hybrid Runbook

Worker
Você pode executar o State Configuration da Automação do Azure em um Hybrid Runbook Worker. Para
gerenciar a configuração de servidores que oferecem suporte ao Hybrid Runbook Worker, você deve adicionar
os servidores como nós DSC. Confira Habilitar computadores para gerenciamento pelo State Configuration da
Automação do Azure.
Limites de trabalho do runbook

O número máximo de grupos de Hybrid Worker por conta de automação é 4000 e é aplicável para os trabalhos
híbridos do sistema & usuário. Se você tiver mais de 4.000 computadores para gerenciar, é recomendável criar
outra conta de automação.
Runbooks em um Hybrid Runbook Worker

Você pode ter runbooks que gerenciam recursos no computador local ou executados em recursos no ambiente
local onde um usuário Hybrid Runbook Worker está implantado. Nesse caso, você pode optar por executar seus
runbooks no trabalho híbrido em vez de em uma conta da Automação. Os runbooks executados em um Hybrid
Runbook Worker têm estrutura idêntica àqueles executados na conta da Automação. Confira Executar runbooks
em um Hybrid Runbook Worker.
Trabalhos do Hybrid Runbook Worker
Os trabalhos do Hybrid Runbook Workers são executados na conta Sistema local no Windows ou na conta
nxautomation no Linux. A automação do Azure lida com trabalhos em Hybrid runbook Workers de forma
diferente dos trabalhos executados em áreas restritas do Azure. Confira Ambiente de execução de runbook.
Se o computador host do Hybrid Runbook Worker reiniciar, qualquer trabalho de runbook em execução será
reiniciado desde o início ou do último ponto de verificação para runbooks do Fluxo de trabalho do PowerShell.
Se um trabalho do runbook for reiniciado mais de três vezes, será suspenso.
Permissões de runbook para um Hybrid Runbook Worker
Como eles acessam recursos que não são do Azure, os runbooks em execução em um usuário Hybrid Runbook
Worker não podem usar o mecanismo de autenticação normalmente usado por runbooks Autenticando nos
recursos do Azure. Um runbook fornece sua própria autenticação aos recursos locais, ou configura a
autenticação usando entidades gerenciadas para os recursos do Azure. Você também pode especificar uma
conta Executar como para fornecer um contexto de usuário a todos os runbooks.
Exibir Hybrid runbook Workers do sistema
Depois que o recurso de Gerenciamento de Atualizações estiver habilitado em computadores Windows ou
Linux, você poderá inventariar a lista de grupos de Hybrid runbook Workers do sistema na portal do Azure.
Você pode exibir até 2.000 trabalhadores no portal selecionando a guia grupo de trabalhos híbridos do
sistema da opção Hybrid Workers grupo no painel esquerdo da conta de automação selecionada.
Se você tiver mais de 2.000 trabalhadores híbridos, para obter uma lista de todos eles, poderá executar o
seguinte script do PowerShell:
"Get-AzSubscription -SubscriptionName "<subscriptionName>" | Set-AzContext

$workersList = (Get-AzAutomationHybridWorkerGroup -ResourceGroupName "<resourceGroupName>" -
AutomationAccountName "<automationAccountName>").Runbookworker
$workersList | export-csv -Path "<Path>\output.csv" -NoClobber -NoTypeInformation"
Próximas etapas
Para saber como configurar os runbooks para automatizar processos no datacenter local ou em outro
ambiente de nuvem, consulte Executar runbooks em um Hybrid Runbook Worker.
Para saber como solucionar problemas de seus Hybrid Runbook Workers, veja Solucionar Problemas do
Hybrid Runbook Worker.
Como habilitar a virtualização aninhada em uma
VM do Azure
A virtualização aninhada tem suporte em várias famílias de máquinas virtuais do Azure. Essa funcionalidade
proporciona uma grande flexibilidade no suporte a cenários como ambientes de desenvolvimento, teste,
treinamento e demonstração.
Este artigo demonstra como habilitar o Hyper-V em uma VM do Azure e configurar a conectividade de Internet
com essa máquina virtual convidada.
Criar uma VM do Azure com capacidade de aninhamento

Crie uma nova VM do Windows Server 2016 do Azure. Para obter uma lista completa dos tamanhos de
máquinas virtuais que dão suporte para aninhamento, confira o artigo da Unidade de Computação do Azure.
Escolha um tamanho de VM grande o suficiente para dar suporte às demandas de uma máquina virtual
convidada. Neste exemplo, estamos usando uma VM do Azure de tamanho D4_v3.
Exiba a disponibilidade regional das máquinas virtuais da série Dv3 ou Ev3 aqui.
NOTE
Para obter instruções detalhadas sobre como criar uma nova máquina virtual, consulte Criar e gerenciar VMs Windows
com o módulo do Azure PowerShell
Conectar-se à VM do Azure
Inicie uma conexão da área de trabalho remota para a máquina virtual.
1. Clique no botão Conectar nas propriedades da máquina virtual. Um arquivo do protocolo RDP (.rdp) é
criado e baixado.
2. Para se conectar à sua VM, abra o arquivo RDP baixado. Se solicitado, clique em Conectar . Em um Mac,
você precisa de um cliente RDP, como este Cliente de Área de Trabalho Remota da Mac App Store.
3. Insira o nome de usuário e a senha especificados na criação da máquina virtual e clique em Ok .
4. Você pode receber um aviso do certificado durante o processo de logon. Clique em Sim ou em
Continuar para prosseguir com o processo de conexão.
Habilitar o recurso Hyper-V na VM do Azure

Defina essas configurações manualmente ou use um script do PowerShell que fornecemos para automatizar a
configuração.
Opção 1: Usar um script do PowerShell para configurar a virtualização aninhada
Um script do PowerShell para habilitar a virtualização aninhada em um host do Windows Server 2016 está
disponível no GitHub. O script verifica os pré-requisitos e, em seguida, configura a virtualização aninhada na VM
do Azure. Uma reinicialização da VM do Azure é necessária para concluir a configuração. Esse script pode
funcionar em outros ambientes, mas não há garantia disso. Confira a postagem no blog do Azure com uma
demonstração de vídeo ao vivo sobre a virtualização aninhada em execução no Azure!
https://aka.ms/AzureNVblog.
Opção 2: Configurar a virtualização aninhada manualmente
1. Na VM do Azure, abra o PowerShell como Administrador.
2. Habilite o recurso Hyper-V e as Ferramentas de Gerenciamento.
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
WARNING
Este comando reinicia a VM do Azure. Você perderá sua conexão RDP durante o processo de reinicialização.
3. Depois que a VM do Azure for reiniciada, reconecte-se à VM usando o RDP.
Configurar a conectividade com a Internet para a máquina virtual

convidada
Crie um novo adaptador de rede virtual para a máquina virtual convidada e configure um Gateway de NAT para
habilitar a conectividade com a Internet.
Criar um comutador de rede virtual NAT
2. Crie um comutador interno.
New-VMSwitch -Name "InternalNAT" -SwitchType Internal
3. Exiba as propriedades do comutador e anote o ifIndex do novo adaptador.
Get-NetAdapter
NOTE
Anote o “ifIndex” do comutador virtual recém-criado.
4. Crie um endereço IP para o Gateway de NAT.

Para configurar o gateway, você precisa de algumas informações sobre a rede:
IPAddress – o IP do Gateway de NAT especifica o endereço IPv4 ou IPv6 a ser usado como o endereço de
gateway padrão da sub-rede da rede virtual. O formulário genérico é a.b.c. 1 (por exemplo,
“192.168.0.1”). Embora a posição final não tenha de ser 1, ela geralmente é (com base no comprimento
do prefixo). Normalmente, você deve usar um espaço de endereço de rede privada RFC 1918.
PrefixLength – o tamanho do prefixo da sub-rede define o tamanho da sub-rede local (máscara de sub-
rede). O tamanho do prefixo de sub-rede será um valor inteiro entre 0 e 32. O valor 0 mapeará toda a
Internet e 32 permitirá somente um IP mapeado. Os valores comuns variam de 24 a 12, dependendo de
quantos IPs precisam ser anexados ao NAT. Um PrefixLength comum é 24 – essa é uma máscara de sub-
rede igual a 255.255.255.0.
InterfaceIndex – ifIndex é o índice de interface do comutador virtual criado na etapa anterior.
New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 13
Criar a rede NAT

Para configurar o gateway, você precisará fornecer informações sobre a rede e o Gateway de NAT:
Name – esse é o nome da rede NAT.
InternalIPInterfaceAddressPrefix – o prefixo de sub-rede NAT descreve o prefixo de IP do Gateway de NAT
acima, bem como o Tamanho de Prefixo da Sub-rede NAT acima. O formato genérico será a.b.c.0/Tamanho
de Prefixo da Sub-rede NAT.
No PowerShell, crie uma nova rede NAT.
New-NetNat -Name "InternalNat" -InternalIPInterfaceAddressPrefix 192.168.0.0/24
Criar a máquina virtual convidada

IMPORTANT
O agente convidado do Azure não tem suporte em VMs aninhadas e pode causar problemas no host e nas VMs
aninhadas. Não instale o agente do Azure em VMs aninhadas e não use uma imagem para criar as VMs aninhadas que já
têm o agente convidado do Azure instalado.
1. Abra o Gerenciador do Hyper-V e crie uma nova máquina virtual. Configure a máquina virtual para usar
a nova rede Interna criada.
2. Instale um sistema operacional na máquina virtual convidada.
NOTE
Você precisa de uma mídia de instalação de um sistema operacional para instalar na VM. Nesse caso, estamos
usando o Windows 10 Enterprise.
Atribuir um endereço IP à máquina virtual convidada

Atribua um endereço IP à máquina virtual convidada definindo um endereço IP estático na máquina virtual
convidada manualmente ou configurando o DHCP na VM do Azure para atribuir o endereço IP dinamicamente.
Opção 1: configurar o DHCP para atribuir dinamicamente um endereço IP à máquina virtual convidada
Siga as etapas abaixo para configurar o DHCP na máquina virtual host para a atribuição de endereço dinâmico.
Instalar o servidor DHCP na VM do Azure
1. Abra o Gerenciador de Servidor. No Painel, clique em Adicionar funções e recursos . O Assistente para
Adicionar Funções e Recursos é aberto.
2. No assistente, clique em Avançar até a página Funções de Servidor.
3. Clique para selecionar a caixa de seleção Ser vidor DHCP , clique em Adicionar Recursos e, em
seguida, clique em Avançar até concluir o assistente.
4. Clique em Instalar .
Configurar um novo escopo do DHCP
1. Abra o Gerenciador DHCP.
2. No painel de navegação, expanda o nome do servidor, clique com o botão direito do mouse em IPv4 e
clique em Novo Escopo . O Assistente para Novos Escopos será exibido. Clique em Avançar .
3. Insira um Nome e uma Descrição para o escopo e clique em Avançar .
4. Defina um intervalo de IP para o servidor DHCP (por exemplo, 192.168.0.100 para 192.168.0.200).
5. Clique em Avançar até a página Gateway Padrão. Insira o Endereço IP criado anteriormente (por
exemplo, 192.168.0.1) como o Gateway Padrão e, em seguida, clique em Adicionar .
6. Clique em Avançar até a conclusão do assistente, deixando todos os valores padrão e, em seguida, clique
em Concluir .
Opção 2: definir um endereço IP estático manualmente na máquina virtual convidada
Se você não configurou o DHCP para atribuir dinamicamente um endereço IP à máquina virtual convidada, siga
estas etapas para configurar um endereço IP estático.
2. Clique com o botão direito do mouse na máquina virtual convidada e clique em Conectar.
3. Entre na máquina virtual convidada.
4. Na máquina virtual convidada, abra a Central de Rede e Compartilhamento.
5. Configure o adaptador de rede para um endereço dentro do intervalo da rede NAT criada na seção
anterior.
Neste exemplo, você usará um endereço no intervalo 192.168.0.0/24.
Testar a conectividade na máquina virtual convidada

Na máquina virtual convidada, abra o navegador e navegue para uma página da Web.
Para obter instruções sobre como habilitar a conectividade transparente entre as VMs convidadas e VMs do
Azure, consulte este documento.
Montar o Armazenamento de Arquivos do Azure
em VMs Linux usando SMB
Este artigo mostra como utilizar o serviço armazenamento de Arquivos do Azure em uma VM Linux usando
uma montagem SMB com a CLI do Azure. O armazenamento de arquivos do Azure oferece compartilhamentos
de arquivos na nuvem usando o protocolo SMB padrão.
O armazenamento de arquivos oferece compartilhamentos de arquivos na nuvem que usam o protocolo SMB
padrão. Você pode montar um compartilhamento de arquivos em qualquer sistema operacional que dá suporte
a SMB 3.0. Ao usar uma montagem SMB no Linux, você obtém backups fáceis em uma localização robusta e
permanente de armazenamento de arquivamento com suporte em um SLA.
Mover arquivos de uma VM para uma montagem SMB hospedada no Armazenamento de arquivos é uma
ótima maneira de depurar logs. O mesmo compartilhamento SMB pode ser montado localmente em sua
estação de trabalho Mac, Linux ou Windows. O SMB não é a melhor solução para transmitir logs do Linux ou de
aplicativo em tempo real, pois o protocolo SMB não foi desenvolvido para lidar com tarefas de log tão grandes.
Uma ferramenta de camada de log unificada dedicada, como o Fluentd, poderá ser uma escolha melhor em
relação ao SMB para coletar a saída de log do Linux e de aplicativo.
Este guia exige que você esteja executando a CLI do Azure versão 2.0.4 ou posterior. Execute az --version para
descobrir a versão. Se você precisar instalar ou atualizar, confira Instalar a CLI do Azure.

Criar um grupo de recursos denominado myResourceGroup no local Leste dos EUA.
Criar uma conta de armazenamento

Crie uma nova conta de armazenamento no grupo de recursos que você criou ao utilizar o az storage account
create. Este exemplo cria uma conta de armazenamento denominada mySTORAGEACCT<random number> e
coloca uma referência a essa conta de armazenamento na variável STORAGEACCT . Os nomes de conta de
armazenamento devem ser exclusivo e, portanto, use $RANDOM para acrescentar um número ao final e torná-lo
exclusivo.
STORAGEACCT=$(az storage account create \

--resource-group "myResourceGroup" \
--name "mystorageacct$RANDOM" \
--location eastus \
--sku Standard_LRS \
--query "name" | tr -d '"')
Obter a chave de Armazenamento

Ao criar uma conta de armazenamento, as chaves da conta são criadas em pares, para que possam ser giradas
sem nenhuma interrupção de serviço. Depois de mudar as chaves para a segunda chave do par, você cria um
novo par de chaves. Novas chaves de conta de armazenamento são sempre criadas em pares, garantindo que
você sempre tenha, pelo menos, uma chave de conta de armazenamento não utilizada pronta para ser mudada.
Exibir as chaves da conta de armazenamento, usando az storage account keys list. Este exemplo armazena o
valor da chave 1 na variável STORAGEKEY .
STORAGEKEY=$(az storage account keys list \

--account-name $STORAGEACCT \
--query "[0].value" | tr -d '"')
Criar um compartilhamento de arquivo

Criar o compartilhamento de armazenamento de arquivos usando criar compartilhamento de armazenamento
az.
Os nomes de compartilhamento precisam ter somente letras em minúsculas, números e hifens, mas não podem
começar com um hífen. Para obter detalhes completos sobre como nomear arquivos e compartilhamentos de
arquivos, confira Nomenclatura e referência de compartilhamentos, diretórios, arquivos e metadados.
Este exemplo cria um compartilhamento chamado myshare com uma cota de 10-GiB.
az storage share create --name myshare \

--quota 10 \
--account-name $STORAGEACCT \
--account-key $STORAGEKEY
Criar um ponto de montagem

Para montar o compartilhamento de arquivos do Azure no seu computador Linux, você precisa certificar-se de
que você tem o pacote cifs-utils instalado. Para instruções sobre instalação, consulte Instalar o pacote cifs-utils
para sua distribuição Linux.
Os arquivos do Azure usa o protocolo SMB, que se comunica pela porta TCP 445. Se você estiver tendo
problemas para montar o compartilhamento de arquivos do Azure, verifique se que o firewall não está
bloqueando a porta TCP 445.
mkdir -p /mnt/MyAzureFileShare
Montar o compartilhamento
Monte o compartilhamento de arquivos do Azure para o diretório.
sudo mount -t cifs //$STORAGEACCT.file.core.windows.net/myshare /mnt/MyAzureFileShare -o

vers=3.0,username=$STORAGEACCT,password=$STORAGEKEY,dir_mode=0777,file_mode=0777,serverino
O comando acima usa o montar comando para montar o compartilhamento de arquivos do Azure e as opções
específicas ao cifs. Especificamente, o dir_mode e file_mode opções de conjunto de arquivos e diretórios para a
permissão 0777 . O 0777 dá a permissão de leitura, gravação e execução permissões para todos os usuários.
Você pode alterar essas permissões, substituindo os valores com os outros permissões chmod. Você também
pode usar outras cifs opções como gid ou uid.
Persista a montagem
Ao reinicializar a VM Linux, o compartilhamento SMB montado é desmontado durante o desligamento. Para
montar novamente o compartilhamento SMB durante a inicialização, adicione uma linha ao /etc/fstab do Linux.
O Linux usa o arquivo fstab para listar os sistemas de arquivos que precisa montar durante o processo de
inicialização. A adição do compartilhamento SMB garante que o compartilhamento do Armazenamento de
arquivos seja um sistema de arquivos montado permanentemente para a VM Linux. É possível adicionar o
compartilhamento SMB do Armazenamento de arquivos a uma nova VM ao usar a inicialização de nuvem.
//myaccountname.file.core.windows.net/mystorageshare /mnt/mymountpoint cifs

vers=3.0,username=mystorageaccount,password=myStorageAccountKeyEndingIn==,dir_mode=0777,file_mode=0777
Para aumentar a segurança em ambientes de produção, você deve armazenar suas credenciais fora fstab.
Próximas etapas
Usando Cloud-init para personalizar uma VM do Linux durante a criação
Adicionar um disco a uma VM do Linux
VMs do Azure Disk Encryption para Linux
Mover arquivos de e para uma VM Linux usando o
SCP
Este artigo mostra como mover arquivos da estação de trabalho para uma VM Linux do Azure ou de uma VM
Linux do Azure para a estação de trabalho, usando o SCP (Cópia Segura). Mover arquivos entre a estação de
trabalho e uma VM Linux, de forma rápida e segura, é uma parte crítica do gerenciamento da infraestrutura do
Azure.
Para este artigo, você precisa de uma VM Linux implantada no Azure usando arquivos de chave SSH pública e
privada. Você também precisa de um cliente SCP para o computador local. Ele é criado com base em SSH e
incluído no shell de Bash padrão da maioria dos computadores Linux e Mac e alguns shells do Windows.
Comandos rápidos
Copiar um arquivo para a VM Linux
scp file azureuser@azurehost:directory/targetfile
Copiar um arquivo da VM Linux
scp azureuser@azurehost:directory/file targetfile
Passo a passo detalhado

Como exemplo, movemos um arquivo de configuração do Azure para uma VM Linux e efetuamos pull de um
diretório de arquivos de log, ambos usando o SCP e chaves SSH.
Autenticação de par de chaves SSH

O SCP usa o SSH para a camada de transporte. O SSH manipula a autenticação no host de destino e também
move o arquivo em um túnel criptografado fornecido por padrão com o SSH. Para autenticação de SSH, nomes
de usuário e senhas podem ser usados. No entanto, a autenticação de chaves SSH públicas e privadas é
recomendada como uma melhor prática de segurança. Depois de o SSH autenticar a conexão, o SCP inicia a
cópia do arquivo. Usando um ~/.ssh/config configurado corretamente e chaves SSH pública e privada, a
conexão do SCP pode ser estabelecida sem o uso de um nome de usuário, com apenas um nome do servidor
(ou endereço IP). Se você tiver apenas uma chave SSH, o SCP a procurará no diretório ~/.ssh/ e a usará por
padrão para fazer logon na VM.
Para obter mais informações sobre como configurar o ~/.ssh/config e chaves SSH pública e privada, veja
Create SSH keys (Criar chaves SSH).
Usar o SCP para copiar um arquivo para uma VM Linux

Para o primeiro exemplo, copiamos um arquivo de configuração do Azure para uma VM Linux usada para
implantar a automação. Já que esse arquivo contém credenciais de API do Azure, as quais incluem segredos, a
segurança é importante. O túnel criptografado fornecido por SSH protege o conteúdo do arquivo.
O comando a seguir copia o arquivo local .azure/config para uma VM do Azure com o FQDN
myserver.eastus.cloudapp.azure.com. O nome de usuário administrador na VM do Azure é azureuser. O arquivo
é direcionado para o diretório /home/azureuser/. Substitua seus próprios valores nesse comando.
scp ~/.azure/config azureuser@myserver.eastus.cloudapp.com:/home/azureuser/config
Usar o SCP para copiar um diretório de uma VM Linux

Neste exemplo, copiamos um diretório de arquivos de log da VM Linux para a estação de trabalho. Um arquivo
de log pode ou não conter dados confidenciais ou segredos. No entanto, usar o SCP garante que o conteúdo
dos arquivos de log é criptografado. Usar o SCP para transferir os arquivos é a maneira mais fácil de enviar o
diretório de log e os arquivos para a estação de trabalho e, ao mesmo tempo, permanecer seguro.
O comando a seguir copia os arquivos no diretório inicial/azureuser/logs/ na VM do Azure para o diretório local
/tmp:
scp -r azureuser@myserver.eastus.cloudapp.com:/home/azureuser/logs/. /tmp/
O -r sinalizador instrui o SCP a copiar recursivamente os arquivos e diretórios do ponto do diretório listado
no comando. Observe também que a sintaxe de linha de comando é semelhante a um comando de cópia cp .
Próximas etapas
Gerenciar usuários, SSH e verificar ou reparar discos em VMs do Linux do Azure usando a extensão
VMAccess
Infraestrutura de Atualização do Red Hat para as
VMs Red Hat Enterprise do Linux sob demanda no
Azure
A RHUI (Infraestrutura de Atualização do Red Hat) permite que os provedores de nuvem, como o Azure,
espelhem o conteúdo do repositório hospedado pelo Red Hat, criem repositórios personalizados com conteúdo
específico ao Azure e o disponibilizem para as VMs do usuário final.
As imagens PAYG (Pagas conforme o uso) do RHEL (Red Hat Enterprise Linux) vêm pré-configuradas para
acessar o RHUI do Azure. Nenhuma configuração adicional é necessária. Para obter as atualizações mais
recentes, execute sudo yum update depois que sua instância do RHEL estiver pronta. Este serviço é incluído
como parte das taxas de software PAYG do RHEL.
Informações adicionais sobre imagens do RHEL no Azure, incluindo políticas de publicação e retenção, estão
disponíveis aqui.
Informações sobre as políticas de suporte do Red Hat para todas as versões do RHEL podem ser encontradas na
página Ciclo de vida do Red Hat Enterprise Linux.
IMPORTANT
RHUI destina-se apenas a imagens para PAYG (Pagamento Conforme o Uso). Para imagens personalizadas e golden,
também conhecidas como BYOS (traga sua própria licença), o sistema precisa ser anexado ao RHSM ou ao Satélite para
receber atualizações. Confira o artigo do Red Hat para obter mais detalhes.
Informações importantes sobre o RHUI do Azure

O Azure RHUI é a infraestrutura de atualização que dá suporte a todas as VMs PAYG do RHEL criadas no
Azure. Isso não impede que você registre suas VMs PAYG do RHEL com o Gerenciador de Assinaturas ou
Satélite ou outra fonte de atualizações, mas fazer isso com uma VM PAYG resultará em uma cobrança
dupla indireta. Confira o ponto a seguir para obter detalhes.
O acesso ao RHUI hospedado pelo Azure é incluído no preço de imagem PAYG do RHEL. Cancelar o
registro de uma VM RHEL PAYG do RHUI hospedado no Azure não converte a máquina virtual em uma
VM do tipo BYOL (traga sua própria licença). Se você registrar a mesma VM com outra origem de
atualizações, você pode incorrer em encargos duplos indiretos. Você será cobrado pela primeira vez pela
taxa de software RHEL do Azure. Você será cobrado pela segunda vez por assinaturas do Red Hat
adquiridas anteriormente. Se você precisar usar consistentemente uma infraestrutura de atualização
diferente do RHUI hospedado pelo Azure, considere a possibilidade de inscrever-se para usar as imagens
BYOS do RHEL.
As imagens de PAYG do RHEL para SAP no Azure (RHEL for SAP, RHEL for SAP HANA e RHEL for SAP
Business Applications) são conectadas a canais de RHUI dedicados que permanecem na versão
secundária específica do RHEL, conforme necessário para certificação SAP.
O acesso ao RHUI hospedado pelo Azure é limitado às VMs nos Intervalos de IP do datacenter do
Microsoft Azure. Se você estiver encaminhando por proxy todo o tráfego de VM por meio da
infraestrutura de rede local, talvez você precise configurar rotas definidas pelo usuário para as VMs PAYG
do RHEL para acessar o RHUI do Azure. Se esse for o caso, as rotas definidas pelo usuário precisarão ser
adicionadas para todos os endereços IP do RHUI.
Comportamento de atualização da imagem

Desde de abril de 2019, o Azure oferece imagens RHEL que estão conectadas a repositórios EUS (suporte de
atualização estendida) por padrão e imagens RHEL que são conectadas aos repositórios regulares (não EUS) por
padrão. Mais detalhes sobre o EUS do RHEL estão disponíveis na documentação do ciclo de vida da versão do
Red Hat e na documentação do EUS. O comportamento padrão de sudo yum update variará dependendo de
qual imagem do RHEL você provisionou, já que imagens diferentes estão conectadas a repositórios diferentes.
Para obter uma lista de imagens completa, execute az vm image list --publisher redhat --all usando a CLI do
Azure.
Imagens conectadas a repositórios não EUS
Se provisionar uma VM de uma imagem do RHEL que está conectada a repositórios não EUS, você será
atualizado para a versão secundária mais recente do RHEL quando executar sudo yum update . Por exemplo, se
você provisionar uma VM de uma imagem RHEL 7,4 PAYG e executar sudo yum update , você acabará com uma
VM rhel 7,8 (a versão secundária mais recente na família RHEL7).
As imagens que estão conectadas a repositórios não EUS não conterão um número de versão secundária no
SKU. O SKU é o terceiro elemento no URN (nome completo da imagem). Por exemplo, todas as imagens a seguir
são anexadas a repositórios não EUS:
RedHat:RHEL:7-LVM:7.4.2018010506
RedHat:RHEL:7-RAW:7.4.2018010506
Observe que os SKUs são 7-LVM ou 7-RAW. A versão secundária é indicada na versão (quarto elemento no
URN) dessas imagens.
Imagens conectadas a repositórios EUS
Se provisionar uma VM de uma imagem do RHEL que está conectada a repositórios EUS, você não será
atualizado para a versão secundária mais recente do RHEL quando executar sudo yum update . Isso ocorre
porque as imagens conectadas a repositórios EUS também são bloqueadas por versão para sua versão
secundária específica.
As imagens que estão conectadas a repositórios EUS conterão um número de versão secundário na SKU. Por
exemplo, todas as imagens a seguir são anexadas a repositórios EUS:
RedHat:RHEL:7.4:7.4.2019062107
RedHat:RHEL:7.5:7.5.2019062018
RedHat:RHEL:7.6:7.6.2019062116
EUS de RHEL e bloqueio de versão de VMs do RHEL

Os repositórios de suporte de atualização estendida (EUS) estão disponíveis para clientes que desejam bloquear
suas VMs do RHEL para uma determinada versão secundária do RHEL após o provisionamento da VM. É
possível bloquear a versão da VM do RHEL para uma versão secundária específica, atualizando os repositórios
para apontar os repositórios do Suporte de Atualização Estendida. Você também pode desfazer a operação de
bloqueio de versão do EUS.
NOTE
Não há suporte para EUS em Extras do RHEL. Isso significa que, se você estiver instalando um pacote que geralmente está
disponível no canal Extras do RHEL, não poderá fazer isso enquanto estiver em EUS. O ciclo de vida do produto Extras do
Red Hat é detalhado aqui.
No momento da redação deste artigo, o suporte do EUS foi encerrado para o RHEL < = 7.4. Consulte a seção
"Red Hat Enterprise Linux manutenção estendida" na documentação do Red Hat para obter mais detalhes.
O suporte para EUS do RHEL 7.4 termina em 31 de agosto de 2019
O suporte para EUS do RHEL 7.5 termina em 30 de abril de 2020
O suporte a RHEL 7,6 EUS termina em 31 de maio de 2021
O suporte para EUS do RHEL 7.7 termina em 30 de agosto de 2021
Alternar uma VM RHEL 7. x para EUS (bloqueio de versão para uma versão secundária específica)
Use as instruções a seguir para bloquear uma VM RHEL 7. x para uma versão secundária específica (executar
como raiz):
NOTE
Isso se aplica apenas às versões do RHEL 7. x para as quais o EUS está disponível. No momento da redação deste artigo,
isso inclui o RHEL 7.2-7.7. Mais detalhes estão disponíveis na página Ciclo de vida do Red Hat Enterprise Linux.
1. Desabilite repositórios não EUS:
yum --disablerepo='*' remove 'rhui-azure-rhel7'
2. Adicione repositórios EUS:
yum --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel7-
eus.config' install 'rhui-azure-rhel7-eus'
3. Bloqueie a variável releasever (executar como raiz):
echo $(. /etc/os-release && echo $VERSION_ID) > /etc/yum/vars/releasever
NOTE
A instrução acima bloqueará a versão secundária do RHEL para a versão secundária atual. Insira uma versão
secundária específica, caso queira atualizar e bloquear para uma versão secundária posterior que não seja a mais
recente. Por exemplo, echo 7.5 > /etc/yum/vars/releasever bloqueará sua versão do RHEL para RHEL 7,5.
4. Atualizar a VM do RHEL
sudo yum update
Alternar uma VM RHEL 8. x para EUS (bloqueio de versão para uma versão secundária específica)
Use as instruções a seguir para bloquear uma VM RHEL 8. x para uma versão secundária específica (executar
como raiz):
NOTE
Isso se aplica somente a versões do RHEL 8. x para as quais o EUS está disponível. No momento da redação deste artigo,
isso inclui o RHEL 8.1-8.2. Mais detalhes estão disponíveis na página Ciclo de vida do Red Hat Enterprise Linux.
1. Desabilite repositórios não EUS:
yum --disablerepo='*' remove 'rhui-azure-rhel8'
2. Obtenha o arquivo de configuração EUS repositórios:
wget https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel8-eus.config
yum --config=rhui-microsoft-azure-rhel8-eus.config install rhui-azure-rhel8-eus
4. Bloqueie a variável releasever (executar como raiz):
echo $(. /etc/os-release && echo $VERSION_ID) > /etc/yum/vars/releasever
NOTE
A instrução acima bloqueará a versão secundária do RHEL para a versão secundária atual. Insira uma versão
secundária específica, caso queira atualizar e bloquear para uma versão secundária posterior que não seja a mais
recente. Por exemplo, echo 8.1 > /etc/yum/vars/releasever bloqueará sua versão do RHEL para RHEL 8,1.
NOTE
Se houver problemas de permissão para acessar o releasever, você poderá editar o arquivo usando '
nano/etc/yum/VARs/releaseve ' e adicionar os detalhes da versão da imagem e salvar (' CTRL + o ' e pressionar
Enter e ' Ctrl + x ').
sudo yum update
Alternar uma VM RHEL 7. x de volta para não EUS (remover um bloqueio de versão )
Execute o seguinte como raiz:
1. Remova o arquivo releasever :
rm /etc/yum/vars/releasever
2. Desabilite repositórios EUS:
yum --disablerepo='*' remove 'rhui-azure-rhel7-eus'

3. Configure a VM do RHEL
yum --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel7.config'
install 'rhui-azure-rhel7'
sudo yum update
Mudar uma VM RHEL 8. x de volta para não EUS (remover um bloqueio de versão )
Execute o seguinte como raiz:
1. Remova o arquivo releasever :
rm /etc/yum/vars/releasever
2. Desabilite repositórios EUS:
yum --disablerepo='*' remove 'rhui-azure-rhel8-eus'
3. Obtenha o arquivo de configuração repositórios regular:
wget https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel8.config
yum --config=rhui-microsoft-azure-rhel8.config install rhui-azure-rhel8
sudo yum update
Os IPs para os servidores de distribuição de conteúdo do RHUI

O RHUI está disponível em todas as regiões onde as imagens do RHEL sob demanda estão disponíveis.
Atualmente, inclui todas as regiões públicas listadas na página Painel de status do Azure e as regiões Microsoft
Azure Alemanha e Governo dos EUA do Azure.
Se você estiver usando uma configuração de rede para restringir o acesso de VMs PAYG do RHEL, verifique se os
seguintes IPs são permitidos para que yum update funcione dependendo do ambiente em que você está:
# Azure Global
13.91.47.76
40.85.190.91
52.187.75.218
52.174.163.213
52.237.203.198
# Azure US Government
13.72.186.193
13.72.14.155
52.244.249.194
# Azure Germany
51.5.243.77
51.4.228.145
NOTE
As novas imagens do governo dos EUA do Azure, a partir de janeiro de 2020, usarão o IP público mencionado no
cabeçalho global do Azure acima.
NOTE
Além disso, observe que o Azure Alemanha foi preterido em favor de regiões públicas da Alemanha. A recomendação
para os clientes do Azure Alemanha é começar a apontar para RHUI públicas usando as etapas aqui.
Infraestrutura RHUI do Azure

Atualizar o certificado de cliente RHUI expirado em uma VM
Se você estiver usando uma imagem de VM do RHEL mais antiga, por exemplo, RHEL 7.4 (URN de imagem:
RedHat:RHEL:7.4:7.4.2018010506 ), terá problemas de conectividade ao RHUI devido a um certificado de cliente
TLS/SSL expirado. O erro que você vê pode se parecer com "O par SSL rejeitou seu certificado como expirado"
ou "Erro: Não é possível recuperar metadados de repositório (repomd.xml) do repositório:... Verifique o caminho
e tente novamente" . Para resolver esse problema, atualize o pacote do cliente de RHUI na VM usando o
comando a seguir:
sudo yum update -y --disablerepo='*' --enablerepo='*microsoft*'
Como alternativa, a execução de sudo yum update também atualizará o pacote do certificado do cliente
(dependendo da sua versão do RHEL), apesar dos erros de “certificado SSL expirado” que você verá em outros
repositórios. Se a atualização for bem-sucedida, a conectividade normal a outros repositórios de RHUI deverá
ser restaurada, portanto, será possível executar sudo yum update com êxito.
Se você encontrar um erro 404 ao executar um yum update , tente o seguinte para atualizar o cache yum:
sudo yum clean all;

sudo yum makecache
Solução de problemas de conexão com o RHUI do Azure

Se você estiver tendo problemas para se conectar ao RHUI do Azure de sua VM PAYG do Azure RHEL, siga estas
etapas:
1. Inspecione a configuração da VM para o ponto de extremidade do RHUI do Azure:
a. Verifique se o arquivo contém uma referência para
/etc/yum.repos.d/rh-cloud.repo
rhui-[1-3].microsoft.com na baseurl da seção [rhui-microsoft-azure-rhel*] do arquivo. Se esse
é o caso, significa que você está usando o novo RHUI do Azure.
b. No entanto, se ele estiver apontando para um local com o padrão a seguir, será necessária uma
atualização da configuração: mirrorlist.*cds[1-4].cloudapp.net . Você está usando o instantâneo
de VM antigo e precisa atualizá-lo o para que ele aponte para o novo RHUI do Azure.
2. Acesso ao RHUI hospedado no Azure é limitado às VMs dentro dos intervalos IP do datacenter do Azure.
3. Se estiver usando a nova configuração, verifique se a VM se conecta do intervalo de IP do Azure e, se
ainda não puder se conectar ao RHUI do Azure, registre um caso de suporte na Microsoft ou no Red Hat.
Atualização de infraestrutura
Em setembro de 2016, implantamos uma RHUI atualizada do Azure. Em abril de 2017, desligamos o antigo
RHUI do Azure. Se você usa as imagens PAYG do RHEL (ou seus instantâneos) de setembro de 2016 ou posterior,
você está se conectando automaticamente ao novo RHUI do Azure. No entanto, se houver instantâneos mais
antigos em suas VMs, você precisará atualizar manualmente a configuração deles para acessar o RHUI do Azure,
conforme descrito na seção a seguir.
Os novos servidores do Azure RHUI são implantados com o Gerenciador de Tráfego do Azure. No Gerenciador
de Tráfego, um único ponto de extremidade (rhui-1.microsoft.com) pode ser usado por qualquer VM,
independentemente da região.
Procedimento de atualização manual para usar os servidores do RHUI do Azure
Esse procedimento é fornecido apenas para referência. Imagens RHEL PAYG já tem a configuração correta para
se conectar ao Azure RHUI. Para atualizar manualmente a configuração para usar os servidores de RHUI do
Azure, conclua as seguintes etapas:
Para RHEL 6:
Para RHEL 7:
Para RHEL 8:
1. Crie um arquivo de configuração:
vi rhel8.config
2. Adicione o seguinte conteúdo ao arquivo de configuração:

[rhui-microsoft-azure-rhel8]
name=Microsoft Azure RPMs for Red Hat Enterprise Linux 8
baseurl=https://rhui-1.microsoft.com/pulp/repos/microsoft-azure-rhel8 https://rhui-
2.microsoft.com/pulp/repos/microsoft-azure-rhel8 https://rhui-
3.microsoft.com/pulp/repos/microsoft-azure-rhel8
enabled=1
gpgcheck=1
gpgkey=https://rhelimage.blob.core.windows.net/repositories/RPM-GPG-KEY-microsoft-azure-
release sslverify=1
3. Salve o arquivo e execute o seguinte comando:
dnf --config rhel8.config install 'rhui-azure-rhel8'
4. Atualize sua VM
sudo dnf update
Próximas etapas
Para criar uma VM do Red Hat Enterprise Linux por meio de uma imagem PAYG do Azure Marketplace e
aproveitar o RHUI hospedado pelo Azure, acesse o Azure Marketplace.
Para saber mais sobre as imagens de Red Hat no Azure, acesse a página da documentação.
Informações sobre as políticas de suporte do Red Hat para todas as versões do RHEL podem ser encontradas
na página Ciclo de vida do Red Hat Enterprise Linux.
Localizar imagens de VM do Linux no Azure
Marketplace com a CLI do Azure
Este tópico descreve como usar a CLI do Azure para localizar imagens de VM no Azure Marketplace. Use essas
informações para especificar uma imagem do Marketplace quando você criar uma VM programaticamente com
a CLI, os modelos do Gerenciador de Recursos ou outras ferramentas.
Procure também imagens e ofertas disponíveis usando a vitrine do Azure Marketplace, o portal do Azure ou o
Azure PowerShell.
Verifique se você está conectado a uma conta do Azure ( az login ).
Terminologia
Uma imagem do Marketplace no Azure tem os seguintes atributos:
Publicador : a organização que criou a imagem. Exemplos: Canonical, MicrosoftWindowsServer
Ofer ta : Nome de um grupo de imagens relacionadas criadas por um publicador. Exemplos: UbuntuServer,
WindowsServer
SKU : uma instância de uma oferta, como uma versão principal de uma distribuição. Exemplos: 18, 4-LTS,
2019-datacenter
Versão : o número de versão de uma imagem de SKU.
Para identificar uma imagem do Marketplace quando implantar uma VM de forma programática, forneça esses
valores individualmente como parâmetros, ou algumas ferramentas aceitam a imagem URN. Algumas
ferramentas aceitam uma imagem URN, que combina esses valores, separados por dois pontos (:) caractere:
Publicador: Oferta: Sku : versão. Em uma URN, substitua o número de versão por "mais recente", o que seleciona
a versão mais recente da imagem.
Se o editor de imagens fornecer licenças adicionais e termos de compra, você deverá aceitar esses termos e
ativar a implantação programática. Você também precisará fornecer parâmetros do plano de compra ao
implantar uma VM programaticamente. Consulte Implantar uma imagem com termos do Marketplace.
Pré-requisitos

Implantar de um VHD usando parâmetros do plano de compra
Se você tiver um VHD existente que foi criado usando uma imagem paga do Azure Marketplace, talvez seja
necessário fornecer as informações do plano de compra ao criar uma nova VM a partir desse VHD.
Se você ainda tiver a VM original ou outra VM criada usando a mesma imagem do Marketplace, poderá obter o
nome do plano, o editor e as informações do produto dele usando AZ VM Get-Instance-View. Este exemplo
obtém uma VM chamada myVM no grupo de recursos MyResource Group e, em seguida, exibe as informações
do plano de compra.
az vm get-instance-view -g myResourceGroup -n myVM --query plan
Se você não obtiver as informações do plano antes da exclusão da VM original, poderá arquivar uma solicitação
de suporte. Eles precisarão do nome da VM, da ID da assinatura e do carimbo de data/hora da operação de
exclusão.
Depois de ter as informações do plano, você pode criar a nova VM usando o --attach-os-disk parâmetro para
especificar o VHD.
az vm create \
--name myNewVM \
--nics myNic \
--size Standard_DS1_v2 --os-type Linux \
--attach-os-disk myVHD \
--plan-name planName \
--plan-publisher planPublisher \
--plan-product planProduct
Implantar uma nova VM usando parâmetros do plano de compra

Se você já tiver informações sobre a imagem, poderá implantá-la usando o az vm create comando. Neste
exemplo, implantamos uma VM com a imagem RabbitMQ certificada pela BitNami:
az group create --name myResourceGroupVM --location westus
az vm create --resource-group myResourceGroupVM --name myVM --image bitnami:rabbitmq:rabbitmq:latest --plan-

name rabbitmq --plan-product rabbitmq --plan-publisher bitnami
Se você receber uma mensagem sobre como aceitar os termos da imagem, consulte a seção aceitar os termos
mais adiante neste artigo.
Listar imagens populares

Execute o comando az vm image list sem a opção --all para ver uma lista de imagens de VM populares no
Azure Marketplace. Por exemplo, execute o comando a seguir para exibir uma lista armazenada em cache de
imagens populares em formato de tabela:
az vm image list --output table
A saída inclui o URN da imagem (o valor na coluna Urn). Ao criar uma VM com uma das imagens populares do
Marketplace, você poderá especificar como alternativa o UrnAlias, uma forma abreviada, como UbuntuLTS .
You are viewing an offline list of images, use --all to retrieve an up-to-date list
UrnAlias Version
------------- ---------------------- ------------------ -------------------------------------------------
------------- ------------------- ---------
CentOS OpenLogic 7.5 OpenLogic:CentOS:7.5:latest
CentOS latest
CoreOS CoreOS Stable CoreOS:CoreOS:Stable:latest
CoreOS latest
Debian credativ 8 credativ:Debian:8:latest
Debian latest
openSUSE-Leap SUSE 42.3 SUSE:openSUSE-Leap:42.3:latest
openSUSE-Leap latest
RHEL RedHat 7-RAW RedHat:RHEL:7-RAW:latest
RHEL latest
SLES SUSE 12-SP2 SUSE:SLES:12-SP2:latest
SLES latest
UbuntuServer Canonical 16.04-LTS Canonical:UbuntuServer:16.04-LTS:latest
UbuntuLTS latest
...
Localizar imagens específicas

Para localizar uma imagem de VM específica no mercado, use o comando az vm image list com a opção
--all . Essa versão do comando leva algum tempo para concluir e pode retornar uma saída longa, portanto,
você geralmente filtra a lista por --publisher ou outro parâmetro.
O exemplo a seguir exibe todas as ofertas para Debian (lembre-se de que sem a opção --all , ele pesquisa
apenas no cache local de imagens comuns):
az vm image list --offer Debian --all --output table
Resultado parcial:

Version
----------------- ----------- ------------------- -----------------------------------------------------
--------------
Debian credativ 7 credativ:Debian:7:7.0.201602010
7.0.201602010
7.0.201603020
7.0.201604050
7.0.201604200
7.0.201606280
7.0.201609120
7.0.201611020
7.0.201701180
8.0.201602010
8.0.201603020
8.0.201604050
8.0.201604200
8.0.201606280
8.0.201609120
8.0.201611020
8.0.201701180
8.0.201703150
8.0.201704110
8.0.201704180
8.0.201706190
8.0.201706210
8.0.201708040
8.0.201710090
8.0.201712040
8.0.201801170
8.0.201803130
8.0.201803260
8.0.201804020
8.0.201804150
8.0.201805160
8.0.201807160
8.0.201901221
...
Aplique filtros semelhantes com as opções --location , --publisher e --sku . Você pode executar
correspondências parciais em um filtro, assim como procurar por --offer Deb para localizar todas as imagens
Debian.
Se você não especificar um local específico com a opção --location , os valores para o local padrão serão
retornados. (Defina um local diferente do padrão executando az configure --defaults location=<location> .)
Por exemplo, o comando a seguir lista todos as SKUs do Debian 8 no local Europa Ocidental:
az vm image list --location westeurope --offer Deb --publisher credativ --sku 8 --all --output table
Resultado parcial:
------- ----------- ----------------- ----------------------------------------------- -------------
Debian credativ 8 credativ:Debian:8:8.0.201602010 8.0.201602010
...
Navegar pelas imagens

Outra maneira de localizar uma imagem em um local é executar os comandos az vm image list-publishers, az
vm image list-offers e az vm image list-skus em sequência. Com esses comandos, você determina estes valores:
1. Liste os editores de imagem.
2. Para um determinado editor, liste suas ofertas.
3. Para uma determinada oferta, liste seus SKUs.
Em seguida, para uma SKU selecionada, você pode escolher uma versão para implantar.
Por exemplo, o comando a seguir lista os editores de imagem na localização Oeste dos EUA:
az vm image list-publishers --location westus --output table
Resultado parcial:
Location Name
---------- ----------------------------------------------------
westus 128technology
westus 1e
westus 4psa
westus 5nine-software-inc
westus 7isolutions
westus a10networks
westus abiquo
westus accellion
westus accessdata-group
westus accops
westus Acronis
westus Acronis.Backup
westus actian-corp
westus actian_matrix
westus actifio
westus activeeon
westus advantech-webaccess
westus aerospike
westus affinio
westus aiscaler-cache-control-ddos-and-url-rewriting-
westus akamai-technologies
westus akumina
...
Use essas informações para encontrar as ofertas do editor específico. Por exemplo, para o editor Canonical no
local Oeste dos EUA, localize as ofertas dele executando azure vm image list-offers . Passe a localização e o
editor como no exemplo a seguir:
az vm image list-offers --location westus --publisher Canonical --output table
Saída:
Location Name
---------- -------------------------
westus Ubuntu15.04Snappy
westus Ubuntu15.04SnappyDocker
westus UbunturollingSnappy
westus UbuntuServer
westus Ubuntu_Core
Você vê que, na região Oeste dos EUA, o Canonical publica a oferta UbuntuServer no Azure. Mas quais SKUs?
Para obter esses valores, execute azure vm image list-skus e defina a localização, o editor e a oferta que você
descobriu:
az vm image list-skus --location westus --publisher Canonical --offer UbuntuServer --output table
Saída:
Location Name
---------- -----------------
westus 12.04.3-LTS
westus 12.04.4-LTS
westus 12.04.5-LTS
westus 14.04.0-LTS
westus 14.04.1-LTS
westus 14.04.2-LTS
westus 14.04.3-LTS
westus 14.04.4-LTS
westus 14.04.5-DAILY-LTS
westus 14.04.5-LTS
westus 16.04-DAILY-LTS
westus 16.04-LTS
westus 16.04.0-LTS
westus 18.04-DAILY-LTS
westus 18.04-LTS
westus 18.10
westus 18.10-DAILY
westus 19.04-DAILY
Finalmente, use o comando az vm image list para encontrar uma versão específica do SKU que você deseja,
por exemplo, 18.04-LTS :
az vm image list --location westus --publisher Canonical --offer UbuntuServer --sku 18.04-LTS --all --output
table
Resultado parcial:

------------ ----------- --------- ------------------------------------------------ ---------------
UbuntuServer Canonical 18.04-LTS Canonical:UbuntuServer:18.04-LTS:18.04.201804262 18.04.201804262
...
Agora você pode escolher exatamente a imagem que deseja usar anotando o valor do URN. Passe esse valor
com o parâmetro --image quando criar uma VM com o comando az vm create. Lembre-se de que é possível
substituir, como opção, o número de versão no URN por "mais recente". Essa versão é sempre a versão mais
recente da imagem.
Se você implantar uma VM com um modelo do Gerenciador de Recursos, defina os parâmetros de imagem
individualmente nas propriedades imageReference . Consulte a referência de modelo.
Implantar uma imagem com termos do Marketplace
Algumas imagens de VM no Azure Marketplace têm licenças e termos de compra adicionais que você deve
aceitar antes de implantá-las programaticamente.
Para implantar uma VM por meio de uma dessas imagens, você precisará aceitar os termos da imagem e
habilitar a implantação programática. Será necessário fazer isso apenas uma vez por assinatura. Posteriormente,
todas as vezes que você implantar uma VM programaticamente a partir da imagem, também será necessário
especificar os parâmetros do plano de compra.
As seções a seguir mostram como:
Descubra se uma imagem do Marketplace tem termos de licença adicionais
Aceitar os termos de forma programática
Fornecer parâmetros de plano de compra quando você implantar uma VM de forma programática
Exibir propriedades de plano
Para exibir as informações do plano de compra de uma imagem, execute o comando az vm image show. Se a
propriedade plan na saída não for null , isso significa que a imagem tem termos que você precisa aceitar
antes da implantação programática.
Por exemplo, a imagem Canonical Ubuntu Server 18.04 LTS não possui termos adicionais, porque a informação
plan é null :
az vm image show --location westus --urn Canonical:UbuntuServer:18.04-LTS:latest
Saída:
{
"dataDiskImages": [],
"id": "/Subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/Providers/Microsoft.Compute/Locations/westus/Publishers/Canonical/ArtifactTypes/VMImage/Offers/
UbuntuServer/Skus/18.04-LTS/Versions/18.04.201901220",
"location": "westus",
"name": "18.04.201901220",
"osDiskImage": {
"operatingSystem": "Linux"
},
"plan": null,
"tags": null
}
Executar um comando semelhante para a imagem de RabbitMQ Certified by Bitnami mostra as seguintes plan
propriedades: name , product e publisher . (Algumas imagens também têm uma promotion code propriedade.)
Para implantar essa imagem, consulte as seções a seguir para aceitar os termos e habilitar a implantação
programática.
az vm image show --location westus --urn bitnami:rabbitmq:rabbitmq:latest
Saída:
{
"dataDiskImages": [],
"id": "/Subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/Providers/Microsoft.Compute/Locations/westus/Publishers/bitnami/ArtifactTypes/VMImage/Offers/ra
bbitmq/Skus/rabbitmq/Versions/3.7.1901151016",
"name": "3.7.1901151016",
"osDiskImage": {
"operatingSystem": "Linux"
},
"plan": {
"name": "rabbitmq",
"product": "rabbitmq",
"publisher": "bitnami"
},
"tags": null
}
Aceitar os termos
Para exibir e aceitar os termos de licença, use o comando az vm image accept-terms. Quando aceita os termos,
você habilita a implantação programática na sua assinatura. Você só precisa aceitar os termos uma vez por
assinatura para a imagem. Por exemplo:
az vm image accept-terms --urn bitnami:rabbitmq:rabbitmq:latest
A saída inclui um licenseTextLink para os termos da licença e indica que o valor de accepted é true :
{
"accepted": true,
"additionalProperties": {},
"id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/providers/Microsoft.MarketplaceOrdering/offertypes/bitnami/offers/rabbitmq/plans/rabbitmq",
"licenseTextLink":
"https://storelegalterms.blob.core.windows.net/legalterms/3E5ED_legalterms_BITNAMI%253a24RABBITMQ%253a24RABB
ITMQ%253a24IGRT7HHPIFOBV3IQYJHEN2O2FGUVXXZ3WUYIMEIVF3KCUNJ7GTVXNNM23I567GBMNDWRFOY4WXJPN5PUYXNKB2QLAKCHP4IE5
GO3B2I.txt",
"name": "rabbitmq",
"plan": "rabbitmq",
"privacyPolicyLink": "https://bitnami.com/privacy",
"product": "rabbitmq",
"publisher": "bitnami",
"retrieveDatetime": "2019-01-25T20:37:49.937096Z",
"signature":
"XXXXXXLAZIK7ZL2YRV5JYQXONPV76NQJW3FKMKDZYCRGXZYVDGX6BVY45JO3BXVMNA2COBOEYG2NO76ONORU7ITTRHGZDYNJNXXXXXX",
"type": "Microsoft.MarketplaceOrdering/offertypes"
}
Próximas etapas
Para criar uma máquina virtual rapidamente usando as informações de imagem, consulte Criar e gerenciar VMs
do Linux usando a CLI do Azure.
Localizar e usar imagens de VM do Azure
Marketplace com Azure PowerShell
Este tópico descreve como usar o Azure PowerShell para localizar imagens de VM no Azure Marketplace. Em
seguida, você pode especificar uma imagem do Marketplace e planejar informações ao criar uma VM.
Você também pode procurar imagens e ofertas disponíveis usando a vitrine do Azure Marketplace, o portal do
Azure ou a CLI do Azure.
Terminologia
Uma imagem do Marketplace no Azure tem os seguintes atributos:
Publicador : a organização que criou a imagem. Exemplos: Canonical, MicrosoftWindowsServer
Ofer ta : Nome de um grupo de imagens relacionadas criadas por um publicador. Exemplos: UbuntuServer,
WindowsServer
SKU : uma instância de uma oferta, como uma versão principal de uma distribuição. Exemplos: 18, 4-LTS,
2019-datacenter
Versão : o número de versão de uma imagem de SKU.
Para identificar uma imagem do Marketplace quando implantar uma VM de forma programática, forneça esses
valores individualmente como parâmetros, ou algumas ferramentas aceitam a imagem URN. Algumas
ferramentas aceitam uma imagem URN, que combina esses valores, separados por dois pontos (:) caractere:
Publicador: Oferta: Sku : versão. Em uma URN, substitua o número de versão por "mais recente", o que seleciona
a versão mais recente da imagem.
Se o editor de imagens fornecer licenças adicionais e termos de compra, você deverá aceitar esses termos e
ativar a implantação programática. Você também precisará fornecer parâmetros do plano de compra ao
implantar uma VM programaticamente. Consulte Implantar uma imagem com termos do Marketplace.
Criar uma VM do VHD com informações do plano

Se você tiver um VHD existente que foi criado usando uma imagem do Azure Marketplace, talvez seja
necessário fornecer as informações do plano de compra ao criar uma nova VM a partir desse VHD.
Se você ainda tiver a VM original ou outra VM criada na mesma imagem, poderá obter o nome do plano, o
editor e as informações do produto usando Get-AzVM. Este exemplo obtém uma VM chamada myVM no grupo
de recursos MyResource Group e, em seguida, exibe as informações do plano de compra.
$vm = Get-azvm `
-Name myVM
$vm.Plan
Se você não obtiver as informações do plano antes da exclusão da VM original, poderá arquivar uma solicitação
de suporte. Eles precisarão do nome da VM, da ID da assinatura e do carimbo de data/hora da operação de
exclusão.
Para criar uma VM usando um VHD, consulte este artigo criar uma VM de um VHD especializado e adicionar
uma linha para adicionar as informações do plano à configuração da VM usando set-AzVMPlan semelhante ao
seguinte:
$vmConfig = Set-AzVMPlan `
-VM $vmConfig `
-Publisher "publisherName" `
-Product "productName" `
-Name "planName"
Criar uma nova VM com base em uma imagem do Marketplace

Se você já tiver as informações sobre qual imagem deseja usar, poderá passar essas informações para o cmdlet
set-AzVMSourceImage para adicionar informações de imagem à configuração da VM. Consulte as próximas
seções para pesquisar e listar as imagens disponíveis no Marketplace.
Algumas imagens pagas também exigem que você forneça informações do plano de compra usando o set-
AzVMPlan.
...
$vmConfig = New-AzVMConfig -VMName "myVM" -VMSize Standard_D1
# Set the Marketplace image

$offerName = "windows-data-science-vm"
$skuName = "windows2016"
$version = "19.01.14"
$vmConfig = Set-AzVMSourceImage -VM $vmConfig -PublisherName $publisherName -Offer $offerName -Skus $skuName
-Version $version
# Set the Marketplace plan information, if needed

$publisherName = "microsoft-ads"
$productName = "windows-data-science-vm"
$planName = "windows2016"
$vmConfig = Set-AzVMPlan -VM $vmConfig -Publisher $publisherName -Product $productName -Name $planName
...
Em seguida, você passará a configuração da VM junto com os outros objetos de configuração para o New-AzVM
cmdlet. Para obter um exemplo detalhado de como usar uma configuração de VM com o PowerShell, consulte
este script.
Se você receber uma mensagem sobre como aceitar os termos da imagem, consulte a seção aceitar os termos
mais adiante neste artigo.
Listar imagens
Uma maneira de localizar uma imagem em um local é executar os cmdlets Get-AzVMImagePublisher, Get-
AzVMImageOffer e Get-AzVMImageSku na ordem:
1. Liste os editores de imagem.
2. Para um determinado editor, liste suas ofertas.
3. Para uma determinada oferta, liste seus SKUs.
Em seguida, para uma SKU escolhida, execute Get-AzVMImage para listar as versões para implantar.
1. Lista os editores:
$locName="<Azure location, such as West US>"
Get-AzVMImagePublisher -Location $locName | Select PublisherName
2. Preencha o nome do editor escolhido e liste as ofertas:
$pubName="<publisher>"
Get-AzVMImageOffer -Location $locName -PublisherName $pubName | Select Offer
3. Preencha o nome da oferta escolhida e listar os SKUs:
$offerName="<offer>"
Get-AzVMImageSku -Location $locName -PublisherName $pubName -Offer $offerName | Select Skus
4. Preencha o nome da SKU escolhida e obter a versão da imagem:
$skuName="<SKU>"
Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Sku $skuName | Select
Version
Na saída do comando Get-AzVMImage , você pode selecionar uma imagem de versão para implantar uma nova
máquina virtual.
O exemplo a seguir mostra a sequência completa de comandos e suas saídas:
$locName="West US"
Get-AzVMImagePublisher -Location $locName | Select PublisherName
Resultado parcial:
PublisherName
-------------
...
abiquo
accedian
accellion
accessdata-group
accops
Acronis
Acronis.Backup
actian-corp
actian_matrix
actifio
activeeon
adgs
advantech
advantech-webaccess
advantys
...
Para o editor de MicrosoftWindowsServer :
$pubName="MicrosoftWindowsServer"
Get-AzVMImageOffer -Location $locName -PublisherName $pubName | Select Offer
Saída:
Offer
-----
Windows-HUB
WindowsServer
WindowsServerSemiAnnual
Para a oferta de WindowsServer:
$offerName="WindowsServer"
Get-AzVMImageSku -Location $locName -PublisherName $pubName -Offer $offerName | Select Skus
Resultado parcial:
Skus
----
2008-R2-SP1
2008-R2-SP1-smalldisk
2012-Datacenter
2012-Datacenter-smalldisk
2012-R2-Datacenter
2012-R2-Datacenter-smalldisk
2016-Datacenter
2016-Datacenter-Server-Core
2016-Datacenter-Server-Core-smalldisk
2016-Datacenter-smalldisk
2016-Datacenter-with-Containers
2016-Datacenter-with-RDSH
2019-Datacenter
2019-Datacenter-Core
2019-Datacenter-Core-smalldisk
2019-Datacenter-Core-with-Containers
...
Em seguida, para a SKU 2019-Datacenter:
$skuName="2019-Datacenter"
Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Sku $skuName | Select Version
Agora você pode combinar o editor, a oferta, a SKU e a versão selecionados em um URN (valores separados por
:). Passe esse URN com o parâmetro --image quando criar uma VM com o cmdlet New-AzVM. Opcionalmente,
você pode substituir o número da versão no URN por "latest" para obter a versão mais recente da imagem.
Se você implantar uma VM com um modelo do Resource Manager, definirá os parâmetros da imagem
individualmente nas propriedades imageReference . Consulte a referência de modelo.
Implantar uma imagem com termos do Marketplace

Algumas imagens de VM no Azure Marketplace têm licenças e termos de compra adicionais que você deve
aceitar antes de implantá-las programaticamente.
Para implantar uma VM por meio de uma dessas imagens, você precisará aceitar os termos da imagem e
habilitar a implantação programática. Será necessário fazer isso apenas uma vez por assinatura. Posteriormente,
todas as vezes que você implantar uma VM programaticamente a partir da imagem, também será necessário
especificar os parâmetros do plano de compra.
As seções a seguir mostram como:
Descubra se uma imagem do Marketplace tem termos de licença adicionais
Aceitar os termos de forma programática
Fornecer parâmetros de plano de compra quando você implantar uma VM de forma programática
Exibir propriedades de plano
Para exibir as informações do plano de compra de uma imagem, execute o cmdlet Get-AzVMImage . Se a
propriedade PurchasePlan na saída não for null , isso significa que a imagem tem termos que você precisa
aceitar antes da implantação programática.
Por exemplo, a imagem do Windows Server 2016 Datacenter não tem termos adicionais, portanto, as
informações de PurchasePlan são null :
$version = "2016.127.20170406"
Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Skus $skuName -Version $version
Saída:
Id : /Subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/Providers/Microsoft.Compute/Locations/westus/Publishers/MicrosoftWindowsServer/ArtifactTypes/VM
Image/Offers/WindowsServer/Skus/2016-Datacenter/Versions/2019.0.20190115
Location : westus
PublisherName : MicrosoftWindowsServer
Offer : WindowsServer
Skus : 2019-Datacenter
Version : 2019.0.20190115
FilterExpression :
Name : 2019.0.20190115
OSDiskImage : {
"operatingSystem": "Windows"
}
PurchasePlan : null
DataDiskImages : []
O exemplo a seguir mostra um comando semelhante para a imagem máquina virtual de ciência de dados-
Windows 2016 , que tem as seguintes PurchasePlan Propriedades: name , product e publisher . Algumas
imagens também têm um promotion code propriedade. Para implantar essa imagem, consulte as seções a
seguir para aceitar os termos e ativar a implantação programática.
Get-AzVMImage -Location "westus" -PublisherName "microsoft-ads" -Offer "windows-data-science-vm" -Skus

"windows2016" -Version "0.2.02"
Saída:
Id : /Subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/Providers/Microsoft.Compute/Locations/westus/Publishers/microsoft-
ads/ArtifactTypes/VMImage/Offers/windows-data-science-vm/Skus/windows2016/Versions/19.01.14
Location : westus
PublisherName : microsoft-ads
Offer : windows-data-science-vm
Skus : windows2016
Version : 19.01.14
FilterExpression :
Name : 19.01.14
OSDiskImage : {
"operatingSystem": "Windows"
}
PurchasePlan : {
"publisher": "microsoft-ads",
"name": "windows2016",
"product": "windows-data-science-vm"
}
DataDiskImages : []
Aceitar os termos
Para exibir os termos da licença, use o cmdlet Get-AzMarketplaceterms e passe os parâmetros do plano de
compra. A saída fornece um link para os termos da imagem do Marketplace e mostra se você aceitou os termos
anteriormente. Certifique-se de usar todas as letras minúsculas nos valores de parâmetros.
Get-AzMarketplaceterms -Publisher "microsoft-ads" -Product "windows-data-science-vm" -Name "windows2016"
Saída:
Publisher : microsoft-ads
Product : windows-data-science-vm
Plan : windows2016
LicenseTextLink :
https://storelegalterms.blob.core.windows.net/legalterms/3E5ED_legalterms_MICROSOFT%253a2DADS%253a24WINDOWS%
253a2DDATA%253a2DSCIENCE%253a2DVM%253a24WINDOWS2016%253a24OC5SKMQOXSED66BBSNTF4XRCS4XLOHP7QMPV54DQU7JCBZWYFP
35IDPOWTUKXUC7ZAG7W6ZMDD6NHWNKUIVSYBZUTZ245F44SU5AD7Q.txt
PrivacyPolicyLink : https://www.microsoft.com/EN-US/privacystatement/OnlineServices/Default.aspx
Signature :
2UMWH6PHSAIM4U22HXPXW25AL2NHUJ7Y7GRV27EBL6SUIDURGMYG6IIDO3P47FFIBBDFHZHSQTR7PNK6VIIRYJRQ3WXSE6BTNUNENXA
Accepted : False
Signdate : 1/25/2019 7:43:00 PM
Use o cmlet Set-AzMarketplaceterms para aceitar ou rejeitar os termos. Você só precisa aceitar os termos uma
vez por assinatura para a imagem. Certifique-se de usar todas as letras minúsculas nos valores de parâmetros.
$agreementTerms=Get-AzMarketplaceterms -Publisher "microsoft-ads" -Product "windows-data-science-vm" -Name

"windows2016"
Set-AzMarketplaceTerms -Publisher "microsoft-ads" -Product "windows-data-science-vm" -Name "windows2016" -

Terms $agreementTerms -Accept
Saída:
Publisher : microsoft-ads
Product : windows-data-science-vm
Plan : windows2016
LicenseTextLink :
https://storelegalterms.blob.core.windows.net/legalterms/3E5ED_legalterms_MICROSOFT%253a2DADS%253a24WINDOWS%
253a2DDATA%253a2DSCIENCE%253a2DV
M%253a24WINDOWS2016%253a24OC5SKMQOXSED66BBSNTF4XRCS4XLOHP7QMPV54DQU7JCBZWYFP35IDPOWTUKXUC7ZAG7W6ZMDD6NHWNKUI
VSYBZUTZ245F44SU5AD7Q.txt
PrivacyPolicyLink : https://www.microsoft.com/EN-US/privacystatement/OnlineServices/Default.aspx
Signature :
XXXXXXK3MNJ5SROEG2BYDA2YGECU33GXTD3UFPLPC4BAVKAUL3PDYL3KBKBLG4ZCDJZVNSA7KJWTGMDSYDD6KRLV3LV274DLBXXXXXX
Accepted : True
Signdate : 2/23/2018 7:49:31 PM
Próximas etapas
Para criar uma máquina virtual rapidamente com o cmdlet New-AzVM usando informações básicas de imagem,
consulte Criar uma máquina virtual do Windows com o PowerShell.
Para obter mais informações sobre como usar imagens do Azure Marketplace para criar imagens
personalizadas em uma galeria de imagens compartilhadas, consulte fornecer informações do plano de compra
do Azure Marketplace ao criar imagens.
Usar o cliente do Windows no Azure para cenários
de desenvolvimento/teste
Use o Windows 7, Windows 8 ou Windows 10 Enterprise (x64) no Azure para cenários de

desenvolvimento/teste, desde que você tenha uma assinatura apropriada do Visual Studio (anteriormente
MSDN).
Para executar o Windows 10 em um ambiente de produção, consulte como implantar o Windows 10 no Azure
com direitos de hospedagem multilocatário.
Qualificação de assinatura
Assinantes ativos do Visual Studio (pessoas que adquiriram uma licença de assinatura do Visual Studio) podem
usar imagens de cliente do Windows para fins de desenvolvimento e teste. As imagens de cliente do Windows
podem ser usadas em seu próprio hardware ou em máquinas virtuais do Azure.
Determinadas imagens de cliente do Windows estão disponíveis no Azure Marketplace. Os assinantes do Visual
Studio em qualquer tipo de oferta também podem preparar e criar imagens de 64 bits do Windows 7, do
Windows 8 ou do Windows 10 e, em seguida, carregar para o Azure.
Ofertas qualificadas e imagens de cliente

A tabela a seguir detalha as IDs de oferta qualificadas para implantar imagens de cliente do Windows por meio
do Azure Marketplace. As imagens de cliente do Windows são visíveis apenas para as ofertas a seguir.
N O M E DA O F ERTA N ÚM ERO DA O F ERTA IM A GEN S DE C L IEN T E DISP O N ÍVEIS
Desenvolvimento/Teste pré-pago 0023P Windows 10 Enterprise N (x64)

Windows 8.1 Enterprise N (x64)
Windows 7 Enterprise N com SP1 (x64)
Assinantes do Visual Studio Enterprise 0029P Windows 10 Enterprise N (x64)

(MPN) Windows 8.1 Enterprise N (x64)
Assinantes do Visual Studio 0059P Windows 10 Enterprise N (x64)

Professional Windows 8.1 Enterprise N (x64)
Assinantes do Visual Studio Test 0060P Windows 10 Enterprise N (x64)

Professional Windows 8.1 Enterprise N (x64)
Visual Studio Premium com MSDN 0061P Windows 10 Enterprise N (x64)

(benefício) Windows 8.1 Enterprise N (x64)

N O M E DA O F ERTA N ÚM ERO DA O F ERTA IM A GEN S DE C L IEN T E DISP O N ÍVEIS

(BizSpark) Windows 8.1 Enterprise N (x64)
Desenvolvimento/Teste Enterprise 0148P Windows 10 Enterprise N (x64)

Verificar sua assinatura do Azure

Se você não souber sua ID de oferta, poderá obtê-la por meio do portal do Azure ou de uma destas duas
maneiras:
Na janela assinaturas :
Ou, clique em Cobrança e, em seguida, clique em sua ID de assinatura. A ID da oferta aparece na janela
Cobrança. Você também pode exibir a ID da oferta na guia ' assinaturas ' do portal da conta do Azure:
Próximas etapas
Agora você pode implantar suas VMs usando o PowerShell, os modelos do Resource Manager ou o Visual
Studio.
Trazer e criar imagens do Linux no Azure
Esta visão geral aborda os conceitos básicos sobre a geração de imagens e como criar e usar com êxito imagens
do Linux no Azure. Antes de trazer uma imagem personalizada para o Azure, você precisa estar ciente dos tipos
e das opções disponíveis para você.
Este artigo percorrerá os pontos e requisitos de decisão de imagem e explicará os principais conceitos, para que
você possa acompanhar e ser capaz de criar as próprias imagens personalizadas de acordo com sua
especificação.
Diferença entre discos gerenciados e imagens

O Azure permite que você coloque um VHD na plataforma ou use como um Disco Gerenciado ou como uma
origem para uma imagem.
Os discos gerenciados do Azure são VHDs únicos. É possível usar um VHD existente e criar um disco gerenciado
com base nele ou criar um disco gerenciado vazio do zero. É possível criar VMs com base em discos
gerenciados anexando o disco à VM, mas você só pode usar um VHD com uma VM. Não é possível modificar
nenhuma propriedade do sistema operacional; o Azure tentará ligar a VM e inicializar usando esse disco.
As imagens do Azure podem ser compostas por vários discos do sistema operacional e de dados. Quando você
usa uma imagem gerenciada para criar uma VM, a plataforma faz uma cópia da imagem e a usa para criar a VM,
de modo que a imagem gerenciada dá suporte à reutilização da mesma imagem para várias VMs. O Azure
também fornece funcionalidades avançadas de gerenciamento para imagens, como replicação global, e controle
de versão por meio da Galeria de Imagens Compartilhadas.
Generalizados e especializados
O Azure oferece dois tipos de imagem principais: generalizados e especializados. Os termos “generalizados” e
“especializados” são termos originalmente do Windows, que foram migrados para o Azure. Esses tipos definem
como a plataforma tratará a VM quando ela for ativada. Os dois tipos têm vantagens e desvantagens e pré-
requisitos. Antes de começar, é necessário saber qual tipo de imagem será necessário. Veja abaixo um resumo
dos cenários e do tipo que você precisará escolher:
C EN Á RIO T IP O DE IM A GEM O P Ç Õ ES DE A RM A Z EN A M EN TO
Criar uma imagem que possa ser Generalizada Galeria de Imagens Compartilhadas ou
configurada para uso por várias VMs e imagens gerenciadas autônomas
eu possa definir o nome do host,
adicionar um usuário administrador e
executar outras tarefas durante a
primeira inicialização.
Criar uma imagem com base em um Especializada Galeria de Imagens Compartilhadas ou

instantâneo de VM ou um backup um disco gerenciado
Crie rapidamente uma imagem que Especializada Galeria de imagens compartilhadas

não precise de nenhuma configuração
para criar várias VMs
Imagens generalizada
Uma imagem generalizada é uma imagem que requer que a instalação seja concluída na primeira inicialização.
Por exemplo, na primeira inicialização, você define o nome do host, o usuário administrador e outras
configurações específicas da VM. Isso é útil quando você deseja que a imagem seja reutilizada várias vezes e
quando você deseja passar parâmetros durante a criação. Se a imagem generalizada contiver o agente do Azure,
o agente processará os parâmetros e informará à plataforma que a configuração inicial foi concluída. Esse
processo chama-se provisionamento.
O provisionamento requer que um provisionador esteja incluído na imagem. Há dois provisionadores:
Agente Linux do Azure
cloud-init
Estes são pré-requisitos para criar uma imagem.
Imagens especializadas
Essas são imagens que estão completamente configuradas e não exigem parâmetros especiais e de VM; a
plataforma só ativará a VM e você precisará que o identificador seja único dentro da VM, como definir um nome
de host, para evitar conflitos de DNS na mesma VNET.
No entanto, os agentes de provisionamento não são necessários para essas imagens, mas talvez seja
interessante ter funcionalidades de manipulação de extensão. É possível instalar o Agente do Linux, mas
desabilitar a opção de provisionamento. Embora você não precise de um agente de provisionamento, a imagem
deve atender aos pré-requisitos para Imagens do Azure.
Opções de armazenamento de imagens

Ao trazer sua imagem do Linux, você tem duas opções:
Imagens gerenciadas para criação de VM simples em um ambiente de desenvolvimento e teste.
Galeria de Imagens Compartilhadas para criar e compartilhar imagens em escala.
Imagens gerenciadas
As imagens gerenciadas podem ser usadas para criar várias VMs, mas elas têm muitas limitações. As imagens
gerenciadas só podem ser criadas com base em uma origem generalizada (VM ou VHD). Elas só podem ser
usadas para criar VMs na mesma região e não podem ser compartilhados entre assinaturas e locatários.
As imagens gerenciadas podem ser usadas para ambientes de desenvolvimento e teste, em que são necessárias
algumas imagens generalizadas simples para usar em uma região e assinatura.
SIG (Galeria de Imagens Compartilhadas) do Azure
As Galerias de Imagens Compartilhadas são recomendadas para criar, gerenciar e compartilhar imagens em
escala. A galeria de imagens compartilhadas ajuda você a criar a estrutura e a organização em torno das suas
imagens gerenciadas.
Suporte para imagens generalizadas e especializadas.
Suporte para imagens da geração 1 e 2.
Replicação global de imagens.
Agrupamento e controle de versão de imagens para facilitar o gerenciamento.
Imagens altamente disponíveis com ZRS (Armazenamento com Redundância de Zona) em regiões que dão
suporte a Zonas de Disponibilidade. O ZRS oferece maior resiliência contra falhas em zonas.
Compartilhamento entre assinaturas e até mesmo entre locatários do AD (Active Directory) usando o Azure
RBAC.
Dimensionamento das suas implantações com réplicas de imagem em cada região.
Em um alto nível, você cria um SIG e ele é composto por:
Definições de imagem – são contêineres que armazenam grupos de imagens.
Versões de imagem – essas são as imagens reais
Geração do Hyper-V
O Azure dá suporte ao Hyper-V geração 1 (Gen1) e à geração 2 (Gen2); o Gen2 é a última geração e oferece
funcionalidade adicional em relação ao Gen1. Por exemplo: maior memória, Intel SGX (Intel com Software Guard
Extensions) e vPMEM (memória persistente virtualizada). As VMs de geração 2 em execução no local têm alguns
recursos que ainda não têm suporte no Azure. Para obter mais informações, confira a seção Recursos e
funcionalidades. Para obter mais informações, veja este artigo. Crie imagens Gen2 se você precisar de
funcionalidade adicional.
Se você ainda precisar criar sua imagem, verifique se ela atende aos pré-requisitos de imagem e carregue no
Azure. Requisitos específicos de distribuição:
Distribuições com base em CentOS
Debian Linux
Oracle Linux
SLES e openSUSE
Ubuntu
Próximas etapas
Saiba como criar uma Galeria de Imagens Compartilhadas.
Provisionamento de VM do Linux do Azure
Quando você cria uma VM com base em uma imagem generalizada (Galeria de Imagens Compartilhadas ou
Imagem Gerenciada), o painel de controle permitirá que você crie uma VM e passe parâmetros e configurações
para a VM. Isso é chamado de provisionamento de VM. Durante o provisionamento, a plataforma disponibiliza
os valores de parâmetros de criação de VM necessários (nome de host, nome de usuário, senha, chaves SSH,
customData) para a VM enquanto ela é inicializada.
Um agente de provisionamento embutido dentro da imagem fará interface com a plataforma, conectando-se
com até várias interfaces de provisionamento independentes. Defina as propriedades e o sinal como a
plataforma que ele concluiu.
Os agentes de provisionamento podem ser o Agente Linux do Azure ou a inicialização de nuvem. Estes são pré-
requisitos da criação de imagens generalizadas.
Os agentes de provisionamento fornecem suporte para todas as distribuições Linux do Azure endossadas e
você descobrirá que as imagens de distribuição endossadas, em muitos casos, serão fornecidas com o cloud-init
e o Agente do Linux. Isso lhe dá a opção de ter o cloud-init para lidar com o provisionamento. Em seguida, o
Agente do Linux dará suporte para manipular as Extensões do Azure. O fornecimento de suporte para extensões
significa que a VM será qualificada para dar suporte a serviços adicionais do Azure, como Redefinição de Senha
de VM, Monitoramento do Azure, Backup do Azure, Criptografia de Disco do Azure etc.
Após a conclusão do provisionamento, o cloud-init será executado em cada inicialização. O cloud-init vai
monitorar se há alterações na VM, como alterações de rede, montagem e formatação do disco efêmero e
inicialização do Agente do Linux. O Agente do Linux é executado continuamente no servidor, buscando um
“estado de meta” (nova configuração) da plataforma do Azure, portanto, sempre que você instalar extensões, o
agente poderá processá.
Embora, no momento, haja dois agentes de provisionamento, o cloud-init deve ser o agente de
provisionamento escolhido e o Agente do Linux deve ser instalado para suporte de extensão. Com isso, é
possível aproveitar as otimizações de plataforma e desabilitar/remover o Agente do Linux. Para obter mais
detalhes sobre como criar imagens sem o agente e como removê-lo, leia esta documentação.
Se você tem um kernel do Linux que não dá suporte à execução de nenhum agente, mas deseja definir algumas
propriedades de criação da VM, como hostname, customData, userName, password, ssh keys, este documento
aborda como você pode criar imagens generalizadas sem um agente e atender aos requisitos da plataforma.
Responsabilidades do agente de provisionamento

Provisionamento de imagem
Criação de uma conta de usuário
Configurando os tipos de autenticação do SSH
Implantação de chaves públicas do SSH e pares de chaves
Configuração do nome de host
Publicando o nome do host para a plataforma de DNS
Relatório de impressão digital da chave host SSH para a plataforma
Gerenciamento de recursos de disco
Formatação e montagem do disco do recurso
Consumir e processar customData
Rede
Gerencia as rotas para melhorar a compatibilidade com os servidores DHCP de plataforma
Garante a estabilidade do nome da interface de rede
Kernel
Configura NUMA virtual (desabilitar para kernel < 2.6.37 )
Consome entropia de Hyper-V para /dev/random
Configura os tempos limite de SCSI para o dispositivo raiz (o qual poderia ser remoto)
Diagnóstico
Redirecionamento de console de porta serial
Comunicação
O fluxo de informações da plataforma para o agente ocorre por meio de dois canais:
Um DVD anexado ao tempo de inicialização para as implementações de IaaS. O DVD inclui um arquivo de
configuração em conformidade com OVF que inclui todas as informações de provisionamento que não
sejam os pares de chaves SSH real.
Um ponto de extremidade TCP que expõe uma API REST usada para obter a implantação e a configuração de
topologia.
Requisitos do agente de provisionamento do Azure

O Agente do Linux e o cloud-init dependem de alguns pacotes de sistema para funcionar corretamente:
Python 2.6+
OpenSSL 1.0+
OpenSSH 5.3+
Utilitários do sistema de arquivos: sfdisk , fdisk , mkfs , parted
Ferramentas de senha: chpasswd, sudo
Ferramentas de processamento de texto: sed, grep
Ferramentas de rede: roteamento ip
Suporte a kernel para montar sistemas de arquivos UDF.
Próximas etapas
Se precisar, você poderá desabilitar o provisionamento e remover o agente do Linux.
Informações para distribuições não endossadas
O SLA (contrato de nível de serviço) da plataforma do Azure aplica-se a máquinas virtuais com o sistema
operacional Linux somente quando uma das distribuições endossadas é usada com os detalhes da configuração
especificados neste artigo. Para essas distribuições endossadas, as imagens do Linux pré-configuradas são
fornecidas no Azure Marketplace.
Linux no Azure – distribuições endossadas
Suporte para imagens Linux no Microsoft Azure
Todas as distribuições em execução no Azure têm vários pré-requisitos. Este artigo pode não ser abrangente,
pois cada distribuição é diferente. Mesmo que você atenda a todos os critérios abaixo, talvez seja necessário
ajustar significativamente o sistema Linux para que funcione corretamente.
É recomendável iniciar com uma das distribuições endossadas do Linux no Azure. Os artigos a seguir mostram
como preparar as várias distribuições endossadas do Linux com suporte no Azure:
Debian Linux
Oracle Linux
SLES e openSUSE
Ubuntu
Este artigo concentra-se na orientação geral para executar a distribuição do Linux no Azure.
Notas de instalação gerais do Linux

O formato VHDX (disco rígido virtual para Hyper-V) não tem suporte no Azure, apenas VHD fixo. Você pode
converter o disco para o formato VHD usando o Gerenciador do Hyper-V ou o cmdlet Convert-VHD . Se você
estiver usando o VirtualBox, selecione Tamanho fixo em vez do padrão (alocado dinamicamente) ao criar o
disco.
O Azure dá suporte a máquinas virtuais Gen1 (inicialização do BIOS) & Gen2 (inicialização UEFI).
O tamanho máximo permitido para o VHD é 1.023 GB.
Ao instalar o sistema Linux, é recomendável usar partições padrão em vez do LVM (Gerenciador de Volume
Lógico), que é o padrão para muitas instalações. Usar partições padrão evitará conflitos de nome do LVM
com VMs clonadas, especialmente se um disco de SO já estiver conectado a outra VM idêntica para solução
de problemas. LVM ou RAID podem ser usados nos discos de dados.
O suporte do kernel para a montagem de sistemas de arquivos UDF é necessário. Na primeira inicialização
no Azure, a configuração de provisionamento é passada para a VM do Linux usando a mídia em formato
UDF anexada ao convidado. O agente Linux do Azure deve montar o sistema de arquivos UDF para ler a
configuração e provisionar a VM.
As versões do kernel do Linux anteriores à 2.6.37 não são suporte para NUMA no Hyper-V com tamanhos de
VM maiores. Esse problema afeta principalmente distribuições mais antigas usando o kernel do Red Hat
2.6.32, e foi corrigido no RHEL (Red Hat Enterprise Linux) 6.6 (kernel-2.6.32-504). Sistemas que executam
kernels personalizados anteriores a 2.6.37 ou com base em RHEL anteriores a 2.6.32-504 devem definir o
parâmetro de inicialização numa=off na linha de comando do kernel em grub.conf. Para obter mais
informações, consulte o KB 436883 do Red Hat.
Não configure uma partição de permuta no disco do sistema operacional. O agente do Linux pode ser
configurado para criar um arquivo de permuta no disco de recursos temporário, conforme descrito nas
etapas a seguir.
Todos os VHDs no Azure devem ter um tamanho virtual alinhado a 1 MB. Ao converter de um disco bruto
em VHD, será necessário garantir que o tamanho do disco bruto seja um múltiplo de 1 MB antes da
conversão, conforme descrito nas etapas a seguir.
Instalação dos módulos de kernel sem Hyper-V
O Azure é executado no Hipervisor Hyper-V, portanto, o Linux exige que determinados módulos do kernel sejam
executados no Azure. Se você tiver uma VM que foi criada fora do Hyper-V, os instaladores do Linux talvez não
incluam os drivers do Hyper-V no ramdisk inicial (initrd ou initramfs), exceto se a VM detectar que está em
execução em um ambiente Hyper-V. Ao usar um sistema de virtualização diferente (como VirtualBox, KVM e
assim por diante) para preparar a imagem do Linux, talvez seja necessário recompilar o initrd para que pelo
menos os módulos de kernel hv_vmbus e hv_storvsc estejam disponíveis no ramdisk inicial. Esse problema
conhecido é para sistemas com base na distribuição anterior do Red Hat e, possivelmente, em outros.
O mecanismo para recriar a imagem initrd ou initramfs pode variar dependendo da distribuição. Consulte a
documentação da distribuição ou suporte para o procedimento adequado. Aqui está um exemplo para
recompilar o initrd usando o utilitário mkinitrd :
1. Faça o backup da imagem initrd existente:
cd /boot
sudo cp initrd-ùname -r`.img initrd-ùname -r`.img.bak
2. Recompile o initrd com os módulos do kernel hv_vmbus e hv_storvsc:
sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-ùname -r`.img ùname -r`
Redimensionando VHDs
As imagens de VHD no Azure devem ter um tamanho virtual alinhado para 1MB. Normalmente, os VHDs criados
usando o Hyper-V estão alinhados corretamente. Se o VHD não estiver alinhado corretamente, você poderá
receber uma mensagem de erro semelhante à seguinte ao tentar criar uma imagem do VHD.
O VHD http: / / <mystorageaccount> . blob.Core.Windows.net/VHDs/MyLinuxVM.VHD tem um tamanho
virtual sem suporte de 21475270656 bytes. O tamanho deve ser um número inteiro (em MBs).
Nesse caso, redimensione a VM usando o console do Gerenciador Hyper-V ou o cmdlet do PowerShell Resize-
VHD. Se você não estiver executando em um ambiente Windows, é recomendável usar qemu-img para converter
(se necessário) e redimensionar o VHD.
NOTE
Há um bug conhecido em qemu-img versões >=2.2.1 que resulta em um VHD formatado incorretamente. O problema
foi corrigido na versão QEMU 2.6. É recomendável usar qemu-img 2.2.0 ou inferior, ou 2.6 ou superior.
1. Redimensionar o VHD diretamente, usando ferramentas como qemu-img ou vbox-manage pode resultar
em um VHD incapaz de ser inicializado. É recomendável primeiro converter o VHD em uma imagem de
disco RAW. Se a imagem da VM foi criada como uma imagem de disco RAW (o padrão para alguns
hipervisores como KVM), você poderá pular esta etapa.
qemu-img convert -f vpc -O raw MyLinuxVM.vhd MyLinuxVM.raw
2. Calcule o tamanho necessário da imagem de disco para que o tamanho virtual seja alinhado a 1 MB. O
script de shell bash a seguir usa qemu-img info para determinar o tamanho virtual da imagem do disco
e, em seguida, calcula o tamanho para o próximo 1 MB.
rawdisk="MyLinuxVM.raw"
vhddisk="MyLinuxVM.vhd"
MB=$((1024*1024))
size=$(qemu-img info -f raw --output json "$rawdisk" | \
gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')
rounded_size=$(((($size+$MB-1)/$MB)*$MB))
echo "Rounded Size = $rounded_size"
3. Redimensione o disco bruto usando $rounded_size como definido acima.
qemu-img resize MyLinuxVM.raw $rounded_size
4. Agora, converta o disco RAW novamente em um VHD de tamanho fixo.
qemu-img convert -f raw -o subformat=fixed -O vpc MyLinuxVM.raw MyLinuxVM.vhd
Ou, com a versão 2.6+ do qemu, inclua a opção force_size .
qemu-img convert -f raw -o subformat=fixed,force_size -O vpc MyLinuxVM.raw MyLinuxVM.vhd
Requisitos do kernel do Linux

Os drivers LIS (Serviços de Integração do Linux) para Hyper-V e Azure são obtidos diretamente no kernel
upstream do Linux. Muitas distribuições que incluem uma versão recente do kernel do Linux (como 3.x) já
possuem esses drivers disponíveis ou, caso contrário, fornecem versões portadas desses drivers com seus
kernels. Esses drivers são constantemente atualizados no kernel upstream com novas correções e recursos,
portanto, quando possível, é recomendável a execução de uma distribuição endossada que inclui essas
correções e atualizações.
Se você estiver executando uma variante do Red Hat Enterprise Linux versões 6.0 a 6.3, será necessário instalar
os últimos drivers LIS para Hyper-V. Começando com o RHEL 6.4+ (e derivados), os drivers LIS já estão
incluídos no kernel e, portanto, nenhum pacote de instalação adicional é necessário.
Se um kernel personalizado for necessário, é recomendável uma versão recente do kernel (como 3.8+). No caso
das distribuições ou dos fornecedores que mantêm seus próprios kernels, será necessário reverter os drivers
LIS do kernel upstream para seu kernel personalizado. Mesmo se você já estiver executando uma versão do
kernel relativamente recente, é recomendável controlar todas as correções upstream nos drivers LIS e fazer a
reversão conforme necessário. Os locais dos arquivos de origem do driver LIS são especificados no arquivo
MAINTAINERS na árvore de origem do kernel do Linux:
F: arch/x86/include/asm/mshyperv.h
F: arch/x86/include/uapi/asm/hyperv.h
F: arch/x86/kernel/cpu/mshyperv.c
F: drivers/hid/hid-hyperv.c
F: drivers/hv/
F: drivers/input/serio/hyperv-keyboard.c
F: drivers/net/hyperv/
F: drivers/scsi/storvsc_drv.c
F: drivers/video/fbdev/hyperv_fb.c
F: include/linux/hyperv.h
F: tools/hv/
Os seguintes patches devem ser incluídos no kernel. Esta lista não pode ser completa para todas as
distribuições.
ata_piix: adie os discos para os drivers Hyper-V por padrão
storvsc: conta para pacotes em trânsito no caminho RESET
storvsc: evite o uso de WRITE_SAME
storvsc: desabilite WRITE SAME para RAID e drivers do adaptador de host virtual
storvsc: correção de desreferência de ponteiro NULL
storvsc: as falhas do buffer de anéis podem resultar em congelamento de E/S
scsi_sysfs: proteger contra a execução dupla de __scsi_remove_device
O agente Linux do Azure

O agente Linux do Azure waagent provisiona uma máquina virtual do Linux no Azure. Você pode obter a última
versão, verificar os problemas com arquivos ou enviar solicitações de pull no repositório GitHub do agente
Linux.
O agente Linux consta na licença do Apache 2.0. Muitas distribuições já fornecem pacotes RPM ou. deb para
o agente, e esses pacotes podem ser facilmente instalados e atualizados.
O agente Linux do Azure requer Python v2.6+.
Além disso, o agente requer o módulo python-pyasn1. A maioria das distribuições fornece esse módulo
como um pacote separado a ser instalado.
Em alguns casos, é possível que o agente Linux do Azure não seja compatível com o NetworkManager.
Muitos dos pacotes RPM/DEB fornecidos pelas distribuições configuram NetworkManager como um conflito
para o pacote waagent. Nesses casos, ele irá desinstalar o NetworkManager quando você instalar o pacote
do agente Linux.
O agente Linux do Azure deve estar na ou acima da versão mínima com suporte.
Requisitos gerais do sistema Linux

1. Modifique a linha de inicialização do kernel no GRUB ou no GRUB2 para incluir os seguintes parâmetros,
de modo que todas as mensagens do console sejam enviadas para a primeira porta serial. Essas
mensagens podem ajudar o suporte do Azure a depurar quaisquer problemas.
console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300
Além disso, é recomendável remover os seguintes parâmetros, se existirem.
rhgb quiet crashkernel=auto
Inicialização gráfica e silenciosa não é útil em um ambiente de nuvem, onde queremos que todos os logs
sejam enviados para a porta serial. A opção crashkernel pode ser deixada configurada, se necessário,
mas observe que esse parâmetro reduz a quantidade de memória disponível na VM em pelo menos 128
MB, o que pode ser problemático para tamanhos de VM menores.
2. Instale o Agente Linux do Azure.
O agente Linux do Azure é necessário para garantir o provisionamento de uma imagem Linux no Azure.
Muitas distribuições fornecem o agente como um pacote RPM ou. deb (o pacote é normalmente
chamado de WALinuxAgent ou WALinuxAgent). Você também pode seguir as etapas descritas no Guia do
agente Linuxpara instalar o agente manualmente.
3. Certifique-se de que o servidor SSH está instalado e configurado para iniciar no tempo de inicialização.
Essa configuração geralmente é a padrão.
4. Não crie espaço de troca no disco do sistema operacional.
O Agente Linux do Azure pode configurar automaticamente o espaço de permuta usando o disco de
recurso local que é anexado à VM após o provisionamento no Azure. O disco de recurso local é um disco
temporário e pode ser esvaziado quando a VM é desprovisionada. Depois de instalar o Agente Linux do
Azure (etapa 2 acima), modifique os seguintes parâmetros em /etc/waagent.conf conforme necessário.
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=2048 ## NOTE: Set this to your desired size.
5. Execute os seguintes comandos para desprovisionar a máquina virtual.
sudo waagent -force -deprovision

export HISTSIZE=0
logout
NOTE
No Virtualbox você pode ver o seguinte erro após executar waagent -force -deprovision que informa
[Errno 5] Input/output error . Essa mensagem de erro não é crítica e pode ser ignorada.
Desligar a máquina virtual e carregar o VHD no Azure.

Preparar uma máquina virtual baseada em CentOS
para o Azure
Saiba como criar e carregar um VHD (disco rígido virtual) do Azure que contenha um sistema operacional Linux
baseado em CentOS.
Preparar uma máquina virtual CentOS 6.x para o Azure
Preparar uma máquina virtual CentOS 7.0 ou posterior para o Azure
Pré-requisitos
Este artigo pressupõe que você já instalou um sistema operacional Linux CentOS (ou derivado similar) em um
disco rígido virtual. Existem várias ferramentas para criar arquivos .vhd, por exemplo, uma solução de
virtualização como o Hyper-V. Para obter instruções, consulte Instalar a função Hyper-V e configurar uma
máquina Virtual.
Notas de instalação do CentOS
Veja também as Notas de instalação gerais do Linux para obter mais dicas sobre como preparar o Linux para
o Azure.
O formato VHDX não tem suporte no Azure, somente o VHD fixo . Você pode converter o disco em formato
VHD usando o Gerenciador do Hyper-V ou o cmdlet convert-vhd. Se você estiver usando o VirtualBox, isso
significará selecionar Tamanho fixo em vez do padrão alocado dinamicamente durante a criação do disco.
Ao instalar o sistema Linux, é recomendável que você use partições padrão em vez de LVM (geralmente o
padrão para muitas instalações). Isso irá evitar conflitos de nome LVM com VMs clonadas, especialmente se
um disco do sistema operacional precisar ser anexado a outra VM idêntica para solução de problemas. LVM
ou RAID podem ser usados nos discos de dados.
É necessário supor te a kernel para montar sistemas de arquivos UDF. Na primeira inicialização no
Azure, a configuração de provisionamento é transmitida à VM do Linux por meio de mídia formatada para
UDF, a qual é anexada ao convidado. O agente de Linux do Azure deve ser capaz de montar o sistema de
arquivos UDF para ler sua configuração e provisionar a VM.
Versões de kernel do Linux abaixo de 2.6.37 não dão suporte ao NUMA no Hyper-V com tamanhos maiores
de VM. Esse problema afeta principalmente distribuições mais antigas usando kernel Red Hat 2.6.32
upstream e foi corrigido no RHEL 6.6 (kernel-2.6.32-504). Sistemas que executam kernels personalizados
anteriores a 2.6.37 ou com base em RHEL anteriores a 2.6.32-504 devem definir o parâmetro de inicialização
numa=off na linha de comando do kernel em grub.conf. Para obter mais informações, consulte Red Hat KB
436883.
Não configure uma partição de permuta no disco do SO. Verifique as etapas a seguir para obter mais
informações a esse respeito.
Todos os VHDs no Azure devem ter um tamanho virtual alinhado a 1 MB. Ao converter de um disco não
processado para VHD, certifique-se de que o tamanho do disco não processado seja um múltiplo de 1 MB
antes da conversão. Consulte Notas de Instalação do Linux para obter mais informações.
CentOS 6.x
1. No Gerenciador do Hyper-V, selecione a máquina virtual.
2. Clique em Conectar para abrir a janela do console para a máquina virtual.
3. No CentOS 6, NetworkManager pode interferir com o agente Linux do Azure. Desinstale este pacote ao
executar o seguinte comando:
sudo rpm -e --nodeps NetworkManager
4. Crie ou edite o arquivo /etc/sysconfig/network e adicione o texto a seguir:
NETWORKING=yes
HOSTNAME=localhost.localdomain
5. Crie ou edite o arquivo /etc/sysconfig/network-scripts/ifcfg-eth0 e adicione o texto a seguir:
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
6. Modifique as regras de udev para evitar a geração de regras estáticas das interfaces Ethernet. Essas
regras podem provocar problemas ao clonar uma máquina virtual no Microsoft Azure ou no Hyper-V:
sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules

sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
7. Certifique-se de que o serviço de rede será iniciado na inicialização executando o seguinte comando:
sudo chkconfig network on
8. Se quiser usar os espelhos OpenLogic hospedados em datacenters do Azure, substitua o arquivo

/etc/yum.repos.d/CentOS-Base.repo pelos repositórios a seguir. Isso também adicionará o repositório
[openlogic] , que inclui pacotes adicionais como o agente Linux do Azure:
[openlogic]
name=CentOS-$releasever - openlogic packages for $basearch
baseurl=http://olcentgbl.trafficmanager.net/openlogic/$releasever/openlogic/$basearch/
enabled=1
gpgcheck=0
[base]
name=CentOS-$releasever - Base
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
#released updates
[updates]
name=CentOS-$releasever - Updates
#mirrorlist=http://mirrorlist.centos.org/?
release=$releasever&arch=$basearch&repo=updates&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/updates/$basearch/
gpgcheck=1
#additional packages that may be useful

[extras]
name=CentOS-$releasever - Extras
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/extras/$basearch/
gpgcheck=1
#additional packages that extend functionality of existing packages

[centosplus]
name=CentOS-$releasever - Plus
release=$releasever&arch=$basearch&repo=centosplus&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
#contrib - packages by Centos Users

[contrib]
name=CentOS-$releasever - Contrib
release=$releasever&arch=$basearch&repo=contrib&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/contrib/$basearch/
gpgcheck=1
enabled=0
NOTE
O restante deste guia parte do pressuposto de que você esteja usando, no mínimo, o repositório [openlogic] ,
que será usado para instalar o agente Linux do Azure abaixo.
9. Adicione a seguinte linha a /etc/yum.conf:
http_caching=packages
10. Execute o seguinte comando para limpar os metadados atuais do yum e atualizar o sistema com os
pacotes mais recentes:
yum clean all
A menos que você esteja criando uma imagem para uma versão anterior do CentOS, é recomendável
atualizar todos os pacotes para a versão mais recente:
sudo yum -y update
Pode ser necessária uma reinicialização depois de executar esse comando.

11. (Opcional) Instale os drivers dos LIS (Serviços de Integração do Linux).
IMPORTANT
A etapa é necessária para CentOS 6.3 e anteriores e opcionais para versões posteriores.
sudo rpm -e hypervkvpd ## (may return error if not installed, that's OK)
sudo yum install microsoft-hyper-v
Como alternativa, você pode seguir as instruções de instalação manual página de download do LIS para
instalar o RPM para sua VM.
12. Instale o agente Linux do Azure e as dependências. Iniciar e habilitar o serviço waagent:
sudo yum install python-pyasn1 WALinuxAgent

sudo service waagent start
sudo chkconfig waagent on
A instalação do pacote WALinuxAgent removerá o NetworkManager e os pacotes NetworkManager-

gnome se eles já não tiverem sido removidos conforme descrito na etapa 3.
13. Modifique a linha de inicialização do kernel em sua configuração de grub para incluir parâmetros
adicionais de kernel para o Azure. Para fazer isso, abra /boot/grub/menu.lst em um editor de texto e
verifique se o kernel padrão inclui os seguintes parâmetros:
console=ttyS0 earlyprintk=ttyS0 rootdelay=300
Isso também garantirá que todas as mensagens do console sejam enviadas para a primeira porta serial,
que pode auxiliar o suporte do Azure com problemas de depuração.
Além disso, recomendamos que você remova os seguintes parâmetros:
As inicializações gráfica e silenciosa não são úteis em ambientes de rede, quando queremos que todos os
logs sejam enviados para a porta serial. Você pode deixar configurada a opção crashkernel , mas esse
parâmetro reduz a memória disponível na máquina virtual em 128 MB ou mais, o que pode ser um
problema em máquinas virtuais menores.
IMPORTANT
CentOS 6.5 e anteriores também devem definir o parâmetro de kernel numa=off . Consulte Red Hat KB 436883.
14. Confira se o servidor SSH está instalado e configurado para iniciar no tempo de inicialização. Geralmente,
esse é o padrão.
15. Não crie espaço de permuta no disco do SO.
recurso local que é anexado à VM após o provisionamento no Azure. Observe que o disco de recurso
local é um disco temporário e pode ser esvaziado quando a VM é desprovisionada. Depois de instalar o
Agente Linux do Azure (confira a etapa anterior), modifique adequadamente os seguintes parâmetros em
/etc/waagent.conf :
ResourceDisk.SwapSizeMB=2048 ## NOTE: set this to whatever you need it to be.
16. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
no Azure:
sudo waagent -force -deprovision+user

export HISTSIZE=0
logout
17. Clique em Ação -> Desligar no Gerenciador do Hyper-V. Agora, seu VHD Linux está pronto para ser
carregado no Azure.
CentOS 7.0+
Alterações no CentOS 7 (e em derivativos similares)
A preparação de uma máquina virtual CentOS 7 para o Azure é muito parecida com a preparação das máquinas
virtuais CentOS 6, mas há diversas diferenças que merecem atenção:
O pacote do NetworkManager não entra mais em conflito com o agente Linux do Azure. Esse pacote é
instalado por padrão e recomendamos que você não o remova.
O GRUB2 agora é usado como carregador de inicialização padrão. Com isso, o procedimento de edição de
parâmetros do kernel mudou (confira abaixo).
O XFS agora é o sistema de arquivos padrão. Ainda é possível usar o sistema de arquivos ext4 se você
preferir.
Etapas de configuração
NETWORKING=yes
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=no
sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules
6. Se quiser usar os espelhos OpenLogic hospedados em datacenters do Azure, substitua o arquivo

/etc/yum.repos.d/CentOS-Base.repo pelos repositórios a seguir. Essa ação adiciona o repositório
[openlogic] que inclui pacotes para o agente Linux do Azure:
[openlogic]
name=CentOS-$releasever - openlogic packages for $basearch
baseurl=http://olcentgbl.trafficmanager.net/openlogic/$releasever/openlogic/$basearch/
enabled=1
gpgcheck=0
[base]
name=CentOS-$releasever - Base
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/os/$basearch/
gpgcheck=1
#released updates
[updates]
name=CentOS-$releasever - Updates
release=$releasever&arch=$basearch&repo=updates&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/updates/$basearch/
gpgcheck=1
#additional packages that may be useful

[extras]
name=CentOS-$releasever - Extras
#mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/extras/$basearch/
gpgcheck=1
#additional packages that extend functionality of existing packages

[centosplus]
name=CentOS-$releasever - Plus
release=$releasever&arch=$basearch&repo=centosplus&infra=$infra
baseurl=http://olcentgbl.trafficmanager.net/centos/$releasever/centosplus/$basearch/
gpgcheck=1
enabled=0
NOTE
O restante deste guia parte do pressuposto de que você esteja usando, no mínimo, o repositório [openlogic] ,
que será usado para instalar o agente Linux do Azure abaixo.
7. Execute o comando a seguir para limpar os metadados atuais do yum e instalar atualizações:
sudo yum clean all
A menos que você esteja criando uma imagem para uma versão anterior do CentOS, é recomendável
atualizar todos os pacotes para a versão mais recente:
sudo yum -y update
Uma reinicialização necessária talvez depois de executar esse comando.

adicionais de kernel para o Azure. Para fazer isso, abra /etc/default/grub em um editor de texto e edite o
parâmetro GRUB_CMDLINE_LINUX , por exemplo:
GRUB_CMDLINE_LINUX="rootdelay=300 console=ttyS0 earlyprintk=ttyS0 net.ifnames=0"
que pode auxiliar o suporte do Azure com problemas de depuração. Ele também desativa novas
convenções de nomenclatura do CentOS 7 para NICs. Além disso, recomendamos que você remova os
seguintes parâmetros:
logs sejam enviados para a porta serial. Você pode deixar configurada a opção crashkernel , mas esse
parâmetro reduz a memória disponível na máquina virtual em 128 MB ou mais, o que pode ser um
problema em máquinas virtuais menores.
9. Depois de editar /etc/default/grub como mostrado acima, execute o comando a seguir para recompilar
a configuração do grub:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
10. Se estiver criando a imagem do VMware, Vir tualBox ou KVM: Verifique se os drivers do Hyper-V estão
incluídos no initramfs:
Edite /etc/dracut.conf e adicione o conteúdo:
add_drivers+=" hv_vmbus hv_netvsc hv_storvsc "
Recompile o initramfs:
sudo dracut -f -v
11. Instale o agente Linux do Azure e as dependências para extensões de VM do Azure:
sudo yum install python-pyasn1 WALinuxAgent

sudo systemctl enable waagent
12. Instalar Cloud-init para lidar com o provisionamento

yum install -y cloud-init cloud-utils-growpart gdisk hyperv-daemons
# Configure waagent for cloud-init

sed -i 's/Provisioning.UseCloudInit=n/Provisioning.UseCloudInit=y/g' /etc/waagent.conf
sed -i 's/Provisioning.Enabled=y/Provisioning.Enabled=n/g' /etc/waagent.conf
echo "Adding mounts and disk_setup to init stage"

sed -i '/ - mounts/d' /etc/cloud/cloud.cfg
sed -i '/ - disk_setup/d' /etc/cloud/cloud.cfg
sed -i '/cloud_init_modules/a\\ - mounts' /etc/cloud/cloud.cfg
sed -i '/cloud_init_modules/a\\ - disk_setup' /etc/cloud/cloud.cfg
echo "Allow only Azure datasource, disable fetching network setting via IMDS"
cat > /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg <<EOF
datasource_list: [ Azure ]
datasource:
Azure:
apply_network_config: False
EOF
if [[ -f /mnt/resource/swapfile ]]; then

echo Removing swapfile - RHEL uses a swapfile by default
swapoff /mnt/resource/swapfile
rm /mnt/resource/swapfile -f
fi
echo "Add console log file"

cat >> /etc/cloud/cloud.cfg.d/05_logging.cfg <<EOF
# This tells cloud-init to redirect its stdout and stderr to

# 'tee -a /var/log/cloud-init-output.log' so the user can see output
# there without needing to look on the console.
output: {all: '| tee -a /var/log/cloud-init-output.log'}
EOF
13. A configuração de permuta não cria o espaço de permuta no disco do sistema operacional.
Anteriormente, o agente Linux do Azure foi usado para configurar automaticamente o espaço de permuta
usando o disco de recurso local que está anexado à máquina virtual depois que a máquina virtual é
provisionada no Azure. No entanto, isso agora é manipulado por Cloud-init, você não deve usar o
agente do Linux para formatar o disco de recursos criar o arquivo de permuta, modificar os seguintes
parâmetros de forma /etc/waagent.conf apropriada:
sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf

sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf
Se você quiser montar, Formatar e criar a permuta, poderá:

Passe isso como uma configuração de Cloud-init toda vez que criar uma VM
Use uma diretiva Cloud-init inclusas na imagem que fará isso toda vez que a VM for criada:
cat > /etc/cloud/cloud.cfg.d/00-azure-swap.cfg << EOF
#cloud-config
# Generated by Azure cloud image build
disk_setup:
ephemeral0:
table_type: mbr
layout: [66, [33, 82]]
overwrite: True
fs_setup:
- device: ephemeral0.1
filesystem: ext4
filesystem: swap
mounts:
- ["ephemeral0.1", "/mnt"]
- ["ephemeral0.2", "none", "swap", "sw", "0", "0"]
EOF
no Azure:
# Note: if you are migrating a specific virtual machine and do not wish to create a generalized
image,
# skip the deprovision step
# sudo rm -rf /var/lib/waagent/
# sudo rm -f /var/log/waagent.log
# waagent -force -deprovision+user

# rm -f ~/.bash_history
# export HISTSIZE=0
# logout
carregado no Azure.
Próximas etapas
Agora, você está pronto para usar o disco rígido virtual CentOS Linux para criar novas máquinas virtuais no
Azure. Se esta é a primeira vez que você está carregando o arquivo .vhd para o Azure, consulte Criar uma VM do
Linux a partir de um disco personalizado.
Preparar um VHD do Debian para o Azure
Pré-requisitos
Esta seção pressupõe que você já instalou um sistema operacional Linux Debian a partir de um arquivo .iso
baixado do site do Debian para um disco rígido virtual. Existem várias ferramentas para criar arquivos .vhd;
Hyper-V é apenas um exemplo. Para obter instruções sobre como usar a Hyper-V, consulte Instalar a função
Hyper-V e configurar uma máquina Virtual.
Notas de instalação
Veja também as Notas de Instalação Geral do Linux para obter mais dicas sobre como preparar o Linux para
o Azure.
Não há suporte para o formato VHDX mais recente no Azure. Você pode converter o disco para o formato
VHD usando o Gerenciador do Hyper-V ou o cmdlet Conver t-VHD .
um disco do sistema operacional precisar ser anexado a outra VM para solução de problemas. Se você
preferir, é possível usar LVM ou RAID em discos de dados.
Não configure uma partição de permuta no disco do SO. O agente Linux do Azure pode ser configurado para
criar um arquivo de permuta no disco de recursos temporários. Verifique as etapas a seguir para obter mais
informações.
antes da conversão. Para obter mais informações, consulte Notas de Instalação do Linux.
Usar o gerenciamento do Azure para criar VHDs Debian

Há ferramentas disponíveis para gerar VHDs de Debian para o Azure, como os scripts do Azure-Manage de
credativ. Essa é a abordagem recomendada em vez de criar uma imagem do zero. Por exemplo, para criar um
VHD no Debian 8, execute os seguintes comandos para baixar o azure-manage utilitário (e dependências) e
executar o azure_build_image script:
# sudo apt-get update

# sudo apt-get install git qemu-utils mbr kpartx debootstrap
# sudo apt-get install python3-pip python3-dateutil python3-cryptography

# sudo pip3 install azure-storage azure-servicemanagement-legacy azure-common pytest pyyaml
# git clone https://github.com/credativ/azure-manage.git
# cd azure-manage
# sudo pip3 install .
# sudo azure_build_image --option release=jessie --option image_size_gb=30 --option image_prefix=debian-

jessie-azure section
Preparar manualmente um VHD do Debian

3. Se você instalou o sistema operacional usando um arquivo ISO, em seguida, comente qualquer linha
relacionada a " deb cdrom " no /etc/apt/source.list .
4. Edite o arquivo /etc/default/grub e modifique o parâmetro GRUB_CMDLINE_LINUX da seguinte
maneira para incluir parâmetros adicionais de kernel para o Azure.
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 earlyprintk=ttyS0,115200"
5. Recompile o grub e execute:
# sudo update-grub
6. Adicione repositórios do Azure de Debian ao/etc/apt/sources.List para o Debian 8, 9 ou 10:

Debian 8.x "Jessie"
deb http://debian-archive.trafficmanager.net/debian jessie main

deb-src http://debian-archive.trafficmanager.net/debian jessie main
deb http://debian-archive.trafficmanager.net/debian-security jessie/updates main
deb-src http://debian-archive.trafficmanager.net/debian-security jessie/updates
deb http://debian-archive.trafficmanager.net/debian jessie-updates main
deb-src http://debian-archive.trafficmanager.net/debian jessie-updates main
deb http://debian-archive.trafficmanager.net/debian jessie-backports main
deb-src http://debian-archive.trafficmanager.net/debian jessie-backports main
Debian 9 "Stretch"
deb http://debian-archive.trafficmanager.net/debian stretch main

deb-src http://debian-archive.trafficmanager.net/debian stretch main
deb http://debian-archive.trafficmanager.net/debian-security stretch/updates main
deb-src http://debian-archive.trafficmanager.net/debian-security stretch/updates main
deb http://debian-archive.trafficmanager.net/debian stretch-updates main
deb-src http://debian-archive.trafficmanager.net/debian stretch-updates main
deb http://debian-archive.trafficmanager.net/debian stretch-backports main
deb-src http://debian-archive.trafficmanager.net/debian stretch-backports main
Debian 10. x "Buster"
deb http://debian-archive.trafficmanager.net/debian buster main

deb-src http://debian-archive.trafficmanager.net/debian buster main
deb http://debian-archive.trafficmanager.net/debian-security buster/updates main
deb-src http://debian-archive.trafficmanager.net/debian-security buster/updates main
deb http://debian-archive.trafficmanager.net/debian buster-updates main
deb-src http://debian-archive.trafficmanager.net/debian buster-updates main
deb http://debian-archive.trafficmanager.net/debian buster-backports main
deb-src http://debian-archive.trafficmanager.net/debian buster-backports main
7. Instale o Agente Linux do Azure:

# sudo apt-get install waagent
8. Para Debian 9 +, é recomendável usar o novo kernel do Debian Cloud para uso com as VMs no Azure.
Para instalar esse novo kernel, primeiro crie um arquivo chamado /etc/apt/preferences.d/linux.pref com o
conteúdo a seguir:
Package: linux-* initramfs-tools
Pin: release n=stretch-backports
Pin-Priority: 500
Em seguida, execute "sudo apt-get install linux-image-cloud-amd64" para instalar o novo kernel Debian
Cloud.
9. Desprovisione a máquina virtual, prepare-a para provisionamento no Azure e execute:
# sudo waagent –force -deprovision

# export HISTSIZE=0
# logout
10. Clique em ação -> desligar no Gerenciador do Hyper-V. Agora, seu VHD Linux está pronto para ser
carregado no Azure.
Próximas etapas
Agora, você está pronto para usar o disco rígido virtual Debian para criar novas máquinas virtuais no Azure. Se
esta é a primeira vez que você está carregando o arquivo .vhd para o Azure, consulte Criar uma VM do Linux a
partir de um disco personalizado.
Usando uma imagem flatcar predefinida para o
Azure
Você pode baixar imagens de disco rígido virtual do Azure predefinidas do contêiner do flatcar Linux para cada
um dos canais com suporte do flatcar:
estável
Beta
alpha
perímetro
Esta imagem já está totalmente configurada e otimizada para ser executada no Azure. Você só precisa
descompactá-lo.
Criando sua própria máquina virtual baseada em flatcar para o Azure

Como alternativa, você pode optar por criar sua própria imagem do Linux de contêiner flatcar.
Em qualquer computador baseado em Linux, siga as instruções detalhadas no Guia do SDK para
desenvolvedores do Linux do contêiner flatcar. Ao executar o image_to_vm.sh script, certifique-se de que você
passou --format=azure para criar um disco rígido virtual do Azure.
Próximas etapas
Quando você tiver o arquivo. VHD, poderá usar o arquivo resultante para criar novas máquinas virtuais no
Azure. Se esta for a primeira vez que você está carregando um arquivo. vhd no Azure, consulte criar uma VM do
Introdução ao FreeBSD no Azure
Este artigo fornece uma visão geral da execução de uma máquina virtual FreeBSD no Azure.
Visão geral
O FreeBSD para Microsoft Azure é um sistema operacional avançado usado para capacitar servidores
modernos, desktops e plataformas incorporadas.
A Microsoft Corporation está disponibilizando imagens do FreeBSD no Azure com o Agente convidado da VM
Azure pré-configurado. No momento, as seguintes versões do FreeBSD são oferecidas como imagens pela
Microsoft:
FreeBSD 10.4 no Azure Marketplace
O agente é responsável pela comunicação entre a VM do FreeBSD e a malha do Azure para operações como
provisionamento da VM no primeiro uso (nome de usuário, senha, chave SSH, nome do host, etc.) e habilitação
da funcionalidade para extensões de VM seletivas.
Para versões futuras do FreeBSD, a estratégia é manter-se atualizado e disponibilizar as versões mais recentes
logo após a publicação pela equipe de engenharia de versão do FreeBSD.
Criar uma VM do FreeBSD por meio da CLI do Azure no FreeBSD
Primeiro, você precisa instalar a CLI do Azure seguindo os comandos em um computador FreeBSD.
curl -L https://aka.ms/InstallAzureCli | bash
Se o bash não estiver instalado no seu computador FreeBSD, execute o comando a seguir antes da instalação.
sudo pkg install bash
Se o Python não estiver instalado no seu computador FreeBSD, execute o comando a seguir antes da instalação.
sudo pkg install python35

cd /usr/local/bin
sudo rm /usr/local/bin/python
sudo ln -s /usr/local/bin/python3.5 /usr/local/bin/python
Durante a instalação, Modify profile to update your $PATH and enable shell/tab completion now? (Y/n) será
solicitado. Se responder y e inserir /etc/rc.conf como a path to an rc file to update , você poderá
encontrar o problema ERROR: [Errno 13] Permission denied . Para resolvê-lo, você deve conceder o direito de
gravação ao usuário atual sobre o arquivo etc/rc.conf .
Agora você pode entrar no Azure e criar sua VM do FreeBSD. Abaixo está um exemplo de como criar uma VM
do FreeBSD 11.0. Você também pode adicionar o parâmetro --public-ip-address-dns-name com um nome DNS
exclusivo para um IP público recém-criado.
az login
az vm create --name myFreeBSD11 \
--image MicrosoftOSTC:FreeBSD:11.0:latest \
--generate-ssh-keys
Em seguida, é possível entrar na VM do FreeBSD pelo endereço IP impresso na saída acima da implantação.
ssh azureuser@xx.xx.xx.xx -i /etc/ssh/ssh_host_rsa_key
Extensões de VM para FreeBSD

Os itens a seguir têm suporte de extensões de VM no FreeBSD.
VMAccess
A extensão VMAccess pode:
Redefinir a senha do usuário sudo original.
Criar um novo usuário sudo com a senha especificada.
Definir a chave pública do host com a chave fornecida.
Redefinir a chave pública do host fornecida durante o provisionamento da VM se a chave do host não for
fornecida.
Abrir a porta (22) SSH e restaurar o sshd_config se reset_ssh estiver definido como true.
Remover o usuário existente.
Verificar os discos.
Reparar o disco adicionado.
CustomScript
A extensão CustomScript pode:
Se for fornecida, baixar os scripts personalizados do Armazenamento do Azure ou do armazenamento
público externo (por exemplo, GitHub).
Executar o script de ponto de entrada.
Oferecer suporte ao comando embutido.
Converter automaticamente o estilo newline do Windows em scripts de Shell e Python.
Remover automaticamente BOM em scripts de Shell e Python.
Proteger dados confidenciais em CommandToExecute.
NOTE
A VM do FreeBSD só oferece suporte ao CustomScript versão 1. x até o momento.
Autenticação: nomes de usuário, senhas e chaves SSH

Ao criar uma máquina virtual FreeBSD usando o Portal do Azure, você deve fornecer um nome de usuário, uma
senha ou uma chave pública SSH. Os nomes de usuário para implantação de uma máquina virtual do FreeBSD
no Azure não devem corresponder aos nomes de contas do sistema (UID <100) já presentes na máquina virtual
(“root”, por exemplo). Atualmente, há suporte apenas para a chave RSA SSH. Uma chave SSH multilinha deve
começar com ---- BEGIN SSH2 PUBLIC KEY ---- e terminar com ---- END SSH2 PUBLIC KEY ---- .
Obtendo privilégios de superusuário
A conta de usuário especificada durante a implantação da instância de máquina virtual no Azure é uma conta
privilegiada. O pacote do sudo foi instalado na imagem de FreeBSD publicada. Depois de fazer logon usando
essa conta de usuário, você poderá executar comandos como raiz usando a sintaxe de comando.
$ sudo <COMMAND>
Opcionalmente, é possível obter um shell root usando sudo -s .
Problemas conhecidos
O Agente convidado de VM do Azure versão 2.2.2 tem um problema conhecido que causa a falha de
provisionamento da VM do FreeBSD no Azure. A correção foi capturada pelo Agente Convidado da VM do Azure
versão 2.2.3 e versões posteriores.
Próximas etapas
Acesse o Azure Marketplace para criar uma VM FreeBSD.
Como usar o Filtro de Pacote do FreeBSD para criar
um firewall seguro no Azure
Este artigo apresenta como implantar um firewall NAT usando o Filtro de Pacote do FreeBSD por meio do
modelo do Azure Resource Manager para um cenário comum de servidor Web.
O que é o PF?
PF (Filtro de Pacote, também grafado pf) é um filtro de pacote com estado licenciado BSD, uma parte central do
software de firewall. Desde então, o PF evoluiu rapidamente e agora apresenta várias vantagens sobre outros
firewalls disponíveis. O NAT (Conversão de Endereços de Rede) está no PF desde o primeiro dia. Em seguida, o
agendador de pacotes e o gerenciamento de filas ativas foram integrados ao PF, integrando o ALTQ e tornando-
o configurável por meio da configuração do PF. Recursos como pfsync e CARP para failover e redundância,
authpf para autenticação de sessão e ftp-proxy para facilitar o firewall do difícil protocolo FTP, também
estenderam o PF. Em resumo, o PF é um firewall avançado e repleto de recursos.
Introdução
Se estiver interessado em configurar um firewall seguro na nuvem para seus servidores Web, é hora de
começar. Você também pode aplicar os scripts usados nesse modelo do Azure Resource Manager para
configurar a topologia de rede. O modelo do Azure Resource Manager configura uma máquina virtual FreeBSD
que executa o NAT/redirecionamento usando o PF e duas máquinas virtuais FreeBSD com o servidor Web
Nginx instalado e configurado. Além de executar o NAT para o tráfego de saída dos dois servidores Web, a
máquina virtual do NAT/redirecionamento intercepta as solicitações HTTP e as redireciona para os dois
servidores Web no estilo round robin. A VNet usa o intervalo de endereços IP privado 10.0.0.2/24 não roteável
e é possível modificar os parâmetros do modelo. O modelo do Azure Resource Manager também define uma
tabela de rotas para toda a VNet, que é uma coleção de rotas individuais usadas para substituir as rotas padrão
do Azure de acordo com o endereço IP de destino.
Implantar por meio da CLI do Azure

Você precisa da Azure CLI mais recente instalada e conectada a uma conta do Azure usando az login. Crie um
grupo de recursos com az group create. O exemplo a seguir cria um grupo de recursos chamado
myResourceGroup na localização West US .
az group create --name myResourceGroup --location westus
Em seguida, implante o modelo PF-FreeBSD-setup com AZ Deployment Group Create. Baixe

azuredeploy.parameters.json no mesmo caminho e defina seus próprios valores de recursos, como
adminPassword , networkPrefix e domainNamePrefix .
az deployment group create --resource-group myResourceGroup --name myDeploymentName \

--template-uri https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/pf-freebsd-
setup/azuredeploy.json \
--parameters '@azuredeploy.parameters.json' --verbose
Após cerca de cinco minutos, você deverá obter as informações de "provisioningState": "Succeeded" . Em
seguida, é possível executar SSH para a VM de front-end (NAT) ou acessar o servidor Web Nginx em um
navegador usando o endereço IP público ou o FQDN da VM de front-end (NAT). O exemplo a seguir lista o
FQDN e o endereço IP público atribuído à VM de front-end (NAT) no grupo de recursos myResourceGroup .
az network public-ip list --resource-group myResourceGroup
Próximas etapas
Você deseja configurar seu próprio NAT no Azure? Software Livre: gratuito mas eficiente? Portanto, o PF é uma
boa opção. Ao usar o modelo pf-freebsd-setup, você só precisa de cinco minutos para configurar um firewall
NAT com o balanceamento de carga round robin empregando o PF do FreeBSD no Azure para um cenário
comum de servidor Web.
Se desejar saber mais sobre a oferta do FreeBSD no Azure, consulte Introdução ao FreeBSD no Azure.
Se desejar saber mais sobre o PF, consulte Manual do FreeBSD ou Guia do Usuário do PF.
Preparar uma máquina virtual Oracle Linux para o
Azure
Este artigo pressupõe que você já instalou um sistema operacional Oracle Linux em um disco rígido virtual.
Existem várias ferramentas para criar arquivos .vhd, por exemplo, uma solução de virtualização como o Hyper-V.
Para obter instruções, consulte Instalar a função Hyper-V e configurar uma máquina Virtual.
Notas de instalação do Oracle Linux

o Azure.
O Hyper-V e o Azure dão suporte ao Oracle Linux com o UEK (Unbreakable Enterprise Kernel) ou o kernel
compatível com o Red Hat.
O UEK2 da Oracle não é compatível com o Hyper-V nem com o Azure, pois não contém os drivers
necessários.
VHD usando o Gerenciador do Hyper-V ou o cmdlet convert-vhd.
É necessário supor te a kernel para montar sistemas de arquivos UDF. Na primeira inicialização no
Azure, a configuração de provisionamento é transmitida à VM do Linux por meio de mídia formatada para
UDF, a qual é anexada ao convidado. O agente de Linux do Azure deve ser capaz de montar o sistema de
arquivos UDF para ler sua configuração e provisionar a VM.
As versões do kernel do Linux anteriores à 2.6.37 não são suporte para NUMA no Hyper-V com tamanhos de
VM maiores. Esse problema afeta principalmente distribuições mais antigas usando o kernel Red Hat 2.6.32
upstream e foi corrigido no Oracle Linux 6.6 e posterior
Não configure uma partição de permuta no disco do SO. Verifique as etapas a seguir para obter mais
Certifique-se de que o repositório Addons está habilitado. Edite o arquivo
/etc/yum.repos.d/public-yum-ol6.repo (Oracle Linux 6) ou /etc/yum.repos.d/public-yum-ol7.repo (Oracle
Linux 7) e altere a linha enabled=0 para enabled=1 em [ol6_addons] ou [ol7_addons] nesse arquivo.
Oracle Linux 6.4 e posterior

Você deve concluir as etapas de configuração específicas do sistema operacional para que a máquina virtual
seja executada no Azure.
1. No painel central do Gerenciador do Hyper-V, selecione a máquina virtual.
2. Clique em Conectar para abrir a janela da máquina virtual.
3. Desinstale o NetworkManager executando o seguinte comando:
# sudo rpm -e --nodeps NetworkManager
Obser vação: Se o pacote ainda não foi instalado, esse comando falhará com uma mensagem de erro.
Isso é esperado.
4. Crie um arquivo chamado network in the /etc/sysconfig/ que contém o seguinte texto:
NETWORKING=yes
5. Crie um arquivo chamado ifcfg-eth0 in the /etc/sysconfig/network-scripts/ que contém o seguinte

texto:
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
# sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules

# sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
# chkconfig network on
8. Instale o python-pyasn1 executando o seguinte comando:
# sudo yum install python-pyasn1
adicionais de kernel para o Azure. Para fazer isso, abra "/boot/grub/menu.lst" em um editor de texto e
verifique se o kernel inclui os seguintes parâmetros:
Isso garantirá que todas as mensagens do console sejam enviadas para a primeira porta serial, que pode
auxiliar o suporte do Azure com problemas de depuração.
logs sejam enviados para a porta serial.
Você pode deixar configurada a opção crashkernel , mas esse parâmetro reduz a memória disponível na
máquina virtual em 128 MB ou mais, o que pode ser um problema em máquinas virtuais menores.
esse é o padrão.
11. Instale o Agente Linux do Azure executando o comando a seguir. A versão mais recente é 2.0.15.
# sudo yum install WALinuxAgent
Observe que a instalação do pacote WALinuxAgent removerá o NetworkManager e os pacotes

NetworkManager-gnome se eles já não tiverem sido removidos conforme descrito na etapa 2.
Agente Linux do Azure (consulte a etapa anterior), modifique os seguintes parâmetros em
/etc/waagent.conf de maneira apropriada:
no Azure:
# sudo waagent -force -deprovision

# export HISTSIZE=0
# logout
carregado no Azure.
Oracle Linux 7.0 e posterior

Alterações no Oracle Linux 7
A preparação de uma máquina virtual Oracle Linux 7 para o Azure é muito parecida com a preparação das
máquinas virtuais Oracle Linux 6, mas há diversas diferenças que merecem atenção:
O Azure dá suporte ao Oracle Linux com o UEK (Unbreakable Enterprise Kernel) ou o kernel compatível com
o Red Hat. É recomendável o Oracle Linux com UEK.
O pacote do NetworkManager não entra mais em conflito com o agente Linux do Azure. Esse pacote é
instalado por padrão e recomendamos que você não o remova.
O GRUB2 agora é usado como carregador de inicialização padrão. Com isso, o procedimento de edição de
parâmetros do kernel mudou (confira abaixo).
O XFS agora é o sistema de arquivos padrão. Ainda é possível usar o sistema de arquivos ext4 se você
preferir.
Etapas de configuração
3. Crie um arquivo chamado network in the /etc/sysconfig/ que contém o seguinte texto:
NETWORKING=yes
4. Crie um arquivo chamado ifcfg-eth0 in the /etc/sysconfig/network-scripts/ que contém o seguinte

texto:
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
# sudo chkconfig network on
7. Execute o comando a seguir para instalar o pacote python-pyasn1:
# sudo yum install python-pyasn1
8. Execute o comando a seguir para limpar os metadados atuais do yum e instalar atualizações:
# sudo yum clean all

# sudo yum -y update
adicionais de kernel para o Azure. Para fazer isso, abra "/etc/default/grub" em um editor de texto e edite o
parâmetro GRUB_CMDLINE_LINUX . Por exemplo:
que pode auxiliar o suporte do Azure com problemas de depuração. Ele também desativa as convenções
de nomenclatura para NICs no Oracle Linux 7 com o Unbreakable Enterprise Kernel. Além disso,
recomendamos que você remova os seguintes parâmetros:

logs sejam enviados para a porta serial.
Você pode deixar configurada a opção crashkernel , mas esse parâmetro reduz a memória disponível na
máquina virtual em 128 MB ou mais, o que pode ser um problema em máquinas virtuais menores.
10. Depois de editar "/etc/default/grub" como mostramos acimo, execute o comando a seguir para
recompilar a configuração do grub:
# sudo grub2-mkconfig -o /boot/grub2/grub.cfg
esse é o padrão.
12. Instale o agente Linux do Azure e as dependências:

sudo systemctl enable waagent
13. Instalar Cloud-init para lidar com o provisionamento


datasource:
Azure:
EOF

echo Removing swapfile - RHEL uses a swapfile by default
fi


EOF



#cloud-config
disk_setup:
ephemeral0:
table_type: mbr
layout: [66, [33, 82]]
overwrite: True
fs_setup:
filesystem: ext4
filesystem: swap
mounts:
EOF
no Azure:
image,

# export HISTSIZE=0
# logout
carregado no Azure.
Próximas etapas
Agora você está pronto para usar o .vhd Oracle Linux para criar novas máquinas virtuais no Azure. Se esta é a
primeira vez que você está carregando o arquivo .vhd para o Azure, consulte Criar uma VM do Linux a partir de
um disco personalizado.
Criar e carregar uma imagem de disco OpenBSD
no Azure
Este artigo mostra como criar e carregar um disco rígido virtual (VHD) que contém o sistema operacional
OpenBSD. Depois de carregá-lo, você pode usá-lo como sua própria imagem para criar uma máquina virtual
(VM) no Azure por meio da CLI do Azure.
Pré-requisitos
Este artigo pressupõe que você tenha os seguintes itens:
Uma assinatura do Azure - Se não tiver uma conta, você poderá criar uma em apenas alguns minutos. Se
você tiver uma assinatura do MSDN, confira crédito Azure mensal para assinantes do Visual Studio. Caso
contrário, saiba como criar uma conta de avaliação gratuita.
CLI do Azure – Verifique se você instalou a versão mais recente da CLI do Azure e entrou em uma conta do
Azure usando az login.
Sistema operacional OpenBSD instalado em um arquivo. vhd -um sistema operacional OpenBSD
com suporte (versão 6,6 AMD64) deve ser instalado em um disco rígido virtual. Existem várias ferramentas
para criar arquivos .vhd. Por exemplo, você pode usar uma solução de virtualização, como o Hyper-V, para
criar o arquivo .vhd e instalar o sistema operacional. Para obter instruções sobre como instalar e usar o
Hyper-V, confira Instalar o Hyper-V e criar uma máquina virtual.
Preparar imagem OpenBSD do Azure

Na VM em que você instalou o sistema de operacional OpenBSD 6.1, que adicionou suporte Hyper-V, conclua os
procedimentos a seguir:
1. Se DHCP não está habilitado durante a instalação, habilite o serviço da seguinte maneira:
echo dhcp > /etc/hostname.hvn0
2. Instalar um console serial da seguinte maneira:
echo "stty com0 115200" >> /etc/boot.conf

echo "set tty com0" >> /etc/boot.conf
3. Configure a instalação do pacote da seguinte maneira:
echo "https://ftp.openbsd.org/pub/OpenBSD" > /etc/installurl
4. Por padrão, o usuário root encontra-se desabilitado nas máquinas virtuais no Azure. Os usuários
podem executar comandos com privilégios elevados usando o comando doas na VM OpenBSD. Doas é
habilitado por padrão. Para obter mais informações, consulte doas.conf.
5. Instalar e configurar os pré-requisitos para o agente do Azure da seguinte maneira:
pkg_add py-setuptools openssl git
ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
ln -sf /usr/local/bin/pydoc2.7 /usr/local/bin/pydoc
6. A versão mais recente do agente do Azure sempre pode ser encontrada no GitHub. Instale o agente da
seguinte maneira:
git clone https://github.com/Azure/WALinuxAgent

cd WALinuxAgent
python setup.py install
waagent -register-service
IMPORTANT
Depois de instalar o agente do Azure, convém verificar se ele está em execução da seguinte maneira:
ps auxw | grep waagent

root 79309 0.0 1.5 9184 15356 p1 S 4:11PM 0:00.46 python /usr/local/sbin/waagent
-daemon (python2.7)
cat /var/log/waagent.log
7. Desprovisione o sistema para limpá-lo e torná-lo adequado para o reprovisionamento. O comando a

seguir também exclui a última conta de usuário provisionada e os dados associados:
waagent -deprovision+user -force
Agora você pode desligar sua VM.
Preparar o VHD
O formato VHDX não tem suporte no Azure, somente o VHD fixo . Você pode converter o disco no formato VHD
fixo usando o Gerenciador do Hyper-V ou o cmdlet convert-vhd do Powershell. Um exemplo é como segue.
Convert-VHD OpenBSD61.vhdx OpenBSD61.vhd -VHDType Fixed
Criar recursos de armazenamento e carregar

Primeiro, crie um grupo de recursos com az group create. O exemplo a seguir cria um grupo de recursos
Para carregar seu VHD, crie uma conta de armazenamento com criar conta de armazenamento az. O nome da
conta de armazenamento deve ser exclusivo; portanto, forneça seu próprio nome. O exemplo a seguir cria uma
conta de armazenamento chamada mystorageaccount:
az storage account create --resource-group myResourceGroup \
--name mystorageaccount \
--location eastus \
--sku Premium_LRS
Para controlar o acesso à conta de armazenamento, obter a chave de armazenamento com az storage account
keys list da seguinte maneira:
STORAGE_KEY=$(az storage account keys list \

--account-name mystorageaccount \
--query "[?keyName=='key1'] | [0].value" -o tsv)
Para separar logicamente os VHDs que você carregue, crie um contêiner dentro da conta de armazenamento
com criar contêiner de armazenamento az:
az storage container create \

--name vhds \
--account-key ${STORAGE_KEY}
Por fim, carregue o VHD com carregamento de blob de armazenamento az da seguinte maneira:
az storage blob upload \

--container-name vhds \
--file ./OpenBSD61.vhd \
--name OpenBSD61.vhd \
--account-key ${STORAGE_KEY}
Criar VM a partir de seu VHD

Você pode criar uma VM com um script de exemplo ou diretamente com criar vm az. Para especificar o VHD
OpenBSD carregado, use o parâmetro --image da seguinte maneira:
az vm create \
--name myOpenBSD61 \
--image "https://mystorageaccount.blob.core.windows.net/vhds/OpenBSD61.vhd" \
--os-type linux \
Obter o endereço IP para sua VM OpenBSD com az vm lista--endereços ip da seguinte maneira:
az vm list-ip-addresses --resource-group myResourceGroup --name myOpenBSD61
Agora você pode SSH para sua VM OpenBSD normal:
ssh azureuser@<ip address>
Próximas etapas
Se você quiser saber mais sobre o suporte de Hyper-V em OpenBSD6.1, leia OpenBSD 6.1 e hyperv.4.
Se você quiser criar uma VM de disco gerenciado, leia disco az.
Preparar uma máquina virtual baseada no Red Hat
para o Azure
Neste artigo, você aprenderá como preparar uma máquina virtual do Red Hat Enterprise Linux (RHEL) para usar
no Azure. Neste artigo, abordamos as versões 6.7+ e 7.1+ do RHEL. Neste artigo, abordamos os seguintes
hipervisores de preparação: Hyper-V, máquina virtual baseada em kernel (KVM) e VMware. Para saber mais
informações sobre os requisitos de qualificação para participação no programa Red Hat Cloud Access, confira o
site Red Hat Cloud Access e o artigoComo executar o RHEL no Azure. Para obter maneiras de automatizar a
criação de imagens RHEL, consulte Construtor de imagens do Azure.
Gerenciador do Hyper-V
Esta seção mostra como preparar uma máquina virtual RHEL 6, RHEL 7ou RHEL 8 usando o Gerenciador do
Hyper-V.
Pré -requisitos
Esta seção pressupõe que você já baixou um arquivo ISO do site do Red Hat e já instalou a imagem do RHEL em
um disco rígido virtual (VHD). Para obter mais detalhes sobre como usar o Gerenciador do Hyper-V para instalar
uma imagem do sistema operacional, confira Como instalar a função Hyper-V e configurar uma máquina
virtual.
Notas de instalação do RHEL
O Azure não oferece suporte para o formato VHDX. O Azure suporta apenas VHD fixo. Você pode usar o
Gerenciador do Hyper-V para converter o disco em formato VHD, ou pode usar o cmdlet convert-vhd.
Quando criar o disco, se você usar o VirtualBox, selecione Tamanho fixo em vez da opção padrão
alocada dinamicamente.
O Azure dá suporte a máquinas virtuais Gen1 (inicialização do BIOS) & Gen2 (inicialização UEFI).
O tamanho máximo permitido para o VHD é 1.023 GB.
Gerenciador de Volume lógico (LVM) tem suporte e pode ser usado no disco do sistema operacional ou
discos de dados em máquinas virtuais do Azure. No entanto, em geral é recomendável usar partições
padrão em disco do sistema operacional em vez de LVM. Essa prática evitará conflitos de nome LVM
entre máquinas virtuais clonadas, especialmente se você precisar anexar um disco do sistema
operacional em outra máquina virtual idêntica para solução de problemas. Consulte também LVM e RAID
documentação.
É necessário supor te de kernel para montar sistemas de arquivos de formato de disco
universal (UDF) . Na primeira inicialização no Azure, a configuração de provisionamento é transmitida à
máquina virtual do Linux por meio de mídia formatada para UDF, a qual é anexada ao convidado. O
agente Linux do Azure deve ser capaz de montar o sistema de arquivos UDF para ler sua configuração e
provisionar a máquina virtual, sem isso, o provisionamento falhará!
Não configure uma partição de permuta no disco do sistema operacional. Verifique as etapas a seguir
para obter mais informações sobre esse assunto.
processado para VHD, certifique-se de que o tamanho do disco não processado seja um múltiplo de 1
MB antes da conversão. Encontre mais detalhes nas etapas abaixo. Consulte também Notas de Instalação
do Linux para obter mais informações.
RHEL 6 usando o Gerenciador do Hyper-V
3. No RHEL 6, NetworkManager pode interferir com o agente Linux do Azure. Desinstale este pacote ao
NETWORKING=yes
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
6. Mova (ou remova) as regras de udev para evitar a geração de regras estáticas da interface Ethernet. Essas
regras causam problemas ao clonar uma máquina virtual no Microsoft Azure ou no Hyper-V:
7. Certifique-se de que o serviço de rede será iniciado durante a inicialização executando o seguinte
comando:
8. Registre a sua assinatura do Red Hat para habilitar a instalação de pacotes do repositório RHEL ao
# sudo subscription-manager register --auto-attach --username=XXX --password=XXX
9. O pacote WALinuxAgent WALinuxAgent-<version> foi enviado para o repositório de extras do Red Hat.
Habilite o repositório de extras para a VM executando o seguinte comando:
# subscription-manager repos --enable=rhel-6-server-extras-rpms
adicionais de kernel para o Azure. Para fazer esta modificação, abra /boot/grub/menu.lst em um editor
de texto e verifique se o kernel padrão inclui os seguintes parâmetros:
Isso garantirá que todas as mensagens do console sejam enviadas para a primeira porta serial, o que
pode auxiliar o suporte do Azure com problemas de depuração.
logs sejam enviados para a porta serial. Você pode deixar a opção crashkernel configurada se quiser.
Observe que esse parâmetro reduz a memória disponível na máquina virtual em 128 MB ou mais. Essa
configuração pode ser um problema em máquinas virtuais menores.
11. Confira se o servidor shell seguro (SSH) está instalado e configurado para iniciar no momento da
inicialização, que geralmente é o padrão. Modifique o /etc/ssh/sshd_config para incluir a seguinte linha:
ClientAliveInterval 180
12. Instale o Agente Linux do Azure executando o seguinte comando:
# sudo chkconfig waagent on
A instalação do pacote WALinuxAgent removerá os pacotes NetworkManager e NetworkManager-gnome

se eles já não tiverem sido removidos na etapa 3.
13. Não crie espaço de permuta no disco do sistema operacional.
O agente de Linux do Azure pode configurar automaticamente o espaço de permuta usando o disco de
recurso local anexado à máquina virtual, depois da mesma ser provisionada no Azure. Observe que o
disco de recurso local é um disco temporário e pode ser esvaziado se a máquina virtual for
desprovisionada. Depois de instalar o agente de Linux do Azure na etapa anterior, modifique os seguintes
parâmetros em /etc/waagent.conf:
14. Cancele o registro da assinatura (se necessário) executando o seguinte comando:
# sudo subscription-manager unregister
no Azure:
image,
# export HISTSIZE=0
# logout
16. Clique em ação > desligar no Gerenciador do Hyper-V. Agora, seu VHD Linux está pronto para ser
carregado no Azure.
NETWORKING=yes
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
PERSISTENT_DHCLIENT=yes
NM_CONTROLLED=yes
comando:
# sudo systemctl enable network
adicionais de kernel para o Azure. Para fazer esta modificação, abra /etc/default/grub em um editor de
texto e edite o parâmetro GRUB_CMDLINE_LINUX . Por exemplo:
GRUB_CMDLINE_LINUX="rootdelay=300 console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200

earlyprintk=ttyS0 net.ifnames=0"
GRUB_TERMINAL_OUTPUT="serial console"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1
Isso também garantirá que todas as mensagens do console sejam enviadas para a primeira porta serial e
habilitam a interação com o console serial, o que pode auxiliar o suporte do Azure com problemas de
depuração. Essa configuração também desliga as novas convenções de nomenclatura do RHEL 7 para
NICs.
Observe que este parâmetro reduz a memória disponível na máquina virtual em 128 MB ou mais, o que
pode ser um problema em máquinas virtuais menores.
8. Depois de editar /etc/default/grub , execute o comando a seguir para recompilar a configuração do
grub:
NOTE
Se estiver carregando uma VM habilitada para UEFI, o comando para atualizar o grub será
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg .
9. Confira se o servidor SSH está instalado e configurado para iniciar no momento da inicialização, que
geralmente é o padrão. Modifique o /etc/ssh/sshd_config para incluir a seguinte linha:
11. Instale o agente Linux do Azure, o Cloud-init e outros utilitários necessários executando o seguinte
comando:
# sudo yum install -y WALinuxAgent cloud-init cloud-utils-growpart gdisk hyperv-daemons
# sudo systemctl enable waagent.service

# sudo systemctl enable cloud-init.service
12. Configure Cloud-init para lidar com o provisionamento:

a. Configurar waagent para Cloud-init:
sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf

NOTE
Se você estiver migrando uma máquina virtual específica e não quiser criar uma imagem generalizada, defina
Provisioning.Agent=disabled na /etc/waagent.conf configuração.
a. Configurar montagens:

a. Configurar fonte de origem do Azure:
datasource:
Azure:
EOF
a. Se configurado, remova o Swapfile existente:

echo "Removing swapfile" #RHEL uses a swapfile by defaul
fi
a. Configurar o log de inicialização de nuvem:


EOF
ResourceDisk.Format=n

#cloud-config
disk_setup:
ephemeral0:
table_type: mbr
layout: [66, [33, 82]]
overwrite: True
fs_setup:
filesystem: ext4
filesystem: swap
mounts:
EOF
14. Se você quiser cancelar o registro da assinatura, execute o seguinte comando:
15. Desprovisionar
Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
no Azure:
Cau t i on
Se você estiver migrando uma máquina virtual específica e não quiser criar uma imagem generalizada,
ignore a etapa de desprovisionamento. A execução do comando waagent -force -deprovision tornará o
computador de origem inutilizável; esta etapa destina-se apenas a criar uma imagem generalizada.
# export HISTSIZE=0
# logout
carregado no Azure.
3. Verifique se o serviço Gerenciador de rede será iniciado no momento da inicialização executando o
seguinte comando:
# sudo systemctl enable NetworkManager.service
4. Configure a interface de rede para iniciar automaticamente na inicialização e use DHCP:
# nmcli con mod eth0 connection.autoconnect yes ipv4.method auto
6. Modifique a linha de inicialização do kernel na configuração do grub para incluir parâmetros de kernel
adicionais para o Azure e habilite o console serial.
a. Remova os parâmetros GRUB atuais:
# grub2-editenv - unset kernelopts
a. Edite /etc/default/grub em um editor de texto e adicione o seguinte parâmetros:
GRUB_CMDLINE_LINUX="rootdelay=300 console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200

earlyprintk=ttyS0 net.ifnames=0"
GRUB_TERMINAL_OUTPUT="serial console"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"
Isso também garantirá que todas as mensagens do console sejam enviadas para a primeira porta serial e
habilitam a interação com o console serial, o que pode auxiliar o suporte do Azure com problemas de
depuração. Essa configuração também desativa as novas convenções de nomenclatura para NICs.
a. Além disso, recomendamos que você remova os seguintes parâmetros:
grub:
E para uma VM habilitada para UEFI, execute o seguinte comando:
# sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
9. Instale o agente Linux do Azure, o Cloud-init e outros utilitários necessários executando o seguinte
comando:
# sudo yum install -y WALinuxAgent cloud-init cloud-utils-growpart gdisk hyperv-daemons

# sudo systemctl enable cloud-init.service
10. Configure Cloud-init para lidar com o provisionamento:
a. Configurar waagent para Cloud-init:
sed -i 's/Provisioning.Agent=auto/Provisioning.Agent=cloud-init/g' /etc/waagent.conf

NOTE
Se você estiver migrando uma máquina virtual específica e não quiser criar uma imagem generalizada, defina
Provisioning.Agent=disabled na /etc/waagent.conf configuração.
a. Configurar montagens:

a. Configurar fonte de origem do Azure:
datasource:
Azure:
EOF
a. Se configurado, remova o Swapfile existente:

echo "Removing swapfile" #RHEL uses a swapfile by defaul
fi
a. Configurar o log de inicialização de nuvem:


EOF


#cloud-config
disk_setup:
ephemeral0:
table_type: mbr
layout: [66, [33, 82]]
overwrite: True
fs_setup:
filesystem: ext4
filesystem: swap
mounts:
EOF
13. Desprovisionar
Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
no Azure:
# export HISTSIZE=0
# logout
Cau t i on
Se você estiver migrando uma máquina virtual específica e não quiser criar uma imagem generalizada,
ignore a etapa de desprovisionamento. A execução do comando waagent -force -deprovision tornará o
computador de origem inutilizável; esta etapa destina-se apenas a criar uma imagem generalizada.
carregado no Azure.
KVM
Esta seção mostra como usar o KVM para preparar um distribuição RHEL 6 ou RHEL 7 para carregar no Azure.
RHEL 6 usando o KVM
1. Baixe a imagem KVM do RHEL 6 no site do Red Hat.
2. Definir uma senha raiz.
Gere uma senha criptografada e copie a saída do comando:
# openssl passwd -1 changeme
Defina uma senha raiz com guestfish:
# guestfish --rw -a <image-name>

> <fs> run
> <fs> list-filesystems
> <fs> mount /dev/sda1 /
> <fs> vi /etc/shadow
> <fs> exit
Altere o segundo campo do usuário raiz de "!!" para a senha criptografada.

3. Crie uma máquina virtual no KVM da imagem qcow2. Defina o tipo de disco como qcow2 e defina o
modelo de dispositivo do adaptador de rede virtual para vir tio . Em seguida, inicie a máquina virtual e
faça logon como raiz.
NETWORKING=yes
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
regras causam problemas ao clonar uma máquina virtual no Azure ou no Hyper-V:
comando:
# chkconfig network on
# subscription-manager register --auto-attach --username=XXX --password=XXX

adicionais de kernel para o Azure. Para fazer esta configuração, abra /boot/grub/menu.lst em um editor
de texto e verifique se o kernel padrão inclui os seguintes parâmetros:
pode auxiliar o suporte do Azure com problemas de depuração.
Além dos itens acima, recomendamos remover os seguintes parâmetros:
10. Adicione os módulos do Hyper-V em initramfs:
Edite /etc/dracut.conf e adicione o seguinte conteúdo:
Recrie initramfs:
# dracut -f -v
11. Desinstale cloud-init:
# yum remove cloud-init
12. Verifique se o servidor SSH está instalado e configurado para começar na hora da inicialização:
# chkconfig sshd on
Modifique o /etc/ssh/sshd_config para incluir as seguintes linhas:
PasswordAuthentication yes

# yum install WALinuxAgent
# chkconfig waagent on
15. O agente de Linux do Azure pode configurar automaticamente o espaço de permuta usando o disco de
disco de recurso local é um disco temporário e poderá ser esvaziado se a máquina virtual for
desprovisionada. Depois de instalar o agente Linux do Azure na etapa anterior, modifique os seguintes
parâmetros no /etc/waagent.conf adequadamente:
# subscription-manager unregister
no Azure:
image,

# export HISTSIZE=0
# logout
18. Finalize a máquina virtual no KVM.

19. Converta a imagem qcow2 para o formato VHD.
NOTE
Há um bug conhecido nas versões qemu-img > = 2.2.1 que resulta em um VHD formatado incorretamente. O
problema foi corrigido na versão QEMU 2.6. É recomendável usar o qemu-img 2.2.0 ou inferior, ou atualizar para
a versão 2.6 ou posterior. Referência: https://bugs.launchpad.net/qemu/+bug/1490611.
Primeiro, converta a imagem no formato bruto:
# qemu-img convert -f qcow2 -O raw rhel-6.9.qcow2 rhel-6.9.raw
Certifique-se de que o tamanho da imagem bruta é alinhado com 1 MB. Caso contrário, arredonde o
tamanho para alinhar com 1 MB:
# MB=$((1024*1024))
# size=$(qemu-img info -f raw --output json "rhel-6.9.raw" | \
# rounded_size=$((($size/$MB + 1)*$MB))
# qemu-img resize rhel-6.9.raw $rounded_size
Converta o disco bruto em um VHD de tamanho fixo:
# qemu-img convert -f raw -o subformat=fixed -O vpc rhel-6.9.raw rhel-6.9.vhd
Ou, com QEMU versão 2.6 + inclua a force_size opção:
# qemu-img convert -f raw -o subformat=fixed,force_size -O vpc rhel-6.9.raw rhel-6.9.vhd
RHEL 7 usando KVM

1. Baixe a imagem KVM do RHEL 7 no site do Red Hat. Este procedimento usa RHEL 7 como exemplo.
2. Definir uma senha raiz.
Gere uma senha criptografada e copie a saída do comando:
# openssl passwd -1 changeme
Defina uma senha raiz com guestfish:
# guestfish --rw -a <image-name>

> <fs> run
> <fs> list-filesystems
> <fs> mount /dev/sda1 /
> <fs> vi /etc/shadow
> <fs> exit
Altere o segundo campo do usuário raiz de "!!" para a senha criptografada.

3. Crie uma máquina virtual no KVM da imagem qcow2. Defina o tipo de disco como qcow2 e defina o
modelo de dispositivo do adaptador de rede virtual para vir tio . Em seguida, inicie a máquina virtual e
faça logon como raiz.
NETWORKING=yes

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=yes
comando:
# subscription-manager register --auto-attach --username=XXX --password=XXX
adicionais de kernel para o Azure. Para fazer essa configuração, abra /etc/default/grub em um editor de
Esse comando garantirá que todas as mensagens do console sejam enviadas para a primeira porta serial,
o que pode auxiliar o suporte do Azure com problemas de depuração. O comando também desliga as
novas convenções de nomenclatura do RHEL 7 para NICs. Além dos itens acima, recomendamos remover
os seguintes parâmetros:
grub:
# grub2-mkconfig -o /boot/grub2/grub.cfg
10. Adicione os módulos do Hyper-V em initramfs.

Recrie initramfs:
# dracut -f -v
11. Desinstale cloud-init:
# yum remove cloud-init
12. Verifique se o servidor SSH está instalado e configurado para começar na hora da inicialização:
# systemctl enable sshd
Modifique o /etc/ssh/sshd_config para incluir as seguintes linhas:
# yum install WALinuxAgent
Habilite o serviço de waagent:
# systemctl enable waagent.service
15. Instalar Cloud-init siga as etapas em "preparar uma máquina virtual RHEL 7 do Gerenciador do Hyper-V",
etapa 12, "instalar Cloud-init para lidar com o provisionamento".
16. Alternar configuração
Não crie espaço de permuta no disco do sistema operacional. Siga as etapas em ' preparar uma máquina
virtual RHEL 7 do Gerenciador do Hyper-V ', etapa 13, ' configuração de permuta '
# subscription-manager unregister
18. Desprovisionar
Siga as etapas em "preparar uma máquina virtual RHEL 7 do Gerenciador do Hyper-V", etapa 15,
"desprovisionar"
19. Finalize a máquina virtual no KVM.
20. Converta a imagem qcow2 para o formato VHD.
NOTE
# qemu-img convert -f qcow2 -O raw rhel-7.4.qcow2 rhel-7.4.raw
# MB=$((1024*1024))
VMware
Esta seção mostra como preparar um distribuição RHEL 6 ou RHEL 7 do VMware.
Pré -requisitos
Esta seção pressupõe que você já instalou uma máquina virtual RHEL no VMware. Para saber mais sobre como
instalar um sistema operacional no VMware, confira Guia de instalação do sistema operacional convidado
VMware.
Ao instalar o sistema operacional Linux, recomendamos usar partições-padrão em vez de LVM, que
geralmente é o padrão para muitas instalações. Isso evitará conflitos de nome LVM entre a máquina virtual
clonada, especialmente se um disco do sistema operacional precisar ser anexado a outra máquina virtual
para solução de problemas. Se você preferir, é possível usar LVM ou RAID em discos de dados.
Não configure uma partição de permuta no disco do sistema operacional. O agente Linux pode ser
configurado para criar um arquivo de permuta no disco de recursos temporários. Confira as etapas a seguir
para obter mais informações sobre esse assunto.
Ao criar o disco rígido virtual, escolha Armazenar disco vir tual como um único arquivo .
RHEL 6 usando VMware
1. No RHEL 6, NetworkManager pode interferir com o agente Linux do Azure. Desinstale este pacote ao
2. Crie um arquivo chamado network no diretório /etc/sysconfig/ que contém o seguinte texto:
NETWORKING=yes
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
regras causam problemas ao clonar uma máquina virtual no Azure ou no Hyper-V:
comando:
adicionais de kernel para o Azure. Para fazer isso, abra /etc/default/grub em um editor de texto e edite o
parâmetro GRUB_CMDLINE_LINUX . Por exemplo:
GRUB_CMDLINE_LINUX="rootdelay=300 console=ttyS0 earlyprintk=ttyS0"
pode auxiliar o suporte do Azure com problemas de depuração. Além dos itens acima, recomendamos
remover os seguintes parâmetros:
9. Adicione os módulos do Hyper-V em initramfs:
Recrie initramfs:
# dracut -f -v
12. Não crie espaço de permuta no disco do sistema operacional.

O agente de Linux do Azure pode configurar automaticamente o espaço de permuta usando o disco de
disco de recurso local é um disco temporário e poderá ser esvaziado se a máquina virtual for
desprovisionada. Depois de instalar o agente de Linux do Azure na etapa anterior, modifique os seguintes
parâmetros em /etc/waagent.conf :
no Azure:
image,

# export HISTSIZE=0
# logout
15. Desligue a máquina virtual e, em seguida, converta o arquivo VMDK em um arquivo .vhd.
NOTE
# qemu-img convert -f vmdk -O raw rhel-6.9.vmdk rhel-6.9.raw
# MB=$((1024*1024))
RHEL 7 usando VMware

NETWORKING=yes

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=yes
comando:
adicionais de kernel para o Azure. Para fazer esta modificação, abra /etc/default/grub em um editor de
Essa configuração também garantirá que todas as mensagens do console sejam enviadas para a primeira
porta serial, o que pode auxiliar o suporte do Azure com problemas de depuração. Ele também desativa
novas convenções de nomenclatura do RHEL 7 para NICs. Além dos itens acima, recomendamos remover
os seguintes parâmetros:
grub:
7. Adicione os módulos do Hyper-V em initramfs.

Recrie initramfs:
# dracut -f -v
8. Confira se o servidor SSH está instalado e configurado para iniciar no tempo de inicialização. Essa
configuração geralmente é o padrão. Modifique o /etc/ssh/sshd_config para incluir a seguinte linha:
11. Instalar Cloud-init

Siga as etapas em "preparar uma máquina virtual RHEL 7 do Gerenciador do Hyper-V", etapa 12, "instalar
Cloud-init para lidar com o provisionamento".
Não crie espaço de permuta no disco do sistema operacional. Siga as etapas em ' preparar uma máquina
virtual RHEL 7 do Gerenciador do Hyper-V ', etapa 13, ' configuração de permuta '
14. Desprovisionar
Siga as etapas em "preparar uma máquina virtual RHEL 7 do Gerenciador do Hyper-V", etapa 15,
"desprovisionar"
15. Desligue a máquina virtual e converta o arquivo VMDK no formato VHD.
NOTE
# qemu-img convert -f vmdk -O raw rhel-7.4.vmdk rhel-7.4.raw
# MB=$((1024*1024))
Arquivo início rápido

Esta seção mostra como preparar um distribuição RHEL 7 de um ISO usando um arquivo início rápido.
RHEL 7 de um arquivo início rápido
1. Crie um arquivo de início rápido que inclui o seguinte conteúdo e salve o arquivo. Para saber mais sobre
a instalação de início rápido, consulte o Guia de instalação de início rápido.
# Kickstart for provisioning a RHEL 7 Azure VM
# System authorization information

auth --enableshadow --passalgo=sha512
# Use graphical install

text
# Do not run the Setup Agent on first boot

firstboot --disable
# Keyboard layouts
keyboard --vckeymap=us --xlayouts='us'
# System language
lang en_US.UTF-8
# Network information
network --bootproto=dhcp
# Root password
rootpw --plaintext "to_be_disabled"
# System services
services --enabled="sshd,waagent,NetworkManager"
# System timezone
timezone Etc/UTC --isUtc --ntpservers
0.rhel.pool.ntp.org,1.rhel.pool.ntp.org,2.rhel.pool.ntp.org,3.rhel.pool.ntp.org
# Partition clearing information

clearpart --all --initlabel
# Clear the MBR

zerombr
# Disk partitioning information

part /boot --fstype="xfs" --size=500
part /boot --fstype="xfs" --size=500
part / --fstyp="xfs" --size=1 --grow --asprimary
# System bootloader configuration

bootloader --location=mbr
# Firewall configuration
firewall --disabled
# Enable SELinux
selinux --enforcing
# Don't configure X
skipx
# Power down the machine after install

poweroff
%packages
@base
@console-internet
chrony
sudo
parted
-dracut-config-rescue
%end
%post --log=/var/log/anaconda/post-install.log
#!/bin/bash
# Register Red Hat Subscription

subscription-manager register --username=XXX --password=XXX --auto-attach --force
# Install latest repo update

yum update -y
# Enable extras repo

subscription-manager repos --enable=rhel-7-server-extras-rpms
# Install WALinuxAgent
yum install -y WALinuxAgent
# Unregister Red Hat subscription

subscription-manager unregister
# Enable waaagent at boot-up

systemctl enable waagent
# Install cloud-init


# Disable the root account

usermod root -p '!!'
# Disabke swap in WALinuxAgent

# Configure swap using cloud-init

#cloud-config
disk_setup:
ephemeral0:
table_type: mbr
layout: [66, [33, 82]]
overwrite: True
fs_setup:
filesystem: ext4
filesystem: swap
mounts:
EOF
# Set the cmdline

sed -i 's/^$GRUB_CMDLINE_LINUX$=".*"$/\1="console=tty1 console=ttyS0 earlyprintk=ttyS0
rootdelay=300"/g' /etc/default/grub
# Enable SSH keepalive

sed -i 's/^#$ClientAliveInterval$.*$/\1 180/g' /etc/ssh/sshd_config
# Build the grub cfg

grub2-mkconfig -o /boot/grub2/grub.cfg
# Configure network
cat << EOF > /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=yes
EOF
# Deprovision and prepare for Azure if you are creating a generalized image
sudo cloud-init clean --logs --seed
sudo rm -rf /var/lib/cloud/
sudo rm -rf /var/lib/waagent/
sudo rm -f /var/log/waagent.log
sudo waagent -force -deprovision+user

rm -f ~/.bash_history
export HISTSIZE=0
%end
2. Coloque o arquivo de início rápido onde o sistema de instalação pode acessá-lo.

3. Crie uma nova máquina virtual no Gerenciador do Hyper-V. Na página Conectar Disco Rígido Vir tual ,
selecione Anexar um disco rígido vir tual posteriormente e conclua o Assistente de Nova Máquina
Virtual.
4. Abra as configurações da máquina virtual:
a. Anexe um novo disco rígido virtual à máquina virtual. Selecione Formato VHD e Tamanho Fixo .
b. Anexe o ISO de instalação à unidade de DVD.
c. Configure o BIOS para inicializar do CD.
5. Iniciar a máquina virtual. Quando o guia de instalação for exibida, pressione Tab para configurar as
opções de inicialização.
6. Insira inst.ks=<the location of the kickstart file> no final das opções de inicialização e pressione
Enter .
7. Aguarde a conclusão da instalação. Quando a instalação for concluída, a máquina virtual desligará
automaticamente. Agora, seu VHD Linux está pronto para ser carregado no Azure.
Problemas conhecidos
O driver do Hyper-V não foi incluído no disco de RAM inicial ao usar um hipervisor Hyper-V
Em alguns casos, os instaladores do Linux podem não incluir os drivers para Hyper-V no disco RAM inicial
(initrd ou initramfs), a menos que ele detecte que está em execução em um ambiente Hyper-V.
Quando você estiver usando um sistema de virtualização diferente (ou seja, VirtualBox, Xen, etc.) para preparar
sua imagem do Linux, talvez seja necessário recompilar a initrd para garantir que pelo menos os módulos de
kernel hv_vmbus e hv_storvsc estejam disponíveis no disco RAM inicial. Esse já é um problema conhecido em
sistemas com base em distribuição no Red Hat em upstream.
Para resolver esse problema, adicione os módulos do Hyper-V nos initramfs e os recompile:
Recrie initramfs:
# dracut -f -v
Para obter mais detalhes, consulte as informações sobre recriação de initramfs.
Próximas etapas
Agora, você está pronto para usar o disco rígido virtual Red Hat Enterprise Linux para criar novas máquinas
virtuais no Azure. Se esta é a primeira vez que você está carregando o arquivo .vhd para o Azure, consulte
Criar uma VM do Linux a partir de um disco personalizado.
Para obter mais detalhes sobre os hipervisores certificados para execução do Red Hat Enterprise Linux, visite
o site da Red Hat.
Para saber mais sobre como usar imagens BYOS do RHEL prontas para produção, vá para a página de
documentação do BYOS.
Preparar uma máquina virtual do SLES ou
openSUSE para o Azure
Este artigo pressupõe que você já instalou um sistema operacional SUSE ou openSUSE Linux em um disco
rígido virtual. Existem várias ferramentas para criar arquivos .vhd, por exemplo, uma solução de virtualização
como o Hyper-V. Para obter instruções, consulte Instalar a função Hyper-V e configurar uma máquina Virtual.
Notas de instalação do SLES / openSUSE

o Azure.
VHD usando o Gerenciador do Hyper-V ou o cmdlet convert-vhd.
Não configure uma partição de permuta no disco do SO. O agente Linux pode ser configurado para criar um
arquivo de permuta no disco de recursos temporários. Verifique as etapas a seguir para obter mais
Use o SUSE Studio

SUSE Studio pode criar e gerenciar facilmente suas imagens SLES e openSUSE no Azure e no Hyper-V. Essa é a
abordagem recomendada para personalizar suas próprias imagens SLES e openSUSE.
Como uma alternativa para compilar seu próprio VHD, o SUSE também publica imagens BYOS (traga sua
própria assinatura) para SLES no depósito de VM.
Preparar SUSE Linux Enterprise Server para o Azure

3. Registre seu sistema SUSE Linux Enterprise para permitir baixar atualizações e instalar pacotes.
4. Atualize o sistema com os patches mais recentes:
# sudo zypper update
5. Instalar o agente Linux do Azure e a nuvem-init

# SUSEConnect -p sle-module-public-cloud/15.2/x86_64 (SLES 15 SP2)
# sudo zypper refresh
# sudo zypper install python-azure-agent
# sudo zypper install cloud-init
6. Habilitar waagent & Cloud-init para iniciar na inicialização

# systemctl enable cloud-init-local.service
# systemctl enable cloud-init.service
# systemctl enable cloud-config.service
# systemctl enable cloud-final.service
# systemctl daemon-reload
# cloud-init clean
7. Atualizar waagent e configuração de inicialização de nuvem
# sed -i 's/Provisioning.UseCloudInit=n/Provisioning.UseCloudInit=y/g' /etc/waagent.conf

# sed -i 's/Provisioning.Enabled=y/Provisioning.Enabled=n/g' /etc/waagent.conf
# sudo sh -c 'printf "datasource:\n Azure:" > /etc/cloud/cloud.cfg.d/91-azure_datasource.cfg'

# sudo sh -c 'printf "reporting:\n logging:\n type: log\n telemetry:\n type: hyperv" >
/etc/cloud/cloud.cfg.d/10-azure-kvp.cfg'
8. Edite o arquivo/etc/default/grub para garantir que os logs do console sejam enviados para a porta serial
e, em seguida, atualize o arquivo de configuração principal com Grub2-mkconfig-o/boot/Grub2/grub.cfg
auxiliar o suporte do Azure com problemas de depuração.
9. Verifique se o arquivo/etc/fstab faz referência ao disco usando seu UUID (por UUID)

11. É recomendável editar o arquivo "/etc/sysconfig/network/dhcp" e alterar o parâmetro

DHCLIENT_SET_HOSTNAME para o seguinte:
DHCLIENT_SET_HOSTNAME="no"
12. Em "/etc/sudoers", exclua o comentário ou remova as seguintes linhas, se estiverem presentes:
Defaults targetpw # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
esse é o padrão.
Não crie espaço de permuta no disco do sistema operacional.
# sed -i 's/ResourceDisk.Format=y/ResourceDisk.Format=n/g' /etc/waagent.conf

# sed -i 's/ResourceDisk.EnableSwap=y/ResourceDisk.EnableSwap=n/g' /etc/waagent.conf

Passe isso como uma configuração de Cloud-init sempre que criar uma VM.

#cloud-config
disk_setup:
ephemeral0:
table_type: mbr
layout: [66, [33, 82]]
overwrite: True
fs_setup:
filesystem: ext4
filesystem: swap
mounts:
EOF
no Azure:


# export HISTSIZE=0
# logout
carregado no Azure.
Preparar o openSUSE 13.1+

3. No shell, execute o comando ' zypper lr '. Se este comando retornar uma saída semelhante à seguinte, os
repositórios estarão configurados conforme o esperado – nenhum ajuste é necessário (observe que os
números de versão podem variar):
# A L IA S NAME H A B IL ITA DA AT UA L IZ A R
1 Nuvem: Tools_13.1 Nuvem: Tools_13.1 Sim Sim
2 openSUSE_13 openSUSE_13 Sim Sim

openSUSE_13.1_OS openSUSE_13.1_OS
S S
3 openSUSE_13 openSUSE_13 Sim Sim

openSUSE_13.1_Up openSUSE_13.1_Up
dates dates
Se o comando retornar "Nenhum repositório definido...", use os seguintes comandos para adicionar esses
repositórios:
# sudo zypper ar -f http://download.opensuse.org/repositories/Cloud:Tools/openSUSE_13.1

Cloud:Tools_13.1
# sudo zypper ar -f https://download.opensuse.org/distribution/13.1/repo/oss openSUSE_13.1_OSS
# sudo zypper ar -f http://download.opensuse.org/update/13.1 openSUSE_13.1_Updates
Em seguida, você pode verificar se os repositórios foram adicionados executando novamente o comando
' zypper lr '. Caso um dos repositórios de atualização relevantes não esteja habilitado, habilite-o com o
comando a seguir:
# sudo zypper mr -e [NUMBER OF REPOSITORY]
4. Atualize o kernel para a versão mais recente disponível:
# sudo zypper up kernel-default
Ou para atualizar o sistema com todos os patches mais recentes:
# sudo zypper update
5. Instale o Agente Linux do Azure.
# sudo zypper install WALinuxAgent
adicionais de kernel para o Azure. Para fazer isso, abra "/boot/grub/menu.lst" em um editor de texto e
verifique se o kernel padrão inclui os seguintes parâmetros:
auxiliar o suporte do Azure com problemas de depuração. Além disso, remova os seguintes parâmetros
da linha de inicialização do kernel, se existirem:
libata.atapi_enabled=0 reserve=0x1f0,0x8
7. É recomendável editar o arquivo "/etc/sysconfig/network/dhcp" e alterar o parâmetro

DHCLIENT_SET_HOSTNAME para o seguinte:
DHCLIENT_SET_HOSTNAME="no"
8. Impor tante: Em "/etc/sudoers", exclua o comentário ou remova as seguintes linhas, se estiverem

presentes:
Defaults targetpw # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
esse é o padrão.
Agente Linux do Azure (consulte a etapa anterior), modifique os seguintes parâmetros em
/etc/waagent.conf de maneira apropriada:
no Azure:

# export HISTSIZE=0
# logout
12. Verifique se o Agente Linux do Azure é executado durante a inicialização:
carregado no Azure.
Próximas etapas
Agora, você está pronto para usar o disco rígido virtual SUSE Linux para criar novas máquinas virtuais no Azure.
Se esta é a primeira vez que você está carregando o arquivo .vhd para o Azure, consulte Criar uma VM do Linux
a partir de um disco personalizado.
Preparar uma máquina virtual do Ubuntu para o
Azure
O Ubuntu agora publica VHDs oficiais do Azure para download em https://cloud-images.ubuntu.com/ . Se você
precisar compilar sua própria imagem do Ubuntu especializada para o Azure, em vez de usar o procedimento
manual abaixo, é recomendável começar com esses VHDs de trabalho conhecidos e personalizá-los conforme
necessário. As versões mais recentes da imagem sempre podem ser encontradas nos seguintes locais:
Ubuntu 16.04/Xenial: Ubuntu-16, 4-Server-cloudimg-AMD64-DISK1. vmdk
Ubuntu 18.04/Bionic: Bionic-Server-cloudimg-AMD64. vmdk
Pré-requisitos
Este artigo pressupõe que você já instalou um sistema operacional Ubuntu Linux em um disco rígido virtual.
Existem várias ferramentas para criar arquivos .vhd, por exemplo, uma solução de virtualização como o Hyper-V.
Para obter instruções, consulte Instalar a função Hyper-V e configurar uma máquina Virtual.
Notas de instalação do Ubuntu
o Azure.
O formato VHDX não tem suporte no Azure, somente o VHD fixo . Você pode converter o disco para o
formato VHD usando o Gerenciador do Hyper-V ou o Convert-VHD cmdlet.
Não configure uma partição de permuta ou um Swapfile no disco do sistema operacional. O agente de
provisionamento Cloud-init pode ser configurado para criar um arquivo de permuta ou uma partição de
permuta no disco de recursos temporário. Verifique as etapas a seguir para obter mais informações a esse
respeito.
Etapas manuais
NOTE
Antes de tentar criar sua própria imagem personalizada do Ubuntu para o Azure, considere usar as imagens previamente
compiladas e testadas em https://cloud-images.ubuntu.com/ vez disso.

3. Substitua os repositórios atuais na imagem para usar o repositório do Azure do Ubuntu.
Antes de editar /etc/apt/sources.list , é recomendável fazer um backup:
# sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
Ubuntu 16, 4 e Ubuntu 18, 4:
# sudo sed -i
's/http:\/\/archive\.ubuntu\.com\/ubuntu\//http:\/\/azure\.archive\.ubuntu\.com\/ubuntu\//g'
/etc/apt/sources.list
# sudo sed -i 's/http:\/\/[a-z][a-
z]\.archive\.ubuntu\.com\/ubuntu\//http:\/\/azure\.archive\.ubuntu\.com\/ubuntu\//g'
/etc/apt/sources.list
4. As imagens do Ubuntu Azure agora estão usando o kernel personalizado pelo Azure. Atualize o sistema
operacional para o kernel mais recente personalizado do Azure e instale as ferramentas Linux do Azure
(incluindo as dependências do Hyper-V) executando os seguintes comandos:
Ubuntu 16, 4 e Ubuntu 18, 4:
# sudo apt update

# sudo apt install linux-azure linux-image-azure linux-headers-azure linux-tools-common linux-cloud-
tools-common linux-tools-azure linux-cloud-tools-azure
(recommended) # sudo apt full-upgrade
# sudo reboot
5. Modifique a linha de inicialização para o Grub para incluir parâmetros adicionais de kernel para o Azure.
Para fazer isso, abra /etc/default/grub em um editor de texto, localize a variável chamada
GRUB_CMDLINE_LINUX_DEFAULT (ou adicione-a, se necessário) e edite-a para incluir os seguintes parâmetros:
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200n8 earlyprintk=ttyS0,115200

rootdelay=300 quiet splash"
Salve e feche esse arquivo e execute sudo update-grub . Isso garantirá que todas as mensagens do
console sejam enviadas para a primeira porta serial, que pode auxiliar o suporte técnico do Azure com
problemas de depuração.
esse é o padrão.
7. Instale o Cloud-init (o agente de provisionamento) e o agente Linux do Azure (o manipulador de
extensões de convidado). Cloud-init usa o netplan para configurar a configuração de rede do sistema
durante o provisionamento e cada inicialização subsequente.
# sudo apt update

# sudo apt install cloud-init netplan.io walinuxagent && systemctl stop walinuxagent
NOTE
O walinuxagent pacote pode remover o NetworkManager e NetworkManager-gnome pacotes, se estiverem
instalados.
8. Remova as configurações padrão de Cloud-init e os artefatos restantes do netplan que podem entrar em
conflito com o provisionamento de inicialização de nuvem no Azure:
# rm -f /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg /etc/cloud/cloud.cfg.d/curtin-preserve-
sources.cfg
# rm -f /etc/cloud/ds-identify.cfg
# rm -f /etc/netplan/*.yaml
9. Configure Cloud-init para provisionar o sistema usando a fonte de origem do Azure:
# cat > /etc/cloud/cloud.cfg.d/90_dpkg.cfg << EOF

EOF
# cat > /etc/cloud/cloud.cfg.d/90-azure.cfg << EOF

system_info:
package_mirrors:
- arches: [i386, amd64]
failsafe:
primary: http://archive.ubuntu.com/ubuntu
security: http://security.ubuntu.com/ubuntu
search:
primary:
- http://azure.archive.ubuntu.com/ubuntu/
security: []
- arches: [armhf, armel, default]
failsafe:
primary: http://ports.ubuntu.com/ubuntu-ports
security: http://ports.ubuntu.com/ubuntu-ports
EOF
# cat > /etc/cloud/cloud.cfg.d/10-azure-kvp.cfg << EOF

reporting:
logging:
type: log
telemetry:
type: hyperv
EOF
10. Configure o agente Linux do Azure para contar com a inicialização de nuvem para executar o
provisionamento. Confira o projeto WALinuxAgent para obter mais informações sobre essas opções.

cat >> /etc/waagent.conf << EOF

# For Azure Linux agent version >= 2.2.45, this is the option to configure,
# enable, or disable the provisioning behavior of the Linux agent.
# Accepted values are auto (default), waagent, cloud-init, or disabled.
# A value of auto means that the agent will rely on cloud-init to handle
# provisioning if it is installed and enabled, which in this case it will.
Provisioning.Agent=auto
EOF
11. Limpar artefatos e logs de tempo de execução do agente do Azure e do Cloud-init:

# sudo cloud-init clean --logs --seed
# sudo rm -rf /var/lib/cloud/
# sudo systemctl stop walinuxagent.service
no Azure:
NOTE
O sudo waagent -force -deprovision+user comando tentará limpar o sistema e torná-lo adequado para
reprovisionamento. A +user opção exclui a última conta de usuário provisionada e os dados associados.
WARNING
O desprovisionamento usando o comando acima não garante que a imagem seja desmarcada de todas as
informações confidenciais e seja adequada para redistribuição.
# sudo waagent -force -deprovision+user

# export HISTSIZE=0
# logout
13. Clique em Ação -> Desligar no Gerenciador do Hyper-V.

14. O Azure aceita somente VHDs de tamanho fixo. Se o disco do sistema operacional da VM não for um
VHD de tamanho fixo, use o Convert-VHD cmdlet do PowerShell e especifique a -VHDType Fixed opção.
Consulte os documentos Convert-VHD aqui: Convert-VHD.
Próximas etapas
Agora, você está pronto para usar o disco rígido virtual Ubuntu Linux para criar novas máquinas virtuais no
Azure. Se esta é a primeira vez que você está carregando o arquivo .vhd para o Azure, consulte Criar uma VM do
Suporte à cloud-init para máquinas virtuais no
Azure
Este artigo mostra que o suporte que existe para a cloud-init para configurar uma máquina virtual VM ou
conjuntos de dimensionamento de máquinas virtuais no momento do provisionamento no Azure. Essas
configurações de cloud-init são executadas na primeira inicialização depois que os recursos são provisionados
pelo Azure.
O provisionamento de VM é o processo em que o Azure passará seus valores de parâmetro de criação de VM,
como nome de host, nome de usuário, senha etc. e os disponibilizará para a VM à medida que ele for
inicializado. Um 'agente de provisionamento' consumirá esses valores, vai configurar a VM e relatará quando
isso for concluído.
O Azure dá suporte a dois agentes de provisionamento de cloud-init e ao WALA (Agente Linux do Azure).
Visão geral da cloud-init

A cloud-init é uma abordagem amplamente utilizada para personalizar uma VM do Linux quando ela é
inicializada pela primeira vez. Você pode utilizar a inicialização de nuvem para instalar pacotes e gravar
arquivos, ou para configurar usuários e segurança. Como o cloud-init é executado durante o processo de
inicialização inicial, não há etapa adicional ou agentes necessários para aplicar a configuração. Para obter mais
informações sobre como formatar corretamente seus arquivos #cloud-config ou outras entradas, confira o site
de documentação da cloud-init. Os arquivos #cloud-config são arquivos de texto codificados em base64.
A cloud-init também funciona entre distribuições diferentes. Por exemplo, você não usa apt-get install nem
yum install para instalar um pacote. Em vez disso, você pode definir uma lista de pacotes para instalar. A cloud-
init usará automaticamente a ferramenta de gerenciamento de pacote nativo de distribuição que você
selecionar.
Estamos trabalhando ativamente com nossos parceiros endossados do Linux distribuição para ter imagens
habilitadas para Cloud-init disponíveis no Azure Marketplace. Essas imagens farão com que as implantações e
as configurações de cloud-init funcionem perfeitamente com VMs e conjuntos de dimensionamento de
máquinas virtuais. Inicialmente, colaboramos com os parceiros da distribuição de Linux endossada e upstream
para garantir as funções de cloud-init com o sistema operacional no Azure, então os pacotes são atualizados e
disponibilizados publicamente nos repositórios de pacotes da distribuição.
Há dois estágios para disponibilizar o cloud-init para os sistemas operacionais de distribuição do Linux
endossados no Azure, o suporte a pacotes e o suporte a imagens:
o "suporte a pacotes do cloud-init no Azure" documenta quais pacotes do cloud-init, juntamente com as
versões posteriores, são compatíveis ou estão em versão prévia, para que você possa usar esses pacotes com
o sistema operacional em uma imagem personalizada.
"imagem pronta para o cloud-init" documenta se a imagem já está configurada para usar o cloud-init.
Canônico
SUP O RT E A O
IM A GEM PA C OT E DO
F O RN EC EDO R/ V P RO N TA PA RA O C LO UD- IN IT N O
ERSÃ O O F ERTA SK U VERSÃ O C LO UD- IN IT A Z URE
Canonical 20.04 UbuntuServer 18.04-LTS mais recente sim sim
Canonical 14.04 UbuntuServer 14.04.5-LTS mais recente sim sim
RHEL
SUP O RT E A O
RedHat 7.6 RHEL 7-RAW-CI 7.6.2019072418 sim sim – suporte da

versão do
pacote: 18.2-
1.el7_6.2
RedHat 7.7 RHEL 7-RAW-CI 7.7.2019081601 Sim (Observação: N/D

esta é uma
imagem de
visualização e
não deve mais
ser usada, mas
será removida
em 1º de
setembro de
2020)
RedHat 7.7 RHEL 7.7 7.7.2020051912 sim sim – suporte da

(Gen1) versão do
pacote: 18.5-
6.el7
RedHat 7.7 RHEL 77-gen2 7.7.2020051913 sim sim – suporte da

(Gen2) versão do
pacote: 18.5-
6.el7
RedHat 7.7 RHEL 7-LVM 7.7.2020051921 sim sim – suporte da

(Gen1) versão do
pacote: 18.5-
6.el7
RedHat 7.7 RHEL 7lvm-gen2 7.7.2020051922 sim sim – suporte da

(Gen2) versão do
pacote: 18.5-
6.el7
SUP O RT E A O
RedHat 7.7 rhel-byos rhel-lvm77 7.7.20200416 sim sim – suporte da

(Gen1) versão do
pacote: 18.5-
6.el7
RedHat 8.1 RHEL 8.1-ci 8.1.2020042511 Sim (Observação: Não, ETA para
(Gen1) esta é uma suporte
imagem de completo em
visualização e, junho de 2020
depois que todas
as imagens RHEL
8,1 dão suporte
a Cloud-init, isso
será removido
em 1º de agosto
de 2020)
RedHat 8.1 RHEL 81-ci-gen2 8.1.2020042524 Sim (Observação: Não, ETA para
(Gen2) esta é uma suporte
imagem de completo em
visualização e, junho de 2020
depois que todas
as imagens RHEL
8,1 dão suporte
a Cloud-init, isso
será removido
em 1º de agosto
de 2020)
Todas as imagens de RedHat: RHEL 7,8 e 8,2 (Gen1 e Gen2) são provisionadas usando Cloud-init.
CentOS
SUP O RT E A O
OpenLogic 7.7 CentOS 7-CI 7.7.20190920 Sim (Observação: N/D

esta é uma
imagem de
visualização e
não deve mais
ser usada, mas
será removida
em 1º de
setembro de
2020)
OpenLogic 7.7 CentOS 7.7 7.7.2020062400 sim Sim – suporte da

versão do
pacote:
18.5-
6.el7.centos.5
SUP O RT E A O
OpenLogic 7,7 CentOS 7_7-Gen2 7.7.2020062401 sim Sim – suporte da

(Gen2) versão do
pacote:
18.5-
6.el7.centos.5
OpenLogic 7.7 CentOS-HPC 7.7 7.6.2020062600 sim Sim – suporte da

versão do
pacote:
18.5-
6.el7.centos.5
OpenLogic 7,7 CentOS-HPC 7_7-Gen2 7.6.2020062601 sim Sim – suporte da

(Gen2) versão do
pacote:
18.5-
6.el7.centos.5
OpenLogic 8,1 CentOS 8_1 8.1.2020062400 sim Sim – suporte da

versão do
pacote:
18.5-
7.el8_1.1
OpenLogic 8,1 CentOS 8_1-Gen2 8.1.2020062401 sim Sim – suporte da

(Gen2) versão do
pacote:
18.5-
7.el8_1.1
OpenLogic 8,1 CentOS-HPC 8_1 8.1.2020062400 sim Sim – suporte da

versão do
pacote:
18.5-
7.el8_1.1
OpenLogic 8,1 CentOS-HPC: 8_1-Gen2 8.1.2020062401 sim Sim – suporte da

(Gen2) 8_1-Gen2 versão do
pacote:
18.5-
7.el8_1.1
Todas as imagens OpenLogic: CentOS 7,8 e 8,2 (Gen1 e Gen2) são provisionadas usando Cloud-init.
Oracle
SUP O RT E A O
SUP O RT E A O
Oracle 7.7 Oracle-Linux 77-ci 7.7.01 imagem de não, na versão

visualização prévia, o pacote
(Observação: é: 18.5-3.0.1.el7
esta é uma
imagem de
visualização e,
uma vez que
todas as imagens
do Oracle 7,7
dão suporte a
Cloud-init, ela
será removida
mid 2020, o
aviso será
fornecido)
SUSE SLES
Essas imagens SLES foram atualizadas para provisionar usando Cloud-init, as variantes de imagem Gen2
também foram atualizadas.
SuSE: SLES-15-SP1-{Basic/BYOS/HPC/HPC-BYOS/CHOST-BYOS}: Gen1:2020.06.10
SuSE: SLES-SAP-15-SP1: Gen1:2020.06.10
SuSE: SLES-SAP-15-SP1-BYOS: Gen1:2020.06.10
SuSE: Manager-proxy-4-BYOS: Gen1:2020.06.10
SuSE: Manager-Server-4-BYOS: Gen1:2020.06.10
SuSE: SLES-{BYOS/SAP/SAP-BYOS}: 15:2020.06.10
SuSE: SLES-12-SP5: Gen1:2020.06.10
SuSE: SLES-12-SP5 {-BYOS/Basic/HPC-BYOS/HPC}: Gen1:2020.06.10
SuSE: SLES-{BYOS/SAP/SAP-BYOS}: 12-SP4:2020.06.10
Debian
SUP O RT E A O
Debian (GEN1) Debian-10 10-cloudinit cloud-init- Sim (Observação: Não, em versão

preview esta é uma prévia.
imagem de
visualização e
não deve mais
ser usada, isso
será removido
em 1º de janeiro
de 2021)
SUP O RT E A O
Debian (Gen2) Debian-10 10-cloudinit- cloud-init- Sim (Observação: Não, em versão

Gen2 preview esta é uma prévia.
imagem de
visualização e
não deve mais
ser usada, isso
será removido
em 1º de janeiro
de 2021)
Debian (GEN1) Debian-10 10-cloudinit 10:0.20201013.4 sim Sim – suporte da

22 versão do
pacote:
20.2-
2~deb10u1
Debian (Gen2) Debian-10 10-cloudinit- 0.20201013.422 sim Sim – suporte da

Gen2 versão do
pacote:
20.2-
2~deb10u1
Atualmente, o Azure Stack dará suporte ao provisionamento de imagens habilitadas para cloud-init.
Qual é a diferença entre cloud-init e o Agente do Linux (WALA)?

O WALA é um agente específico da plataforma do Azure usado para provisionar e configurar VMs e lidar com
extensões do Azure.
Estamos aprimorando a tarefa de configuração de VMs para usar cloud-init em vez do agente do Linux, para
permitir que os clientes existentes de cloud-init usem seus scripts atuais de cloud-init ou que os novos clientes
aproveitem as funcionalidades avançadas de configuração do cloud-init. Se você tiver investimentos existentes
em scripts do cloud-init para configurar os sistemas Linux, não há nenhuma configuração adicional
necessária para habilitar o cloud-init para processá-los.
O cloud-init não pode processar extensões do Azure, portanto, o WALA ainda é necessário na imagem para
processar extensões, mas precisará ter o respectivo código de provisionamento desabilitado, pois imagens de
distribuições do Linux endossadas que estejam sendo convertidas para provisionamento pelo cloud-init terão o
WALA instalado e estarão configuradas corretamente.
Ao criar uma VM, se você não incluir a opção --custom-data da CLI do Azure no momento de provisionamento,
o cloud-init ou o WALA usa os parâmetros necessários mínimos para provisionar a VM e concluir a implantação
com os padrões. Se você fizer referência à configuração do cloud-init com a opção --custom-data , tudo o que
estiver contido em seus dados personalizados estará disponível para o cloud-init quando a VM for inicializada.
As configurações de cloud-init aplicadas às VMs não têm restrições de tempo e não farão com que uma
implantação falhe por tempo limite. Isso não se verifica para o WALA, pois se você alterar os padrões do WALA
para processar dados personalizados, ele não poderá exceder o tempo de provisionamento total permitido de
40 minutos da VM, caso contrário, a criação da VM falhará.
Implantando uma Máquina Virtual habilitada para cloud-init

Implantar uma máquina virtual habilitada para cloud-init é tão simples quanto fazer referência a uma
distribuição habilitada para cloud-init durante a implantação. Os mantenedores da distribuição de Linux
precisam optar por habilitar e integrar o cloud-init em suas imagens publicadas da base do Azure. Depois de
confirmar, a imagem que você deseja implantar é habilitada para cloud-init, e você pode usar a CLI do Azure
para implantar a imagem.
A primeira etapa para implantar essa imagem é criar um grupo de recursos com o comando az group create.
gerenciados.
A próxima etapa é criar um arquivo no shell atual, chamado cloud-init.txt, e colar a configuração a seguir. Para
este exemplo, crie o arquivo no Cloud Shell, não no seu computador local. Você pode usar qualquer editor que
queira. Insira sensible-editor cloud-init.txt para criar o arquivo e ver uma lista de editores disponíveis.
Escolha #1 para usar o editor nano . Certifique-se de que o arquivo de inicialização de nuvem inteiro seja
copiado corretamente, especialmente a primeira linha:
#cloud-config
packages:
- httpd
NOTE
Cloud-init tem vários tipos de entrada, Cloud-init usará a primeira linha do CustomData/UserData para indicar como ele
deve processar a entrada; por exemplo, #cloud-config indica que o conteúdo deve ser processado como uma
configuração de Cloud-init.
Pressione ctrl-X para sair do arquivo, digite y para salvar o arquivo e pressione enter para confirmar o
nome do arquivo na saída.
A etapa final cria uma VM com o comando az vm create.
O exemplo a seguir cria uma VM denominada centos74 e cria chaves SSH, se elas ainda não existirem em um
local de chave padrão. Para usar um conjunto específico de chaves, use a opção --ssh-key-value . Utiçize o
--custom-data parâmetro para passar no arquivo de configuração de inicialização de nuvem. Forneça o
caminho completo para a configuração cloud-init.txt se você salvou o arquivo fora do seu diretório de trabalho
atual.
az vm create \
--name centos74 \
--image OpenLogic:CentOS-CI:7-CI:latest \
--generate-ssh-keys
Quando a VM tiver sido criada, a CLI do Azure mostrará informações específicas para a sua implantação. Anote
publicIpAddress . Esse endereço é usado para acessar a VM. Leva algum tempo para que a VM seja criada, os
pacotes sejam instalados e o aplicativo comece a funcionar. Há tarefas em segundo plano que continuarão em
execução depois que a CLI do Azure faz você voltar para o prompt. Você pode usar SSH na VM e usar as etapas
descritas na seção de resolução de problemas para exibir os logs de cloud-init.
Você também pode implantar uma VM habilitada para Cloud-init passando os parâmetros no modelo ARM.
Resolução de problemas do cloud-init

Depois que a VM tiver sido provisionada, o cloud-init será executado em todos os módulos e o script definido
em --custom-data para configurar a VM. Se você precisar solucionar quaisquer erros ou omissões da
configuração, você precisará pesquisar o nome do módulo ( disk_setup ou runcmd por exemplo) no log do
cloud-init - localizado em /var/log/cloud-init.log .
NOTE
Nem toda falha do módulo resulta em uma falha fatal de configuração geral do cloud-init. Por exemplo, usando o módulo
runcmd , se o script falhar, o cloud-init ainda relatará o provisionamento bem-sucedido, porque o módulo runcmd foi
executado.
Para obter mais detalhes de registro do cloud-init, consulte a documentação do cloud-init
Próximas etapas
Solucionar problemas com Cloud-init.
Para obter exemplos de alterações de configuração do cloud-init, consulte os seguintes documentos:
Add an additional Linux user to a VM (Adicionar um usuário adicional do Linux a uma VM)
Run a package manager to update existing packages on first boot (Executar um gerenciador de pacotes para
atualizar os pacotes existentes na primeira inicialização)
Change VM local hostname (Alterar o nome do host local da VM)
Install an application package, update configuration files and inject keys (Instalar um pacote de aplicativo,
atualizar os arquivos de configuração e injetar chaves)
Aprofundando-se na Cloud-init
Para saber mais sobre a inicialização de nuvem ou solucionar o problema em um nível mais profundo, você
precisa entender como ele funciona. Este documento destaca as partes importantes e explica as especificações
do Azure.
Quando Cloud-init é incluído em uma imagem generalizada, e uma VM é criada a partir dessa imagem, ela
processará as configurações e executará 5 estágios durante a inicialização inicial. Esses estágios são
importantes, pois mostram em que ponto a Cloud-init aplicará as configurações.
Entender a configuração Cloud-Init

Configurar uma VM para ser executada em uma plataforma, significa que a Cloud-init precisa aplicar várias
configurações, como um consumidor de imagem, as principais configurações com as quais você irá interagir é
User data (customData), que dá suporte a vários formatos, elas são documentadas aqui. Você também tem a
capacidade de adicionar e executar scripts (/var/lib/Cloud/scripts) para configuração adicional, abaixo aborda
isso mais detalhadamente.
Algumas configurações já estão inclusas nas imagens do Azure Marketplace que vêm com o Cloud-init, como:
1. Fonte de dados de nuvem -Cloud-init contém código que pode interagir com plataformas de nuvem,
eles são chamados de "DataSources". Quando uma VM é criada a partir de uma imagem de inicialização
de nuvem no Azure, o Cloud-init carrega a fonte de base do Azure, que irá interagir com os pontos de
extremidade de metadados do Azure para obter a configuração específica da VM.
2. Configuração de tempo de execução (/Run/Cloud-init)
3. Configuração de imagem (/etc/Cloud), como /etc/cloud/cloud.cfg , /etc/cloud/cloud.cfg.d/*.cfg .
Um exemplo de onde isso é usado no Azure, é comum que as imagens do sistema operacional Linux com
Cloud-init tenham uma diretiva de DataSource do Azure, que informa ao Cloud-init qual fonte de fontes
deve ser usada, isso economiza o tempo de inicialização da nuvem:
/etc/cloud/cloud.cfg.d# cat 90_dpkg.cfg

# to update this file, run dpkg-reconfigure cloud-init
Estágios de inicialização de Cloud-init (configuração de

processamento)
Ao provisionar com Cloud-init, há cinco estágios de inicialização, que processam a configuração e são
mostrados nos logs.
1. Estágio do gerador: o gerador do sistema de inicialização em nuvem é iniciado e determina que a
inicialização de nuvem deve ser incluída nas metas de inicialização e, nesse caso, habilita a Cloud-init.
2. Estágio local de Cloud-init: aqui Cloud-init procurará a fonte de origem "Azure" local, que habilitará o
Cloud-init para se conectar com o Azure e aplicará uma configuração de rede, incluindo fallback.
3. Estágio de inicialização Cloud-init (rede): a rede deve estar online e as informações da tabela de rotas e
da NIC devem ser geradas. Nesse estágio, os módulos listados em cloud_init_modules
em/etc/Cloud/Cloud.cfg serão executados. A VM no Azure será montada, o disco efêmero será
formatado, o nome do host será definido, juntamente com outras tarefas.
Estes são alguns dos cloud_init_modules :
- migrator
- seed_random
- bootcmd
- write-files
- growpart
- resizefs
- disk_setup
- mounts
- set_hostname
- update_hostname
- ssh
Após esse estágio, o Cloud-init sinalizará para a plataforma do Azure que a VM foi provisionada com
êxito. Alguns módulos podem ter falhado, nem todas as falhas de módulo resultarão em uma falha de
provisionamento.
4. Estágio de configuração Cloud-init: neste estágio, os módulos em cloud_config_modules definidos e
listados em/etc/Cloud/Cloud.cfg serão executados.
5. Estágio final de Cloud-init: neste estágio final, os módulos em cloud_final_modules , listados
em/etc/Cloud/Cloud.cfg, serão executados. Aqui estão os módulos que precisam ser executados no final
da execução do processo de inicialização, como instalações de pacotes e scripts de execução etc.
Durante esse estágio, você pode executar scripts colocando-os nos diretórios em
/var/lib/cloud/scripts :
per-boot -scripts dentro deste diretório, executados em cada reinicialização
per-instance -os scripts dentro desse diretório são executados quando uma nova instância é
inicializada pela primeira vez
per-once -os scripts dentro deste diretório são executados apenas uma vez
Próximas etapas
Solução de problemas de Cloud-init.
Solucionando problemas de provisionamento de
VM com Cloud-init
Se você estiver criando imagens personalizadas generalizadas, usando Cloud-init para fazer o provisionamento,
mas tiver encontrado que a VM não foi criada corretamente, você precisará solucionar problemas de suas
imagens personalizadas.
Alguns exemplos de problemas com o provisionamento:
A VM fica presa em ' criando ' por 40 minutos e a criação da VM é marcada como com falha
CustomData Não é processado
Falha na montagem do disco efêmero
Os usuários não são criados ou há problemas de acesso do usuário
A rede não está configurada corretamente
Trocar falhas de arquivo ou partição
Este artigo orienta você sobre como solucionar problemas de Cloud-init. Para obter detalhes mais detalhados,
consulte aprofundamento da Cloud-init.
Etapa 1: testar a implantação sem customData

O Cloud-init pode aceitar customData , que é passado para ele, quando a VM é criada. Primeiro, você deve
garantir que isso não esteja causando problemas com implantações. Tente provisionar a VM sem passar por
nenhuma configuração. Se você achar que a VM não está provisionada, continue com as etapas abaixo. se você
achar que a configuração que está passando não está sendo aplicada, vá para a .
etapa 4
Etapa 2: examinar os requisitos de imagem

A principal causa da falha de provisionamento da VM é que a imagem do sistema operacional não atende aos
pré-requisitos para execução no Azure. Verifique se suas imagens estão adequadamente preparadas antes de
tentar provisioná-las no Azure.
Os artigos a seguir ilustram as etapas para preparar várias distribuições do Linux com suporte no Azure:
Debian Linux
Oracle Linux
SLES e openSUSE
Ubuntu
Outros: Distribuições não endossadas
Para as imagens do Azure cloud-init com suporte, as distribuições do Linux já têm todos os pacotes e
configurações necessários para provisionar corretamente a imagem no Azure. Se você achar que sua VM não
está conseguindo criar a partir de sua própria imagem organizada, experimente uma imagem do Azure
Marketplace com suporte que já esteja configurada para Cloud-init, com o opcional customData . Se o
customData funcionar corretamente com uma imagem do Azure Marketplace, provavelmente haverá um
problema com a imagem organizada.
Etapa 3: coletar & examinar os logs da VM

Quando a VM não puder ser provisionada, o Azure mostrará o status ' criando ', por 20 minutos, e reinicializará
a VM e aguardará mais 20 minutos antes de finalmente marcar a implantação da VM como com falha, antes de
finalmente marcá-la com um OSProvisioningTimedOut erro.
Enquanto a VM estiver em execução, você precisará dos logs da VM para entender por que houve falha no
provisionamento. Para entender por que o provisionamento de VM falhou, não pare a VM. Mantenha a VM em
execução. Você precisará manter a VM com falha em um estado de execução para coletar logs. Para coletar os
logs, use um dos seguintes métodos:
Console serial
Habilite o diagnóstico de inicialização antes de criar a VM e, em seguida, exibi -las durante a inicialização.
Execute AZ VM Repair para anexar e montar o disco do sistema operacional, o que permitirá que você
colete esses logs:
/var/log/cloud-init*
/var/log/waagent*
/var/log/syslog*
/var/log/rsyslog*
/var/log/messages*
/var/log/kern*
/var/log/dmesg*
/var/log/boot*
Para iniciar a solução de problemas inicial, comece com os logs de Cloud-init e entenda onde a falha ocorreu,
use os outros logs para aprofundar-se e fornecer informações adicionais.
/var/log/Cloud-init.log
/var/log/cloud-init-output.log
Logs de série/inicialização
Em todos os logs, comece a procurar "falha", "aviso", "avisar", "Err", "erro", "erro". É recomendável definir a
configuração para ignorar pesquisas que diferenciam maiúsculas de minúsculas.
TIP
Se você estiver solucionando problemas de uma imagem personalizada, considere adicionar um usuário durante a
imagem. Se o provisionamento falhar ao definir o usuário administrador, você ainda poderá fazer logon no sistema
operacional.
Analisando os logs
Aqui estão mais detalhes sobre o que procurar em cada log de inicialização de nuvem.
/var/log/Cloud-init.log
Por padrão, todos os eventos Cloud-init com uma prioridade de debug ou superior são gravados no
/var/log/cloud-init.log . Isso fornece logs detalhados de cada evento ocorrido durante a inicialização de
Cloud-init.
Por exemplo:
2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while
running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable
Depois de encontrar um erro ou aviso, leia para trás no log de inicialização de nuvem para entender o que a
Cloud-init estava tentando antes de atingir o erro ou o aviso. Em muitos casos, o Cloud-init terá comandos do
sistema operacional executados ou executará operações de provisionamento anteriores ao erro, o que pode
fornecer informações sobre por que os erros apareciam nos logs. O exemplo a seguir mostra que a Cloud-init
tentou montar um dispositivo imediatamente antes de clicar em um erro.
2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto',
u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)
Se você tiver acesso ao console serial, poderá tentar executar novamente o comando que a Cloud-init estava
tentando realizar.
O registro em log para /var/log/cloud-init.log também pode ser reconfigurado
em/etc/cloud/cloud.cfg.d/05_logging. cfg. Para obter mais detalhes sobre o log de inicialização de nuvem,
consulte a documentação de inicialização de nuvem.
/var/log/cloud-init-output.log
Você pode obter informações do stdout e stderr durante os estágios de Cloud-init. Isso normalmente
envolve informações de tabela de roteamento, informações de rede, informações de verificação de chave de
host SSH stdout e stderr para cada estágio de Cloud-init, juntamente com o carimbo de data/hora de cada
estágio. Se desejar, stderr e o stdout registro em log pode ser reconfigurado de
/etc/cloud/cloud.cfg.d/05_logging.cfg .
Logs de série/inicialização
Cloud-init tem várias dependências, elas são documentadas em pré-requisitos obrigatórios para imagens no
Azure, como rede, armazenamento, capacidade de montar um ISO e montar e formatar o disco temporário.
Qualquer um deles pode gerar erros e causar falha na inicialização de nuvem. Por exemplo, se a VM não puder
obter uma concessão DHCP, a inicialização de nuvem falhará.
Se ainda não for possível isolar por que a Cloud-init falhou ao provisionar, você precisará entender quais
estágios de Cloud-init e quando os módulos são executados. Consulte aprofundando-se na inicialização de
nuvem para obter mais detalhes.
Etapa 4: investigar por que a configuração não está sendo aplicada

Nem toda falha em Cloud-init resulta em uma falha de provisionamento fatal. Por exemplo, se você estiver
usando o runcmd módulo em uma configuração de inicialização de nuvem, um código de saída diferente de
zero do comando que está sendo executado fará com que o provisionamento da VM falhe. Isso ocorre porque
ele é executado após a funcionalidade de provisionamento principal que ocorre nos três primeiros estágios de
Cloud-init. Para solucionar problemas por que a configuração não foi aplicada, examine os logs nos módulos
etapa 3 e Cloud-init manualmente. Por exemplo:
runcmd -os scripts são executados sem erros? Execute a configuração manualmente do terminal para
garantir que elas sejam executadas conforme o esperado.
Instalando pacotes – a VM tem acesso aos repositórios de pacotes?
Você também deve verificar a customData configuração de dados fornecida para a VM, que está localizada
em /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt .
Próximas etapas
Se você ainda não puder isolar por que a Cloud-init não executou a configuração, precisará olhar mais
detalhadamente o que acontece em cada estágio Cloud-init e quando os módulos são executados. Consulte
aprofundando -se na configuração do Cloud-init para obter mais informações.
Usar cloud-init para definir o nome do host para
uma VM Linux no Azure
Este artigo mostra como usar cloud-init para configurar um nome do host específico em uma VM (máquina
virtual) ou em um VMSS (conjuntos de dimensionamento de máquinas virtuais) no momento do
provisionamento no Azure. Esses scripts de cloud-init são executados na primeira inicialização depois que os
recursos são provisionados pelo Azure. Para obter mais informações de como o cloud-init funciona nativamente
no Azure e as distribuições do Linux compatíveis, consulte Visão geral de cloud-init
Defina o nome do host com a inicialização de nuvem

Por padrão, o nome do host é o mesmo que o nome da VM quando você cria uma nova máquina virtual no
Azure. Para executar um script cloud-init para alterar esse nome do host padrão ao criar uma VM no Azure com
az vm create, especifique o arquivo cloud-init com a opção --custom-data .
Para ver o processo de atualização em ação, crie um arquivo no shell atual denominado cloud_init_hostname.txt
e cole a seguinte configuração. Para este exemplo, crie o arquivo no Cloud Shell, não no seu computador local.
Você pode usar qualquer editor que queira. Insira sensible-editor cloud_init_hostname.txt para criar o arquivo
e ver uma lista de editores disponíveis. Escolha #1 para usar o editor nano . Verifique se o arquivo cloud-init
inteiro foi copiado corretamente, principalmente a primeira linha.
#cloud-config
hostname: myhostname
Antes de implantar essa imagem, você precisa criar um grupo de recursos com o comando az group create. Um
grupo de recursos do Azure é um contêiner lógico no qual os recursos do Azure são implantados e gerenciados.
Agora, crie uma VM com az vm create e especifique o arquivo de inicialização de nuvem com
--custom-data cloud_init_hostname.txt da seguinte maneira:
az vm create \
--name centos74 \
--image OpenLogic:CentOS:7-CI:latest \
--custom-data cloud_init_hostname.txt \
--generate-ssh-keys
Depois de criado, a CLI do Azure mostra informações sobre a VM. Use o publicIpAddress para conectar por SSH
à VM. Insira seu próprio endereço da seguinte maneira:
ssh <publicIpAddress>
Para ver o nome da VM, use o comando hostname da seguinte maneira:

hostname
A VM deve relatar o nome de host como esse valor definido no arquivo de inicialização de nuvem, conforme
mostrado no exemplo de saída a seguir:
myhostname
Próximas etapas
Para obter exemplos adicionais de alterações de configuração do cloud-init, consulte o seguinte:
Usar a cloud-init para atualizar e instalar pacotes
em uma VM do Linux no Azure
Este artigo mostra como usar Cloud-init para atualizar pacotes em uma VM (máquina virtual) do Linux ou
conjuntos de dimensionamento de máquinas virtuais no tempo de provisionamento no Azure. Esses scripts de
cloud-init são executados na primeira inicialização depois que os recursos são provisionados pelo Azure. Para
obter mais informações de como o cloud-init funciona nativamente no Azure e as distribuições do Linux
compatíveis, consulte Visão geral de cloud-init
Atualizar uma VM com a inicialização de nuvem

Para fins de segurança, convém configurar uma VM para aplicar as atualizações mais recentes na primeira
inicialização. Como a inicialização de nuvem funciona em diferentes distribuições de Linux, não é necessário
especificar apt ou yum para o gerenciador de pacotes. Em vez disso, você define package_upgrade e permite
que o processo de inicialização de nuvem determine o mecanismo apropriado para a distribuição em uso. Esse
fluxo de trabalho permite que você use os mesmos scripts de inicialização de nuvem entre distribuições.
Para ver o processo de atualização em ação, crie um arquivo em seu shell atual chamado cloud_init_upgrade.txt
e cole a seguinte configuração. Para este exemplo, crie o arquivo no Cloud Shell, não no seu computador local.
Você pode usar qualquer editor que queira. Insira sensible-editor cloud_init_upgrade.txt para criar o arquivo e
ver uma lista de editores disponíveis. Escolha #1 para usar o editor nano . Verifique se o arquivo cloud-init
inteiro foi copiado corretamente, principalmente a primeira linha.
#cloud-config
packages:
- httpd
--custom-data cloud_init_upgrade.txt da seguinte maneira:
az vm create \
--name centos74 \
--custom-data cloud_init_upgrade.txt \
--generate-ssh-keys
Conecte-se por SSH ao endereço IP público da VM mostrado na saída do comando anterior. Insira seu próprio
publicIpAddress da seguinte maneira:
Execute a ferramenta de gerenciamento de pacotes e verifique se há atualizações.
sudo yum update
Já que a cloud-init realizou a verificação em busca de atualizações e as instalou na inicialização, não deve haver
atualizações adicionais a serem aplicadas. Consulte o processo de atualização, o número de pacotes alterados,
bem como a instalação do httpd executando yum history e examine a saída semelhante a mostrada abaixo.
Loaded plugins: fastestmirror, langpacks

ID | Command line | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
3 | -t -y install httpd | 2018-04-20 22:42 | Install | 5
2 | -t -y upgrade | 2018-04-20 22:38 | I, U | 65
1 | | 2017-12-12 20:32 | Install | 522
Próximas etapas
Usar cloud-init para adicionar um usuário a uma
VM Linux no Azure
Este artigo mostra como usar cloud-init para adicionar um usuário em uma VM (máquina virtual) ou VMSS
(conjuntos de dimensionamento de máquinas virtuais) no tempo de provisionamento no Azure. Esse script
cloud-init é executado na primeira inicialização uma vez que os recursos tiverem sido provisionados pelo Azure.
Para obter mais informações sobre como a Cloud-init funciona nativamente no Azure e o distribuições do Linux
com suporte, consulte visão geral de Cloud-init.
Adicionar um usuário a uma VM com a inicialização de nuvem

Uma das primeiras tarefas em qualquer nova VM Linux é adicionar um usuário adicional para você para evitar o
uso do root. As chaves de SSH são uma prática recomendada para segurança e usabilidade. As chaves são
adicionadas ao arquivo ~/.ssh/authorized_keys com esse script de inicialização de nuvem.
Para adicionar um usuário a uma VM Linux, crie um arquivo no shell atual chamado cloud_init_add_user.txt e
cole a configuração a seguir. Para este exemplo, crie o arquivo no Cloud Shell, não no seu computador local.
Você pode usar qualquer editor que queira. Insira sensible-editor cloud_init_add_user.txt para criar o arquivo
e ver uma lista de editores disponíveis. Escolha #1 para usar o editor nano . Verifique se o arquivo cloud-init
inteiro foi copiado corretamente, principalmente a primeira linha. Você precisa fornecer sua própria chave
pública (como o conteúdo de ~/.ssh/id_rsa.pub) para o valor de ssh-authorized-keys: , ela foi reduzida aqui
para simplificar o exemplo.
#cloud-config
users:
- default
- name: myadminuser
groups: sudo
shell: /bin/bash
sudo: ['ALL=(ALL) NOPASSWD:ALL']
ssh-authorized-keys:
- ssh-rsa AAAAB3<snip>
NOTE
O arquivo #cloud-config inclui o parâmetro - default incluído. Isso acrescentará o usuário ao usuário administrador
existente criado durante o provisionamento. Se você criar um usuário sem o parâmetro - default , o usuário
administrador gerado automaticamente criado pela plataforma Azure será substituído.
--custom-data cloud_init_add_user.txt da seguinte maneira:
az vm create \
--name centos74 \
--custom-data cloud_init_add_user.txt \
--generate-ssh-keys
Para confirmar se o usuário foi adicionado para a VM e os grupos especificados, exiba o conteúdo do arquivo
/etc/group da seguinte maneira:
cat /etc/group
A saída de exemplo a seguir mostra que o usuário do arquivo cloud_init_add_user.txt foi adicionado à VM e ao
grupo apropriado:
root:x:0:
<snip />
sudo:x:27:myadminuser
<snip />
myadminuser:x:1000:
Próximas etapas
Usar Cloud-init para configurar uma partição de
permuta em uma VM do Linux
Este artigo mostra como usar Cloud-init para configurar a partição de permuta em várias distribuições do Linux.
A partição de permuta foi tradicionalmente configurada pelo agente do Linux (WALA) com base em quais
distribuições exigiam uma. Este documento descreverá o processo de criação da partição de permuta sob
demanda durante o tempo de provisionamento usando Cloud-init. Para obter mais informações de como o
cloud-init funciona nativamente no Azure e as distribuições do Linux compatíveis, consulte Visão geral de cloud-
init
Criar partição de permuta para imagens baseadas no Ubuntu

Por padrão no Azure, as imagens da galeria do Ubuntu não criam partições de permuta. Para habilitar a
configuração da partição de permuta durante o tempo de provisionamento da VM usando Cloud-init, consulte o
documento AzureSwapPartitions no wiki do Ubuntu.
Criar partição de permuta para imagens baseadas em Red Hat e

CentOS
Crie um arquivo em seu shell atual chamado cloud_init_swappart.txt e cole a configuração a seguir. Para este
exemplo, crie o arquivo no Cloud Shell, não no seu computador local. Você pode usar qualquer editor que
queira. Insira sensible-editor cloud_init_swappart.txt para criar o arquivo e ver uma lista de editores
disponíveis. Escolha #1 para usar o editor nano . Verifique se o arquivo cloud-init inteiro foi copiado
corretamente, principalmente a primeira linha.
#cloud-config
disk_setup:
ephemeral0:
table_type: gpt
layout: [66, [33,82]]
overwrite: true
fs_setup:
filesystem: ext4
filesystem: swap
mounts:
--custom-data cloud_init_swappart.txt da seguinte maneira:
az vm create \
--name centos74 \
--custom-data cloud_init_swappart.txt \
--generate-ssh-keys
Verificar se a partição de permuta foi criada

Depois que você tiver SSH'ed na VM, verifique se a partição de permuta foi criada
swapon -s
A saída desse comando deve ter esta aparência:
Filename Type Size Used Priority

/dev/sdb2 partition 2494440 0 -1
NOTE
Se você tiver uma imagem do Azure existente que tenha uma partição de permuta configurada e quiser alterar a
configuração da partição de permuta para novas imagens, deverá remover a partição de permuta existente. Consulte o
documento 'Personalizar imagens para provisionar por cloud-init' para obter mais detalhes.
Próximas etapas
Usar cloud-init para executar um script de bash em
uma VM Linux no Azure
Este artigo mostra como usar cloud-init para executar um script de bash existente em uma VM (máquina
virtual) Linux ou VMSS (conjuntos de dimensionamento de máquinas virtuais) no tempo de provisionamento
no Azure. Esses scripts de cloud-init são executados na primeira inicialização depois que os recursos são
provisionados pelo Azure. Para obter mais informações de como o cloud-init funciona nativamente no Azure e
as distribuições do Linux compatíveis, consulte Visão geral de cloud-init
Executar um script de bash com cloud-init

Com a cloud-init você não precisa converter seus scripts existentes em uma cloud-config, a cloud-init aceita
vários tipos de entrada, um dos quais é um script de bash.
Se você estiver usando a Extensão do Azure de Script Personalizado do Linux para executar seus scripts, poderá
migrá-las para usar a cloud-init. No entanto, as Extensões do Azure integraram os relatórios para alertar para
falhas de script, uma implantação de imagem de cloud-init NÃO falhará se o script falhar.
Para ver essa funcionalidade em ação, crie um script de bash simples para teste. Como o arquivo #cloud-config
de cloud-init, esse script deve ser local para onde você executará os comandos de AzureCLI para provisionar sua
máquina virtual. Para este exemplo, crie o arquivo no Cloud Shell, não no seu computador local. Você pode usar
qualquer editor que queira. Insira sensible-editor simple_bash.sh para criar o arquivo e ver uma lista de
editores disponíveis. Escolha #1 para usar o editor nano . Verifique se o arquivo cloud-init inteiro foi copiado
corretamente, principalmente a primeira linha.
#!/bin/sh
echo "this has been written via cloud-init" + $(date) >> /tmp/myScript.txt
Agora, crie uma VM com az vm create e especifique o arquivo de script de bash com
--custom-data simple_bash.sh da seguinte maneira:
az vm create \
--name centos74 \
--custom-data simple_bash.sh \
--generate-ssh-keys
Verificar se o script de bash foi executado

Altere para o diretório /tmp e verifique se o arquivo myScript.txt existe e tem o texto apropriado dentro dele. Se
não estiver, você poderá verificar o /var/log/cloud-init.log para obter mais detalhes. Pesquise a seguinte
entrada:
Running config-scripts-user using lock Running command ['/var/lib/cloud/instance/scripts/part-001']
Próximas etapas
Criando imagens generalizadas sem um agente de
provisionamento
Microsoft Azure fornece agentes de provisionamento para VMs do Linux na forma de walinuxagent ou Cloud-
init (recomendado). Mas pode haver um cenário em que você não queira usar nenhum desses aplicativos para o
agente de provisionamento, como:
Sua versão/distribuição do Linux não dá suporte ao agente Cloud-init/Linux.
Você precisa que propriedades específicas da VM sejam definidas, como nome do host.
NOTE
Se você não precisar que nenhuma propriedade seja definida ou que qualquer forma de provisionamento aconteça,
considere a criação de uma imagem especializada.
Este artigo mostra como você pode configurar sua imagem de VM para atender aos requisitos da plataforma
Azure e definir o nome do host, sem instalar um agente de provisionamento.
Rede e relatórios prontos

Para que sua VM Linux se comunique com os componentes do Azure, você precisará de um cliente DHCP para
recuperar um IP de host da rede virtual, bem como a resolução de DNS e o gerenciamento de rotas. A maioria
dos distribuiçõess é fornecida com esses utilitários prontos para uso. As ferramentas que foram testadas no
Azure por fornecedores de distribuição do Linux incluem dhclient , network-manager systemd-networkd e
outras.
NOTE
Atualmente, a criação de imagens generalizadas sem um agente de provisionamento dá suporte apenas a VMs
habilitadas para DHCP.
Após a instalação e configuração da rede, você deve "reportar pronto". Isso dirá ao Azure que a VM foi
provisionada com êxito.
IMPORTANT
A falha ao relatar pronto para o Azure resultará na reinicialização da VM!
Demonstração/exemplo
Esta demonstração mostrará como você pode usar uma imagem existente do Marketplace (nesse caso, uma VM
Debian Buster) e remover o agente do Linux (walinuxagent), mas também criar o processo mais básico para
relatar ao Azure que a VM está "pronta".
Crie o grupo de recursos e a VM base:
$ az group create --location eastus --name demo1
Criar a VM base:
$ az vm create \
--resource-group demo1 \
--name demo1 \
--location eastus \
--ssh-key-value <ssh_pub_key_path> \
--public-ip-address-dns-name demo1 \
--image "debian:debian-10:10:latest"
Remover o agente de provisionamento de imagem

Depois que a VM estiver Provisionando, você poderá SSH nela e remover o agente do Linux:
$ sudo apt purge -y waagent

$ sudo rm -rf /var/lib/waagent /etc/waagent.conf /var/log/waagent.log
Adicionar o código necessário à VM

Além disso, dentro da VM, como removemos o agente Linux do Azure, precisamos fornecer um mecanismo
para relatar prontamente.
Script do Python
import http.client
import sys
from xml.etree import ElementTree
wireserver_ip = '168.63.129.16'
wireserver_conn = http.client.HTTPConnection(wireserver_ip)
print('Retrieving goal state from the Wireserver')

wireserver_conn.request(
'GET',
'/machine?comp=goalstate',
headers={'x-ms-version': '2012-11-30'}
)
resp = wireserver_conn.getresponse()
if resp.status != 200:
print('Unable to connect with wireserver')
sys.exit(1)
wireserver_goalstate = resp.read().decode('utf-8')
xml_el = ElementTree.fromstring(wireserver_goalstate)
container_id = xml_el.findtext('Container/ContainerId')
instance_id = xml_el.findtext('Container/RoleInstanceList/RoleInstance/InstanceId')
print(f'ContainerId: {container_id}')
print(f'InstanceId: {instance_id}')
# Construct the XML response we need to send to Wireserver to report ready.

health = ElementTree.Element('Health')
goalstate_incarnation = ElementTree.SubElement(health, 'GoalStateIncarnation')
goalstate_incarnation.text = '1'
container = ElementTree.SubElement(health, 'Container')
container_id_el = ElementTree.SubElement(container, 'ContainerId')
container_id_el.text = container_id
role_instance_list = ElementTree.SubElement(container, 'RoleInstanceList')
role = ElementTree.SubElement(role_instance_list, 'Role')
role = ElementTree.SubElement(role_instance_list, 'Role')
instance_id_el = ElementTree.SubElement(role, 'InstanceId')
instance_id_el.text = instance_id
health_second = ElementTree.SubElement(role, 'Health')
state = ElementTree.SubElement(health_second, 'State')
state.text = 'Ready'
out_xml = ElementTree.tostring(
health,
encoding='unicode',
method='xml'
)
print('Sending the following data to Wireserver:')
print(out_xml)
wireserver_conn.request(
'POST',
'/machine?comp=health',
headers={
'x-ms-version': '2012-11-30',
'Content-Type': 'text/xml;charset=utf-8',
'x-ms-agent-name': 'custom-provisioning'
},
body=out_xml
)
resp = wireserver_conn.getresponse()
print(f'Response: {resp.status} {resp.reason}')
wireserver_conn.close()
Etapas genéricas (sem usar o Python )

Se sua VM não tiver o Python instalado ou disponível, você poderá reproduzir programaticamente essa lógica
de script acima com as seguintes etapas:
1. Recupere o ContainerId e InstanceId analisando a resposta do WireServer:
curl -X GET -H 'x-ms-version: 2012-11-30' http://168.63.129.16/machine?comp=goalstate .
2. Construa os seguintes dados XML, injetando o analisado ContainerId e InstanceId a partir da etapa
acima:
<Health>
<GoalStateIncarnation>1</GoalStateIncarnation>
<Container>
<ContainerId>CONTAINER_ID</ContainerId>
<RoleInstanceList>
<Role>
<InstanceId>INSTANCE_ID</InstanceId>
<Health>
<State>Ready</State>
</Health>
</Role>
</RoleInstanceList>
</Container>
</Health>
3. Poste esses dados no WireServer:

curl -X POST -H 'x-ms-version: 2012-11-30' -H "x-ms-agent-name: WALinuxAgent" -H "Content-Type:
text/xml;charset=utf-8" -d "$REPORT_READY_XML" http://168.63.129.16/machine?comp=health
Automatizando a execução do código na primeira inicialização

Esta demonstração usa o sistema, que é o sistema de inicialização mais comum no moderno Linux distribuições.
Portanto, a maneira mais fácil e nativa de garantir que esse mecanismo de relatório pronto seja executado no
momento certo é criar uma unidade de serviço do sistema. Você pode adicionar o seguinte arquivo de unidade
a /etc/systemd/system (Este exemplo nomeia o arquivo de unidade azure-provisioning.service ):
[Unit]
Description=Azure Provisioning
[Service]
Type=oneshot
ExecStart=/usr/bin/python3 /usr/local/azure-provisioning.py
ExecStart=/bin/bash -c "hostnamectl set-hostname $(curl \
-H 'metadata: true' \
'http://169.254.169.254/metadata/instance/compute/name?api-version=2019-06-01&format=text')"
ExecStart=/usr/bin/systemctl disable azure-provisioning.service
[Install]
WantedBy=multi-user.target
Esse serviço em sistema faz três coisas para o provisionamento básico:

1. Relatórios prontos para o Azure (para indicar que ele foi fornecido com êxito).
2. Renomeia a VM com base no nome da VM fornecida pelo usuário ao extrair esses dados do serviço de
metadados de instância do Azure (IMDS). Obser vação O IMDS também fornece outros metadados de
instância, como chaves públicas SSH, para que você possa definir mais do que o nome do host.
3. Desabilita a si mesmo para que ele só seja executado na primeira inicialização e não nas reinicializações
subsequentes.
Com a unidade no sistema de arquivos, execute o seguinte para habilitá-lo:
$ sudo systemctl enable azure-provisioning.service
Agora a VM está pronta para ser generalizada e tem uma imagem criada a partir dela.
Concluindo a preparação da imagem
De volta ao seu computador de desenvolvimento, execute o seguinte para preparar a criação da imagem da VM
de base:
$ az vm deallocate --resource-group demo1 --name demo1

$ az vm generalize --resource-group demo1 --name demo1
E crie a imagem a partir desta VM:
$ az image create \
--source demo1 \
--location eastus \
--name demo1img
Agora, estamos prontos para criar uma nova VM (ou várias VMs) a partir da imagem:
$ IMAGE_ID=$(az image show -g demo1 -n demo1img --query id -o tsv)
$ az vm create \
--name demo12 \
--location eastus \
--ssh-key-value <ssh_pub_key_path> \
--public-ip-address-dns-name demo12 \
--image "$IMAGE_ID"
--enable-agent false
NOTE
É importante definir --enable-agent como false porque walinuxagent não existe nessa VM que será criada a partir
da imagem.
Esta VM deve ser provisionada com êxito. Fazendo logon na VM de provisionamento novo, você deve ser capaz
de ver a saída do serviço de sistema pronto para o relatório:
$ sudo journalctl -u azure-provisioning.service

-- Logs begin at Thu 2020-06-11 20:28:45 UTC, end at Thu 2020-06-11 20:31:24 UTC. --
Jun 11 20:28:49 thstringnopa systemd[1]: Starting Azure Provisioning...
Jun 11 20:28:54 thstringnopa python3[320]: Retrieving goal state from the Wireserver
Jun 11 20:28:54 thstringnopa python3[320]: ContainerId: 7b324f53-983a-43bc-b919-1775d6077608
Jun 11 20:28:54 thstringnopa python3[320]: InstanceId: fbb84507-46cd-4f4e-bd78-a2edaa9d059b._thstringnopa2
Jun 11 20:28:54 thstringnopa python3[320]: Sending the following data to Wireserver:
Jun 11 20:28:54 thstringnopa python3[320]: <Health><GoalStateIncarnation>1</GoalStateIncarnation><Container>
<ContainerId>7b324f53-983a-43bc-b919-1775d6077608</ContainerId><RoleInstanceList><Role><InstanceId>fbb84507-
46cd-4f4e-bd78-a2edaa9d059b._thstringnopa2</InstanceId><Health><State>Ready</State></Health></Role>
</RoleInstanceList></Container></Health>
Jun 11 20:28:54 thstringnopa python3[320]: Response: 200 OK
Jun 11 20:28:56 thstringnopa bash[472]: % Total % Received % Xferd Average Speed Time Time
Time Current
Jun 11 20:28:56 thstringnopa bash[472]: Dload Upload Total Spent
Left Speed
Jun 11 20:28:56 thstringnopa bash[472]: [158B blob data]
Jun 11 20:28:56 thstringnopa2 systemctl[475]: Removed /etc/systemd/system/multi-user.target.wants/azure-
provisioning.service.
Jun 11 20:28:56 thstringnopa2 systemd[1]: azure-provisioning.service: Succeeded.
Jun 11 20:28:56 thstringnopa2 systemd[1]: Started Azure Provisioning.
Suporte
Se você implementar seu próprio código/agente de provisionamento, terá o suporte desse código, o suporte da
Microsoft investigará apenas os problemas relacionados às interfaces de provisionamento que não estão
disponíveis. Estamos continuamente fazendo melhorias e alterações nessa área, portanto, você deve monitorar
as alterações na Cloud-init e no agente Linux do Azure para provisionar alterações de API.
Próximas etapas
Para obter mais informações, consulte provisionamento do Linux.
Desabilitar ou remover o agente do Linux de VMs e
imagens
Antes de remover o agente do Linux, você deve entender o que a VM não poderá fazer depois que o agente do
Linux for removido.
As extensões de VM (máquina virtual) do Azure são aplicativos pequenos que fornecem tarefas de configuração
e automação de pós-implantação em VMs do Azure, as extensões são instaladas e gerenciadas pelo plano de
controle do Azure. É o trabalho do agente Linux do Azure processar os comandos de extensão de plataforma e
garantir o estado correto da extensão dentro da VM.
A plataforma do Azure hospeda várias extensões que variam de configuração de VM, monitoramento,
segurança e aplicativos de utilidade. Há uma grande opção de extensões de primeira e de terceiros, exemplos de
principais cenários para os quais as extensões são usadas:
Suporte a serviços do Azure de primeira parte, como o backup do Azure, monitoramento, criptografia de
disco, segurança, replicação de site e outros.
SSH/redefinições de senha
Configuração da VM-executando scripts personalizados, instalando o chefe, agentes Puppet etc..
Produtos de terceiros, como produtos AV, ferramentas de vulnerabilidade de VM, VM e ferramenta de
monitoramento de aplicativo.
As extensões podem ser incluídas com uma nova implantação de VM. Por exemplo, podem fazer parte de
uma implantação maior, configuração de aplicativos no provisionamento de VM, ou executar em qualquer
pós-implantação de sistemas operado por extensão com suporte.
Desabilitando o processamento de extensão

Há várias maneiras de desabilitar o processamento de extensão, dependendo de suas necessidades, mas antes
de continuar, você deve remover todas as extensões implantadas na VM, por exemplo, usando o CLI do Azure,
você pode listar e excluir:
az vm extension delete -g MyResourceGroup --vm-name MyVm -n extension_name
NOTE
Se você não fizer isso, a plataforma tentará enviar a configuração de extensão e o tempo limite após 40min.
Desabilitar no plano de controle

Se você não tiver certeza se precisará de extensões no futuro, poderá deixar o agente do Linux instalado na VM
e desabilitar a capacidade de processamento da extensão da plataforma. Essa opção está disponível na
Microsoft.Compute versão da API 2018-06-01 ou superior e não tem uma dependência na versão do agente do
Linux instalada.
az vm update -g <resourceGroup> -n <vmName> --set osProfile.allowExtensionOperations=false
Você pode reabilitar facilmente esse processamento de extensão da plataforma, com o comando acima, mas
defini-lo como ' true '.
Remover o agente do Linux de uma VM em execução

Verifique se você removeu todas as extensões existentes da VM antes, conforme descrito acima.
Etapa 1: remover o agente Linux do Azure
Se você apenas remover o agente do Linux e não os artefatos de configuração associados, poderá reinstalar o
em uma data posterior. Execute uma das seguintes opções, como raiz, para remover o agente Linux do Azure:
Para o Ubuntu >= 18, 4
apt -y remove walinuxagent
Para redhat >= 7,7
yum -y remove WALinuxAgent
Para SUSE
zypper --non-interactive remove python-azure-agent
Etapa 2: (opcional) remover os artefatos do agente Linux do Azure
IMPORTANT
Você pode remover todos os artefatos associados do agente do Linux, mas isso significa que você não poderá reinstalá-lo
em uma data posterior. Portanto, é altamente recomendável que você considere desabilitar o agente do Linux primeiro,
removendo o agente do Linux usando apenas o.
Se você souber que não reinstalará o agente do Linux novamente, será possível executar o seguinte:
Para o Ubuntu >= 18, 4
apt -y purge walinuxagent

rm -rf /var/lib/waagent
rm -f /var/log/waagent.log
Para redhat >= 7,7
yum -y remove WALinuxAgent

rm -f /etc/waagent.conf.rpmsave
Para SUSE
zypper --non-interactive remove python-azure-agent

rm -f /etc/waagent.conf.rpmsave
Preparando uma imagem sem o agente do Linux

Se você tiver uma imagem que já contém Cloud-init e quiser remover o agente do Linux, mas ainda provisionar
usando Cloud-init, execute as etapas na etapa 2 (e, opcionalmente, a etapa 3) como raiz para remover o agente
Linux do Azure e, em seguida, o seguinte removerá a configuração de Cloud-init e os dados armazenados em
cache, e preparar a VM
cloud-init clean --logs --seed
Desprovisionar e criar uma imagem

O agente do Linux tem a capacidade de limpar alguns dos metadados de imagem existentes, com a etapa
"waagent-deprovision + User", no entanto, depois que ele tiver sido removido, será necessário executar ações
como a abaixo e remover quaisquer outros dados confidenciais dela.
Remover todas as chaves de host SSH existentes
rm /etc/ssh/ssh_host_*key*
Excluir a conta do administrador
touch /var/run/utmp
userdel -f -r <admin_user_account>
Excluir a senha raiz
passwd -d root
Depois de concluir o acima, você poderá criar a imagem personalizada usando o CLI do Azure.
Criar uma imagem gerenciada regular
az vm deallocate -g <resource_group> -n <vm_name>

az vm generalize -g <resource_group> -n <vm_name>
az image create -g <resource_group> -n <image_name> --source <vm_name>
Criar uma versão de imagem em uma galeria de imagens compar tilhadas

-g $sigResourceGroup
--gallery-name $sigName
--gallery-image-definition $imageDefName
--gallery-image-version 1.0.0
--managed-image /subscriptions/00000000-0000-0000-0000-
00000000xxxx/resourceGroups/imageGroups/providers/images/MyManagedImage
Criando uma VM com base em uma imagem que não contém um agente do Linux
Ao criar a VM a partir da imagem sem nenhum agente Linux, você precisa garantir que a configuração de
implantação da VM indique que as extensões não têm suporte nesta VM.
NOTE
Se você não fizer isso, a plataforma tentará enviar a configuração de extensão e o tempo limite após 40min.
Para implantar a VM com extensões desabilitadas, você pode usar o CLI do Azure com --Enable-Agent.
az vm create \
--resource-group $resourceGroup \
--name $prodVmName \
--image RedHat:RHEL:8.1-ci:latest \
--admin-username azadmin \
--ssh-key-value "$sshPubkeyPath" \
--enable-agent false
Como alternativa, você pode fazer isso usando modelos de Azure Resource Manager (ARM), definindo
"provisionVMAgent": false, .
"osProfile": {
"computerName": "[parameters('virtualMachineName')]",
"disablePasswordAuthentication": "true",
"provisionVMAgent": false,
"ssh": {
"publicKeys": [
{
"keyData": "[parameters('adminPublicKey')]"
Próximas etapas
Para obter mais informações, consulte Provisionando o Linux.
Como criar uma imagem gerenciada de uma
máquina virtual ou um VHD
Para criar várias cópias de uma VM (máquina virtual) para uso no Azure para desenvolvimento e teste, capture
uma imagem gerenciada da VM ou do VHD do sistema operacional. Para criar, armazenar e compartilhar
imagens em escala, confira as Galerias de Imagens Compartilhadas.
Uma imagem gerenciada dá suporte a até 20 implantações simultâneas. A tentativa de criar simultaneamente
mais de 20 VMs a partir da mesma imagem gerenciada pode exceder os tempos limite de provisionamento
devido às limitações de desempenho de armazenamento de um único VHD. Para criar simultaneamente mais de
20 VMs, use uma imagem das Galerias de Imagens Compartilhadas, configurada com uma réplica para cada 20
implantações simultâneas de VM.
Para criar uma imagem gerenciada, você precisará remover informações pessoais da conta. Nas etapas a seguir,
desprovisione uma VM existente, desaloque e crie uma imagem. Você pode usar essa imagem para criar VMs
em qualquer grupo de recursos dentro da sua assinatura.
Para criar uma cópia da VM Linux existente para backup ou depuração ou então carregar um VHD Linux
especializado de uma VM local, consulte Carregar e criar uma VM Linux com base em uma imagem de disco
personalizada.
Você pode usar o serviço de Construtor de Imagens de VM do Azure (Visualização Pública) para criar
sua imagem personalizada, sem necessidade de aprender nenhuma ferramenta ou instalar pipelines de build,
basta apenas fornecer uma configuração da imagem e o Construtor de Imagens a criará. Para saber mais,
consulte Introdução ao Construtor de Imagens de VM do Azure.
Você precisará dos seguintes itens antes de criar uma imagem:
Uma VM do Azure criada no modelo de implantação do Gerenciador de Recursos usando discos
gerenciados. Se você ainda não criou uma VM Linux, você pode usar o portal, da CLI do Azure, ou os
modelos do Gerenciador de Recursos . Configure a VM conforme necessário. Por exemplo, adicionar
discos de dados, aplicar atualizações e instalar aplicativos.
A versão mais recente daCLI do Azure instalada e estar conectado a uma conta do Azure com login az.
Prefere um tutorial?
Para uma versão simplificada deste artigo e para testar, avaliando ou aprendendo sobre VMs no Azure, consulte
Criar uma imagem personalizada de uma VM do Azure usando a CLI. Caso contrário, continue lendo aqui para
obter o panorama completo.
Etapa 1: Desprovisionar a VM
Primeiro, você vai desprovisionar a VM usando o agente de VM do Azure para excluir dados e arquivos
específicos do computador. Use o comando waagent com o -deprovision+user parâmetro em sua VM do Linux
de origem. Para saber mais, confira o Guia do usuário do agente Linux para o Azure.
1. Conecte-se à VM do Linux com um cliente SSH.
2. Na janela SSH, digite o seguinte comando:
sudo waagent -deprovision+user
NOTE
Execute este comando apenas em uma VM que você irá capturar como uma imagem. Esse comando não garante
que a imagem é declarada com relação a todas as informações confidenciais ou está disponível para redistribuição.
O +user parâmetro também remove a última conta de usuário provisionada. Para manter as credenciais de
conta de usuário na VM, use apenas -deprovision .
3. Insira y para continuar. Você pode adicionar o parâmetro -force para evitar esta etapa de confirmação.
4. Depois de concluir o comando, insira sair para fechar o cliente SSH. A VM ainda estará em execução neste
ponto.
Etapa 2: Criar a imagem de VM

Use a CLI do Azure para marcar a VM como generalizada e capturar a imagem. Nos exemplos a seguir, substitua
os nomes de parâmetro de exemplo com seus próprios valores. Os nomes de parâmetro de exemplo incluem
myResourceGroup, myVnet e myVM.
1. Desaloque a VM desprovisionada com az vm deallocate. O exemplo a seguir desaloca a VM chamada
myVM no grupo de recursos chamado myResourceGroup.
az vm deallocate \
--name myVM
Aguarde até que a VM seja completamente desalocada antes de prosseguir. Isso pode demorar alguns
minutos para ser concluído. A VM é desligada durante a desalocação.
2. Marque a VM como generalizada com az vm generalize. O exemplo a seguir marca a VM denominada
myVM no grupo de recursos chamado myResourceGroup como generalizada.
az vm generalize \
--name myVM
Uma VM que foi generalizada não pode mais ser reiniciada.

3. Crie uma imagem do recurso da VM com az image create. O exemplo a seguir cria uma imagem
chamada myImage no grupo de recursos denominado myResourceGroup usando o recurso VM
denominado myVM.
az image create \
--name myImage --source myVM
NOTE
A imagem é criada no mesmo grupo de recursos da VM de origem. Você pode criar VMs em qualquer grupo de
recursos em sua assinatura desde esta imagem. De uma perspectiva de gerenciamento, você poderá criar um
grupo de recursos específicos para seus recursos de máquina virtual e imagens.
Se você quiser armazenar a imagem no armazenamento com resiliência de zona, será necessário criá-la em uma
região que dê suporte para zonas de disponibilidade e inclua o parâmetro --zone-resilient true .
Esse comando retorna JSON que descreve a imagem da VM. Salve essa saída para referência posterior.
Etapa 3: Criar uma VM com base na imagem capturada

Criar uma VM usando a imagem criada com criar vm az. O exemplo a seguir cria uma VM denominada
myVMDeployed da imagem denominada myImage.
az vm create \
--name myVMDeployed \
--image myImage\
Criação da VM em outro grupo de recursos

Com os discos gerenciados, você pode criar VMs de uma imagem em qualquer grupo de recursos em sua
assinatura. Para criar uma máquina virtual em um grupo de recursos diferente do da imagem, especifique a ID
de recurso completa para a imagem. Use az image list para exibir uma lista de imagens. A saída deverá ser
semelhante ao seguinte exemplo:
"id": "/subscriptions/guid/resourceGroups/MYRESOURCEGROUP/providers/Microsoft.Compute/images/myImage",
"name": "myImage",
O exemplo a seguir usa criar vm az para criar uma VM em um grupo de recursos que não seja a imagem de
origem, especificando a ID do recurso de imagem.
az vm create \
--resource-group myOtherResourceGroup \
--name myOtherVMDeployed \
--image "/subscriptions/guid/resourceGroups/MYRESOURCEGROUP/providers/Microsoft.Compute/images/myImage" \
Etapa 4: Verificar a implantação

SSH para a máquina virtual que você criou para verificar a implantação e começar a usar a nova VM. Para se
conectar via SSH, localize o endereço IP ou o FQDN da VM com az vm show.
az vm show \
--name myVMDeployed \
--show-details
Próximas etapas
Para criar, armazenar e compartilhar imagens em escala, confira as Galerias de Imagens Compartilhadas.
Preparar um VHD ou VHDX do Windows para
carregar no Azure
Antes de carregar uma VM (máquina virtual) do Windows do local para o Azure, você deve preparar o disco
rígido virtual (VHD ou VHDX). O Azure dá suporte a VMs de geração 1 e geração 2 que estão no formato de
arquivo VHD e que têm um disco de tamanho fixo. O tamanho máximo permitido para o VHD do sistema
operacional em uma VM de geração 1 é 2 TB.
Você pode converter um arquivo VHDX em VHD, converter um disco de expansão dinâmica em um disco de
tamanho fixo, mas não pode alterar a geração de uma VM. Para obter mais informações, consulte devo criar
uma VM de geração 1 ou 2 no Hyper-V? e suporte para VMs de geração 2 no Azure.
Para obter informações sobre a política de suporte para VMs do Azure, consulte suporte de software de
servidor da Microsoft para VMs do Azure.
NOTE
As instruções neste artigo se aplicam a:
A versão de 64 bits do Windows Server 2008 R2 e sistemas operacionais Windows Server posteriores. Para obter
informações sobre como executar um sistema operacional de 32 bits no Azure, consulte suporte para sistemas
operacionais de 32 bits em VMs do Azure.
Se qualquer ferramenta de recuperação de desastre for usada para migrar a carga de trabalho, como Azure Site
Recovery ou migrações para Azure, esse processo ainda será necessário no sistema operacional convidado para
preparar a imagem antes da migração.
Verificador de Arquivos do Sistema

Executar o utilitário do verificador de arquivos do sistema Windows antes da generalização da imagem do
sistema operacional
O verificador de arquivos do sistema (SFC) é usado para verificar e substituir os arquivos do sistema Windows.
IMPORTANT
Use uma sessão do PowerShell com privilégios elevados para executar os exemplos neste artigo.
Execute o comando SFC:
sfc.exe /scannow
Beginning system scan. This process will take some time.
Beginning verification phase of system scan.

Verification 100% complete.
Windows Resource Protection did not find any integrity violations.
Após a verificação do SFC ser concluída, instale as atualizações do Windows e reinicie o computador.
Definir configurações do Windows para o Azure
NOTE
A plataforma Azure monta um arquivo ISO para o DVD-ROM quando uma VM do Windows é criada a partir de uma
imagem generalizada. Por esse motivo, o DVD-ROM deve ser habilitado no sistema operacional na imagem generalizada.
Se estiver desabilitada, a VM do Windows ficará presa na experiência inicial do uso (OOBE).
1. Remova todas as rotas persistentes estáticas na tabela de roteamento:

Para exibir a tabela de roteamento, execute route.exe print .
Verifique a seção rotas de persistência . Se houver uma rota persistente, use o route.exe delete
comando para removê-la.
2. Remova o proxy de WinHTTP:
netsh.exe winhttp reset proxy
Se a VM precisar trabalhar com um proxy específico, adicione uma exceção de proxy para o endereço IP
do Azure (168.63.129.16) para que a VM possa se conectar ao Azure:
$proxyAddress='<your proxy server>'

$proxyBypassList='<your list of bypasses>;168.63.129.16'
netsh.exe winhttp set proxy $proxyAddress $proxyBypassList
3. Abra o DiskPart:
diskpart.exe
Defina a política SAN de disco como Onlineall :
DISKPART> san policy=onlineall

DISKPART> exit
4. Defina a hora UTC (tempo Universal Coordenado) para o Windows. Além disso, defina o tipo de
inicialização do serviço de tempo do Windows W32Time como automático :
Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\TimeZoneInformation -Name

RealTimeIsUniversal -Value 1 -Type DWord -Force
Set-Service -Name w32time -StartupType Automatic
5. Defina o perfil de energia como alto desempenho:
powercfg.exe /setactive SCHEME_MIN
6. Verifique se as variáveis de ambiente Temp e tmp estão definidas com seus valores padrão:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name

TEMP -Value "%SystemRoot%\TEMP" -Type ExpandString -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name TMP
-Value "%SystemRoot%\TEMP" -Type ExpandString -Force
Verificar os serviços Windows
Verifique se cada um dos seguintes serviços do Windows está definido com o valor padrão do Windows. Esses
serviços são os mínimos que devem ser configurados para garantir a conectividade da VM. Para definir as
configurações de inicialização, execute o seguinte exemplo:
Get-Service -Name BFE, Dhcp, Dnscache, IKEEXT, iphlpsvc, nsi, mpssvc, RemoteRegistry |
Where-Object StartType -ne Automatic |
Set-Service -StartupType Automatic
Get-Service -Name Netlogon, Netman, TermService |

Where-Object StartType -ne Manual |
Set-Service -StartupType Manual
Atualizar configurações do registro da área de trabalho remota

Verifique se as seguintes configurações estão definidas corretamente para acesso remoto:
NOTE
Se você receber uma mensagem de erro durante a execução
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services -Name <string> -
Value <object>
, poderá ignorá-la com segurança. Isso significa que o domínio não está definindo essa configuração por meio de um
objeto Política de Grupo.
1. O protocolo RDP está habilitado:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name

fDenyTSConnections -Value 0 -Type DWord -Force
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' -Name
fDenyTSConnections -Value 0 -Type DWord -Force
2. A porta RDP é configurada corretamente usando a porta padrão de 3389:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp' -

Name PortNumber -Value 3389 -Type DWord -Force
Quando você implanta uma VM, as regras padrão são criadas para a porta 3389. Para alterar o número
da porta, faça isso depois que a VM for implantada no Azure.
3. O ouvinte está escutando em cada interface de rede:

Name LanAdapter -Value 0 -Type DWord -Force
4. Configure o modo NLA (autenticação em nível de rede) para as conexões RDP:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -

Name UserAuthentication -Value 1 -Type DWord -Force
Name SecurityLayer -Value 1 -Type DWord -Force
Name fAllowSecProtocolNegotiation -Value 1 -Type DWord -Force
5. Defina o valor de keep alive:

KeepAliveEnable -Value 1 -Type DWord -Force
KeepAliveInterval -Value 1 -Type DWord -Force
Name KeepAliveTimeout -Value 1 -Type DWord -Force
6. Defina as opções de reconexão:

fDisableAutoReconnect -Value 0 -Type DWord -Force
Name fInheritReconnectSame -Value 1 -Type DWord -Force
Name fReconnectSame -Value 0 -Type DWord -Force
7. Limite o número de conexões simultâneas:

Name MaxInstanceCount -Value 4294967295 -Type DWord -Force
8. Remova todos os certificados autoassinados vinculados ao ouvinte RDP:
if ((Get-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-

Tcp').Property -contains 'SSLCertificateSHA1Hash')
{
Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal
Server\WinStations\RDP-Tcp' -Name SSLCertificateSHA1Hash -Force
}
Esse código garante que você possa se conectar ao implantar a VM. Você também pode examinar essas
configurações depois que a VM for implantada no Azure.
9. Se a VM fizer parte de um domínio, verifique as políticas a seguir para certificar-se de que as
configurações anteriores não sejam revertidas.
GO A L P O L ÍT IC A VA LO R
RDP está habilitado Configuração do Permitir que os usuários se

Computador\Diretivas\Configuraçõe conectem remotamente usando a
s do Windows\Modelos Área de Trabalho Remota
Administrativos\Componentes\Servi
ços de Área de Trabalho
Remota\Host de Sessão da Área de
Trabalho Remota\Conexões
Diretiva de grupo do NLA Configurações\Modelos Exigir autenticação de usuário para

Administrativos\Componentes\Servi acesso remoto usando NLA
ços de Área de Trabalho
Remota\Host de Sessão da Área de
Trabalho Remota\Segurança
Configurações Keep-Alive Configuração do Configurar o intervalo de conexão

Computador\Políticas\Configurações keep-alive
do Windows\Modelos
Administrativos\Componentes do
Windows\ Serviços de Área de
Trabalho Remota\Host da Sessão da
Área de Trabalho Remota\Conexões
Configurações de reconexão Configuração do Reconectar automaticamente

Computador\Políticas\Configurações
do Windows\Modelos
Número limitado de configurações Configuração do Limitar o número de conexões

de conexão Computador\Políticas\Configurações
do Windows\Modelos
Configure as regras do Firewall do Windows

1. Ative o Firewall do Windows nos três perfis (domínio, padrão e público):
Set-NetFirewallProfile -Profile Domain, Public, Private -Enabled True
2. Execute o exemplo a seguir para permitir o WinRM por meio dos três perfis de firewall (domínio, privado
e público) e habilite o serviço remoto do PowerShell:
Enable-PSRemoting -Force
Set-NetFirewallRule -DisplayName 'Windows Remote Management (HTTP-In)' -Enabled True
3. Ative as seguintes regras de firewall para permitir o tráfego RDP:
Set-NetFirewallRule -DisplayGroup 'Remote Desktop' -Enabled True
4. Habilite a regra para compartilhamento de arquivos e impressoras para que a VM possa responder às
solicitações de ping dentro da rede virtual:
Set-NetFirewallRule -DisplayName 'File and Printer Sharing (Echo Request - ICMPv4-In)' -Enabled True
5. Crie uma regra para a rede da plataforma Azure:
New-NetFirewallRule -DisplayName AzurePlatform -Direction Inbound -RemoteAddress 168.63.129.16 -

Profile Any -Action Allow -EdgeTraversalPolicy Allow
New-NetFirewallRule -DisplayName AzurePlatform -Direction Outbound -RemoteAddress 168.63.129.16 -
Profile Any -Action Allow
6. Se a VM fizer parte de um domínio, verifique as seguintes políticas do Azure AD para certificar-se de que
as configurações anteriores não sejam revertidas.
Habilitar os perfis do Firewall do Configuração do Proteger todas as conexões de rede

Windows Computador\Políticas\Configurações
do Windows\Modelos
Administrativos\Rede\Conexão de
Rede\Firewall do Windows\Perfil de
Domínio\Firewall do Windows
Habilitar o RDP Configuração do Permitir exceções de área de

Computador\Políticas\Configurações trabalho remota de entrada
do Windows\Modelos
Configuração do Permitir exceções de área de

Computador\Políticas\Configurações trabalho remota de entrada
do Windows\Modelos
Rede\Firewall do Windows\Perfil
Padrão\ Firewall do Windows
Habilitar o ICMP-V4 Configuração do Permitir exceções do ICMP

do Windows\Modelos
Configuração do Permitir exceções do ICMP

do Windows\Modelos
Rede\Firewall do Windows\Perfil
Padrão\ Firewall do Windows
Verificar a VM
Verifique se a VM está íntegra, segura e RDP acessível:
1. Para verificar se o disco está íntegro e consistente, verifique o disco na próxima reinicialização da VM:
chkdsk.exe /f
Verifique se o relatório mostra um disco limpo e íntegro.

2. Defina as configurações de BCD (Dados de Configuração da Inicialização).
bcdedit.exe /set "{bootmgr}" integrityservices enable
bcdedit.exe /set "{default}" device partition=C:
bcdedit.exe /set "{default}" integrityservices enable
bcdedit.exe /set "{default}" recoveryenabled Off
bcdedit.exe /set "{default}" osdevice partition=C:
bcdedit.exe /set "{default}" bootstatuspolicy IgnoreAllFailures
#Enable Serial Console Feature

bcdedit.exe /set "{bootmgr}" displaybootmenu yes
bcdedit.exe /set "{bootmgr}" timeout 5
bcdedit.exe /set "{bootmgr}" bootems yes
bcdedit.exe /ems "{current}" ON
bcdedit.exe /emssettings EMSPORT:1 EMSBAUDRATE:115200
3. O log de despejo pode ser útil para solucionar problemas de falha do Windows. Habilitar a coleta de log
de despejo:
# Set up the guest OS to collect a kernel dump on an OS crash event

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name CrashDumpEnabled -
Type DWord -Force -Value 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name DumpFile -Type
ExpandString -Force -Value "%SystemRoot%\MEMORY.DMP"
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl' -Name NMICrashDump -Type
DWord -Force -Value 1
# Set up the guest OS to collect user mode dumps on a service crash event
$key = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps'
if ((Test-Path -Path $key) -eq $false) {(New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows\Windows
Error Reporting' -Name LocalDumps)}
New-ItemProperty -Path $key -Name DumpFolder -Type ExpandString -Force -Value 'C:\CrashDumps'
New-ItemProperty -Path $key -Name CrashCount -Type DWord -Force -Value 10
New-ItemProperty -Path $key -Name DumpType -Type DWord -Force -Value 2
Set-Service -Name WerSvc -StartupType Manual
4. Verifique se o repositório do Instrumentação de Gerenciamento do Windows (WMI) é consistente:
winmgmt.exe /verifyrepository
Se o repositório estiver corrompido, consulte WMI: repositório corrompido ou não.

5. Verifique se nenhum outro aplicativo está usando a porta 3389. Esta porta é usada para o serviço de RDP
no Azure. Para ver quais portas são usadas na VM, execute netstat.exe -anob :
netstat.exe -anob
6. Para carregar um VHD do Windows que seja um controlador de domínio:

Siga estas etapas extras para preparar o disco.
Verifique se você conhece a senha do Modo de Restauração dos Serviços de Diretório (DSRM)
caso precise iniciar a VM no DSRM. Para obter mais informações, consulte definir uma senha do
DSRM.
7. Verifique se você conhece a conta de administrador interna e a senha. Talvez você queira redefinir a
senha do administrador local atual e verificar se pode usar essa conta para entrar no Windows por meio
da conexão RDP. Essa permissão de acesso é controlada pelo objeto de Política de Grupo "permitir logon
Serviços de Área de Trabalho Remota". Exibir este objeto no Editor de Política de Grupo Local:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
8. Verifique as seguintes políticas do Azure AD para certificar-se de que não estão bloqueando o acesso
RDP:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
Assignment\Deny access to this computer from the network

Assignment\Deny log on through Remote Desktop Services
9. Verifique a seguinte política do Azure AD para certificar-se de que não está removendo nenhuma das
contas de acesso necessárias:
Assignment\Access this computer from the network
A política deve listar os seguintes grupos:
Administradores
Operadores de cópia
Todos
Usuários
10. Reinicie a VM para certificar-se de que o Windows ainda está íntegro e pode ser acessado por meio da
conexão RDP. Neste ponto, considere a criação de uma VM no servidor local do Hyper-V para garantir
que a VM seja iniciada completamente. Em seguida, teste para certificar-se de que você pode acessar a
VM por meio de RDP.
11. Remova os filtros adicionais de interface do driver de transporte (TDI). Por exemplo, remova o software
que analisa pacotes TCP ou firewalls extras.
12. Desinstale qualquer outro software ou driver de terceiros que esteja relacionado a componentes físicos
ou a qualquer outra tecnologia de virtualização.
Instalar atualizações do Windows
O ideal é que você mantenha o computador atualizado para o nível de patch, se isso não for possível, verifique
se as atualizações a seguir estão instaladas. Para obter as atualizações mais recentes, consulte as páginas do
histórico do Windows Update: Windows 10 e Windows server 2019, Windows 8.1 e Windows Server 2012 R2 e
Windows 7 SP1 e Windows Server 2008 R2 SP1.
W IN DO W W IN DO W W IN DO W
W IN DO W S 10 S 10 S 10
S 7 SP 1, W IN DO W W IN DO W V1607, V1709, V1803,
W IN DO W S 8, S 8. 1, W IN DO W W IN DO W W IN DO W
S SERVER W IN DO W W IN DO W S SERVER W IN DO W S SERVER S SERVER
C OMPON 2008 R2 S SERVER S SERVER 2016 S 10 2016 2016
EN T E B IN Á RIO SP 1 2012 2012 R2 V1607 V1703 V1709 V1803
Armazen disk.sys 6.1.7601. 6.2.9200. 6.3.9600. - - - -

amento 23403 – 17638/6. 18203 –
KB31255 2.9200.2 KB31370
74 1757 – 61
KB31370
61
W IN DO W S 10 S 10 S 10
storport.s 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

ys 23403 – 17188/6. 18573 – 93.1358 63.332
KB31255 2.9200.2 KB40227 –
74 1306 – 26 KB40227
KB30184 15
89
ntfs.sys 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

23403 – 17623/6. 18654 – 93.1198 63.447
KB31255 2.9200.2 KB40227 –
74 1743 – 26 KB40227
KB31212 15
55
Iologmsg. 6.1.7601. 6.2.9200. - - - - -

dll 23403 – 16384 –
KB31255 KB29953
74 87
Classpnp. 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

sys 23403 – 17061/6. 18334 – 93.953 –
KB31255 2.9200.2 KB31726 KB40227
74 1180 – 14 15
KB29953
87
Volsnap.s 6.1.7601. 6.2.9200. 6.3.9600. - 10.0.150 - -

ys 23403 – 17047/6. 18265 – 63.0
KB31255 2.9200.2 KB31453
74 1165 – 84
KB29753
31
partmgr.s 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

ys 23403 – 16681 – 17401 – 93.953 – 63.0
KB31255 KB28771 KB30008 KB40227
74 14 50 15
volmgr.sy 10.0.150 - -
s 63.0
Volmgrx.s 6.1.7601. - - - 10.0.150 - -

ys 23403 – 63.0
KB31255
74
Msiscsi.sy 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

s 23403 – 21006 – 18624 – 93.1066 63.447
KB31255 KB29551 KB40227 –
74 63 26 KB40227
15
W IN DO W S 10 S 10 S 10
Msdsm.sy 6.1.7601. 6.2.9200. 6.3.9600. - - - -

s 23403 – 21474 – 18592 –
KB31255 KB30461 KB40227
74 01 26
Mpio.sys 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

23403 – 21190 – 18616 – 93.1198
KB31255 KB30461 KB40227 –
74 01 26 KB40227
15
vmstorfl.s 6.3.9600. 6.3.9600. 6.3.9600. 10.0.143 10.0.150 10.0.162 -

ys 18907 - 18080 - 18907 - 93.2007 - 63.850 - 99.371 -
KB40726 KB30631 KB40726 KB43454 KB43454 KB43454
50 09 50 18 19 20
Fveapi.dll 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

23311 – 20930 – 18294 – 93.576 –
KB31255 KB29302 KB31726 KB40227
74 44 14 15
Fveapibas 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

e.dll 23403 – 20930 – 17415 – 93.206 –
KB31255 KB29302 KB31726 KB40227
74 44 14 15
Rede netvsc.sys - - - 10.0.143 10.0.150 - -

93.1198 63.250 –
– KB40200
KB40227 01
15
mrxsmb1 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

0.sys 23816 – 22108 – 18603 – 93.479 – 63.483
KB40227 KB40227 KB40227 KB40227
22 24 26 15
mrxsmb2 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

0.sys 23816 – 21548 – 18586 – 93.953 – 63.483
KB40227 KB40227 KB40227 KB40227
22 24 26 15
mrxsmb.s 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

ys 23816 – 22074 – 18586 – 93.953 – 63.0
KB40227 KB40227 KB40227 KB40227
22 24 26 15
tcpip.sys 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

23761 – 22070 – 18478 – 93.1358 63.447
KB40227 KB40227 KB40227 –
22 24 26 KB40227
15
W IN DO W S 10 S 10 S 10
http.sys 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

23403 – 17285 – 18574 – 93.251 – 63.483
KB31255 KB30425 KB40227 KB40227
74 53 26 15
vmswitch. 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

sys 23727 – 22117 – 18654 – 93.1358 63.138
KB40227 KB40227 KB40227 –
19 24 26 KB40227
15
Core ntoskrnl.e 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

xe 23807 – 22170 – 18696 – 93.1358 63.483
KB40227 KB40227 KB40227 –
19 18 26 KB40227
15
Serviços rdpcorets. 6.2.9200. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

da Área dll 21506 – 22104 – 18619 – 93.1198 63.0
de KB40227 KB40227 KB40227 –
Trabalho 19 24 26 KB40227
Remota 15
termsrv.dl 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 10.0.150 - -

l 23403 – 17048 – 17415 – 93.0 – 63.0
KB31255 KB29735 KB30008 KB40227
74 01 50 15
termdd.sy 6.1.7601. - - - - - -
s 23403 –
KB31255
74
win32k.sy 6.1.7601. 6.2.9200. 6.3.9600. 10.0.143 - - -

s 23807 – 22168 – 18698 – 93.594 –
KB40227 KB40227 KB40227 KB40227
19 18 26 15
rdpdd.dll 6.1.7601. - - - - - -
23403 –
KB31255
74
rdpwd.sys 6.1.7601. - - - - - -
23403 –
KB31255
74
Seguranç MS17- KB40122 KB40122 KB40122 KB40126 KB40126 - -

a 010 12 13 13 06 06
W IN DO W S 10 S 10 S 10
KB40122 KB40131 KB40131 - -

16 98 98
KB40122 KB40122 KB40122 KB40134 KB40134 - -

15 14 16 29 29
KB40122 KB40134 KB40134 - -

17 29 29
CVE- KB41037 KB41037 KB41037 KB41037 KB41037 KB41037 KB41037

2018- 18 30 25 23 31 27 21
0886
KB41037 KB41037 KB41037

12 26 15
NOTE
Para evitar uma reinicialização acidental durante o provisionamento da VM, é recomendável garantir que todas as
instalações de Windows Update sejam concluídas e que nenhuma atualização esteja pendente. Uma maneira de fazer isso
é instalar todas as possíveis atualizações do Windows e reinicializar uma vez antes de executar o sysprep.exe comando.
Determinar quando usar o Sysprep

A ferramenta de preparação do sistema ( sysprep.exe ) é um processo que você pode executar para redefinir
uma instalação do Windows. O Sysprep fornece uma experiência "pronta para uso" removendo todos os dados
pessoais e redefinindo vários componentes.
Normalmente, você executa sysprep.exe o para criar um modelo no qual é possível implantar várias outras
VMs que têm uma configuração específica. O modelo é chamado de imagem generalizada.
Para criar apenas uma VM de um disco, você não precisa usar o Sysprep. Em vez disso, você pode criar a VM
com base em uma imagem especializada. Para obter informações sobre como criar uma VM de um disco
especializado, consulte:
Criar uma VM com base em um disco especializado
Criar uma VM com base em um disco VHD
Para criar uma imagem generalizada, você precisa executar o Sysprep. Para obter mais informações, consulte
como usar o Sysprep: uma introdução.
Nem toda função ou aplicativo instalado em um computador baseado no Windows dá suporte a imagens
generalizadas. Antes de usar esse procedimento, verifique se o Sysprep dá suporte à função do computador.
Para obter mais informações, consulte suporte do Sysprep para funções de servidor.
Em particular, o Sysprep exige que as unidades sejam totalmente descriptografadas antes da execução. Se você
habilitou a criptografia em sua VM, desabilite-a antes de executar o Sysprep.
Generalizar um VHD
NOTE
Depois de executar as sysprep.exe etapas a seguir, desative a VM. Não ative-a novamente até criar uma imagem a
partir dela no Azure.
1. Entre na VM Windows.
2. Execute uma sessão do PowerShell como administrador.
3. Exclua o diretório Panther (C:\Windows\Panther).
4. Altere o diretório para %windir%\system32\sysprep . Em seguida, execute sysprep.exe .
5. Na caixa de diálogo ferramenta de preparação do sistema , selecione entrar no OOBE (experiência
inicial do sistema) e verifique se a caixa de seleção generalizar está selecionada.
6. Em Opções de Desligamento , selecione Desligar .

7. Selecione OK .
8. Quando o Sysprep for concluído, desligue a VM. Não use reinicialização para desligar a VM.
Agora o VHD está pronto para ser carregado. Para obter mais informações sobre como criar uma VM de um
disco generalizado, consulte carregar um VHD generalizado e usá-lo para criar uma nova VM no Azure.
NOTE
Não há suporte para um arquivo de unattend.xml personalizado. Embora possamos dar suporte à propriedade
additionalUnattendContent , que fornece apenas suporte limitado para adicionar as opções Microsoft-Windows-Shell-
setup no arquivo unattend.xml que o agente de provisionamento do Azure usa. Você pode usar, por exemplo,
additionalUnattendContent para adicionar FirstLogonCommands e LogonCommands. Para obter mais informações,
consulte AdditionalUnattendContent FirstLogonCommands example.
Converter o disco virtual em um VHD de tamanho fixo

Use um dos métodos nesta seção para converter e redimensionar seu disco virtual para o formato necessário
para o Azure:
1. Faça backup da VM antes de executar o processo de conversão ou redimensionamento de disco virtual.
2. Verifique se o VHD do Windows funciona corretamente no servidor local. Resolva todos os erros na
própria VM antes de tentar convertê-la ou carregá-la no Azure.
3. Converta o disco virtual para o tipo fixo.
4. Redimensione o disco virtual para atender aos requisitos do Azure:
a. Os discos no Azure devem ter um tamanho virtual alinhado a 1 MiB. Se o VHD for uma fração de 1
MiB, você precisará redimensionar o disco para um múltiplo de 1 MiB. Os discos que são frações
de uma MiB causam erros ao criar imagens do VHD carregado. Para verificar o tamanho, você
pode usar o cmdlet Get-VHD do PowerShell para mostrar "tamanho", que deve ser um múltiplo de
1 MIB no Azure e "filesize", que será igual ao "tamanho", mais 512 bytes para o rodapé do VHD.
b. O tamanho máximo permitido para o VHD do sistema operacional com uma VM de geração 1 é
2.048 GiB (2 TiB),
c. O tamanho máximo de um disco de dados é 32.767 GiB (32 TiB).
NOTE
Se você estiver preparando um disco do sistema operacional Windows depois de converter para um disco fixo e
redimensionar, se necessário, crie uma VM que usa o disco. Inicie o e entre na VM e continue com as seções neste
artigo para concluir sua preparação para carregamento.
Se você estiver preparando um disco de dados, poderá parar esta seção e prosseguir com o carregamento do disco.
Usar o Gerenciador do Hyper-V para converter o disco

1. Abra o Gerenciador do Hyper-V e selecione o computador local à esquerda. No menu acima da lista de
computadores, selecione ação > Editar disco .
2. Na página localizar disco rígido vir tual , selecione seu disco virtual.
3. Na página escolher ação , selecione conver ter > Avançar .
4. Para converter do VHDX, selecione VHD > Avançar .
5. Para converter de um disco de expansão dinâmica, selecione tamanho fixo > Avançar .
6. Localize e selecione um caminho para salvar o novo arquivo VHD.
7. Selecione Concluir .
Usar o PowerShell para converter o disco
Você pode converter um disco virtual usando o cmdlet Convert-VHD no PowerShell. Se você precisar de
informações sobre como instalar este cmdlet , consulte instalar a função Hyper-V.
O exemplo a seguir converte o disco de VHDX para VHD. Ele também converte o disco de um disco de expansão
dinâmica em um disco de tamanho fixo.
Convert-VHD -Path C:\test\MyVM.vhdx -DestinationPath C:\test\MyNewVM.vhd -VHDType Fixed
Neste exemplo, substitua o valor de path pelo caminho para o disco rígido virtual que você deseja converter.
Substitua o valor de DestinationPath pelo novo caminho e nome do disco convertido.
Usar o Gerenciador do Hyper-V para redimensionar o disco
1. Abra o Gerenciador do Hyper-V e selecione o computador local à esquerda. No menu acima da lista de
computadores, selecione ação > Editar disco .
2. Na página localizar disco rígido vir tual , selecione seu disco virtual.
3. Na página escolher ação , selecione expandir > Avançar .
4. Na página localizar disco rígido vir tual , insira o novo tamanho em GIB > Avançar .
5. Selecione Concluir .
Usar o PowerShell para redimensionar o disco
Você pode redimensionar um disco virtual usando o cmdlet Resize-VHD no PowerShell. Se você precisar de
informações sobre como instalar este cmdlet , consulte instalar a função Hyper-V.
O exemplo a seguir redimensiona o disco de 100,5 MiB para 101 MiB para atender ao requisito de alinhamento
do Azure.
Resize-VHD -Path C:\test\MyNewVM.vhd -SizeBytes 105906176
Neste exemplo, substitua o valor de path pelo caminho para o disco rígido virtual que você deseja
redimensionar. Substitua o valor de SizeBytes pelo novo tamanho em bytes para o disco.
Converter do formato de disco VMware VMDK
Se você tiver uma imagem de VM do Windows no formato de arquivo VMDK, poderá usar as migrações para
Azure para converter o VMDK e carregá-lo no Azure.
Concluir as configurações recomendadas

As configurações a seguir não afetam o carregamento do VHD. No entanto, é altamente recomendável que você
as configure.
Instale o agente de máquina virtual do Azure. Em seguida, você pode habilitar as extensões de VM. As
extensões de VM implementam a maior parte da funcionalidade crítica que você pode querer usar com
suas VMs. Você precisará das extensões, por exemplo, para redefinir senhas ou configurar o RDP. Para
obter mais informações, consulte a visão geral do agente de máquina virtual do Azure.
Depois de criar a VM no Azure, recomendamos que você coloque o arquivo de paginação no volume da
unidade temporal para melhorar o desempenho. Você pode configurar o posicionamento do arquivo da
seguinte maneira:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' -

Name PagingFiles -Value 'D:\pagefile.sys' -Type MultiString -Force
Se um disco de dados estiver anexado à VM, a letra do volume da unidade temporal normalmente será D.
Essa designação pode ser diferente, dependendo de suas configurações e do número de unidades
disponíveis.
Recomendamos desabilitar os bloqueadores de script que podem ser fornecidos pelo software
antivírus. Eles podem interferir e bloquear os scripts do agente de provisionamento do Windows
executados quando você implanta uma nova VM a partir de sua imagem.
Próximas etapas
Carregar uma imagem de VM Windows no Azure para implantações do Resource Manager
Solucionar problemas de ativação de VM do Windows do Azure
Carregar um VHD generalizado e usá-lo para criar
novas VMs no Azure
Este artigo orienta você a usar o PowerShell para carregar um VHD de uma máquina virtual generalizada no
Microsoft Azure, crie uma imagem do VHD e crie uma nova VM dessa imagem. Você pode carregar um VHD
exportado de uma ferramenta de virtualização local ou de outra nuvem. Usar Discos Gerenciados para a nova
VM simplifica o gerenciamento da VM e fornece maior disponibilidade quando a VM é colocada em um
Para um exemplo de script, consulte Script de exemplo para carregar um VHD no Azure e criar uma nova VM.
Antes de começar
Antes de carregar qualquer VHD no Azure, você deve seguir as etapas em Preparar um VHD ou VHDX do
Windows para carregar no Azure.
Examine Planejar a migração para Discos Gerenciados antes de iniciar a migração para Discos Gerenciados.
Generalize a VM de origem usando o Sysprep

Se você ainda não tiver feito isso, precisará executar Sysprep da VM antes de carregar o VHD no Azure. O
Sysprep remove todas as informações pessoais da conta, entre outros itens, e prepara o computador para ser
utilizado como uma imagem. Para obter detalhes sobre Sysprep, consulte a Visão geral do Sysprep.
Verifique se as funções de servidor em execução no computador são suportadas pelo Sysprep. Para obter mais
informações, consulte Suporte do Sysprep para funções de servidor.
IMPORTANT
Se você planeja executar o Sysprep antes de carregar o VHD no Azure pela primeira vez, verifique se você preparou sua
VM.
1. Entre na máquina virtual Windows.

2. Abra uma janela de prompt de comando como administrador.
3. Exclua o diretório Panther (C:\Windows\Panther).
4. Mude para o diretório para %windir%\system32\sysprep e, em seguida, execute sysprep.exe .
5. Na caixa de diálogo Ferramenta de Preparação do Sistema , selecione Entrar na Configuração
Inicial pelo Usuário do Sistema (OOBE) e verifique se a caixa de seleção Generalizar está ativada.
6. Para Opções de Desligamento , selecione Desligar .
7. Selecione OK .
8. Quando o Sysprep for concluído, desligará a máquina virtual. Não reinicie a VM.
Carregar o VHD
Agora você pode carregar um VHD diretamente em um disco gerenciado. Para obter instruções, confira
Carregar um VHD no Azure usando o Azure PowerShell.
Depois que o VHD for carregado no disco gerenciado, você precisará usar Get-AzDisk para obter o disco
gerenciado.
$disk = Get-AzDisk -ResourceGroupName 'myResourceGroup' -DiskName 'myDiskName'
Criar a imagem
Crie uma imagem gerenciada com base em seu disco gerenciado do sistema operacional generalizado.
Substitua os valores a seguir com suas próprias informações.
Primeiro defina algumas variáveis:
$location = 'East US'

$imageName = 'myImage'
$rgName = 'myResourceGroup'
Crie a imagem usando seu disco gerenciado.
$imageConfig = New-AzImageConfig `
-Location $location
$imageConfig = Set-AzImageOsDisk `
-Image $imageConfig `
-OsState Generalized `
-OsType Windows `
-ManagedDiskId $disk.Id
Crie a imagem.
$image = New-AzImage `
-ImageName $imageName `
-Image $imageConfig
Criar a VM
Agora que tem uma imagem, você pode criar uma ou mais VMs novas por meio da imagem. Este exemplo cria
uma VM denominada myVM a partir de myImage, em myResourceGroup.
New-AzVm `
-Name "myVM" `
-Image $image.Id `
-SecurityGroupName "myNSG" `
-PublicIpAddressName "myPIP" `
-OpenPorts 3389
Próximas etapas
Logue na nova máquina virtual. Para obter mais informações, veja Como se conectar e fazer logon em uma
máquina virtual do Azure executando o Windows.
Criar uma imagem gerenciada de uma VM
generalizada no Azure
Um recurso de imagem gerenciada pode ser criado de uma VM (máquina virtual) generalizada que é
armazenada como um disco gerenciado ou um disco não gerenciado em uma conta de armazenamento. Em
seguida, a imagem pode ser usada para criar várias VMs. Para obter informações de como as imagens
gerenciadas são cobradas, confira Preços do Managed Disks.
Generalizar a VM Windows usando Sysprep

O Sysprep remove todas as informações pessoais e de segurança da conta e prepara a máquina para ser usada
como uma imagem. Para obter informações sobre o Sysprep, confira Visão geral do Sysprep.
Verifique se as funções de servidor em execução no computador são suportadas pelo Sysprep. Para saber mais,
confira Suporte do Sysprep para funções de servidor e Cenários sem suporte.
IMPORTANT
Depois que o Sysprep for executado em uma VM, essa VM será considerada generalizada e não poderá ser reiniciada. O
processo de generalização de uma VM não é reversível. Se você precisar manter o funcionamento da VM original, crie
uma cópia da VM e generalize a cópia.
O Sysprep requer que as unidades sejam totalmente descriptografadas. Se você habilitou a criptografia em sua VM,
desabilite a criptografia antes de executar o Sysprep.
Se você planeja executar o Sysprep antes de carregar o VHD (disco rígido virtual) no Azure pela primeira vez, prepare a
VM.
Para generalizar a VM do Windows, siga estas etapas:

1. Entre na VM do Windows.
2. Abra uma janela de Prompt de comando como administrador.
3. Exclua o diretório Panther (C:\Windows\Panther). Em seguida, altere o diretório
para%WINDIR%\system32\sysprep e, em seguida, execute sysprep.exe .
4. Na caixa de diálogo Ferramenta de Preparação do Sistema , selecione Entrar na OOBE
(configuração inicial pelo usuário) do sistema e marque a caixa de seleção Generalizar .
5. Para Opções de Desligamento , selecione Desligar .
6. Selecione OK .
7. Quando o Sysprep for concluído, ele desligará a VM. Não reinicie a VM.
TIP
Opcional – use DISM para otimizar a imagem e reduzir a primeira hora de inicialização da VM.
Para otimizar a imagem, monte o VHD clicando duas vezes nele no Windows Explorer e, em seguida, execute o DISM com
o parâmetro /optimize-image .
DISM /image:D:\ /optimize-image /boot
No qual D: é o caminho do VHD montado.

A execução de DISM /optimize-image deve ser a última modificação feita no VHD. Se você fizer alterações no VHD
antes da implantação, precisará executar DISM /optimize-image novamente.
Criação de uma imagem gerenciada no portal

1. Acesse o portal do Azure para gerenciar a imagem da VM. Pesquise por Máquinas vir tuais e selecione
essa opção.
2. Selecione a VM na lista.
3. Na página Máquina vir tual da VM, no menu superior, selecione Capturar .
A página Criar imagem será exibida.
4. Para Nome , aceite o nome já preenchido ou insira um nome que você deseje usar para a imagem.
5. Em Grupo de recursos , selecione Criar e insira um nome ou selecione o grupo de recursos a ser
usado.
6. Se você quiser excluir a VM de origem depois que a imagem foi criada, selecione Excluir
automaticamente esta máquina vir tual após criar a imagem .
7. Se você quiser a capacidade de usar a imagem em qualquer zona de disponibilidade, selecione
Habilitado para Resiliência de zona .
8. Selecione Criar para criar a imagem.
Depois que a imagem for criada, você poderá encontrá-la como um recurso de imagem na lista de recursos no
grupo de recursos.
Criar uma imagem de uma VM usando o PowerShell

Criar uma imagem diretamente da VM garante que a imagem inclua todos os discos associados à VM, incluindo
o disco do sistema operacional e os discos de dados. Este exemplo mostra como criar uma imagem gerenciada
de uma VM que usa discos gerenciados.
Antes de iniciar, confira se você tem a versão mais recente do módulo do Azure PowerShell. Para localizar a
versão, execute Get-Module -ListAvailable Az no PowerShell. Se você precisar atualizar, confira Instalar o Azure
PowerShell no Windows com o PowerShellGet. Se você estiver executando o PowerShell localmente, execute
Connect-AzAccount para criar uma conexão com o Azure.
NOTE
Se você quiser armazenar a imagem no armazenamento com redundância de zona, você precisará criá-la em uma região
com suporte para zonas de disponibilidade e incluir o parâmetro -ZoneResilient na configuração da imagem (comando
New-AzImageConfig ).
Para criar uma imagem de VM, siga estas etapas:

1. Defina algumas variáveis.
$vmName = "myVM"
$rgName = "myResourceGroup"
$imageName = "myImage"
2. Verifique se a VM foi desalocada.
Stop-AzVM -ResourceGroupName $rgName -Name $vmName -Force
3. Defina o status da máquina virtual como Generalizado .
Set-AzVm -ResourceGroupName $rgName -Name $vmName -Generalized
4. Obtenha a máquina virtual.
$vm = Get-AzVM -Name $vmName -ResourceGroupName $rgName
5. Crie a configuração de imagem.
$image = New-AzImageConfig -Location $location -SourceVirtualMachineId $vm.Id
6. Crie a imagem.
New-AzImage -Image $image -ImageName $imageName -ResourceGroupName $rgName
Crie uma imagem de um disco gerenciado usando o Powershell

Se você quiser criar uma imagem somente do disco do sistema operacional, especifique a ID do disco
gerenciado como o disco do sistema operacional:
$vmName = "myVM"
2. Obtenha a VM.
$vm = Get-AzVm -Name $vmName -ResourceGroupName $rgName
3. Obtenha a ID do disco gerenciado.
$diskID = $vm.StorageProfile.OsDisk.ManagedDisk.Id
$imageConfig = New-AzImageConfig -Location $location

$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsState Generalized -OsType Windows -
ManagedDiskId $diskID
5. Crie a imagem.
New-AzImage -ImageName $imageName -ResourceGroupName $rgName -Image $imageConfig
Criar uma imagem de um instantâneo usando o PowerShell

Você pode criar uma imagem gerenciada usando um instantâneo de uma VM generalizada seguindo estas
etapas:
$snapshotName = "mySnapshot"
2. Crie o instantâneo.
$snapshot = Get-AzSnapshot -ResourceGroupName $rgName -SnapshotName $snapshotName

$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsState Generalized -OsType Windows -SnapshotId
$snapshot.Id
4. Crie a imagem.
New-AzImage -ImageName $imageName -ResourceGroupName $rgName -Image $imageConfig

Criar uma imagem de uma VM que usa uma conta de
armazenamento
Para criar uma imagem gerenciada de uma VM que não usa discos gerenciados, é necessário o URI do VHD do
sistema operacional na conta de armazenamento, que está no seguinte formato:
https://minhacontadearmazenamento.blob.core.windows.net/contêinervhd/nomedoarquivovhd.vhd. Neste
exemplo, o VHD está em mystorageaccount, em um contêiner denominado vhdcontainer, e o nome do arquivo
do VHD é vhdfilename.vhd.
$vmName = "myVM"
$osVhdUri = "https://mystorageaccount.blob.core.windows.net/vhdcontainer/vhdfilename.vhd"
2. Pare/desaloque a VM.
3. Marque a VM como generalizada.
Set-AzVm -ResourceGroupName $rgName -Name $vmName -Generalized
4. Crie a imagem usando o VHD do sistema operacional generalizado.

$imageConfig = Set-AzImageOsDisk -Image $imageConfig -OsType Windows -OsState Generalized -BlobUri
$osVhdUri
$image = New-AzImage -ImageName $imageName -ResourceGroupName $rgName -Image $imageConfig
Próximas etapas
Criar uma VM de uma imagem gerenciada.
Criar uma VM por meio de uma imagem
gerenciada
Você pode criar várias VMs (máquinas virtuais) de uma imagem de VM gerenciada do Azure usando o
PowerShell ou o portal do Azure. Uma imagem de VM gerenciada contém as informações necessárias para criar
uma VM, incluindo o sistema operacional e os discos de dados. Os VHDs (discos rígidos virtuais) que formam a
imagem, incluindo os discos do sistema operacional e quaisquer discos de dados, são armazenados como
discos gerenciados.
Antes de criar uma VM, será necessário criar uma imagem de VM gerenciada para usar como a imagem de
origem e conceder acesso de leitura na imagem a qualquer usuário que deva ter acesso a ela.
Usar o portal
1. Acesse o portal do Azure para localizar uma imagem gerenciada. Pesquise e selecione Imagens .
2. Selecione a imagem que você deseja usar a partir da lista. A imagem da página Visão geral será aberta.
3. Clique em Criar VM no menu.
4. Insira as informações da máquina virtual. O nome do usuário e a senha inseridos aqui serão usados para
fazer logon na máquina virtual. Quando concluir, selecione OK . Você pode criar a nova VM em um grupo de
recursos existente ou escolher Criar novo para criar um novo grupo de recursos para armazenar a VM.
5. Selecione um tamanho para a VM. Para ver mais tamanhos, selecione Exibir todos os ou altere o filtro Tipo
de disco com supor te .
6. Em Configurações , faça as alterações necessárias e selecione OK .
7. Na página de resumo, você deve ver o nome da sua imagem listado como uma Imagem privada . Selecione
OK para iniciar a implantação da máquina virtual.
Usar o PowerShell
Você pode usar o PowerShell para criar uma VM por meio de uma imagem usando o conjunto de parâmetro
simplificado definido para o novo cmdlet do New-AzVm. A imagem precisa estar no mesmo grupo de recursos
no qual você criará a VM.
O parâmetro simplificado definido para New-AzVm requer apenas que você forneça um nome, um grupo de
recursos e o nome da imagem para criar uma VM de uma imagem. New-AzVm usará o valor do parâmetro -
Name como o nome de todos os recursos que cria automaticamente. Neste exemplo, fornecemos nomes mais
detalhados para cada recurso, mas permitimos ao cmdlet criá-los automaticamente. Você também pode criar
recursos, como a rede virtual, antecipadamente e passar o nome do recurso para o cmdlet. New-AzVm usará os
recursos existentes se puder encontrá-los pelo nome.
O exemplo a seguir cria uma máquina virtual chamada myVMFromImage, no grupo de recursos
myResourceGroup, na imagem chamada myImage.
New-AzVm `
-Name "myVMfromImage" `
-ImageName "myImage" `
-VirtualNetworkName "myImageVnet" `
-SubnetName "myImageSubnet" `
-SecurityGroupName "myImageNSG" `
-PublicIpAddressName "myImagePIP" `
-OpenPorts 3389
Próximas etapas
Criar e gerenciar VMs do Windows com o módulo do Azure PowerShell
Imagens do Visual Studio no Azure
Usar o Visual Studio executando em uma máquina virtual (VM) do Azure pré-configurada é a maneira mais fácil
e rápida de partir do nada para um ambiente de desenvolvimento atualizado. As imagens do sistema com
diferentes configurações do Visual Studio estão disponíveis no Azure Marketplace.
Você é novo no Azure? Crie uma conta gratuita do Azure.
NOTE
Nem todas as assinaturas estão qualificadas para implantar imagens do Windows 10. Para obter mais informações, confira
Usar o cliente Windows no Azure para cenários de desenvolvimento/teste
Quais configurações e versões estão disponíveis?

Imagens para as principais versões mais recentes, Visual Studio 2019 e Visual Studio 2017, Visual Studio 2015,
podem ser encontradas no Microsoft Azure Marketplace. Para cada versão principal, você consulta a versão
originalmente RTW ("lançada para a Web") e as versões atualizadas mais recentes. Cada uma dessas versões
oferece as edições do Visual Studio Enterprise e Visual Studio Community. Essas imagens são atualizadas pelo
menos uma vez por mês para incluir as atualizações mais recentes do Visual Studio e do Windows. Embora os
nomes das imagens permaneçam os mesmos, a descrição de cada imagem inclui a versão do produto instalada
e a data inicial da imagem.
VERSÃ O DE L A N Ç A M EN TO EDIÇ Õ ES VERSÃ O DO P RO DUTO
Visual Studio 2019: mais recente Enterprise, Community 16.8.0 da versão

(versão 16,8)
Visual Studio 2019: RTW Enterprise 16.0.20 da versão
Visual Studio 2017: Mais recente Enterprise, Community 15.9.29 da versão

(versão 15.9)
Visual Studio 2017: RTW Enterprise, Community Versão 15.0.28
Visual Studio 2015: Mais recente Enterprise, Community Versão 14.0.25431.01

(atualização 3)
NOTE
De acordo com a política de atendimento da Microsoft, a versão original (RTW) do Visual Studio 2015 expirou para
manutenção. O Visual Studio 2015 Atualização 3 é a única versão restante oferecida para a linha de produtos Visual
Studio 2015.
Para obter mais informações, consulte a Política de Atendimento do Visual Studio.
Quais recursos são instalados?

Cada imagem contém o conjunto de recursos recomendado para essa edição do Visual Studio. Geralmente, a
instalação inclui:
Todas as cargas de trabalho disponíveis, incluindo cada componente opcional recomendado da carga de
trabalho
.NET 4.6.2 e .NET 4.7 SDKs, Pacotes de Destino, e Ferramentas para Desenvolvedores
Visual F#
Extensão do GitHub para Visual Studio
Ferramentas do LINQ to SQL
A linha de comando usada para instalar o Visual Studio ao compilar as imagens é a seguinte:
vs_enterprise.exe --allWorkloads --includeRecommended --passive ^

add Microsoft.Net.Component.4.7.SDK ^
add Microsoft.Net.Component.4.7.TargetingPack ^
add Microsoft.Net.Component.4.6.2.SDK ^
add Microsoft.Net.Component.4.6.2.TargetingPack ^
add Microsoft.Net.ComponentGroup.4.7.DeveloperTools ^
add Microsoft.VisualStudio.Component.FSharp ^
add Component.GitHub.VisualStudio ^
add Microsoft.VisualStudio.Component.LinqToSql
Se as imagens não incluírem um recurso do Visual Studio que você precise, envie um comentário pela
ferramenta de comentários no canto superior direito da página.
Qual tamanho de VM devo escolher?

O Azure oferece uma gama completa de tamanhos de máquina virtual. Uma vez que o Visual Studio é um
aplicativo multi-thread avançado, você quer um tamanho de VM que inclua pelo menos dois processadores e 7
GB de memória. Estes são os tamanhos de VM recomendados para as imagens do Visual Studio:
Standard_D2_v3
Standard_D2s_v3
Standard_D4_v3
Standard_D4s_v3
Standard_D2_v2
Standard_D2S_v2
Standard_D3_v2
Para obter mais informações sobre os tamanhos das máquinas mais recentes, consulte Tamanhos das máquinas
virtuais do Windows no Azure.
Com o Azure, é possível reequilibrar sua escolha inicial redimensionando a VM. É possível fornecer uma nova
VM com um tamanho mais apropriado ou redimensionar sua VM existente para hardware subjacente diferente.
Para obter mais informações, consulte Redimensionar uma VM do Windows.
Depois que a VM estiver em execução, o que vem a seguir?

O Visual Studio acompanha o modelo "traga sua própria licença" no Azure. De forma semelhante a uma
instalação em hardware proprietário, uma das primeiras etapas é o licenciamento da instalação do Visual Studio.
Para desbloquear o Visual Studio:
Entrar com uma conta da Microsoft associada a uma assinatura do Visual Studio
Desbloquear o Visual Studio com a chave do produto que acompanha a compra inicial
Para obter mais informações, consulte Conectar-se ao Visual Studio e Como desbloquear o Visual Studio.
Como posso salvar a VM de desenvolvimento para uso futuro ou da

equipe?
O espectro de ambientes de desenvolvimento é imenso e há custos reais associados à compilação de ambientes
mais complexos. Independentemente da configuração do seu ambiente, você pode salvar ou capturar sua VM
configurada como uma "imagem base" para uso futuro ou para outros membros da sua equipe. A seguir, ao
inicializar uma nova VM, provisione-a a partir da imagem base e não da imagem do Marketplace do Azure.
Resumo rápido: Utilize a ferramenta de Preparação do Sistema (Sysprep) e desligue a VM em execução, a seguir,
capture (Figura 1) a VM como uma imagem através da Interface do Usuário no portal do Azure. O Azure salva o
arquivo .vhd que contém a imagem, na conta de armazenamento de sua escolha. A nova imagem aparecerá
como um recurso de imagem na lista de recursos da sua assinatura.
(Figura 1) Capturar uma imagem através da interface do usuário do Portal do Azure.

Para obter mais informações, consulte Criar uma imagem gerenciada de uma VM generalizada no Azure.
IMPORTANT
Não se esqueça de usar o Sysprep para preparar a máquina virtual. Se essa etapa for ignorada, o Azure não poderá
fornecer uma VM da imagem.
NOTE
Você ainda tem algum custo para o armazenamento das imagens, mas esse custo incremental pode ser insignificante em
comparação aos custos de despesas gerais para reconstruir a VM a partir do zero para cada membro da equipe que
precise de uma. Por exemplo, há o custo de alguns dólares para criar e armazenar uma imagem de 127 GB por um mês
que é reutilizável por todos os membros de sua equipe. No entanto, esses custos são insignificantes em comparação com
as horas que cada funcionário investe para compilar e validar um desenvolvimento de caixa devidamente configurado
para o uso individual.
Além disso, suas tarefas ou tecnologias de desenvolvimento podem precisar de mais escala, como variedades
de configurações de desenvolvimento e múltiplas configurações de computadores. Você pode usar o Azure
DevTest Labs para criar receitas que automatizam a construção de sua "imagem dourada". Você também pode
usar o DevTest Labs para gerenciar políticas para as VMS em execução da sua equipe. Usar Azure DevTest Labs
para desenvolvedores é a melhor fonte para obter mais informações sobre DevTest Labs.
Próximas etapas
Agora que você conhece as imagens pré-configuradas do Visual Studio, a próxima etapa é criar uma nova VM:
Criar uma VM através do Portal do Azure
Visão geral de Máquinas Virtuais do Windows
Criar uma galeria de imagens compartilhada com o
CLI do Azure


Uma galeria de imagens é o principal recurso usado para habilitar o compartilhamento de imagens.
Caracteres permitidos para o nome da galeria são letras maiúsculas ou minúsculas, dígitos, pontos e pontos
assinatura.
Criar uma galeria de imagens usando az sig create. O exemplo a seguir cria um grupo de recursos da galeria
chamado myGalleryRG no Leste dos EUA, bem como uma galeria chamada myGallery.
az group create --name myGalleryRG --location eastus

az sig create --resource-group myGalleryRG --gallery-name myGallery
Você pode compartilhar imagens entre assinaturas usando o RBAC (Controle de Acesso Baseado em Função).
Você pode compartilhar imagens na Galeria, na definição da imagem ou no nível da versão da imagem.
Qualquer usuário que tenha permissões de leitura para uma versão de imagem, mesmo entre assinaturas,
poderá implantar uma VM usando a versão da imagem.
Recomendamos que você compartilhe com outros usuários no nível da galeria. Para obter a ID do objeto da
galeria, use az sig show.
az sig show \
--query id
Use a ID do objeto como um escopo, juntamente com um endereço de email e az role assignment create para
conceder a um usuário acesso à galeria de imagens compartilhadas. Substitua <email-address> e <gallery iD>
pelas suas informações.
--role "Reader" \
--assignee <email address> \
--scope <gallery ID>
Para obter mais informações de como compartilhar recursos usando o RBAC, confira Gerenciar o acesso usando
a CLI do Azure e RBAC.
Próximas etapas
Crie uma versão de imagem de uma VMou de uma imagem gerenciada usando o CLI do Azure.
Para obter mais informações sobre galerias de imagens compartilhadas, confira a Visão geral. Se você enfrentar
problemas, confira Solução de problemas de galerias de imagens compartilhadas.
Criar uma versão de imagem de uma VM no Azure
usando o CLI do Azure
Se você tiver uma VM existente que deseja usar para criar várias VMs idênticas, poderá usar essa VM para criar
uma imagem em uma galeria de imagens compartilhadas usando o CLI do Azure. Você também pode criar uma
imagem de uma VM usando Azure PowerShell.
Uma versão de imagem é o que você usa para criar uma VM ao usar uma galeria de imagens compartilhada.
Você pode ter diversas versões de uma imagem conforme necessário para seu ambiente. Quando você usa uma
versão de imagem para criar uma VM, a versão da imagem é usada para criar discos para a nova VM. Versões
de imagem podem ser usadas várias vezes.
Antes de começar
Para concluir este artigo, você deve ter uma galeria de imagens compartilhada existente.
Você também deve ter uma VM existente no Azure, na mesma região que a galeria.
Se a VM tiver um disco de dados anexado, o tamanho do disco de dados não poderá ser maior que 1 TB.
Ao trabalhar com este artigo, substitua os nomes de recursos onde necessário.

Você pode ver uma lista das VMs disponíveis usando az vm list.
az vm list --output table
Quando souber o nome da VM e em qual grupo de recursos ela está, obtenha a ID da VM usando az vm get-
instance-view.
az vm get-instance-view -g MyResourceGroup -n MyVm --query id

informações sobre as versões da imagem que são criadas dentro delas.
Verifique se a definição da imagem é do tipo correto. Se tiver generalizado a VM (usando o Sysprep para
Windows ou waagent -deprovision para Linux), você precisará criar uma definição de imagem generalizada
usando --os-state generalized . Se quiser usar a VM sem remover contas de usuário existentes, crie uma
definição de imagem especializada usando --os-state specialized .
do SO Linux. Para criar uma definição para imagens usando um SO Windows, use --os-type Windows .

--offer myOffer \
--sku mySKU \
--os-type Linux \

Crie uma versão da imagem com base na VM usando az image gallery create-image-version.
Neste exemplo, a versão de nossa imagem é 1.0.0 e criaremos duas réplicas na região do Centro-Oeste dos EUA,
uma na região Centro-Sul dos EUA e uma na região Leste dos EUA 2 usando o armazenamento com
redundância de zona. As regiões de replicação precisam incluir a região em que a VM de origem fica localizada.
Substitua o valor de --managed-image neste exemplo pela ID da VM da etapa anterior.

--target-regions "westcentralus" "southcentralus=1" "eastus=1=standard_zrs" \
--replica-count 2 \
ID>/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM"
NOTE
Você também pode armazenar sua imagem no armazenamento Premium adicionando
--storage-account-type premium_lrs ou armazenando o armazenamento com redundância de zona adicionando
Próximas etapas
Crie uma VM a partir da imagem generalizada usando o CLI do Azure.
Para obter informações sobre como fornecer informações do plano de compra, consulte fornecer informações
do plano de compra do Azure Marketplace ao criar imagens.
Criar uma imagem de um disco gerenciado ou
instantâneo em uma galeria de imagens
compartilhada usando o CLI do Azure
Se você tiver um instantâneo ou disco gerenciado existente que deseja migrar para uma galeria de imagens
compartilhada, poderá criar uma imagem da Galeria de imagens compartilhada diretamente do disco
gerenciado ou do instantâneo. Depois de testar a nova imagem, você pode excluir o disco gerenciado de origem
ou o instantâneo. Você também pode criar uma imagem de um disco gerenciado ou instantâneo em uma
galeria de imagens compartilhada usando o Azure PowerShell.
As imagens em uma galeria de imagens têm dois componentes, que serão criados neste exemplo:
Uma definição de imagem contém informações sobre a imagem e os requisitos para usá-la. Isso inclui se
a imagem é Windows ou Linux, especializada ou generalizada, notas de versão e requisitos mínimos e
máximos de memória. É uma definição de um tipo de imagem.
Uma versão de imagem é usada para criar uma VM ao usar uma galeria de imagens compartilhada. Você
pode ter diversas versões de uma imagem conforme necessário para seu ambiente. Quando você cria uma
VM, a versão da imagem é usada para criar novos discos para a VM. Versões de imagem podem ser usadas
várias vezes.
Antes de começar
Para concluir este artigo, você deve ter um instantâneo ou um disco gerenciado.
Se você quiser incluir um disco de dados, o tamanho do disco de dados não poderá ser superior a 1 TB.
Localizar o instantâneo ou o disco gerenciado

Você pode ver uma lista de instantâneos que estão disponíveis em um grupo de recursos usando AZ snapshot
List.
az snapshot list --query "[].[name, id]" -o tsv
Você também pode usar um disco gerenciado em vez de um instantâneo. Para obter um disco gerenciado, use
AZ Disk List.
az disk list --query "[].[name, id]" -o tsv
Depois de ter a ID do instantâneo ou do disco gerenciado e atribuí-lo a uma variável chamada $source a ser
usada posteriormente.
Você pode usar o mesmo processo para obter os discos de dados que deseja incluir na imagem. Atribua-os às
variáveis e, em seguida, use essas variáveis posteriormente ao criar a versão da imagem.
Localizar a Galeria
Você precisará de informações sobre a Galeria de imagens para criar a definição de imagem.
Lista informações sobre as galerias de imagem disponíveis usando AZ SIG List. Observe o nome da galeria a
qual grupo de recursos a galeria está para usar mais tarde.
az sig list -o table

As definições de imagem criam um agrupamento lógico para as imagens. Eles são usados para gerenciar
informações sobre a imagem. Os nomes das definições de imagem podem ser compostos por letras maiúsculas
ou minúsculas, dígitos, pontos, traços e pontos finais.
Ao fazer a definição de imagem, verifique se o tem todas as informações corretas. Neste exemplo, supomos que
o instantâneo ou o disco gerenciado sejam de uma VM em uso e não tenha sido generalizado. Se o disco
gerenciado ou o instantâneo foi tirado de um sistema operacional generalizado (depois de executar o Sysprep
para Windows ou waagent -deprovision ou -deprovision+user Linux), altere o -OsState para generalized .
do SO Linux. Para criar uma definição para imagens usando um SO Windows, use --os-type Windows .
Neste exemplo, a galeria é denominada myGallery, está no grupo de recursos myGalleryRG e o nome da
definição de imagem será mImageDefinition.
resourceGroup=myGalleryRG
gallery=myGallery
imageDef=myImageDefinition
--gallery-name $gallery \
--gallery-image-definition $imageDef \
--offer myOffer \
--sku mySKU \
--os-type Linux \

Crie uma versão de imagem usando AZ Image Gallery Create-Image-Version.
Neste exemplo, a versão da nossa imagem é a 1.0.0 e vamos criar uma réplica na região do Sul EUA Central e
uma réplica na região leste dos EUA 2 usando o armazenamento com redundância de zona. Ao escolher regiões
de destino para replicação, lembre-se de que você também precisa incluir a região de origem do disco
gerenciado ou instantâneo como um destino para replicação.
Passe a ID do instantâneo ou do disco gerenciado no --os-snapshot parâmetro.
--target-regions "southcentralus=1" "eastus2=1=standard_zrs" \
--replica-count 2 \
--os-snapshot $source
Se desejar incluir discos de dados na imagem, você precisará incluir o --data-snapshot-luns parâmetro definido
como o número de LUN e o --data-snapshots conjunto como a ID do disco de dados ou instantâneo.
NOTE
Você também pode armazenar todas as réplicas de versão da imagem no armazenamento com redundância de zona
adicionando --storage-account-type standard_zrs ao criar a versão da imagem.
Próximas etapas
Crie uma VM com base em uma versão de imagem especializada.
Clonar uma imagem gerenciada para uma versão
de imagem usando o CLI do Azure
Se você tiver uma imagem gerenciada existente que deseja clonar em uma galeria de imagens compartilhada,
poderá criar uma imagem da Galeria de imagens compartilhada diretamente da imagem gerenciada. Depois de
testar a nova imagem, você pode excluir a imagem gerenciada de origem. Você também pode migrar de uma
imagem gerenciada para uma galeria de imagens compartilhada usando o PowerShell.
várias vezes.
Antes de começar
Para concluir este artigo, você deve ter uma Galeria de imagens compartilhadaexistente.
Para concluir o exemplo neste artigo, você precisa ter uma imagem gerenciada existente de uma VM
generalizada. Para obter mais informações, consulte capturar uma imagem gerenciada. Se a imagem gerenciada
contiver um disco de dados, o tamanho do disco de dados não poderá ser superior a 1 TB.
Ao trabalhar com este artigo, substitua o grupo de recursos e os nomes de VM quando for necessário.

Como as imagens gerenciadas são sempre imagens generalizadas, você criará uma definição de imagem
usando --os-state generalized para uma imagem generalizada.
Neste exemplo, a definição de imagem é chamada myImageDefinition e é para uma imagem generalizada do
SO Linux. Para criar uma definição para imagens usando um SO Windows, use --os-type Windows .
gallery=myGallery
imageDef=myImageDefinition
--offer myOffer \
--sku mySKU \
--os-type Linux \
--os-state generalized

Crie versões usando AZ Image Gallery Create-Image-Version. Você precisará passar a ID da imagem gerenciada
para usar como uma linha de base para criar a versão da imagem. Você pode usar AZ Image List para obter as
IDs para suas imagens.
az image list --query "[].[name, id]" -o tsv
uma réplica na região leste dos EUA 2 usando o armazenamento com redundância de zona. Ao escolher regiões
de destino para replicação, lembre-se de que você também precisa incluir a região de origem como um destino
para replicação.
Passe a ID da imagem gerenciada no --managed-image parâmetro.
imageID="/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/images/myImage"
--target-regions "southcentralus=1" "eastus2=1=standard_zrs" \
--replica-count 2 \
--managed-image $imageID
NOTE
Você também pode armazenar todas as réplicas de versão da imagem no armazenamento com redundância de zona
adicionando --storage-account-type standard_zrs ao criar a versão da imagem.
Próximas etapas
Crie uma VM com base em uma versão de imagem generalizada.
Copiar uma imagem de outra galeria usando o CLI
do Azure
Se você tiver várias galerias em sua organização, também poderá criar versões de imagem de versões de
imagem existentes armazenadas em outras galerias. Por exemplo, você pode ter uma galeria de
desenvolvimento e teste para criar e testar novas imagens. Quando eles estiverem prontos para serem usados
na produção, você poderá copiá-los para uma galeria de produção usando este exemplo. Você também pode
criar uma imagem de uma imagem em outra galeria usando Azure PowerShell.
Antes de começar
Para concluir este artigo, você deve ter uma galeria de origem, uma definição de imagem e uma versão de
imagem existentes. Você também deve ter uma galeria de destino.
A versão da imagem de origem deve ser replicada para a região onde a Galeria de destino está localizada.
Obter informações da Galeria de origem

Você precisará de informações da definição da imagem de origem para poder criar uma cópia dela em sua nova
galeria.
Liste as informações sobre as galerias de imagens disponíveis usando AZ SIG List para encontrar informações
sobre a Galeria de origem.
Liste as definições de imagem em uma galeria usando AZ SIG Image-Definition List. Neste exemplo, estamos
procurando definições de imagem na galeria chamada myGallery no grupo de recursos myGalleryRG .
az sig image-definition list \

-o table
Liste as versões de uma imagem em uma galeria, usando AZ SIG Image-Version List para localizar a versão da
imagem que você deseja copiar em sua nova galeria. Neste exemplo, estamos procurando todas as versões de
imagem que fazem parte da definição de imagem myImageDefinition .
az sig image-version list \

-o table
Depois de ter todas as informações necessárias, você pode obter a ID da versão da imagem de origem usando
AZ SIG Image-Version show.
az sig image-version show \
--query "id" -o tsv
Criar a definição de imagem

Você precisa criar uma definição de imagem que corresponda à definição de imagem da sua versão de imagem
de origem. Você pode ver todas as informações necessárias para recriar a definição de imagem em sua nova
galeria usando AZ SIG Image-Definition show.
az sig image-definition show \

--gallery-image-definition myImageDefinition
{
"disallowed": null,
"endOfLifeDate": null,
"eula": null,
"hyperVgeneration": "V1",
"id": "/subscriptions/1111abcd-1a23-4b45-67g7-
1234567de123/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefini
tion",
"identifier": {
"offer": "myOffer",
"publisher": "myPublisher",
"sku": "mySKU"
},
"name": "myImageDefinition",
"osState": "Specialized",
"osType": "Linux",
"privacyStatementUri": null,
"purchasePlan": null,
"recommended": null,
"releaseNoteUri": null,
"resourceGroup": "myGalleryRG",
"tags": null,
"type": "Microsoft.Compute/galleries/images"
}
Crie uma nova definição de imagem, em sua nova galeria, usando as informações da saída acima.
--resource-group myNewGalleryRG \
--gallery-name myNewGallery \
--offer myOffer \
--sku mySKU \
--os-type Linux \
--hyper-v-generation V1 \

Crie versões usando AZ Image Gallery Create-Image-Version. Você precisará passar a ID da imagem gerenciada
para usar como uma linha de base para criar a versão da imagem. Você pode usar az image list para obter
informações sobre as imagens que estão em um grupo de recursos.
uma réplica na região leste dos EUA usando o armazenamento com redundância de zona.

--resource-group myNewGalleryRG \
--gallery-name myNewGallery \
--target-regions "southcentralus=1" "eastus=1=standard_zrs" \
--replica-count 2 \
ID>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition/vers
ions/1.0.0"
NOTE
--storage-account-type premium_lrs ou armazenando o armazenamento com redundância de zona adicionando
Próximas etapas
Crie uma VM com base em uma versão de imagem generalizada ou especializada .
Além disso, experimente o Construtor de imagens do Azure (versão prévia) pode ajudar a automatizar a criação
da versão da imagem, até mesmo usá-la para atualizar e criar uma nova versão da imagem a partir de uma
versão de imagem existente.
Criar uma VM com base em uma versão de
imagem generalizada usando a CLI
Crie uma VM com base em uma versão de imagem generalizada armazenada em uma galeria de imagens
compartilhada. Se você quiser criar uma VM usando uma imagem especializada, consulte criar uma VM com
base em uma imagem especializada.
Obter a ID da imagem
Liste as definições de imagem em uma galeria usando AZ SIG Image-Definition List para ver o nome e a ID das
definições.
gallery=myGallery
az sig image-definition list --resource-group $resourceGroup --gallery-name $gallery --query "[].[name, id]"
--output tsv
Criar a VM
Crie uma VM usando az vm create. Para usar a versão mais recente da imagem, defina --image como a ID da
definição da imagem.
imgDef="/subscriptions/<subscription ID where the gallery is

located>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition
"
vmResourceGroup=myResourceGroup
location=eastus
vmName=myVM
adminUsername=azureuser
az group create --name $vmResourceGroup --location $location
az vm create\
--resource-group $vmResourceGroup \
--name $vmName \
--image $imgDef \
--admin-username $adminUsername \
--generate-ssh-keys
Você também pode usar uma versão específica usando a ID da versão da imagem para o --image parâmetro.
Por exemplo, para usar a versão de imagem 1.0.0 Type:
--image "/subscriptions/<subscription ID where the gallery is
located>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition/versions/1.0.0"
.
Próximas etapas
O Construtor de imagens do Azure (visualização) pode ajudar a automatizar a criação da versão da imagem, até
mesmo usá-la para atualizar e criar uma nova versão da imagem a partir de uma versão de imagem existente.
Criar uma VM usando uma versão de imagem
especializada com o CLI do Azure
Crie uma VM com base em uma versão de imagem especializada armazenada em uma galeria de imagens
compartilhada. Se desejar criar uma VM usando uma versão de imagem generalizada, consulte criar uma VM
com base em uma versão de imagem generalizada.
Liste as definições de imagem em uma galeria usando AZ SIG Image-Definition List para ver o nome e a ID das
definições.
gallery=myGallery
az sig image-definition list \
--query "[].[name, id]" \
--output tsv
Crie a VM usando az vm create e o parâmetro --specialized para indicar que se trata de uma imagem
especializada.
Use a ID de definição de imagem de --image para criar a VM com base na versão mais recente da imagem que
está disponível. Você também pode criar a VM com base em uma versão específica fornecendo a ID de versão
da imagem de --image .
Neste exemplo, estamos criando uma VM com base na versão mais recente da imagem myImageDefinition.

--name myVM \
--image "/subscriptions/<Subscription
ID>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition" \
--specialized
Próximas etapas
Você também pode criar um recurso de Galeria de imagens compartilhadas usando modelos. Há vários
Modelos de Início Rápido do Azure disponíveis:
Criar uma Definição de Imagem em uma Galeria de Imagens Compartilhadas
Criar uma Versão da Imagem em uma Galeria de Imagens Compartilhadas
Criar uma VM por meio de uma Versão da Imagem
Listar, atualizar e excluir recursos de imagem
Você pode gerenciar seus recursos da Galeria de imagens compartilhadas usando o CLI do Azure.
Listar informações
Obtenha informações de local, status e outras sobre as galerias de imagens disponíveis usando az sig list.
Liste as definições de imagem em uma galeria, incluindo informações sobre o tipo e o status do sistema
operacional, usando az sig image-definition list.
az sig image-definition list --resource-group myGalleryRG --gallery-name myGallery -o table
Liste as versões da imagem compartilhada em uma galeria usando az sig image-version list.
az sig image-version list --resource-group myGalleryRG --gallery-name myGallery --gallery-image-definition

myImageDefinition -o table
Obtenha a ID de uma versão de imagem usando az sig image-version show.
az sig image-version show \

--query "id"
Atualizar recursos
Há algumas limitações sobre o que pode ser atualizado. Os seguintes itens podem ser atualizados:
Galeria de imagens compartilhadas:
Descrição
definição da imagem:
vCPUs recomendadas
Memória recomendada
Descrição
Data de fim da vida útil
Versão da imagem:
Contagem de réplicas regionais
Regiões de destino
Exclusão da mais recente
Se você planeja adicionar regiões de réplica, não exclua a imagem gerenciada de origem. A imagem gerenciada
de origem é necessária para replicar a versão da imagem para regiões adicionais.
Atualize a descrição de uma galeria usando o (AZ SIG Update.
az sig update \
--set description="My updated description."
Atualize a descrição de uma definição de imagem usando AZ SIG Image-Definition Update.
az sig image-definition update \

--gallery-name myGallery\
--set description="My updated description."
Atualize uma versão de imagem para adicionar uma região a ser replicada usando AZ SIG Image-Version
Update. Essa alteração levará algum tempo, pois a imagem será replicada para a nova região.
az sig image-version update \

--add publishingProfile.targetRegions name=eastus
Este exemplo mostra como usar AZ SIG Image-Version Update para excluir essa versão da imagem de ser usada
como a imagem mais recente .

--set publishingProfile.excludeFromLatest=true
Este exemplo mostra como usar AZ SIG Image-Version Update para incluir essa versão de imagem em ser
considerada para a imagem mais recente .

--set publishingProfile.excludeFromLatest=false
Excluir recursos
Você precisa excluir os recursos na ordem inversa, excluindo a versão da imagem primeiro. Após excluir todas
as versões da imagem, você poderá excluir a definição da imagem. Após excluir todas as definições da imagem,
você poderá excluir a galeria.
Exclua uma versão de imagem usando AZ SIG Image-Version Delete.
az sig image-version delete \

--gallery-image-version 1.0.0
Exclua uma definição de imagem usando AZ SIG Image-Definition Delete.
az sig image-definition delete \

--gallery-image-definition myImageDefinition
Exclua uma galeria de imagens usando AZ SIG Delete.
az sig delete \
--gallery-name myGallery
Próximas etapas
Compartilhar imagens de VM da galeria em
locatários do Azure usando o CLI do Azure
As galerias de imagens compartilhadas permitem compartilhar imagens usando o RBAC do Azure. Você pode
usar o RBAC do Azure para compartilhar imagens dentro de seu locatário e até mesmo para indivíduos fora do
seu locatário. Para obter mais informações sobre essa opção de compartilhamento simples, consulte
compartilhar a Galeria.
Mas, se você quiser compartilhar imagens fora do seu locatário do Azure, em escala, você deve criar um registro
de aplicativo para facilitar o compartilhamento. O uso de um registro de aplicativo pode permitir cenários de
compartilhamento mais complexos, como:
Gerenciamento de imagens compartilhadas quando uma empresa adquire outra, e a infraestrutura do Azure
é distribuída entre locatários separados.
Os parceiros do Azure gerenciam a infraestrutura do Azure em nome de seus clientes. A personalização de
imagens é feita dentro do locatário de parceiros, mas as implantações de infraestrutura ocorrerão no
locatário do cliente.
Criar o registro do aplicativo

Crie um registro de aplicativo que será usado por ambos os locatários para compartilhar os recursos da Galeria
de imagens.
1. Abra o registros de aplicativo (visualização) no portal do Azure.
2. Selecione novo registro no menu na parte superior da página.
3. Em nome , digite myGalleryApp.
4. Em tipos de conta com supor te , selecione contas em qualquer diretório organizacional e contas
pessoais da Microsoft .
5. Em URI de redirecionamento , digite https://www.microsoft.com e, em seguida, selecione registrar .
Depois que o registro do aplicativo tiver sido criado, a página Visão geral será aberta.
6. Na página Visão geral, copie a ID do aplicativo (cliente) e salve-a para uso posterior.
7. Selecione cer tificados & segredos e, em seguida, selecione novo segredo do cliente .
8. Em Descrição , digite segredo do aplicativo entre locatário da Galeria de imagens compartilhadas.
9. Em expira , deixe o padrão de em 1 ano e, em seguida, selecione Adicionar .
10. Copie o valor do segredo e salve-o em um local seguro. Você não pode recuperá-lo depois de sair da página.
Conceda à permissão de registro do aplicativo para usar a Galeria de imagens compartilhadas.
1. Na portal do Azure, selecione a Galeria de imagens compartilhada que você deseja compartilhar com outro
locatário.
2. Selecione selecionar controle de acesso (iam) e, em Adicionar atribuição de função , selecione
Adicionar.
3. Em função , selecione leitor .
4. Em atribuir acesso a:, deixe isso como usuário, grupo ou entidade de ser viço do Azure ad .
5. Em selecionar , digite myGalleryApp e selecione-o quando ele aparecer na lista. Quando terminar, selecione
Salvar .
Dar acesso ao locatário 2
Conceda acesso de locatário 2 ao aplicativo solicitando uma entrada usando um navegador. Substitua <Tenant2
ID> pela ID de locatário do locatário com o qual você gostaria de compartilhar sua galeria de imagens.
Substitua <Application (client) ID> pela ID do aplicativo do registro do aplicativo que você criou. Quando
terminar de fazer as substituições, Cole a URL em um navegador e siga os prompts de entrada para entrar no
locatário 2.
https://login.microsoftonline.com/<Tenant 2 ID>/oauth2/authorize?client_id=<Application (client)

ID>&response_type=code&redirect_uri=https%3A%2F%2Fwww.microsoft.com%2F
No portal do Azure entre como locatário 2 e conceda ao registro do aplicativo acesso ao grupo de recursos no
qual você deseja criar a VM.
1. Selecione o grupo de recursos e, em seguida, selecione iam (controle de acesso) . Em Adicionar
atribuição de função , selecione Adicionar .
2. Em função , digite colaborador .
4. Em selecionar tipo myGalleryApp , em seguida, selecione-o quando aparecer na lista. Quando terminar,
selecione Salvar .
NOTE
IMPORTANT
Você não pode usar o portal para implantar uma VM de uma imagem em outro locatário do Azure. Para criar uma VM de
uma imagem compartilhada entre locatários, você deve usar o CLI do Azure ou o PowerShell.
Criar uma VM usando CLI do Azure

Conecte a entidade de serviço para o locatário 1 usando a appID, a chave do aplicativo e a ID do locatário 1.
Você pode usar az account show --query "tenantId" para obter as IDs de locatário, se necessário.
az account clear
az login --service-principal -u '<app ID>' -p '<Secret>' --tenant '<tenant 1 ID>'
az account get-access-token
Conecte a entidade de serviço para o locatário 2 usando a appID, a chave do aplicativo e a ID do locatário 2:
az login --service-principal -u '<app ID>' -p '<Secret>' --tenant '<tenant 2 ID>'

Crie a VM. Substitua as informações no exemplo pelo seu próprio.

az vm create \
--name myVM \
--image "/subscriptions/<Tenant 1 subscription>/resourceGroups/<Resource
group>/providers/Microsoft.Compute/galleries/<Gallery>/images/<Image definition>/versions/<version>" \
--generate-ssh-keys
Próximas etapas
Se você tiver algum problema, você poderá solucionar problemas de galerias de imagens compartilhadas.
locatários do Azure usando o PowerShell

de imagens.
locatário.
Adicionar.
Salvar .
locatário 2.

selecione Salvar .
NOTE
IMPORTANT
Criar uma VM usando o PowerShell

Faça logon em ambos os locatários usando a ID do aplicativo, o segredo e a ID do locatário.
$applicationId = '<App ID>'

$secret = <Secret> | ConvertTo-SecureString -AsPlainText -Force
$tenant1 = "<Tenant 1 ID>"
$cred = New-Object -TypeName PSCredential -ArgumentList $applicationId, $secret
Clear-AzContext
Connect-AzAccount -ServicePrincipal -Credential $cred -Tenant "<Tenant 1 ID>"
Crie a VM no grupo de recursos que tem permissão no registro do aplicativo. Substitua as informações neste
exemplo pelo seu próprio.
$vmName = "myVMfromImage"
# Set a variable for the image version in Tenant 1 using the full image ID of the shared image version
$image = "/subscriptions/<Tenant 1 subscription>/resourceGroups/<Resource
group>/providers/Microsoft.Compute/galleries/<Gallery>/images/<Image definition>/versions/<version>"
# Create user object


# Networking pieces
# Create a virtual machine configuration using the $image variable to specify the shared image
Set-AzVMSourceImage -Id $image | `

Próximas etapas
Você também pode criar recursos da Galeria de imagens compartilhadas usando o portal do Azure.
Criar uma galeria de imagem compartilhada com o
Azure PowerShell

personalizadas podem ser usadas para inicializar tarefas de implantação, como pré-carregamento de aplicativos,
A galeria de imagens compartilhadas permite compartilhar suas imagens da VM personalizadas com outras
pessoas em sua organização, dentro ou entre regiões, em um locatário do AAD. Escolha quais imagens você
deseja compartilhar, em quais regiões deseja torná-las disponíveis e com quem deseja compartilhá-las. Você
pode criar várias galerias, de modo que pode agrupar logicamente as imagens compartilhadas.
A galeria é um recurso de nível superior que fornece controle de acesso baseado em função do Azure (RBAC do
Azure) completo. As imagens podem ser atualizadas, e você pode optar por replicar cada versão da imagem
para um conjunto diferente de regiões do Azure. A galeria funciona apenas com imagens gerenciadas.
O recurso Galeria de Imagens Compartilhadas tem vários tipos de recursos.
imagens.


imagem.


Uma galeria de imagens é o principal recurso usado para habilitar o compartilhamento de imagens. Caracteres
permitidos para o nome da galeria são letras maiúsculas ou minúsculas, dígitos, pontos e pontos finais. O nome
da galeria não pode conter traços. Os nomes das galerias devem ser exclusivos dentro de sua assinatura.
Crie uma galeria de imagens usando New-AzGallery. O exemplo a seguir cria uma galeria chamada myGallery
no grupo de recursos myGalleryRG.
$resourceGroup = New-AzResourceGroup `
-Name 'myGalleryRG' `
-Location 'West Central US'
$gallery = New-AzGallery `
-GalleryName 'myGallery' `
-Description 'Shared Image Gallery for my organization'
Recomendamos que você compartilhe o acesso no nível da galeria de imagens. Use um endereço de email e o
cmdlet Get-AzADUser para obter a ID do objeto do usuário e, em seguida, use New-AzRoleAssignment para
conceder a ele acesso à galeria. Substitua o email de exemplo, alinne_montes@contoso.com neste exemplo, por
suas informações.
# Get the object ID for the user

$user = Get-AzADUser -StartsWith alinne_montes@contoso.com
# Grant access to the user for our gallery
New-AzRoleAssignment `
-ObjectId $user.Id `
-RoleDefinitionName Reader `
-ResourceName $gallery.Name `
-ResourceType Microsoft.Compute/galleries `
-ResourceGroupName $resourceGroup.ResourceGroupName
Próximas etapas
Crie uma imagem de uma VM, de uma imagem gerenciadaou de uma imagem em outra galeria.
Criar uma imagem de uma VM
Se você tiver uma VM existente que deseja usar para criar várias VMs idênticas, poderá usar essa VM para criar
uma imagem em uma galeria de imagens compartilhadas usando Azure PowerShell. Você também pode criar
uma imagem de uma VM usando o CLI do Azure.
Você pode capturar uma imagem de VMs especializadas e generalizadas usando Azure PowerShell.
várias vezes.
Antes de começar
Para concluir este artigo, você deve ter uma galeria de imagens compartilhada existente e uma VM existente no
Azure para usar como a origem.
Se a VM tiver um disco de dados anexado, o tamanho do disco de dados não poderá ser maior que 1 TB.
Obter a Galeria
Você pode listar todas as galerias e definições de imagem por nome. Os resultados estão no formato
gallery\image definition\image version .
Get-AzResource -ResourceType Microsoft.Compute/galleries | Format-Table
Depois de encontrar a Galeria correta e as definições de imagem, crie variáveis para que elas sejam usadas mais
tarde. Este exemplo obtém a galeria chamada myGallery no grupo de recursos MyResource Group.
$gallery = Get-AzGallery `
-Name myGallery `
Obter a VM
Você pode ver uma lista das VMss que estão disponíveis em um grupo de recursos usando Get-AzVM. Depois
de saber o nome da VM e em qual grupo de recursos ele está, você pode usar Get-AzVM novamente para obter
o objeto da VM e armazená-lo em uma variável para uso posterior. Este exemplo obtém uma VM chamada
sourceVM do grupo de recursos "MyResource Group" e a atribui à variável $sourceVm.
$sourceVm = Get-AzVM `
-Name sourceVM `
É uma prática recomendada stop\deallocate a VM antes de criar uma imagem usando Stop-AzVM.
Stop-AzVM `
-ResourceGroupName $sourceVm.ResourceGroupName `
-Name $sourceVm.Name `
-Force

Ao fazer a definição de imagem, verifique se o tem todas as informações corretas. Se você generaliza a VM
(usando Sysprep para Windows ou waagent-deprovision para Linux), você deve criar uma definição de imagem
usando -OsState generalized . Se você não tiver generalizado a VM, crie uma definição de imagem usando
-OsState specialized .
Crie a definição de imagem usando New-AzGalleryImageDefinition.
Neste exemplo, a definição de imagem é chamada myImageDefinition e é para uma VM especializada que
executa o Windows. Para criar uma definição para imagens usando o Linux, use -OsType Linux .
$imageDefinition = New-AzGalleryImageDefinition `
-ResourceGroupName $gallery.ResourceGroupName `
-OsType Windows `
-Offer 'myOffer' `
-Sku 'mySKU'

Crie uma versão de imagem usando New-AzGalleryImageVersion.
Neste exemplo, a versão da imagem é 1.0.0 e ela é replicado para os datacenters Centro-Oeste dos EUA e
Centro-Sul dos EUA. Ao escolher regiões de destino para replicação, lembre-se de que você também precisa
incluir a região de origem como um destino para replicação.
Para criar uma versão da imagem da VM, use $vm.Id.ToString() para o -SourceImageId .
$region2 = @{Name='East US';ReplicaCount=2}
$job = $imageVersion = New-AzGalleryImageVersion `

-GalleryImageDefinitionName $imageDefinition.Name`
-SourceImageId $sourceVm.Id.ToString() `
-PublishingProfileEndOfLifeDate '2020-12-01' `
-asJob
Pode levar um tempo para replicar a imagem para todas as regiões de destino, portanto, criamos um trabalho
para podermos acompanhar o progresso. Para ver o andamento do trabalho, digite $job.State .
$job.State
NOTE
-StorageAccountType Premium_LRS ou armazenando o armazenamento com redundância de zona adicionando
-StorageAccountType Standard_ZRS ao criar a versão da imagem.
Próximas etapas
Depois de verificar se a nova versão da imagem está funcionando corretamente, você pode criar uma VM. Crie
uma VM com base em uma versão de imagem especializada ou em uma versão de imagem generalizada.
Criar uma imagem de um disco gerenciado ou
instantâneo em uma galeria de imagens
compartilhada usando o PowerShell
Se você tiver um instantâneo ou disco gerenciado existente que deseja migrar para uma galeria de imagens
compartilhada, poderá criar uma imagem da Galeria de imagens compartilhada diretamente do disco
gerenciado ou do instantâneo. Depois de testar a nova imagem, você pode excluir o disco gerenciado de origem
ou o instantâneo. Você também pode criar uma imagem de um disco gerenciado ou instantâneo em uma
galeria de imagens compartilhada usando o CLI do Azure.
várias vezes.
Antes de começar
Para concluir este artigo, você deve ter um instantâneo ou um disco gerenciado.
Se você quiser incluir um disco de dados, o tamanho do disco de dados não poderá ser superior a 1 TB.
Obter o instantâneo ou o disco gerenciado

Você pode ver uma lista de instantâneos que estão disponíveis em um grupo de recursos usando Get-
AzSnapshot.
get-azsnapshot | Format-Table -Property Name,ResourceGroupName
Depois de saber o nome do instantâneo e em qual grupo de recursos ele está, você pode usar Get-AzSnapshot
novamente para obter o objeto de instantâneo e armazená-lo em uma variável para uso posterior. Este exemplo
obtém um instantâneo chamado mysnapshot do grupo de recursos "MyResource Group" e o atribui à variável
$Source.
$source = Get-AzSnapshot `
-SnapshotName mySnapshot `
Você também pode usar um disco gerenciado em vez de um instantâneo. Para obter um disco gerenciado, use
Get-AzDisk.
Get-AzDisk | Format-Table -Property Name,ResourceGroupName
Em seguida, obtenha o disco gerenciado e atribua-o à $source variável.
$source = Get-AzDisk `
-Name myDisk
Você pode usar os mesmos cmdlets para obter os discos de dados que deseja incluir na imagem. Atribua-os às
variáveis e, em seguida, use essas variáveis posteriormente ao criar a versão da imagem.
Obter a Galeria
Depois de encontrar a Galeria correta, crie uma variável para usar mais tarde. Este exemplo obtém a galeria
chamada myGallery no grupo de recursos MyResource Group.
-Name myGallery `

Ao fazer a definição de imagem, verifique se o tem todas as informações corretas. Neste exemplo, supomos que
o instantâneo ou o disco gerenciado sejam de uma VM em uso e não tenha sido generalizado. Se o disco
gerenciado ou o instantâneo foi tirado de um sistema operacional generalizado (depois de executar o Sysprep
para Windows ou waagent -deprovision ou -deprovision+user Linux), altere o -OsState para generalized .
Crie a definição de imagem usando New-AzGalleryImageDefinition. Neste exemplo, a definição de imagem é
chamada myImageDefinition e é para um sistema operacional Windows especializado. Para criar uma definição
para imagens usando um sistema operacional Linux, use -OsType Linux .
-OsType Windows `
-Offer 'myOffer' `
-Sku 'mySKU'
Informações do plano de compra
Em alguns casos, você precisa passar informações do plano de compra no ao criar uma VM de uma imagem
baseada em uma imagem do Azure Marketplace. Nesses casos, recomendamos que você inclua as informações
do plano de compra na definição da imagem. Nesse caso, consulte fornecer informações do plano de compra do
Azure Marketplace ao criar imagens.

Crie uma versão de imagem a partir do instantâneo usando New-AzGalleryImageVersion.
Se você quiser que sua imagem contenha um disco de dados, além do disco do sistema operacional, adicione o
-DataDiskImage parâmetro e defina-o como a ID do instantâneo do disco de dados ou do disco gerenciado.

$region2 = @{Name='West Central US';ReplicaCount=2}
-GalleryImageDefinitionName $imageDefinition.Name `
-OSDiskImage @{Source = @{Id=$source.Id}; HostCaching = "ReadOnly" } `
-asJob
$job.State
NOTE
Você precisa aguardar que a versão da imagem termine completamente de ser compilada e replicada antes de poder usar
o mesmo instantâneo para criar outra versão de imagem.
Você também pode armazenar a versão da imagem no armazenamento com redundância de zona adicionando
Excluir a origem
Depois de verificar se a nova versão da imagem está funcionando corretamente, você pode excluir a origem da
imagem com Remove-AzSnapshot ou Remove-AzDisk.
Próximas etapas
Depois de verificar que a replicação foi concluída, você pode criar uma VM com base na imagem especializada.
Clonar uma imagem gerenciada para uma imagem
da Galeria de imagens compartilhadas
Se você tiver uma imagem gerenciada existente que deseja clonar e mover para uma galeria de imagens
compartilhada, poderá criar uma imagem da Galeria de imagens compartilhada diretamente da imagem
gerenciada. Depois de testar a nova imagem, você pode excluir a imagem gerenciada de origem. Você também
pode migrar de uma imagem gerenciada para uma galeria de imagens compartilhada usando o CLI do Azure.
várias vezes.
Antes de começar
Para concluir este artigo, você deve ter uma imagem gerenciada existente. Se a imagem gerenciada contiver um
disco de dados, o tamanho do disco de dados não poderá ser superior a 1 TB.
Obter a Galeria
Depois de encontrar a Galeria correta, crie uma variável para usar mais tarde. Este exemplo obtém a galeria
chamada myGallery no grupo de recursos MyResource Group.
-Name myGallery `

Ao fazer a definição de imagem, verifique se o tem todas as informações corretas. Como as imagens
gerenciadas são sempre generalizadas, você deve definir -OsState generalized .
Crie a definição de imagem usando New-AzGalleryImageDefinition. Neste exemplo, a definição da imagem é
chamada myImageDefinition e é para um sistema operacional generalizado do Windows. Para criar uma
definição para imagens usando um sistema operacional Linux, use -OsType Linux .
-OsState generalized `
-OsType Windows `
-Offer 'myOffer' `
-Sku 'mySKU'
Obter a imagem gerenciada

Você pode ver uma lista de imagens que estão disponíveis em um grupo de recursos usando Get-AzImage.
Depois que você souber o nome da imagem e em qual grupo de recursos ela está, poderá usar Get-AzImage
novamente para obter o objeto de imagem e armazená-lo em uma variável para uso posterior. Este exemplo
obtém uma imagem chamada myImage do grupo de recursos "myResourceGroup" e o atribui à variável
$managedImage.
$managedImage = Get-AzImage `
-ImageName myImage `

Crie uma versão de imagem da imagem gerenciada usando New-AzGalleryImageVersion.

$region2 = @{Name='West Central US';ReplicaCount=2}
-GalleryImageDefinitionName $imageDefinition.Name `
-ResourceGroupName $imageDefinition.ResourceGroupName `
-Location $imageDefinition.Location `
-SourceImageId $managedImage.Id.ToString() `
-asJob
para podermos acompanhar o progresso. Para ver o progresso, digite $job.State .
$job.State
NOTE
-StorageAccountType Premium_LRS ou armazenando o armazenamento com redundância de zona adicionando
Excluir a imagem gerenciada

Depois de verificar se a nova versão da imagem está funcionando corretamente, você pode excluir a imagem
gerenciada.
Remove-AzImage `
-ImageName $managedImage.Name `
-ResourceGroupName $managedImage.ResourceGroupName
Próximas etapas
Depois de verificar que a replicação foi concluída, você pode criar uma VM a partir da imagem generalizada.
Copiar uma imagem de outra galeria usando o
PowerShell
Se você tiver várias galerias em sua organização, poderá criar imagens de imagens armazenadas em outras
galerias. Por exemplo, você pode ter uma galeria de desenvolvimento e teste para criar e testar novas imagens.
Quando eles estiverem prontos para serem usados na produção, você poderá copiá-los para uma galeria de
produção usando este exemplo. Você também pode criar uma imagem de uma imagem em outra galeria
usando o CLI do Azure.
Antes de começar
Para concluir este artigo, você deve ter uma galeria de origem, uma definição de imagem e uma versão de
imagem existentes. Você também deve ter uma galeria de destino.
A versão da imagem de origem deve ser replicada para a região onde a Galeria de destino está localizada.
Criaremos uma nova definição de imagem e a versão da imagem na Galeria de destino.
Obter a imagem de origem

Você precisará de informações da definição da imagem de origem para poder criar uma cópia dela na Galeria de
destino.
Liste informações sobre as galerias existentes, as definições de imagem e as versões de imagem usando o
cmdlet Get-AzResource .
Os resultados estão no formato gallery\image definition\image version .
Get-AzResource `
-ResourceType Microsoft.Compute/galleries/images/versions | `
Format-Table -Property Name,ResourceGroupName
Depois de ter todas as informações necessárias, você pode obter a ID da versão da imagem de origem usando
Get-AzGalleryImageVersion. Neste exemplo, estamos obtendo a versão da 1.0.0 imagem, da
myImageDefinition definição, na myGallery Galeria de origem, no myResourceGroup grupo de recursos.
$sourceImgVer = Get-AzGalleryImageVersion `
-GalleryImageDefinitionName myImageDefinition `
-GalleryName myGallery `
-Name 1.0.0

Você precisa criar uma nova definição de imagem que corresponda à definição de imagem de sua origem. Você
pode ver todas as informações necessárias para recriar a definição de imagem usando Get-
AzGalleryImageDefinition.
Get-AzGalleryImageDefinition `
-Name myImageDefinition
{
"disallowed": null,
"endOfLifeDate": null,
"eula": null,
"hyperVgeneration": "V1",
"id": "/subscriptions/1111abcd-1a23-4b45-67g7-
1234567de123/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefini
tion",
"identifier": {
"offer": "myOffer",
"publisher": "myPublisher",
"sku": "mySKU"
},
"name": "myImageDefinition",
"osState": "Specialized",
"osType": "Windows",
"privacyStatementUri": null,
"purchasePlan": null,
"recommended": null,
"releaseNoteUri": null,
"resourceGroup": "myGalleryRG",
"tags": null,
"type": "Microsoft.Compute/galleries/images"
}
Crie uma nova definição de imagem, na Galeria de destino, usando o cmdlet New-AzGalleryImageDefinition e
as informações da saída acima.
Neste exemplo, a definição de imagem é chamada myDestinationImgDef na galeria chamada
myDestinationGallery.
$destinationImgDef = New-AzGalleryImageDefinition `
-GalleryName myDestinationGallery `
-ResourceGroupName myDestinationRG `
-Location WestUS `
-Name 'myDestinationImgDef' `
-OsType Windows `
-HyperVGeneration v1 `
-Offer 'myOffer' `
-Sku 'mySKU'

Crie uma versão de imagem usando New-AzGalleryImageVersion. Será necessário passar a ID da imagem de
origem no --managed-image parâmetro para criar a versão da imagem na Galeria de destino.
Neste exemplo, a Galeria de destino é denominada myDestinationGallery, no grupo de recursos
myDestinationRG , na localização oeste dos EUA . A versão da nossa imagem é a 1.0.0 e vamos criar uma réplica
na região do Sul EUA Central e 2 réplicas na região oeste dos EUA .

$region2 = @{Name='West US';ReplicaCount=2}

-GalleryImageDefinitionName $destinationImgDef.Name`
-GalleryName myDestinationGallery `
-ResourceGroupName myDestinationRG `
-Location WestUS `
-Source $sourceImgVer.Id.ToString() `
-asJob
$job.State
NOTE
Você também pode armazenar a imagem no armazenamento Premium adicionando -StorageAccountType Premium_LRS
, ou no Armazenamento com redundância de zona adicionando -StorageAccountType Standard_ZRS ao criar a versão
da imagem.
Próximas etapas
Crie uma VM com base em uma versão de imagem generalizada ou especializada .
Criar uma VM usando uma imagem generalizada
Crie uma VM com base em uma imagem generalizada armazenada em uma galeria de imagens compartilhada.
Se quiser criar uma VM usando uma imagem especializada, consulte criar uma VM com base em uma imagem
especializada.
Quando você tiver uma versão de imagem generalizada, poderá criar uma ou mais novas VMs. Usando o cmdlet
New-AzVM.
Neste exemplo, estamos usando a ID de definição de imagem para garantir que sua nova VM usará a versão
mais recente de uma imagem. Você também pode usar uma versão específica usando a ID de versão da imagem
para Set-AzVMSourceImage -Id . Por exemplo, para usar a versão de imagem 1.0.0 Type:
Set-AzVMSourceImage -Id "/subscriptions/<subscription ID where the gallery is
.
Lembre-se de que o uso de uma versão de imagem específica significa que a automação poderá falhar se essa
versão de imagem específica não estiver disponível porque foi excluída ou removida da região. É recomendável
usar a ID de definição de imagem para criar sua nova VM, a menos que uma versão de imagem específica seja
necessária.
Substitua os nomes de recursos conforme necessário nestes exemplos.
Conjunto de parâmetros simplificado

Você pode usar o parâmetro simplificado definido para criar rapidamente uma VM a partir de uma imagem. O
conjunto de parâmetros simplificado usa o nome da VM para criar automaticamente alguns dos recursos
necessários, como vNet e endereço IP público, para você.
# Create some variables for the new VM

# Get the image. Replace the name of your resource group, gallery, and image definition. This will create
the VM from the latest image version available.
$imageDefinition = Get-AzGalleryImageDefinition `

$cred = Get-Credential `
-Message "Enter a username and password for the virtual machine."

-Name $resourceGroup `
-Location $location
New-AzVM `
-Name $vmName `
-Image $imageDefinition.Id
-Credential $cred
Conjunto de parâmetros completo
Você pode criar uma VM usando recursos específicos usando o conjunto de parâmetros completo.
# Create some variables for the new VM


$cred = Get-Credential `
-Message "Enter a username and password for the virtual machine."

-Name $resourceGroup `
-Location $location
# Network pieces
-Name mySubnet `
-Name MYvNET `
-Name "mypublicdns$(Get-Random)" `
-IdleTimeoutInMinutes 4
$nsgRuleRDP = New-AzNetworkSecurityRuleConfig `
-Name myNetworkSecurityGroupRuleRDP `
-Protocol Tcp `
-Priority 1000 `
-Access Allow
-Name myNetworkSecurityGroup `
-SecurityRules $nsgRuleRDP
-Name myNic `
# Create a virtual machine configuration using $imageDefinition.Id to use the latest image version.
-VMName $vmName `
-VMSize Standard_D1_v2 | `
Set-AzVMSourceImage -Id $imageDefinition.Id | `

New-AzVM `
-VM $vmConfig
Próximas etapas
Criar uma VM usando uma imagem especializada
Crie uma VM com base em uma versão de imagem especializada armazenada em uma galeria de imagens
compartilhada. Se desejar criar uma VM usando uma versão de imagem generalizada, consulte criar uma VM
usando uma imagem generalizada.
Depois de ter uma versão de imagem especializada, você pode criar uma ou mais novas VMs usando o cmdlet
New-AzVM .
Neste exemplo, estamos usando a ID de definição de imagem para garantir que sua nova VM usará a versão
mais recente de uma imagem. Você também pode usar uma versão específica usando a ID de versão da imagem
para Set-AzVMSourceImage -Id . Por exemplo, para usar a versão de imagem 1.0.0 Type:
Set-AzVMSourceImage -Id "/subscriptions/<subscription ID where the gallery is
.
Lembre-se de que o uso de uma versão de imagem específica significa que a automação poderá falhar se essa
versão de imagem específica não estiver disponível porque foi excluída ou removida da região. É recomendável
usar a ID de definição de imagem para criar sua nova VM, a menos que uma versão de imagem específica seja
necessária.
$resourceGroup = "mySIGSpecializedRG"
$vmName = "mySpecializedVM"

-Name mySubnet `
-Name MYvNET `
-Protocol Tcp `
-Protocol Tcp `
-Priority 1000 `
-Name $vmName `
# Create a virtual machine configuration using Set-AzVMSourceImage -Id $imageDefinition.Id to use the latest
available image version.
-VMName $vmName `

New-AzVM `
-VM $vmConfig
Anexar o disco de dados

Se a imagem contiver um disco de dados, você precisará anexar o disco de dados à VM.
$vm = Get-AzVM -Name $vmName -ResourceGroupName $resourceGroup
$lun = $imageVersion.StorageProfile.DataDiskImages.Lun
Add-AzVMDataDisk `
-CreateOption FromImage `
-SourceImageUri $imageversion.Id `
-Lun $lun `
-Caching $imageVersion.StorageProfile.DataDiskImages.HostCaching `
-DiskSizeInGB $imageVersion.StorageProfile.DataDiskImages.SizeInGB `
-VM $vm
Próximas etapas
Listar, atualizar e excluir recursos de imagem
usando o PowerShell
Você pode gerenciar seus recursos da Galeria de imagens compartilhadas usando Azure PowerShell.
Listar informações
Liste todas as galerias por nome.
$galleries = Get-AzResource -ResourceType Microsoft.Compute/galleries

$galleries.Name
Liste todas as definições de imagem por nome.
$imageDefinitions = Get-AzResource -ResourceType Microsoft.Compute/galleries/images

$imageDefinitions.Name
Liste todas as versões de imagem por nome.
$imageVersions = Get-AzResource -ResourceType Microsoft.Compute/galleries/images/versions

$imageVersions.Name
Excluir uma versão de imagem. Este exemplo exclui a versão da imagem chamada 1.0.0.
Remove-AzGalleryImageVersion `
-Name 1.0.0 `
-ResourceGroupName myGalleryRG
Atualizar recursos
Há algumas limitações sobre o que pode ser atualizado. Os seguintes itens podem ser atualizados:
Galeria de imagens compartilhadas:
Descrição
definição da imagem:
vCPUs recomendadas
Memória recomendada
Descrição
Versão da imagem:
Contagem de réplicas regionais
Regiões de destino
Exclusão da mais recente
Se você planeja adicionar regiões de réplica, não exclua a imagem gerenciada de origem. A imagem gerenciada
de origem é necessária para replicar a versão da imagem para regiões adicionais.
Para atualizar a descrição de uma galeria, use Update-AzGallery.
Update-AzGallery `
-Name $gallery.Name `
-ResourceGroupName $resourceGroup.Name
Este exemplo mostra como usar Update-AzGalleryImageDefinition para atualizar a data de fim da vida útil da
nossa definição de imagem.
Update-AzGalleryImageDefinition `
-Name $galleryImage.Name `
-ResourceGroupName $resourceGroup.Name `
-EndOfLifeDate 01/01/2030
Este exemplo mostra como usar Update-AzGalleryImageVersion para excluir essa versão da imagem de ser
usada como a imagem mais recente .
Update-AzGalleryImageVersion `
-GalleryImageDefinitionName $galleryImage.Name `
-Name $galleryVersion.Name `
-PublishingProfileExcludeFromLatest
Este exemplo mostra como usar Update-AzGalleryImageVersion para incluir essa versão de imagem em ser
considerada para a imagem mais recente .
Update-AzGalleryImageVersion `
-GalleryImageDefinitionName $galleryImage.Name `
-Name $galleryVersion.Name `
-PublishingProfileExcludeFromLatest:$false
Limpar os recursos
Ao excluir recursos, você precisa começar com o último item nos recursos aninhados-a versão da imagem.
Depois que as versões forem excluídas, você poderá excluir a definição da imagem. Você não pode excluir a
galeria até que todos os recursos abaixo dele tenham sido excluídos.
$gallery = "myGallery"
$imageDefinition = "myImageDefinition"
$imageVersion = "myImageVersion"
Remove-AzGalleryImageVersion `
-GalleryImageDefinitionName $imageDefinition `
-GalleryName $gallery `
-Name $imageVersion `
-ResourceGroupName $resourceGroup
Remove-AzGalleryImageDefinition `
-GalleryName $gallery `
-GalleryImageDefinitionName $imageDefinition
Remove-AzGallery `
-Name $gallery `
-ResourceGroupName $resourceGroup
Remove-AzResourceGroup -Name $resourceGroup
Próximas etapas
locatários do Azure usando o PowerShell

de imagens.
locatário.
Adicionar.
Salvar .
locatário 2.

selecione Salvar .
NOTE
IMPORTANT
Criar uma VM usando o PowerShell

Faça logon em ambos os locatários usando a ID do aplicativo, o segredo e a ID do locatário.
$applicationId = '<App ID>'

$secret = <Secret> | ConvertTo-SecureString -AsPlainText -Force
$cred = New-Object -TypeName PSCredential -ArgumentList $applicationId, $secret
Clear-AzContext
Crie a VM no grupo de recursos que tem permissão no registro do aplicativo. Substitua as informações neste
exemplo pelo seu próprio.
# Set a variable for the image version in Tenant 1 using the full image ID of the shared image version
$image = "/subscriptions/<Tenant 1 subscription>/resourceGroups/<Resource
group>/providers/Microsoft.Compute/galleries/<Gallery>/images/<Image definition>/versions/<version>"


# Networking pieces
# Create a virtual machine configuration using the $image variable to specify the shared image
Set-AzVMSourceImage -Id $image | `

Próximas etapas
Você também pode criar recursos da Galeria de imagens compartilhadas usando o portal do Azure.
Criar uma galeria de imagens compartilhada
usando o portal

A Galeria de imagens compartilhadas permite que você compartilhe suas imagens de VM personalizadas com
outras pessoas em sua organização, dentro ou entre regiões, dentro de um locatário do Azure AD. Escolha quais
imagens você deseja compartilhar, em quais regiões deseja torná-las disponíveis e com quem deseja
compartilhá-las. Você pode criar várias galerias, de modo que pode agrupar logicamente as imagens
compartilhadas.
O recurso Galeria de Imagens Compartilhadas tem vários tipos de recursos. Usaremos ou criaremos estes itens
neste artigo:
imagens.


imagem.

Antes de começar
Para concluir o exemplo neste artigo, você deve ter uma imagem gerenciada existente de uma VM generalizada
ou um instantâneo de uma VM especializada. Você pode seguir o tutorial: criar uma imagem personalizada de
uma VM do Azure com Azure PowerShell para criar uma imagem gerenciada ou criar um instantâneo para uma
VM especializada. Para imagens gerenciadas e instantâneos, o tamanho do disco de dados não pode ser
superior a 1 TB.

O exemplo a seguir cria uma galeria chamada myGallery no grupo de recursos myGalleryRG.
2. Use a Galeria de imagens de tipo compartilhado na caixa de pesquisa e selecione Galeria de imagens
compar tilhadas nos resultados.
3. Na página Galeria de imagens compar tilhadas , clique em Adicionar .
4. Na página criar galeria de imagens compar tilhadas , selecione a assinatura correta.
5. Em grupo de recursos , selecione criar novo e digite myGalleryRG para o nome.
6. Em nome , digite myGallery para o nome da galeria.
7. Deixe o padrão para região .
8. Você pode digitar uma breve descrição da galeria, como minha galeria de imagens para teste. e, em seguida,
clique em revisar + criar .
9. Depois que a validação for aprovada, selecione criar .

imagem.
Crie a definição de imagem da Galeria dentro da sua galeria. Neste exemplo, a imagem da galeria é denominada
myImageDefinition.
1. Na página da nova galeria de imagens, selecione Adicionar uma nova definição de imagem na parte
superior da página.
2. Em Adicionar nova definição de imagem à galeria de imagens compar tilhadas , para região ,
selecione leste dos EUA.
3. Para nome da definição da imagem , digite myImageDefinition.
4. Para sistema operacional , selecione a opção correta com base em sua VM de origem.
5. Para geração de VM , selecione a opção com base na VM de origem. Na maioria dos casos, essa será a Gen
1. Para obter mais informações, consulte suporte para VMs de geração 2.
6. Para estado do sistema operacional , selecione a opção com base na VM de origem. Para obter mais
informações, consulte generalizado e especializado.
7. Para o Publicador , digite mypublisher.
8. Para ofer ta , digite myoffer.
9. Para SKU , digite mySKU.
10. Quando terminar, selecione revisar + criar .
11. Após a definição da imagem passar na validação, selecione criar .

Crie uma versão de imagem de uma imagem gerenciada. Neste exemplo, a versão da imagem é 1.0.0 e ela é
replicado para os datacenters Centro-Oeste dos EUA e Centro-Sul dos EUA. Ao escolher regiões de destino para
replicação, lembre-se de que você também precisa incluir a região de origem como um destino para replicação.
As etapas para criar uma versão de imagem são um pouco diferentes, dependendo se a origem é uma imagem
generalizada ou um instantâneo de uma VM especializada.
Opção: generalizada
1. Na página da definição de imagem, selecione Adicionar versão na parte superior da página.
2. Em região , selecione a região onde a imagem gerenciada está armazenada. As versões de imagem precisam
ser criadas na mesma região da imagem gerenciada da qual são criadas.
3. Para nome , digite 1.0.0. O nome da versão da imagem deve seguir a principal. secundária. formato de patch
usando inteiros.
4. Em imagem de origem , selecione a imagem gerenciada de origem na lista suspensa.
5. Em excluir da versão mais recente , deixe o valor padrão de não.
6. Em data de término da vida útil , selecione uma data do calendário que esteja a alguns meses no futuro.
7. Em replicação , deixe a contagem de réplicas padrão como 1. Você precisa replicar para a região de
origem, portanto, deixe a primeira réplica como padrão e, em seguida, escolha uma segunda região de
réplica como leste dos EUA.
8. Quando terminar, selecione Revisar + criar . O Azure validará a configuração.
9. Quando a versão da imagem passar na validação, selecione criar .
Opção: especializada
2. Em região , selecione a região em que o instantâneo está armazenado. As versões de imagem precisam ser
criadas na mesma região da origem da qual são criadas.
usando inteiros.
4. Em instantâneo de disco do so , selecione o instantâneo da VM de origem na lista suspensa. Se a VM de
origem tiver um disco de dados que você gostaria de incluir, selecione o número de LUN correto na lista
suspensa e, em seguida, selecione o instantâneo do disco de dados para o instantâneo do disco de
dados .
Recomendamos que você compartilhe o acesso no nível da galeria de imagens. O seguinte guia você pelo
compartilhamento da galeria que você acabou de criar.
1. Abra o portal do Azure.
2. No menu à esquerda, selecione grupos de recursos .
3. Na lista de grupos de recursos, selecione myGaller yRG . A folha do seu grupo de recursos será aberta.
4. No menu à esquerda da página myGaller yRG , selecione controle de acesso (iam) .
5. Em Adicionar uma atribuição de função , selecione Adicionar . O painel Adicionar uma atribuição de
função será aberto.
7. Em atribuir acesso a , deixe o padrão de usuário, grupo ou entidade de ser viço do Azure ad .
8. Em selecionar , digite o endereço de email da pessoa que você deseja convidar.
9. Se o usuário estiver fora de sua organização, você verá a mensagem este usuário receberá um email
que permite colaborar com a Microsoft. Selecione o usuário com o endereço de email e clique em
salvar .
Se o usuário estiver fora de sua organização, ele receberá um convite por email para ingressar na organização.
O usuário precisa aceitar o convite, então ele poderá ver a galeria e todas as definições e versões de imagem na
lista de recursos.
Criar VMs
Agora você pode criar uma ou mais novas VMs. Este exemplo cria uma VM chamada myVMfromImage no
myResourceGroup no datacenter do Leste dos EUA.
1. Vá para a definição de imagem. Você pode usar o filtro de recursos para mostrar todas as definições de
imagem disponíveis.
2. Na página da definição de imagem, selecione criar VM no menu na parte superior da página.
3. Para grupo de recursos , selecione criar novo e digite grupo de recursos para o nome.
4. Em nome da máquina vir tual , digite myVM.
5. Em Região , selecione Leste dos EUA.
6. Para as opções de disponibilidade , deixe o padrão de nenhuma redundância de infraestrutura necessária.
7. O valor da imagem será preenchido automaticamente com a latest versão da imagem se você tiver
iniciado na página para a definição da imagem.
8. Para tamanho , escolha um tamanho de VM na lista de tamanhos disponíveis e escolha selecionar .
9. Em conta de administrador , se a VM de origem tiver sido generalizada, insira seu nome de usuário e a
chave pública SSH . Se a VM de origem era especializada, essas opções serão esmaecidas porque as
informações da VM de origem são usadas.
10. Se você quiser permitir o acesso remoto à VM, em por tas de entrada públicas , escolha permitir por tas
selecionadas e, em seguida, selecione SSH (22) na lista suspensa. Se você não quiser permitir o acesso
remoto à VM, deixe nenhuma selecionada para por tas de entrada públicas .
11. Quando tiver terminado, selecione o botão revisar + criar na parte inferior da página.
12. Depois que a VM passar na validação, selecione criar na parte inferior da página para iniciar a implantação.
Limpar os recursos
Se você quiser excluir recursos individuais, será necessário excluí-los na ordem inversa. Por exemplo, para
excluir uma definição de imagem, você precisa excluir todas as versões de imagem criadas por meio dessa
imagem.
Próximas etapas
Criar uma galeria de imagens compartilhadas do
Azure usando o portal

A galeria de imagens compartilhadas permite compartilhar suas imagens da VM personalizadas com outras
pessoas em sua organização, dentro ou entre regiões, em um locatário do AAD. Escolha quais imagens você
deseja compartilhar, em quais regiões deseja torná-las disponíveis e com quem deseja compartilhá-las. Você
pode criar várias galerias, de modo que pode agrupar logicamente as imagens compartilhadas.
O recurso Galeria de Imagens Compartilhadas tem vários tipos de recursos. Usaremos ou criaremos estes itens
neste artigo:
imagens.


imagem.

O exemplo a seguir cria uma galeria chamada myGallery no grupo de recursos myGalleryRG.
2. Use a Galeria de imagens de tipo compartilhado na caixa de pesquisa e selecione Galeria de imagens
compar tilhadas nos resultados.
3. Na página Galeria de imagens compar tilhadas , clique em Adicionar .
4. Na página criar galeria de imagens compar tilhadas , selecione a assinatura correta.
5. Em grupo de recursos , selecione criar novo e digite myGalleryRG para o nome.
6. Em nome , digite myGallery para o nome da galeria.
7. Deixe o padrão para região .
8. Você pode digitar uma breve descrição da galeria, como minha galeria de imagens para teste. e, em seguida,
clique em revisar + criar .
9. Depois que a validação for aprovada, selecione criar .

imagem.
Crie a definição de imagem da Galeria dentro da sua galeria. Neste exemplo, a imagem da galeria é denominada
myImageDefinition.
1. Na página da nova galeria de imagens, selecione Adicionar uma nova definição de imagem na parte
superior da página.
2. Em Adicionar nova definição de imagem à galeria de imagens compar tilhadas , para região ,
selecione leste dos EUA.
3. Para nome da definição da imagem , digite myImageDefinition.
4. Para sistema operacional , selecione a opção correta com base em sua VM de origem.
5. Para geração de VM , selecione a opção com base na VM de origem. Na maioria dos casos, essa será a Gen
1. Para obter mais informações, consulte suporte para VMs de geração 2.
6. Para estado do sistema operacional , selecione a opção com base na VM de origem. Para obter mais
informações, consulte generalizado e especializado.
7. Para o Publicador , digite mypublisher.
8. Para ofer ta , digite myoffer.
9. Para SKU , digite mySKU.
10. Quando terminar, selecione revisar + criar .
11. Após a definição da imagem passar na validação, selecione criar .

Crie uma versão de imagem de uma imagem gerenciada. Neste exemplo, a versão da imagem é 1.0.0 e ela é
replicado para os datacenters Centro-Oeste dos EUA e Centro-Sul dos EUA. Ao escolher regiões de destino para
replicação, lembre-se de que você também precisa incluir a região de origem como um destino para replicação.
As etapas para criar uma versão de imagem são um pouco diferentes, dependendo se a origem é uma imagem
generalizada ou um instantâneo de uma VM especializada.
Opção: generalizada
2. Em região , selecione a região onde a imagem gerenciada está armazenada. As versões de imagem precisam
ser criadas na mesma região da imagem gerenciada da qual são criadas.
usando inteiros.
4. Em imagem de origem , selecione a imagem gerenciada de origem na lista suspensa.
Opção: especializada
2. Em região , selecione a região em que o instantâneo está armazenado. As versões de imagem precisam ser
criadas na mesma região da origem da qual são criadas.
usando inteiros.
4. Em instantâneo de disco do so , selecione o instantâneo da VM de origem na lista suspensa. Se a VM de
origem tiver um disco de dados que você gostaria de incluir, selecione o número de LUN correto na lista
suspensa e, em seguida, selecione o instantâneo do disco de dados para o instantâneo do disco de
dados .
Recomendamos que você compartilhe o acesso no nível da galeria de imagens. O seguinte guia você pelo
compartilhamento da galeria que você acabou de criar.
1. Abra o portal do Azure.
2. No menu à esquerda, selecione grupos de recursos .
3. Na lista de grupos de recursos, selecione myGaller yRG . A folha do seu grupo de recursos será aberta.
4. No menu à esquerda da página myGaller yRG , selecione controle de acesso (iam) .
5. Em Adicionar uma atribuição de função , selecione Adicionar . O painel Adicionar uma atribuição de
função será aberto.
7. Em atribuir acesso a , deixe o padrão de usuário, grupo ou entidade de ser viço do Azure ad .
8. Em selecionar , digite o endereço de email da pessoa que você deseja convidar.
9. Se o usuário estiver fora de sua organização, você verá a mensagem este usuário receberá um email
que permite colaborar com a Microsoft. Selecione o usuário com o endereço de email e clique em
salvar .
Se o usuário estiver fora de sua organização, ele receberá um convite por email para ingressar na organização.
O usuário precisa aceitar o convite, então ele poderá ver a galeria e todas as definições e versões de imagem na
lista de recursos.
Criar VMs
Agora você pode criar uma ou mais novas VMs. Este exemplo cria uma VM chamada myVM, no MyResource, no
datacenter leste dos EUA .
1. Vá para a definição de imagem. Você pode usar o filtro de recursos para mostrar todas as definições de
imagem disponíveis.
2. Na página da definição de imagem, selecione criar VM no menu na parte superior da página.
3. Para grupo de recursos , selecione criar novo e digite grupo de recursos para o nome.
4. Em nome da máquina vir tual , digite myVM.
5. Em Região , selecione Leste dos EUA.
6. Para as opções de disponibilidade , deixe o padrão de nenhuma redundância de infraestrutura necessária.
7. O valor da imagem será preenchido automaticamente com a latest versão da imagem se você tiver
iniciado na página para a definição da imagem.
8. Para tamanho , escolha um tamanho de VM na lista de tamanhos disponíveis e escolha selecionar .
9. Em conta de administrador , se a imagem tiver sido generalizada, você precisará fornecer um nome de
usuário, como azureuser e uma senha. A senha deve ter no mínimo 12 caracteres e atender a requisitos de
complexidade definidos. Se a imagem for especializada, os campos de nome de usuário e senha ficarão
esmaecidos porque o nome de usuário e a senha da VM de origem são usados.
10. Se você quiser permitir o acesso remoto à VM, em por tas de entrada públicas , escolha permitir por tas
selecionadas e, em seguida, selecione RDP (3389) na lista suspensa. Se você não quiser permitir o acesso
remoto à VM, deixe nenhuma selecionada para por tas de entrada públicas .
11. Quando tiver terminado, selecione o botão revisar + criar na parte inferior da página.
12. Depois que a VM passar na validação, selecione criar na parte inferior da página para iniciar a implantação.
Limpar os recursos
Se você quiser excluir recursos individuais, será necessário excluí-los na ordem inversa. Por exemplo, para
excluir uma definição de imagem, você precisa excluir todas as versões de imagem criadas por meio dessa
imagem.
Próximas etapas
Solucionar problemas de galerias de imagens
compartilhadas no Azure
Se você tiver problemas ao executar qualquer operação em galerias de imagens compartilhadas, definições de
imagem e versões de imagem, execute o comando com falha novamente no modo de depuração. Você ativa o
modo de depuração passando a --debug opção com o CLI do Azure e a -Debug opção com o PowerShell.
Depois de localizar o erro, siga este artigo para solucionar o problema.
Criando ou modificando uma galeria

O nome da galeria é inválido. Os caracteres permitidos são caracteres alfanuméricos em inglês, com
sublinhados e pontos permitidos no meio, até 80 caracteres no total. Todos os outros caracteres especiais,
incluindo traços, não são permitidos.
Causa : o nome da Galeria não atende aos requisitos de nomenclatura.
Solução alternativa : escolha um nome que atenda às seguintes condições:
Tem um limite de 80 caracteres
Contém apenas letras em inglês, números, sublinhados e pontos
Inicia e termina com letras ou números em inglês
O nome da entidade ' galleryname ' é inválido de acordo com sua regra de validação: ^ [^ _ \w] [\w-. _ ] {0,79}
(? <! [-.]) $.
Causa : o nome da Galeria não atende aos requisitos de nomenclatura.
Solução alternativa : escolha um nome para a galeria que atenda às seguintes condições:
O nome de recurso fornecido <galleryname > tem estes caracteres à direita inválidos: <caractere > . O nome
não pode terminar com caracteres: <caractere>
Causa : o nome da galeria termina com um ponto ou sublinhado.
Solução alternativa : escolha um nome para a galeria que atenda às seguintes condições:
A região <local fornecida > não está disponível para o tipo de recurso ' Microsoft. Compute/galerias '. A lista de
regiões disponíveis para o tipo de recurso é...
Causa : a região especificada para a galeria está incorreta ou requer uma solicitação de acesso.
Solução alternativa : Verifique se o nome da região está grafado corretamente. Você pode executar esse
comando para ver as regiões às quais você tem acesso. Se a região não estiver na lista, envie uma solicitação de
acesso.
Não é possível excluir o recurso antes que os recursos aninhados sejam excluídos.
Causa : você tentou excluir uma galeria que contém pelo menos uma definição de imagem existente. Uma
galeria deve estar vazia antes que possa ser excluída.
Solução alternativa : exclua todas as definições de imagem dentro da galeria e, em seguida, continue a excluir
a galeria. Se a definição de imagem contiver versões de imagem, você deverá excluir as versões da imagem
antes de excluir as definições de imagem.
O nome da Galeria ' <galleryname > ' não é exclusivo na assinatura ' '. Escolha outro nome de galeria.
Causa : você tem uma galeria existente com o mesmo nome e tentou criar outra galeria com o mesmo nome.
Solução alternativa : escolha um nome diferente para a galeria.
O recurso <galleryname > já existe no local <região _ 1 > no grupo de recursos <resourcegroup > . Um
recurso com o mesmo nome não pode ser criado no local <região _ 2 > . Selecione um novo nome de recurso.
Causa : você tem uma galeria existente com o mesmo nome e tentou criar outra galeria com o mesmo nome.
Solução alternativa : escolha um nome diferente para a galeria.
Criando ou modificando definições de imagem

A alteração da propriedade ' galleryImage. Properties. <property > ' não é permitida.
Causa : você tentou alterar o tipo de sistema operacional, estado do sistema operacional, geração do Hyper-V,
oferta, Publicador ou SKU. A alteração de qualquer uma dessas propriedades não é permitida.
Solução alternativa : Crie uma nova definição de imagem em vez disso.
O recurso <Gallery/imageDefinitionName > já existe no local <região _ 1 > no grupo de recursos
<resourcegroup > . Um recurso com o mesmo nome não pode ser criado no local <região _ 2 > . Selecione um
novo nome de recurso.
Causa : você tem uma definição de imagem existente na mesma galeria e no mesmo grupo de recursos com o
mesmo nome. Você tentou criar outra definição de imagem com o mesmo nome e na mesma galeria, mas em
uma região diferente.
Solução alternativa : Use um nome diferente para a definição de imagem ou coloque a definição de imagem
em uma galeria ou grupo de recursos diferente.
O nome de recurso fornecido <galleryname > /<imageDefinitionName > tem estes caracteres inválidos:
<caractere > . O nome não pode terminar com caracteres: <caractere>
Causa : o nome da <imageDefinitionName > termina com um ponto ou sublinhado.
Solução alternativa : escolha um nome para a definição de imagem que atenda às seguintes condições:
Contém apenas letras em inglês, números, sublinhados, hifens e pontos
Inicia e termina com letras ou números em inglês.
O nome da entidade <imageDefinitionName > é inválido de acordo com sua regra de validação: ^ [^ _ \ W] [ \
W-. _ ] {0,79} (? <! [-.]) $"
Causa : o nome da <imageDefinitionName > termina com um ponto ou sublinhado.
Solução alternativa : escolha um nome para a definição de imagem que atenda às seguintes condições:
Contém apenas letras em inglês, números, sublinhados, hifens e pontos
O nome do ativo galleryImage. Properties. ID. <propriedade > não é válido. Ele não pode ficar vazio. Os
caracteres permitidos são letras maiúsculas ou minúsculas, dígitos, hífen (-), ponto final (.), sublinhado ( _ ). Os
nomes não têm permissão para terminar com o ponto (.). O comprimento do nome não pode exceder <>
caracteres numéricos.
Causa : o valor de Publicador, oferta ou SKU não atende aos requisitos de nomenclatura.
Solução alternativa : escolha um valor que atenda às seguintes condições:
Tem um limite de 128 caracteres para o fornecedor ou o limite de 64 caracteres para oferta e SKU
Contém apenas letras em inglês, números, hifens, sublinhados e pontos
Não termina com um ponto
Não é possível executar a operação solicitada no recurso aninhado. O recurso pai <galleryname > não foi
encontrado.
Causa : não há uma galeria com o nome <galleryname > na assinatura atual e no grupo de recursos.
Solução alternativa : Verifique se os nomes da galeria, da assinatura e do grupo de recursos estão corretos.
Caso contrário, crie uma nova galeria chamada <galleryname > .
Causa : o nome da região de <> está incorreto ou requer uma solicitação de acesso.
acesso.
Não é possível serializar o valor: <valor > como tipo: ' ISO-8601 '., ISO8601Error: iso 8601 time Designator ' T'
ausente. Não é possível analisar a cadeia de caracteres DateTime <valor>
Causa : o valor fornecido à propriedade não está formatado corretamente como uma data.
Solução alternativa : forneça uma data no formato aaaa-mm-dd, yyyy-mm-dd'T'HH: mm: Sszzz ou ISO 8601-
válido.
Não foi possível converter a cadeia de caracteres em DateTimeOffset: <valor > . Caminho ' Properties.
<property > '
válido.
EndOfLifeDate deve ser definido como uma data futura.
Causa : a propriedade de data de fim da vida útil não está formatada corretamente como uma data após a data
de hoje.
válido.
argumento--<propriedade > : valor int inválido: valor de <>
Causa : <propriedade > aceita apenas valores inteiros e <valor > não é um inteiro.
Solução alternativa : escolha um valor inteiro.
O valor mínimo da propriedade <> não deve ser maior que o valor máximo da propriedade <> .
Causa : o valor mínimo fornecido para <propriedade > é maior que o valor máximo fornecido para
<propriedade > .
Solução alternativa : altere os valores para que o mínimo seja menor ou igual ao máximo.
Imagem da Galeria: <imageDefinitionName > identificadas por (Publicador: <Publisher > , oferta: <oferta > ,
SKU: <SKU > ) já existe. Escolha uma combinação de Publicador, oferta, SKU diferente.
Causa : você tentou criar uma nova definição de imagem com o mesmo editor, oferta e SKU terceto como uma
definição de imagem existente na mesma galeria.
Solução alternativa : em uma galeria, todas as definições de imagem devem ter uma combinação exclusiva de
Publicador, oferta e SKU. Escolha uma combinação exclusiva ou escolha uma nova galeria e crie a definição de
imagem novamente.
Não é possível excluir o recurso antes que os recursos aninhados sejam excluídos.
Causa : você tentou excluir uma definição de imagem que contém versões de imagem. Uma definição de
imagem deve estar vazia antes que possa ser excluída.
Solução alternativa : exclua todas as versões de imagem dentro da definição de imagem e, em seguida,
prossiga para excluir a definição de imagem.
Não é possível associar o parâmetro <propriedade > . Não é possível converter valor <valor > para o tipo
<PropertyType > . Não é possível corresponder o valor do identificador <> ao nome de um enumerador válido.
Especifique um dos seguintes nomes de enumerador e tente novamente: <Choice1 > , <Choice2 > ,...
Causa : a propriedade tem uma lista restrita de valores possíveis e <valor > não é um deles.
Solução alternativa : escolha um dos possíveis valores de <opção > .
Não é possível associar o parâmetro <propriedade > . Não é possível converter valor <valor > para o tipo "
System. DateTime"
válido.
System. Int32"
Não há suporte para o tipo de conta de armazenamento ZRS nesta região.
Causa : você escolheu o ZRS (armazenamento com redundância de zona padrão) em uma região que ainda não
oferece suporte a ele.
Solução alternativa : altere o tipo de conta de armazenamento para Premium _ LRS ou Standard _ LRS .
Verifique nossa documentação para obter a lista mais recente de regiões com a visualização de ZRS habilitada.
Criando ou atualizando versões de imagem

Causa : o nome da região de <> está incorreto ou requer uma solicitação de acesso.
acesso.
Não é possível executar a operação solicitada no recurso aninhado. O recurso pai
<Gallery/imageDefinitionName > não foi encontrado.
Causa : não há uma galeria com o nome <Gallery/imageDefinitionName > na assinatura atual e no grupo de
recursos.
Solução alternativa : Verifique se os nomes da galeria, da assinatura e do grupo de recursos estão corretos.
Caso contrário, crie uma nova galeria com o nome <Gallery > e/ou uma definição de imagem chamada
<imageDefinitionName > no grupo de recursos indicado.
System. DateTime"
válido.
System. Int32"
Regiões de perfil de publicação de versão de imagem da Galeria <publishingRegions > deve conter o local da
versão da imagem <sourceRegion>
Causa : o local da imagem de origem (<sourceRegion > ) deve ser incluído na lista de <publishingRegions > .
Solução alternativa : inclua <sourceRegion > na lista <publishingRegions > .
O valor <valor > do parâmetro <propriedade > está fora do intervalo. O valor deve estar entre <minValue > e
<MaxValue > , inclusive.
Causa : <valor > está fora do intervalo de valores possíveis para a propriedade <> .
Solução alternativa : escolha um valor que esteja dentro do intervalo de <minValue > e <MaxValue > ,
inclusive.
ResourceId de <de origem > não encontrado. Verifique se a origem existe e se está na mesma região que a
versão da imagem da galeria que está sendo criada.
Causa : não há fonte localizada em <ResourceId > ou a origem em <ResourceId > não está na mesma região
que a imagem da galeria que está sendo criada.
Solução alternativa : Verifique se o valor <ResourceId > está correto e se a região de origem da versão da
imagem da galeria é a mesma que a região do valor <ResourceId > .
Não é permitido alterar a propriedade ' galleryImageVersion. Properties. storageProfile. <. > Source.ID '.
Causa : a ID de origem de uma versão de imagem da Galeria não pode ser alterada após a criação.
Solução alternativa : Verifique se a ID de origem é igual à ID de origem existente, altere o número da versão
da imagem ou exclua a versão da imagem atual e tente novamente.
Foram detectados números de LUN duplicados nos discos de dados de entrada. O número de LUN deve ser
exclusivo para cada disco de dados.
Causa : quando você está criando uma versão de imagem usando uma lista de discos e/ou instantâneos de
disco, dois ou mais discos ou instantâneos de disco têm o mesmo LUN.
Solução alternativa : remova ou altere quaisquer LUNs duplicados.
IDs de origem duplicadas são encontradas nos discos de entrada. A ID de origem deve ser exclusiva para cada
disco.
Causa : quando você está criando uma versão de imagem usando uma lista de discos e/ou instantâneos de
disco, dois ou mais discos ou instantâneos de disco têm a mesma ID de recurso.
Solução alternativa : remova ou altere quaisquer IDs de origem de disco duplicadas.
A ID da propriedade <ResourceId > no caminho ' Properties. storageProfile. <diskImages > . Source.ID ' é
inválido. Espere uma ID de recurso totalmente qualificada que comece com '/subscriptions/{subscriptionId} ' ou
'/providers/{resourceProviderNamespace}/'.
Causa : o valor de resourceid <> está formatado incorretamente.
Solução alternativa : Verifique se a ID do recurso está correta.
A ID de origem: <ResourceId > deve ser uma imagem gerenciada, uma máquina virtual ou outra versão de
imagem da Galeria
Solução alternativa : se você estiver usando uma VM, imagem gerenciada ou versão de imagem da galeria
como a imagem de origem, verifique se a ID de recurso da VM, imagem gerenciada ou versão da imagem da
galeria está correta.
A ID de origem: <ResourceId > deve ser um disco gerenciado ou um instantâneo.
Solução alternativa : se você estiver usando discos e/ou instantâneos de disco como fontes para a versão da
imagem, verifique se as IDs de recurso dos discos e/ou instantâneos do disco estão corretos.
Não é possível criar a versão da imagem da Galeria de: <ResourceId > , pois o estado do sistema operacional na
imagem da Galeria pai (<OsState _ 1 > ) não é <OsState _ 2 > .
Causa : o estado do sistema operacional (generalizado ou especializado) não corresponde ao estado do sistema
operacional especificado na definição de imagem.
Solução alternativa : escolha uma fonte com base em uma VM com o estado do sistema operacional de
<OsState _ 1 > ou crie uma nova definição de imagem para VMs com base em <OsState _ 2 > .
O recurso com a ID ' <ResourceId > ' tem uma geração de hipervisor diferente [' <V # _ 1 > '] que a geração de
hipervisor de imagem da Galeria pai [' <V # _ 2 > ']
Causa : a geração de hipervisor da versão de imagem não corresponde à geração de hipervisor especificada na
definição de imagem. O sistema operacional de definição de imagem é <V # _ 1 > e o sistema operacional da
versão da imagem é <v # _ 2 > .
Solução alternativa : escolha uma fonte com a mesma geração de hipervisor que a definição de imagem ou
crie/escolha uma nova definição de imagem que tenha a mesma geração de hipervisor que a versão da
imagem.
O recurso com a ID ' <ResourceId > ' tem um tipo de sistema operacional diferente [' <OsType _ 1 > '] que a
geração de tipo de so da imagem da Galeria pai [' <OsType _ 2 > ']
Causa : a geração de hipervisor da versão de imagem não corresponde à geração de hipervisor especificada na
definição de imagem. O sistema operacional de definição de imagem é <OsType _ 1 > e o sistema operacional
da versão da imagem é <OsType _ 2 > .
Solução alternativa : escolha uma fonte com o mesmo sistema operacional (Linux/Windows) como a definição
de imagem ou crie/escolha uma nova definição de imagem que tenha a mesma geração de sistema operacional
que a versão da imagem.
A ResourceId da máquina virtual de origem <> não pode conter um disco do sistema operacional efêmero.
Causa : a origem em <ResourceId > contém um disco do sistema operacional efêmero. Atualmente, a Galeria de
imagens compartilhadas não oferece suporte a discos do sistema operacional efêmero.
Solução alternativa : escolha uma fonte diferente com base em uma VM que não usa um disco do sistema
operacional efêmero.
A ResourceId da máquina virtual de origem <> não pode conter o disco [' <DiskId > '] armazenado em um tipo
de conta UltraSSD.
Causa : o disco <DiskId > é um disco SSD ultra. Atualmente, a Galeria de imagens compartilhadas não oferece
suporte a discos SSD Ultra.
Solução alternativa : Use uma fonte que contenha somente SSD Premium, SSD Standard e/ou HDD Standard
Managed disks.
A ResourceId da máquina virtual de origem <> deve ser criada a partir de Managed disks.
Causa : a máquina virtual no <ResourceId > usa discos não gerenciados.
Solução alternativa : Use uma fonte baseada em uma VM que contenha somente SSD Premium, SSD Standard
e/ou HDD Standard Managed disks.
Muitas solicitações na fonte ' <ResourceId > '. Reduza o número de solicitações na origem ou aguarde algum
tempo antes de tentar novamente.
Causa : a origem desta versão de imagem está sendo limitada no momento devido a muitas solicitações.
Solução alternativa : tente criar a versão da imagem mais tarde.
O conjunto de criptografia de disco ' <diskEncryptionSetID > ' deve estar na mesma assinatura '
<SubscriptionId > ' que o recurso da galeria.
Causa : os conjuntos de criptografia de disco podem ser usados somente na mesma assinatura e região em que
foram criados.
Solução alternativa : crie ou use um conjunto de criptografia na mesma assinatura e região que a versão da
imagem.
Fonte criptografada: ' <ResourceId > ' está em uma ID de assinatura diferente da assinatura de versão de
imagem da Galeria atual ' <SubscriptionId _ 1 > '. Tente novamente com uma ou mais fontes não criptografadas
ou use a assinatura da origem ' <subassinaturaid _ 2 > ' para criar a versão da imagem da galeria.
Causa : a Galeria de imagens compartilhadas atualmente não oferece suporte à criação de versões de imagem
em outra assinatura de outra imagem de origem se a imagem de origem estiver criptografada.
Solução alternativa : Use uma fonte não criptografada ou crie a versão da imagem na mesma assinatura que a
origem.
O conjunto de criptografia de disco <diskEncryptionSetID > não foi encontrado.
Causa : a criptografia de disco pode estar incorreta.
Solução alternativa : Verifique se a ID de recurso do conjunto de criptografia de disco está correta.
O nome da versão da imagem é inválido. O nome da versão da imagem deve seguir a principal (int). Secundária
(int). Formato de patch (int), por exemplo: 1.0.0, 2018.12.1 etc.
Causa : o formato válido para uma versão de imagem é de três inteiros separados por um ponto. O nome da
versão da imagem não atendeu ao formato válido.
Solução alternativa : Use um nome de versão de imagem que segue o formato Major (int). Secundária (int).
Patch (int). Por exemplo: 1.0.0. ou 2018.12.1.
O valor do parâmetro galleryArtifactVersion. Properties. publishingProfile. targetRegions. encryption.
dataDiskImages. diskEncryptionSetId é inválido
Causa : a ID de recurso do conjunto de criptografia de disco usada em uma imagem de disco de dados usa um
formato inválido.
Solução alternativa : Verifique se a ID de recurso do conjunto de criptografia de disco segue o
formato/subscriptions/<SubscriptionId > /ResourceGroups/<ResourceGroupName >
/Providers/Microsoft.Compute/<diskEncryptionSetName > .
O valor do parâmetro galleryArtifactVersion. Properties. publishingProfile. targetRegions. encryption.
osDiskImage. diskEncryptionSetId é inválido.
Causa : a ID de recurso do conjunto de criptografia de disco usada na imagem de disco do sistema operacional
usa um formato inválido.
Solução alternativa : Verifique se a ID de recurso do conjunto de criptografia de disco segue o
formato/subscriptions/<SubscriptionId > /ResourceGroups/<ResourceGroupName >
/Providers/Microsoft.Compute/<diskEncryptionSetName > .
Não é possível especificar o novo LUN de criptografia de imagem de disco de dados [número <> ] com um
conjunto de criptografia de disco na região [região > de <] para a solicitação atualizar versão da imagem da
galeria. Para atualizar essa versão, remova o novo LUN. Se precisar alterar as configurações de criptografia de
imagem de disco de dados, você deverá criar uma nova versão de imagem da galeria com as configurações
corretas.
Causa : você adicionou criptografia ao disco de dados de uma versão de imagem existente. Você não pode
adicionar criptografia a uma versão de imagem existente.
Solução alternativa : Crie uma nova versão de imagem da galeria ou remova as configurações de criptografia
adicionadas.
A origem da versão do artefato da galeria só pode ser especificada diretamente sob storageProfile ou dentro de
um sistema operacional ou discos de dados individuais. Apenas um tipo de origem (imagem do usuário,
instantâneo, disco, máquina virtual) pode ser fornecido.
Causa : a ID de origem está ausente.
Solução alternativa : Verifique se a ID de origem da origem está presente.
A origem não foi encontrada: <ResourceId > . Certifique-se de que a origem exista.
Causa : a ID de recurso da origem pode estar incorreta.
Solução alternativa : Verifique se a ID de recurso da origem está correta.
Um conjunto de criptografia de disco é necessário para o disco ' galleryArtifactVersion. Properties.
publishingProfile. targetRegions. encryption. osDiskImage. diskEncryptionSetId ' na região de destino ' <região _
1 > ', pois o conjunto de criptografia de disco ' <diskEncryptionSetId > ' é usado para o disco correspondente
na região ' <região _ 2 > '
Causa : a criptografia foi usada no disco do sistema operacional na região do <_ 2 > , mas não na <região _ 1 >
.
Solução alternativa : se você estiver usando a criptografia no disco do sistema operacional, use a criptografia
em todas as regiões.
Um conjunto de criptografia de disco é necessário para o disco ' LUN <Number > ' na região de destino '
<Region _ 1 > ', pois o conjunto de criptografia de disco ' <diskEncryptionSetID > ' é usado para o disco
correspondente na região ' <Region _ 2 > '
Causa : a criptografia foi usada no disco de dados no LUN <número > na região <_ 2 > , mas não na <região _
1>.
Solução alternativa : se você estiver usando a criptografia em um disco de dados, use a criptografia em todas
as regiões.
Um LUN inválido [<Number > ] foi especificado em Encryption. dataDiskImages. O LUN deve ser um dos
seguintes valores [' 0, 9 '].
Causa : o LUN especificado para a criptografia não corresponde a nenhum dos LUNs para discos anexados à
VM.
Solução alternativa : altere o LUN na criptografia para o LUN de um disco de dados presente na VM.
LUNs duplicados ' <Number > ' foram especificados na região de destino ' <Region > ' Encryption.
dataDiskImages.
Causa : as configurações de criptografia usadas em <região > especificou um LUN pelo menos duas vezes.
Solução alternativa : altere o LUN na região <> para garantir que todos os LUNs sejam exclusivos na região
<> .
OSDiskImage e DataDiskImage não podem apontar para o mesmo blob <SourceID>
Causa : as origens do disco do sistema operacional e de pelo menos um disco de dados não são exclusivas.
Solução alternativa : altere a origem do disco do sistema operacional e/ou dos discos de dados para garantir
que o disco do sistema operacional, bem como cada disco de dados seja exclusivo.
Regiões duplicadas não são permitidas em regiões de publicação de destino.
Causa : uma região é listada entre as regiões de publicação mais de uma vez.
Solução alternativa : Remova a região duplicada.
Não é permitido adicionar novos discos de dados ou alterar o LUN de um disco de dados em uma imagem
existente.
Causa : uma chamada de atualização para a versão da imagem contém um novo disco de dados ou tem um
novo LUN para um disco.
Solução alternativa : Use os LUNs e discos de dados da versão da imagem existente.
O conjunto de criptografia de disco <diskEncryptionSetID > deve estar na mesma assinatura <SubscriptionId >
que o recurso da galeria.
Causa : atualmente, a Galeria de imagens compartilhadas não oferece suporte ao uso de uma criptografia de
disco definida em uma assinatura diferente.
Solução alternativa : Crie a versão da imagem e o conjunto de criptografia de disco na mesma assinatura.
Criando ou atualizando uma VM ou conjuntos de dimensionamento

de uma versão de imagem
O cliente tem permissão para executar a ação ' Microsoft. Compute/galerias/images/Versions/Read ' no escopo
<ResourceId > , no entanto, o locatário atual <tenantId1 > não está autorizado a acessar a assinatura vinculada
<subscriptionId2 > .
Causa : a máquina virtual ou o conjunto de dimensionamento foi criado por meio de uma imagem SIG em
outro locatário. Você tentou fazer uma alteração na máquina virtual ou no conjunto de dimensionamento, mas
não tem acesso à assinatura que possui a imagem.
Solução alternativa : entre em contato com o proprietário da assinatura da versão da imagem para conceder
acesso de leitura à versão da imagem.
A imagem da Galeria <ResourceId > não está disponível na região da região <> . Contate o proprietário da
imagem para replicar nessa região ou altere a região solicitada.
Causa : a VM está sendo criada em uma região que não está entre a lista de regiões publicadas para a imagem
da galeria.
Solução alternativa : replique a imagem para a região ou crie uma VM em uma das regiões nas regiões de
publicação da imagem da galeria.
O parâmetro ' osProfile ' não é permitido.
Causa : o nome de usuário do administrador, a senha ou as chaves SSH foram fornecidas para uma VM que foi
criada a partir de uma versão de imagem especializada.
Solução alternativa : não inclua o nome de usuário do administrador, a senha ou as chaves SSH se você
pretende criar uma VM a partir dessa imagem. Caso contrário, use uma versão de imagem generalizada e
forneça o nome de usuário, a senha ou as chaves SSH do administrador.
O parâmetro necessário ' osProfile ' está ausente (nulo).
Causa : a VM é criada a partir de uma imagem generalizada e falta o nome de usuário, a senha ou as chaves
SSH do administrador. Como as imagens generalizadas não retêm o nome de usuário, a senha ou as chaves SSH
do administrador, esses campos devem ser especificados durante a criação de uma VM ou um conjunto de
dimensionamento.
Solução alternativa : especifique o nome de usuário do administrador, a senha ou as chaves SSH ou use uma
versão de imagem especializada.
Não é possível criar a versão da imagem da Galeria de: <ResourceId > , pois o estado do sistema operacional na
imagem da Galeria pai (' especializada ') não é ' generalizado '.
Causa : a versão da imagem é criada a partir de uma fonte generalizada, mas sua definição pai é especializada.
Solução alternativa : Crie a versão da imagem usando uma fonte especializada ou use uma definição pai que
seja generalizada.
Não é possível atualizar o conjunto de dimensionamento de máquinas virtuais <vmssName > , pois o estado
atual do sistema operacional do conjunto de escala de VM é generalizado, o que é diferente do estado
atualizado do sistema operacional da imagem da galeria que é especializada.
Causa : a imagem de origem atual do conjunto de dimensionamento é uma imagem de origem generalizada,
mas está sendo atualizada com uma imagem de origem especializada. A imagem de origem atual e a nova
imagem de origem para um conjunto de dimensionamento devem ser do mesmo estado.
Solução alternativa : para atualizar o conjunto de dimensionamento, use uma versão de imagem generalizada.
O conjunto de criptografia de disco <diskEncryptionSetId > na Galeria de imagens compartilhadas <VersionId
> pertence à assinatura <subscriptionId1 > e não pode ser usado com o recurso ' ' na assinatura
<subscriptionId2>
Causa : o conjunto de criptografia de disco usado para criptografar a versão da imagem reside em uma
assinatura diferente da assinatura para hospedar a versão da imagem.
Solução alternativa : Use a mesma assinatura para a versão de imagem e o conjunto de criptografia de disco.
A criação do conjunto de dimensionamento de máquinas virtuais ou VM leva muito tempo.
Solução alternativa : Verifique se o OSType da versão da imagem da qual você está tentando criar a VM ou o
conjunto de dimensionamento de máquinas virtuais tem o mesmo OSType da fonte que você usou para criar a
versão da imagem.
Criando um disco com base em uma versão de imagem

O valor do parâmetro imageReference é inválido.
Causa : você tentou exportar de uma versão de imagem SIG para um disco, mas usou uma posição de LUN que
não existe na imagem.
Solução alternativa : Verifique a versão da imagem para ver quais posições de LUN estão em uso.
Compartilhando recursos
O compartilhamento de galeria de imagens, definição de imagem e recursos de versão de imagem entre
assinaturas é habilitado usando o controle de acesso baseado em função do Azure (RBAC do Azure).
Velocidade de replicação
Use o sinalizador --Expand ReplicationStatus para verificar se a replicação para todas as regiões de destino
especificadas foi concluída. Caso contrário, aguarde até seis horas para que o trabalho seja concluído. Se falhar,
dispare o comando novamente para criar e replicar a versão da imagem. Se houver muitas regiões de destino
para as quais a versão da imagem está sendo replicada, considere fazer a replicação em fases.
Limites e cotas do Azure

Limites e cotas do Azure se aplicam a todos os recursos de versão de imagem, definição da imagem e galeria de
imagens compartilhadas. Verifique se você está dentro dos limites de suas assinaturas.
Próximas etapas
Saiba mais sobre galerias de imagens compartilhadas.
Visualização: Use chaves gerenciadas pelo cliente
para criptografar imagens
As imagens em uma galeria de imagens compartilhadas são armazenadas como instantâneos, portanto, são
criptografadas automaticamente por meio da criptografia do lado do servidor. A criptografia do lado do
servidor usa a criptografia AESde 256 bits, uma das codificações de bloco mais fortes disponíveis. A criptografia
do lado do servidor também é compatível com FIPS 140-2. Para obter mais informações sobre os módulos de
criptografia subjacentes ao Azure Managed disks, consulte API de criptografia: próxima geração.
Você pode contar com chaves gerenciadas por plataforma para a criptografia de suas imagens ou usar suas
próprias chaves. Você também pode usar ambos juntos para criptografia dupla. Se você optar por gerenciar a
criptografia com suas próprias chaves, pode especificar uma chave gerenciada pelo cliente a ser usada para
criptografar e descriptografar todos os discos nas suas imagens.
A criptografia do lado do servidor por meio de chaves gerenciadas pelo cliente usa Azure Key Vault. Você pode
importar suas chaves RSA para o cofre de chaves ou gerar novas chaves rsa em Azure Key Vault.
Pré-requisitos
Este artigo requer que você já tenha um conjunto de criptografia de disco em cada região em que você deseja
replicar a imagem:
Para usar apenas uma chave gerenciada pelo cliente, consulte os artigos sobre como habilitar chaves
gerenciadas pelo cliente com a criptografia do lado do servidor usando o portal do Azure ou o
PowerShell.
Para usar chaves gerenciadas por plataforma e gerenciadas pelo cliente (para criptografia dupla),
consulte os artigos sobre como habilitar a criptografia dupla em repouso usando o portal do Azure ou o
PowerShell.
IMPORTANT
Você deve usar o link https://aka.ms/diskencryptionupdates para acessar o portal do Azure. A criptografia dupla
em repouso não está visível no momento no portal do Azure público, a menos que você use esse link.
Limitações
Quando você está usando chaves gerenciadas pelo cliente para criptografar imagens em uma galeria de
imagens compartilhada, essas limitações se aplicam:
Os conjuntos de chaves de criptografia devem estar na mesma assinatura que a imagem.
Os conjuntos de chaves de criptografia são recursos regionais, portanto, cada região requer um conjunto
de chaves de criptografia diferente.
Você não pode copiar ou compartilhar imagens que usam chaves gerenciadas pelo cliente.
Depois de usar suas próprias chaves para criptografar um disco ou uma imagem, você não pode voltar a
usar chaves gerenciadas pela plataforma para criptografar esses discos ou imagens.
IMPORTANT
A criptografia por meio de chaves gerenciadas pelo cliente está atualmente em visualização pública. Esta versão de
visualização é fornecida sem um contrato de nível de serviço e não é recomendável para cargas de trabalho de produção.
Alguns recursos podem não ter suporte ou podem ter restrição de recursos. Para obter mais informações, consulte
Termos de Uso Complementares de Versões Prévias do Microsoft Azure.
PowerShell
Para a visualização pública, primeiro você precisa registrar o recurso:
Register-AzProviderFeature -FeatureName SIGEncryption -ProviderNamespace Microsoft.Compute
Demora alguns minutos para que o registro seja concluído. Use Get-AzProviderFeature para verificar o status
do registro do recurso:
Get-AzProviderFeature -FeatureName SIGEncryption -ProviderNamespace Microsoft.Compute
Quando RegistrationState retorna Registered , você pode passar para a próxima etapa.
Verifique o registro do seu provedor. Verifique se ele volta como Registered .
Get-AzResourceProvider -ProviderNamespace Microsoft.Compute | Format-table -Property

ResourceTypes,RegistrationState
Se não retornar Registered , use o seguinte código para registrar os provedores:
Register-AzResourceProvider -ProviderNamespace Microsoft.Compute
Para especificar um conjunto de criptografia de disco para uma versão de imagem, use New-
AzGalleryImageDefinition com o -TargetRegion parâmetro:
$sourceId = <ID of the image version source>
$osDiskImageEncryption = @{DiskEncryptionSetId='subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myRG/providers/Microsoft.Compute/diskEncryptionSets/myDESet'}
$dataDiskImageEncryption1 = @{DiskEncryptionSetId='subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myRG/providers/Microsoft.Compute/diskEncryptionSets/myDESet1';Lun=1}
$dataDiskImageEncryption2 = @{DiskEncryptionSetId='subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myRG/providers/Microsoft.Compute/diskEncryptionSets/myDESet2';Lun=2}
$dataDiskImageEncryptions = @($dataDiskImageEncryption1,$dataDiskImageEncryption2)
$encryption1 = @{OSDiskImage=$osDiskImageEncryption;DataDiskImages=$dataDiskImageEncryptions}
$region1 = @{Name='West US';ReplicaCount=1;StorageAccountType=Standard_LRS;Encryption=$encryption1}
$eastUS2osDiskImageEncryption = @{DiskEncryptionSetId='subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myRG/providers/Microsoft.Compute/diskEncryptionSets/myEastUS2DESet'}
$eastUS2dataDiskImageEncryption1 = @{DiskEncryptionSetId='subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myRG/providers/Microsoft.Compute/diskEncryptionSets/myEastUS2DESet1';Lun=1}
$eastUS2dataDiskImageEncryption2 = @{DiskEncryptionSetId='subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myRG/providers/Microsoft.Compute/diskEncryptionSets/myEastUS2DESet2';Lun=2}
$eastUS2DataDiskImageEncryptions = @($eastUS2dataDiskImageEncryption1,$eastUS2dataDiskImageEncryption2)
$encryption2 = @{OSDiskImage=$eastUS2osDiskImageEncryption;DataDiskImages=$eastUS2DataDiskImageEncryptions}
$region2 = @{Name='East US 2';ReplicaCount=1;StorageAccountType=Standard_LRS;Encryption=$encryption2}
$targetRegion = @($region1, $region2)
# Create the image

New-AzGalleryImageVersion `
-ResourceGroupName $rgname `
-GalleryName $galleryName `
-GalleryImageDefinitionName $imageDefinitionName `
-Name $versionName -Location $location `
-SourceImageId $sourceId `
-ReplicaCount 2 `
-StorageAccountType Standard_LRS `
-TargetRegion $targetRegion

Você pode criar uma VM (máquina virtual) de uma galeria de imagens compartilhada e usar chaves gerenciadas
pelo cliente para criptografar os discos. A sintaxe é a mesma de criar uma VM generalizada ou especializada a
partir de uma imagem. Use o conjunto de parâmetros estendidos e adicione
Set-AzVMOSDisk -Name $($vmName +"_OSDisk") -DiskEncryptionSetId $diskEncryptionSet.Id -CreateOption FromImage
à configuração da VM.
Para discos de dados, adicione o -DiskEncryptionSetId $setID parâmetro ao usar Add-AzVMDataDisk.
CLI
Para a visualização pública, primeiro você precisa se registrar para o recurso. O registro leva cerca de 30
minutos.
az feature register --namespace Microsoft.Compute --name SIGEncryption
Verifique o status do registro do recurso:
az feature show --namespace Microsoft.Compute --name SIGEncryption | grep state
Quando esse código retornar "state": "Registered" , você poderá passar para a próxima etapa.
Verifique seu registro:
az provider show -n Microsoft.Compute | grep registrationState
Se não disser registrado, execute o seguinte comando:
az provider register -n Microsoft.Compute
Para especificar um conjunto de criptografia de disco para uma versão de imagem, use AZ Image Gallery
Create-Image-Version com o --target-region-encryption parâmetro. O formato de --target-region-encryption
é uma lista separada por vírgulas de chaves para criptografar o sistema operacional e os discos de dados. O
resultado deve ser assim:
<encryption set for the OS disk>,<Lun number of the data disk>,<encryption set for the data disk>,<Lun number
for the second data disk>,<encryption set for the second data disk>
.
Use --managed-image para especificar a origem da versão da imagem se a origem do disco do sistema
operacional for um disco gerenciado ou uma VM. Neste exemplo, a origem é uma imagem gerenciada que tem
um disco do sistema operacional e um disco de dados no LUN 0. O disco do sistema operacional será
criptografado com DiskEncryptionSet1 e o disco de dados será criptografado com DiskEncryptionSet2.

-g MyResourceGroup \
--location westus \
--target-regions westus=2=standard_lrs eastus2 \
--target-region-encryption WestUSDiskEncryptionSet1,0,WestUSDiskEncryptionSet2
EastUS2DiskEncryptionSet1,0,EastUS2DiskEncryptionSet2 \
--gallery-name MyGallery \
--gallery-image-definition MyImage \
--managed-image "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/images/myImage"
Use --os-snapshot para especificar o disco do sistema operacional se a origem do disco do sistema operacional
for um instantâneo. Se houver instantâneos de disco de dados que também devem fazer parte da versão da
imagem, adicione-os. Use --data-snapshot-luns para especificar o LUN e use --data-snapshots para especificar
os instantâneos.
Neste exemplo, as origens são instantâneos de disco. Há um disco do sistema operacional e um disco de dados
no LUN 0. O disco do sistema operacional será criptografado com DiskEncryptionSet1 e o disco de dados será
criptografado com DiskEncryptionSet2.
-g MyResourceGroup \
--location westus\
--target-regions westus=2=standard_lrs eastus\
--target-region-encryption WestUSDiskEncryptionSet1,0,WestUSDiskEncryptionSet2
EastUS2DiskEncryptionSet1,0,EastUS2DiskEncryptionSet2 \
--os-snapshot "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/snapshots/myOSSnapshot" \
--data-snapshot-luns 0 \
--data-snapshots "/subscriptions/<subscription
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/snapshots/myDDSnapshot" \
--gallery-name MyGallery \
--gallery-image-definition MyImage
Criar a VM
É possível criar uma VM de uma galeria de imagens compartilhada e usar chaves gerenciadas pelo cliente para
criptografar os discos. A sintaxe é a mesma de criar uma VM generalizada ou especializada a partir de uma
imagem. Basta adicionar o --os-disk-encryption-set parâmetro com a ID do conjunto de criptografia. Para
discos de dados, adicione --data-disk-encryption-sets com uma lista delimitada por espaço dos conjuntos de
criptografia de disco para os discos de dados.
Portal
Ao criar a versão da imagem no portal, você pode usar a guia criptografia para aplicar os conjuntos de
criptografia de armazenamento.
IMPORTANT
Para usar a criptografia dupla, você deve usar o link https://aka.ms/diskencryptionupdates para acessar o portal do Azure.
A criptografia dupla em repouso não está visível no momento no portal do Azure público, a menos que você use esse
link.
1. Na página criar uma imagem de versão , selecione a guia criptografia .

2. Em tipo de criptografia , selecione criptografia em repouso com uma chave gerenciada pelo
cliente ou criptografia dupla com chaves gerenciadas por plataforma e gerenciadas pelo cliente .
3. Para cada disco na imagem, selecione um conjunto de criptografia na lista suspensa conjunto de
criptografia de disco .
Criar a VM
Você pode criar uma VM com base em uma versão de imagem e usar chaves gerenciadas pelo cliente para
criptografar os discos. Quando você cria a VM no portal, na guia discos , selecione criptografia em repouso
com chaves gerenciadas pelo cliente ou criptografia dupla com chaves gerenciadas por plataforma e
gerenciadas pelo cliente para o tipo de criptografia . Em seguida, você pode selecionar o conjunto de
criptografia na lista suspensa.
Próximas etapas
Saiba mais sobre Criptografia de disco do lado do servidor.
Criar um disco gerenciado com base em uma
versão de imagem
Se necessário, você pode exportar o sistema operacional ou um único disco de dados de uma versão de
imagem como um disco gerenciado de uma versão de imagem armazenada em uma galeria de imagens
compartilhada.
CLI
Liste as versões de imagem em uma galeria usando AZ SIG Image-Version List. Neste exemplo, estamos
procurando todas as versões de imagem que fazem parte da definição de imagem myImageDefinition na
Galeria de imagens myGallery .
az sig image-version list \

--resource-group myResourceGroup\
-o table
Defina a source variável como a ID da versão da imagem e, em seguida, use AZ Disk Create para criar o disco
gerenciado.
Neste exemplo, exportamos o disco do sistema operacional da versão da imagem para criar um disco
gerenciado chamado myManagedOSDisk, na região eastus , em um grupo de recursos chamado MyResource
Group.
source="/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/galle
ries/<galleryName>/images/<galleryImageDefinition>/versions/<imageVersion>"
az disk create --resource-group myResourceGroup --location EastUS --name myManagedOSDisk --gallery-image-

reference $source
Se você quiser exportar um disco de dados da versão da imagem, adicione --gallery-image-reference-lun para
especificar o local do LUN do disco de dados a ser exportado.
Neste exemplo, exportamos o disco de dados localizado no LUN 0 da versão da imagem para criar um disco
gerenciado chamado myManagedDataDisk, na região eastus , em um grupo de recursos chamado MyResource
Group.
source="/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/galle
ries/<galleryName>/images/<galleryImageDefinition>/versions/<imageVersion>"
az disk create --resource-group myResourceGroup --location EastUS --name myManagedDataDisk --gallery-image-

reference $source --gallery-image-reference-lun 0
PowerShell
Liste as versões de imagem em uma galeria usando Get-AzResource.
Get-AzResource `
-ResourceType Microsoft.Compute/galleries/images/versions | `
Format-Table -Property Name,ResourceId,ResourceGroupName
Depois de ter todas as informações necessárias, você pode usar Get-AzGalleryImageVersion para obter a versão
da imagem de origem que deseja usar e atribuí-la a uma variável. Neste exemplo, estamos obtendo a versão da
1.0.0 imagem, da myImageDefinition definição, na myGallery Galeria de origem, no myResourceGroup grupo
de recursos.
$sourceImgVer = Get-AzGalleryImageVersion `
-Name 1.0.0
Depois de definir a source variável como a ID da versão da imagem, use New-AzDiskConfig para criar uma
configuração de disco e New-AzDisk para criar o disco.
Neste exemplo, exportamos o disco do sistema operacional da versão da imagem para criar um disco
gerenciado chamado myManagedOSDisk, na região eastus , em um grupo de recursos chamado MyResource
Group.
Crie uma configuração de disco.
-Location EastUS `
-GalleryImageReference @{Id = $sourceImgVer.Id}
Crie o disco.
New-AzDisk -Disk $diskConfig `

-DiskName myManagedOSDisk
Se você quiser exportar um disco de dados na versão da imagem, adicione uma ID de LUN à configuração de
disco para especificar o local do LUN de dados a ser exportado.
Neste exemplo, exportamos o disco de dados localizado no LUN 0 da versão da imagem para criar um disco
gerenciado chamado myManagedDataDisk, na região eastus , em um grupo de recursos chamado MyResource
Group.
Crie uma configuração de disco.
-Location EastUS `
-GalleryImageReference @{Id = $sourceImgVer.Id; Lun=0}
Crie o disco.
New-AzDisk -Disk $diskConfig `

-DiskName myManagedDataDisk
Próximas etapas
Você também pode criar uma versão de imagem de um disco gerenciado usando o CLI do Azure ou o
PowerShell.
Fornecer informações do plano de compra do
Azure Marketplace ao criar imagens
Se você estiver criando uma imagem em uma galeria compartilhada, usando uma fonte que foi criada
originalmente a partir de uma imagem do Azure Marketplace, talvez seja necessário acompanhar as
informações do plano de compra. Este artigo mostra como localizar informações do plano de compra para uma
VM e, em seguida, usar essas informações ao criar uma definição de imagem. Também abordamos o uso das
informações da definição de imagem para simplificar o fornecimento das informações do plano de compra ao
criar uma VM para uma imagem.
Para obter mais informações sobre como localizar e usar imagens do Marketplace, consulte Localizar e usar
imagens do Azure Marketplace.
Obter as informações da VM de origem

Se você ainda tiver a VM original, poderá obter o nome do plano, o editor e as informações do produto a partir
dele usando Get-AzVM. Este exemplo obtém uma VM chamada myVM no grupo de recursos MyResource Group
e, em seguida, exibe as informações do plano de compra para a VM.
$vm = Get-azvm `
-Name myVM
$vm.Plan

Obtenha a Galeria de imagens que você deseja usar para armazenar a imagem. Você pode listar todas as
galerias primeiro.
Em seguida, crie variáveis para a galeria que você deseja usar. Neste exemplo, estamos criando uma variável
chamada $gallery para myGallery no grupo de recursos myGalleryRG .
-Name myGallery `
-ResourceGroupName myGalleryRG
Crie a definição de imagem, usando -PurchasePlanPublisher os -PurchasePlanProduct parâmetros, e

-PurchasePlanName .
-OsType Linux `
-Offer 'myOffer' `
-Sku 'mySKU' `
-PurchasePlanPublisher $vm.Plan.Publisher `
-PurchasePlanProduct $vm.Plan.Product `
-PurchasePlanName $vm.Plan.Name
Em seguida, crie a versão da imagem usando New-AzGalleryImageVersion. Você pode criar uma versão de
imagem de uma VM, imagem gerenciada, VHD\snapshotou outra versão de imagem.
Criar a VM
Ao ir para criar uma VM a partir da imagem, você pode usar as informações da definição de imagem para
passar as informações do Publicador usando set-AzVMPlan.
$resourceGroup = "mySIGPubVM"
$location = "West Central US"
$vmName = "mySIGPubVM"


-Name mySubnet `
-Name MYvNET `
-Protocol Tcp `
-Priority 1000 `
-Name $vmName `
# Create a virtual machine configuration using Set-AzVMSourceImage -Id $imageDefinition.Id to use the latest
available image version. Set-AZVMPlan is used to pass the plan information in for the VM.
-VMName $vmName `
Set-AzVMPlan `
-Publisher $imageDefinition.PurchasePlan.Publisher `
-Product $imageDefinition.PurchasePlan.Product `
-Name $imageDefinition.PurchasePlan.Name | `
# Create the virtual machine

New-AzVM `
-VM $vmConfig
Próximas etapas
Para obter mais informações sobre como localizar e usar imagens do Marketplace, consulte Localizar e usar
imagens do Azure Marketplace.
Visualização: visão geral do construtor de imagens
do Azure
As imagens de VM (máquina virtual) padronizadas permitem que as organizações migrem para a nuvem e
garantam consistência nas implantações. As imagens normalmente incluem definições de segurança e de
configuração, bem como o software necessário. Configurar seu próprio pipeline de geração de imagens requer
tempo, infraestrutura e configuração, mas com o Construtor de Imagens de VM do Azure, basta fornecer uma
configuração simples que descreva sua imagem e enviá-la ao serviço para que a imagem seja criada e
distribuída.
O Construtor de Imagens de VM do Azure (Construtor de Imagens do Azure) permite que você comece com
uma imagem do Azure Marketplace baseada em Windows ou Linux, imagens personalizadas existentes ou ISO
do RHEL (Red Hat Enterprise Linux) e comece a adicionar suas próprias personalizações. Já que o Construtor de
Imagens se baseia no HashiCorp Packer, você também pode importar seus scripts de provisionamento de shell
do Packer existentes. Você também pode especificar onde deseja que suas imagens sejam hospedadas, na
Galeria de Imagens Compartilhadas do Azure, como uma imagem gerenciada ou um VHD.
IMPORTANT
O Construtor de Imagens do Azure está atualmente em versão prévia pública. Essa versão prévia é fornecida sem um
contrato de nível de serviço e não é recomendada para cargas de trabalho de produção. Alguns recursos podem não ter
suporte ou podem ter restrição de recursos. Para obter mais informações, consulte Termos de Uso Complementares de
Versões Prévias do Microsoft Azure.
Versão prévia dos recursos

Para a versão prévia, os seguintes recursos são compatíveis:
Criação de imagens de linha de base golden, que inclui suas configurações corporativas e de segurança
mínimas e permite que os departamentos o personalizem ainda mais para as necessidades deles.
Aplicação de patches em imagens existentes. O Construtor de Imagens permitirá que você aplique patches
continuamente em imagens personalizadas existentes.
Conecte o Construtor de Imagens às suas redes virtuais existentes, para que você possa se conectar a
servidores de configuração existentes (DSC, Chef, Puppet etc.), compartilhamentos de arquivo ou outros
servidores/serviços roteáveis.
Integração com a Galeria de Imagens Compartilhadas do Azure. Permite distribuir, apresentar e escalar
imagens globalmente e fornece um sistema de gerenciamento de imagens.
Integração com pipelines de build de imagem existentes. Basta chamar o Construtor de Imagens de seu
pipeline ou usar a tarefa simples da versão prévia do Azure DevOps do Construtor de Imagens.
Migração de um pipeline de personalização de imagem existente para o Azure. Use seus scripts, comandos e
processos existentes para personalizar imagens.
Criação de imagens no formato VHD para dar suporte ao Azure Stack.
Regiões
O serviço do Construtor de Imagens do Azure estará disponível em versão prévia nessas regiões. As imagens
podem ser distribuídas fora dessas regiões.
Leste dos EUA
Leste dos EUA 2
Centro-Oeste dos EUA
Oeste dos EUA
Oeste dos EUA 2
Norte da Europa
Europa Ocidental
Suporte a SO
O AIB dará suporte a imagens do SO base do Azure Marketplace:
Ubuntu 18.04
Ubuntu 16.04
RHEL 7.6, 7.7
CentOS 7.6, 7.7
SLES 12 SP4
SLES 15, SLES 15 SP1
Windows 10 RS5 Enterprise/Enterprise multisessão/Professional
Windows 2016
Windows 2019
ISOs do RHEL não são mais compatíveis.
Como ele funciona

O Construtor de Imagens do Azure é um serviço do Azure totalmente gerenciado que é acessível por um
provedor de recursos do Azure. O processo do Construtor de Imagens do Azure tem três partes principais:
determinação da origem, personalização e distribuição, que são representadas em um modelo. O diagrama a
seguir mostra os componentes, com algumas das respectivas propriedades.
Processo do Construtor de Imagens
1. Crie o Modelo de Imagem como um arquivo .json. Esse arquivo .json contém informações sobre a origem, as
personalizações e a distribuição da imagem. Há vários exemplos no repositório GitHub do Construtor de
Imagens do Azure.
2. Envie-o para o serviço. Isso criará um artefato de Modelo de Imagem no grupo de recursos que você
especificar. Em segundo plano, o Construtor de Imagens baixará a ISO ou imagem de origem e os scripts,
conforme necessário. Eles são armazenados em um grupo de recursos separado que é criado
automaticamente em sua assinatura, no formato: IT_ <DestinationResourceGroup> _ <TemplateName> .
3. Depois que o modelo de imagem for criado, você poderá compilar a imagem. No construtor de imagem de
plano de fundo usa o modelo e os arquivos de origem para criar uma VM (tamanho padrão:
Standard_D1_v2), rede, IP público, NSG e armazenamento no <DestinationResourceGroup> grupo de
recursos IT_ _ <TemplateName> .
4. Como parte da criação da imagem, o Image Builder distribui a imagem de acordo com o modelo e, em
seguida, exclui os recursos adicionais no <DestinationResourceGroup> grupo de recursos IT_ _
<TemplateName> que foi criado para o processo.
Permissões
Quando você se registra no (AIB), o serviço AIB recebe permissão para criar, gerenciar e excluir um grupo de
recursos de preparo (IT_*), bem como direitos para adicionar a ele recursos necessários para o build da imagem.
Para que isso ocorra, um SPN (nome da entidade de serviço) do AIB é disponibilizado em sua assinatura durante
um registro bem-sucedido.
Para permitir que o Construtor de Imagens de VM do Azure distribua imagens para as imagens gerenciadas ou
para uma Galeria de Imagens Compartilhadas, você precisará criar uma identidade atribuída pelo usuário do
Azure que tenha permissões para ler e gravar imagens. Esse procedimento, caso você esteja acessando o
Armazenamento do Azure, precisará de permissões para ler contêineres privados.
Inicialmente, você precisa seguir a documentação intitulada Criar uma identidade gerenciada atribuída pelo
usuário do Azure sobre como criar uma identidade.
Depois que você tiver a identidade, precisará conceder permissões a ela. Para fazer isso, use uma definição de
função personalizada do Azure e atribua a identidade gerenciada atribuída pelo usuário para usar a definição de
função personalizada.
As permissões são explicadas em mais detalhes aqui e os exemplos mostram como isso é implementado.
NOTE
Anteriormente, com o AIB, você usaria o SPN do AIB e concederia as permissões de SPN aos grupos de recursos de
imagem. Estamos nos distanciando desse modelo para possibilitar futuras funcionalidades. Desde 26 de maio de 2020, o
Construtor de Imagens não aceita modelos que não têm uma identidade atribuída pelo usuário. Os modelos existentes
precisarão ser reenviados para o serviço com uma identidade de usuário. Os exemplos aqui já mostram como você pode
criar uma identidade atribuída pelo usuário e adicioná-las a um modelo. Para obter mais informações, examine esta
documentação sobre essa alteração e atualizações sobre lançamentos.
Custos
Você incorrerá em alguns custos de computação, rede e armazenamento ao criar, compilar e armazenar
imagens com o Construtor de Imagens do Azure. Esses custos são semelhantes aos custos incorridos na criação
manual de imagens personalizadas. Para os recursos, você será cobrado segundo as suas tarifas do Azure.
Durante o processo de criação de imagem, os arquivos são baixados e armazenados no grupo de recursos
IT_<DestinationResourceGroup>_<TemplateName> , o que gera um pequeno custo de armazenamento. Se você não
quiser mantê-los, exclua o modelo de imagem após o build da imagem.
O Construtor de Imagens cria uma VM usando um tamanho de VM D1v2 e o armazenamento e a rede
necessários para a VM. Esses recursos terão a mesma duração que o processo de build e serão excluídos assim
que o Construtor de Imagens terminar de criar a imagem.
O Construtor de Imagens do Azure distribuirá a imagem para suas regiões escolhidas, o que poderá incorrer em
encargos de saída de rede.
Geração do Hyper-V
Atualmente, o Image Builder dá suporte apenas para a criação de imagens de geração do Hyper-V (GEN1) 1
para a Galeria de imagens compartilhada do Azure (SIG) ou a imagem gerenciada. Se você quiser criar imagens
Gen2, precisará usar uma imagem Gen2 de origem e distribuir para o VHD. Depois, você precisará criar uma
imagem gerenciada do VHD e inseri-la no SIG como uma imagem Gen2.
Próximas etapas
Para experimentar o Construtor de Imagens do Azure, confira os artigos para compilar imagens do Linux ou do
Windows.
Versão prévia: criar uma imagem do Linux e
distribuí-la para uma galeria de imagens
compartilhadas usando CLI do Azure
Este artigo mostra como usar o Construtor de Imagens do Azure e a CLI do Azure para criar uma versão de
imagem em uma Galeria de Imagens Compartilhadas e distribuir a imagem globalmente. Faça isso também
com o Azure PowerShell.
Usaremos um modelo .json de exemplo para configurar a imagem. O arquivo .json que estamos usando está
aqui: helloImageTemplateforSIG.json.
Para distribuir a imagem a uma Galeria de Imagens Compartilhadas, o modelo usa sharedImage como o valor
da seção distribute do modelo.
IMPORTANT
Registrar os recursos
Para usar o Construtor de Imagens do Azure durante a versão prévia, você precisa registrar o novo recurso.
az feature register --namespace Microsoft.VirtualMachineImages --name VirtualMachineTemplatePreview
Verifique o status do registro do recurso.
az feature show --namespace Microsoft.VirtualMachineImages --name VirtualMachineTemplatePreview -o json |

grep state
Verifique seu registro.
az provider show -n Microsoft.VirtualMachineImages -o json | grep registrationState

az provider show -n Microsoft.KeyVault -o json | grep registrationState
az provider show -n Microsoft.Compute -o json | grep registrationState
az provider show -n Microsoft.Storage -o json | grep registrationState
Caso o status não seja mostrado como registrado, execute o seguinte:
az provider register -n Microsoft.VirtualMachineImages

az provider register -n Microsoft.KeyVault
az provider register -n Microsoft.Storage
Definir variáveis e permissões
Usaremos algumas informações repetidamente, portanto, criaremos algumas variáveis para armazená-las.
Para a Versão Prévia, o Construtor de Imagens só dará suporte à criação de imagens personalizadas no mesmo
grupo de recursos da imagem gerenciada de origem. Atualize o nome do grupo de recursos neste exemplo para
que seja o mesmo grupo de recursos da imagem gerenciada de origem.
# Resource group name - we are using ibLinuxGalleryRG in this example

sigResourceGroup=ibLinuxGalleryRG
# Datacenter location - we are using West US 2 in this example
location=westus2
# Additional region to replicate the image to - we are using East US in this example
additionalregion=eastus
# name of the shared image gallery - in this example we are using myGallery
sigName=myIbGallery
# name of the image definition to be created - in this example we are using myImageDef
imageDefName=myIbImageDef
# image distribution metadata reference name
runOutputName=aibLinuxSIG
Criar uma variável para a ID da assinatura. Obtenha isso usando az account show -o json | grep id .
subscriptionID=<Subscription ID>
Crie o grupo de recursos.
az group create -n $sigResourceGroup -l $location
Criar uma identidade atribuída pelo usuário e definir permissões no

grupo de recursos
O Construtor de Imagens usará a identidade do usuário fornecida para injetar a imagem na SIG (Galeria de
Imagens Compartilhadas) do Azure. Neste exemplo, você criará uma definição de função do Azure que tem as
ações granulares para executar a distribuição da imagem para o SIG. A definição de função será então atribuída
à identidade do usuário.
# create user assigned identity for image builder to access the storage account where the script is located
identityName=aibBuiUserId$(date +'%s')
az identity create -g $sigResourceGroup -n $identityName
# get identity id
imgBuilderCliId=$(az identity show -g $sigResourceGroup -n $identityName -o json | grep "clientId" | cut -
c16- | tr -d '",')
# get the user identity URI, needed for the template

imgBuilderId=/subscriptions/$subscriptionID/resourcegroups/$sigResourceGroup/providers/Microsoft.ManagedIden
tity/userAssignedIdentities/$identityName
# this command will download an Azure role definition template, and update the template with the parameters
specified earlier.
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solutions/12_Creating_AIB_Security
_Roles/aibRoleImageCreation.json -o aibRoleImageCreation.json
imageRoleDefName="Azure Image Builder Image Def"$(date +'%s')
# update the definition

sed -i -e "s/<subscriptionID>/$subscriptionID/g" aibRoleImageCreation.json
sed -i -e "s/<rgName>/$sigResourceGroup/g" aibRoleImageCreation.json
sed -i -e "s/Azure Image Builder Service Image Creation Role/$imageRoleDefName/g" aibRoleImageCreation.json
# create role definitions

az role definition create --role-definition ./aibRoleImageCreation.json
# grant role definition to the user assigned identity

--assignee $imgBuilderCliId \
--role "$imageRoleDefName" \
--scope /subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup
Criar uma definição de imagem e uma galeria

Para usar o Construtor de Imagens com uma galeria de imagens compartilhadas, você precisa ter uma galeria
de imagens e uma definição de imagem. O Construtor de Imagens não criará a galeria de imagens e a definição
de imagem para você.
Se você ainda não tiver uma definição de imagem e a definição de galeria para usar, comece criando-as.
Primeiro, crie uma galeria de imagens.
az sig create \
-g $sigResourceGroup \
Em seguida, crie uma definição de imagem.

--gallery-name $sigName \
--gallery-image-definition $imageDefName \
--publisher myIbPublisher \
--offer myOffer \
--sku 18.04-LTS \
--os-type Linux
Baixar e configurar o .json

Baixe o modelo .json e configure-o com suas variáveis.
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/1_Creating_a_Cust
om_Linux_Shared_Image_Gallery_Image/helloImageTemplateforSIG.json -o helloImageTemplateforSIG.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateforSIG.json
sed -i -e "s/<rgName>/$sigResourceGroup/g" helloImageTemplateforSIG.json
sed -i -e "s/<imageDefName>/$imageDefName/g" helloImageTemplateforSIG.json
sed -i -e "s/<sharedImageGalName>/$sigName/g" helloImageTemplateforSIG.json
sed -i -e "s/<region1>/$location/g" helloImageTemplateforSIG.json
sed -i -e "s/<region2>/$additionalregion/g" helloImageTemplateforSIG.json
sed -i -e "s/<runOutputName>/$runOutputName/g" helloImageTemplateforSIG.json
sed -i -e "s%<imgBuilderId>%$imgBuilderId%g" helloImageTemplateforSIG.json

Esta próxima parte criará a versão da imagem na galeria.
Envie a configuração de imagem para o serviço Construtor de Imagens do Azure.
az resource create \
--resource-group $sigResourceGroup \
--properties @helloImageTemplateforSIG.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateforSIG01
Inicie o build da imagem.
az resource invoke-action \
-n helloImageTemplateforSIG01 \
--action Run
Criar a imagem e replicá-la para ambas as regiões pode levar algum tempo. Aguarde até que essa parte seja
concluída antes de passar para a criação de uma VM.
Criar a VM
Crie uma VM com base na versão da imagem criada pelo Construtor de Imagens do Azure.
az vm create \
--name myAibGalleryVM \
--admin-username aibuser \
--location $location \
--image
"/subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup/providers/Microsoft.Compute/galleries/$sigN
ame/images/$imageDefName/versions/latest" \
--generate-ssh-keys
Execute o SSH na VM.
ssh aibuser@<publicIpAddress>
Você deve ver que a imagem foi personalizada com uma Mensagem do Dia assim que a conexão SSH é
estabelecida.
*******************************************************
** This VM was built from the: **
** !! AZURE VM IMAGE BUILDER Custom Image !! **
** You have just been Customized :-) **
*******************************************************
Limpar os recursos
Caso deseje tentar agora personalizar novamente a versão da imagem para criar uma versão da mesma
imagem, ignore as próximas etapas e acesse Usar o Construtor de Imagens do Azure para criar outra versão de
imagem.
Isso excluirá a imagem que foi criada, junto com todos os outros arquivos de recurso. Verifique se você concluiu
essa implantação antes de excluir os recursos.
Ao excluir os recursos da galeria de imagens, você precisará excluir todas as versões da imagem para excluir a
definição de imagem usada para criá-las. Para excluir uma galeria, primeiro você precisará excluir todas as
definições de imagem na galeria.
Exclua o modelo do Construtor de Imagens.
az resource delete \
Excluir atribuições de permissões, funções e identidade
az role assignment delete \

az role definition delete --name "$imageRoleDefName"
az identity delete --ids $imgBuilderId
Obtenha a versão da imagem criada pelo Construtor de Imagens, que sempre começa com 0. , e exclua a
versão da imagem
sigDefImgVersion=$(az sig image-version list \

--subscription $subscriptionID --query [].'name' -o json | grep 0. | tr -d '"')
--gallery-image-version $sigDefImgVersion \
--subscription $subscriptionID
Exclua a definição da imagem.

Exclua a galeria.
az sig delete -r $sigName -g $sigResourceGroup
Exclua o grupo de recursos.
az group delete -n $sigResourceGroup -y
Próximas etapas
Saiba mais sobre as Galerias de Imagens Compartilhadas do no Azure.
Versão prévia: criar uma VM do Windows com o
construtor de imagens do Azure
Este artigo mostra como você pode criar uma imagem personalizada do Windows usando o construtor de
imagem de VM do Azure. O exemplo neste artigo usa os personalizadores para personalizar a imagem:
PowerShell (ScriptUri) – Baixe e execute um script do PowerShell.
Reinicialização do Windows – reinicia a VM.
PowerShell (embutido) – executar um comando específico. Neste exemplo, ele cria um diretório na VM
usando mkdir c:\\buildActions .
Arquivo – Copie um arquivo do GitHub para a VM. Este exemplo copia index.MD para
c:\buildArtifacts\index.html na VM.
buildTimeoutInMinutes-aumentar um tempo de compilação para permitir compilações mais longas, o
padrão é de 240 minutos e você pode aumentar um tempo de compilação para permitir compilações mais
longas.
vmProfile-especificando uma vmSize e propriedades de rede
osDiskSizeGB-você pode aumentar o tamanho da imagem
identidade-fornecendo uma identidade para o construtor de imagens do Azure usar durante a compilação
Você também pode especificar um buildTimeoutInMinutes . O padrão é de 240 minutos, e você pode aumentar
um tempo de compilação para permitir compilações mais longas.
Usaremos um modelo .json de exemplo para configurar a imagem. O arquivo. JSON que estamos usando está
aqui: helloImageTemplateWin.jsem.
IMPORTANT
az feature show --namespace Microsoft.VirtualMachineImages --name VirtualMachineTemplatePreview | grep state

az provider show -n Microsoft.VirtualMachineImages | grep registrationState
az provider show -n Microsoft.KeyVault | grep registrationState
az provider show -n Microsoft.Storage | grep registrationState

Definir variáveis
# Resource group name - we are using myImageBuilderRG in this example

imageResourceGroup=myWinImgBuilderRG
# Region location
location=WestUS2
# Name for the image
imageName=myWinBuilderImage
# Run output name
runOutputName=aibWindows
# name of the image to be created
imageName=aibWinImage
Criar uma variável para a ID da assinatura. Obtenha isso usando az account show | grep id .
subscriptionID=<Your subscription ID>

Esse grupo de recursos é usado para armazenar o artefato do modelo de configuração de imagem e a imagem.
az group create -n $imageResourceGroup -l $location

grupo de recursos
O Image Builder usará a identidade do usuário fornecida para injetar a imagem no grupo de recursos. Neste
exemplo, você criará uma definição de função do Azure que tem as ações granulares para executar a
distribuição da imagem. A definição de função será então atribuída à identidade do usuário.
Criar identidade gerenciada atribuída pelo usuário e conceder

permissões
idenityName=aibBuiUserId$(date +'%s')
az identity create -g $imageResourceGroup -n $idenityName
# get identity id
imgBuilderCliId=$(az identity show -g $imageResourceGroup -n $idenityName | grep "clientId" | cut -c16- | tr
-d '",')

imgBuilderId=/subscriptions/$subscriptionID/resourcegroups/$imageResourceGroup/providers/Microsoft.ManagedId
entity/userAssignedIdentities/$idenityName
# download preconfigured role definition example

curl

sed -i -e "s/<rgName>/$imageResourceGroup/g" aibRoleImageCreation.json


--role $imageRoleDefName \
--scope /subscriptions/$subscriptionID/resourceGroups/$imageResourceGroup
Baixar o exemplo de modelo de configuração de imagem

Um modelo de configuração de imagem com parâmetros foi criado para você tentar. Baixe o arquivo example.
JSON e configure-o com as variáveis que você definiu anteriormente.
curl
om_Windows_Managed_Image/helloImageTemplateWin.json -o helloImageTemplateWin.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateWin.json

sed -i -e "s/<rgName>/$imageResourceGroup/g" helloImageTemplateWin.json
sed -i -e "s/<region>/$location/g" helloImageTemplateWin.json
sed -i -e "s/<imageName>/$imageName/g" helloImageTemplateWin.json
sed -i -e "s/<runOutputName>/$runOutputName/g" helloImageTemplateWin.json
sed -i -e "s%<imgBuilderId>%$imgBuilderId%g" helloImageTemplateWin.json
Você pode modificar este exemplo, no terminal usando um editor de texto como vi .
vi helloImageTemplateWin.json
NOTE
Para a imagem de origem, você sempre deve especificar uma versão, não pode usar latest . Se você adicionar ou
alterar o grupo de recursos para o qual a imagem é distribuída, deverá fazer com que as permissões sejam definidas no
grupo de recursos.
Criar a imagem
Enviar a configuração de imagem para o serviço do construtor de imagens de VM
--resource-group $imageResourceGroup \
--properties @helloImageTemplateWin.json \
--is-full-object \
-n helloImageTemplateWin01
Ao concluir, isso retornará uma mensagem de êxito de volta ao console e criará um

Image Builder Configuration Template no $imageResourceGroup . Você pode ver esse recurso no grupo de
recursos na portal do Azure, se você habilitar ' Mostrar tipos ocultos '.
Em segundo plano, o Image Builder também criará um grupo de recursos de preparo em sua assinatura. Esse
grupo de recursos é usado para a compilação da imagem. Ele estará neste formato:
IT_<DestinationResourceGroup>_<TemplateName>
NOTE
Você não deve excluir o grupo de recursos de preparo diretamente. Primeiro, exclua o artefato do modelo de imagem.
isso fará com que o grupo de recursos de preparo seja excluído.
Se o serviço relatar uma falha durante o envio do modelo de configuração de imagem:

Examine essas etapas de solução de problemas .
Você precisará excluir o modelo, usando o trecho a seguir, antes de tentar enviar novamente.
-n helloImageTemplateLinux01
Iniciar a compilação da imagem

Inicie o processo de criação de imagem usando AZ Resource Invoke-Action.
-n helloImageTemplateWin01 \
--action Run
Aguarde até que a compilação seja concluída. Isso pode levar cerca de 15 minutos.
Se você encontrar algum erro, leia essas etapas de solução de problemas .
Criar a VM
Crie a VM usando a imagem que você criou. Substitua <password> pela sua própria senha para o aibuser na
VM.
az vm create \
--name aibImgWinVm00 \
--admin-password <password> \
--image $imageName \
--location $location
Verificar a personalização
Crie uma Conexão de Área de Trabalho Remota com a VM usando o nome de usuário e a senha que você definiu
quando criou a VM. Dentro da VM, abra um prompt de cmd e digite:
dir c:\
Você deve ver esses dois diretórios criados durante a personalização da imagem:
buildActions
buildArtifacts
Limpar
Quando terminar, exclua os recursos.
Excluir o modelo do construtor de imagem
-n helloImageTemplateWin01
Exclua a atribuição de função, a definição de função e a identidade do usuário.

Excluir o grupo de recursos de imagem
az group delete -n $imageResourceGroup
Próximas etapas
Para saber mais sobre os componentes do arquivo. JSON usado neste artigo, consulte referência de modelo do
Image Builder.
Versão prévia: criar uma VM do Windows com o
construtor de imagem do Azure usando o
PowerShell
Este artigo demonstra como você pode criar uma imagem personalizada do Windows usando o módulo do
PowerShell do construtor de imagem de VM do Azure.
Cau t i on
O Construtor de Imagens do Azure está atualmente em versão prévia pública. A versão prévia é fornecida sem
um contrato de nível de serviço. Ela não é recomendada para cargas de trabalho de produção. Alguns recursos
podem não ter suporte ou podem ter restrição de recursos. Para obter mais informações, consulte Termos de
Uso Complementares de Versões Prévias do Microsoft Azure.
Pré-requisitos
Se você optar por usar o PowerShell localmente, este artigo exigirá que você instale o módulo Az PowerShell e
conecte-se à sua conta do Azure usando o cmdlet Connect-AzAccount. Para obter mais informações sobre como
instalar o módulo Az PowerShell, confira Instalar o Azure PowerShell.
IMPORTANT
Embora os módulos do PowerShell AZ. ImageBuilder e AZ. ManagedSer viceIdentity estejam em versão prévia, você
deve instalá-los separadamente usando o Install-Module cmdlet com o AllowPrerelease parâmetro. Depois que
esses módulos do PowerShell ficarem disponíveis para o público geral, eles se tornarão parte das versões futuras do
módulo do PowerShell AZ e estarão disponíveis nativamente em Azure Cloud Shell.
'Az.ImageBuilder', 'Az.ManagedServiceIdentity' | ForEach-Object {Install-Module -Name $_ -AllowPrerelease}
Usar o Azure Cloud Shell

O Azure hospeda o Azure Cloud Shell, um ambiente de shell interativo que pode ser usado por meio do
navegador. É possível usar o bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. É
possível usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo sem precisar
instalar nada no seu ambiente local.
Para iniciar o Azure Cloud Shell:
OPÇ ÃO EXEM P LO / L IN K
Selecione Experimente no canto superior direito de um

bloco de código. Selecionar Experimente não copia
automaticamente o código para o Cloud Shell.
Acesse https://shell.azure.com ou selecione o botão Iniciar

o Cloud Shell para abri-lo no navegador.
Selecione o botão Cloud Shell na barra de menus no canto

superior direito do portal do Azure.
Para executar o código neste artigo no Azure Cloud Shell:

1. Inicie o Cloud Shell.
2. Clique no botão Copiar no bloco de código para copiá-lo.
3. Cole o código na sessão do Cloud Shell ao pressionar Ctrl +Shift +V no Windows e no Linux ou
Cmd +Shift +V no macOS.
4. Pressione Enter para executar o código.
Se tiver várias assinaturas do Azure, escolha a que for adequada para cobrança do recurso. Selecione uma
assinatura específica usando o cmdlet Set-AzContext.
Set-AzContext -SubscriptionId 00000000-0000-0000-0000-000000000000
Registrar recursos
Se esta for a primeira vez que você usa o construtor de imagens do Azure durante a versão prévia, registre o
novo recurso Vir tualMachineTemplatePreview .
Register-AzProviderFeature -ProviderNamespace Microsoft.VirtualMachineImages -FeatureName

VirtualMachineTemplatePreview
NOTE
O RegistrationState pode estar no Registering estado por vários minutos antes da alteração para Registered .
Aguarde até que o status seja registrado antes de continuar.
Get-AzProviderFeature -ProviderNamespace Microsoft.VirtualMachineImages -FeatureName

VirtualMachineTemplatePreview
Registre os provedores de recursos a seguir para uso com sua assinatura do Azure se eles ainda não estiverem
registrados.
Microsoft.Compute
Microsoft.KeyVault
Microsoft.Storage
Microsoft.VirtualMachineImages
Get-AzResourceProvider -ProviderNamespace Microsoft.Compute, Microsoft.KeyVault, Microsoft.Storage,

Microsoft.VirtualMachineImages |
Where-Object RegistrationState -ne Registered |
Register-AzResourceProvider
Definir variáveis
Você usará várias informações repetidamente. Crie variáveis para armazenar as informações.
# Destination image resource group name

$imageResourceGroup = 'myWinImgBuilderRG'
# Azure region
$location = 'WestUS2'
# Name of the image to be created

$imageTemplateName = 'myWinImage'
# Distribution properties of the managed image upon completion

$runOutputName = 'myDistResults'
Crie uma variável para sua ID de assinatura do Azure. Para confirmar que a subscriptionID variável contém sua
ID de assinatura, você pode executar a segunda linha no exemplo a seguir.
# Your Azure Subscription ID

$subscriptionID = (Get-AzContext).Subscription.Id
Write-Output $subscriptionID

Crie um grupo de recursos do Azure usando o cmdlet New-AzResourceGroup. Um grupo de recursos é um
contêiner lógico no qual os recursos do Azure são implantados e gerenciados como um grupo.
O exemplo a seguir cria um grupo de recursos com base no nome na variável $imageResourceGroup na região
especificada na variável $location . Esse grupo de recursos é usado para armazenar o artefato do modelo de
configuração de imagem e a imagem.
New-AzResourceGroup -Name $imageResourceGroup -Location $location
Criar identidade do usuário e definir permissões de função

Conceda permissões do Azure Image Builder para criar imagens no grupo de recursos especificado usando o
exemplo a seguir. Sem essa permissão, o processo de criação de imagem não será concluído com êxito.
Crie variáveis para a definição de função e nomes de identidade. Esses valores devem ser exclusivos.
[int]$timeInt = $(Get-Date -UFormat '%s')

$imageRoleDefName = "Azure Image Builder Image Def $timeInt"
$identityName = "myIdentity$timeInt"
Crie uma identidade de usuário.
New-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name $identityName
Armazene o recurso de identidade e as IDs de entidade de segurança em variáveis.

$identityNameResourceId = (Get-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name
$identityName).Id
$identityNamePrincipalId = (Get-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name
$identityName).PrincipalId
Atribuir permissões para identidade para distribuir imagens

Baixe o arquivo de configuração. JSON e modifique-o com base nas configurações definidas neste artigo.
$myRoleImageCreationUrl =
'https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solutions/12_Creating_AIB_Securit
y_Roles/aibRoleImageCreation.json'
$myRoleImageCreationPath = "$env:TEMP\myRoleImageCreation.json"
Invoke-WebRequest -Uri $myRoleImageCreationUrl -OutFile $myRoleImageCreationPath -UseBasicParsing
$Content = Get-Content -Path $myRoleImageCreationPath -Raw

$Content = $Content -replace '<subscriptionID>', $subscriptionID
$Content = $Content -replace '<rgName>', $imageResourceGroup
$Content = $Content -replace 'Azure Image Builder Service Image Creation Role', $imageRoleDefName
$Content | Out-File -FilePath $myRoleImageCreationPath -Force
Crie a definição da função.
New-AzRoleDefinition -InputFile $myRoleImageCreationPath
Conceda a definição de função à entidade de serviço do construtor de imagem.
$RoleAssignParams = @{
ObjectId = $identityNamePrincipalId
RoleDefinitionName = $imageRoleDefName
Scope = "/subscriptions/$subscriptionID/resourceGroups/$imageResourceGroup"
}
New-AzRoleAssignment @RoleAssignParams
NOTE
Se você receber o erro: "New-AzRoleDefinition: limite de definição de função excedido. Não é possível criar mais definições
de função.", consulte solucionar problemas do RBAC do Azure.

Crie a galeria.
$myGalleryName = 'myImageGallery'
$imageDefName = 'winSvrImages'
New-AzGallery -GalleryName $myGalleryName -ResourceGroupName $imageResourceGroup -Location $location
Criar uma definição de galeria.

$GalleryParams = @{
GalleryName = $myGalleryName
ResourceGroupName = $imageResourceGroup
Location = $location
Name = $imageDefName
OsState = 'generalized'
OsType = 'Windows'
Publisher = 'myCo'
Offer = 'Windows'
Sku = 'Win2019'
}
New-AzGalleryImageDefinition @GalleryParams
Criar uma imagem

Crie um objeto de origem do Azure Image Builder. Consulte Localizar imagens de VM do Windows no Azure
Marketplace com Azure PowerShell para obter valores de parâmetro válidos.
$SrcObjParams = @{
SourceTypePlatformImage = $true
Publisher = 'MicrosoftWindowsServer'
Offer = 'WindowsServer'
Sku = '2019-Datacenter'
Version = 'latest'
}
$srcPlatform = New-AzImageBuilderSourceObject @SrcObjParams
Crie um objeto distribuidor do Azure Image Builder.
$disObjParams = @{
SharedImageDistributor = $true
ArtifactTag = @{tag='dis-share'}
GalleryImageId =
"/subscriptions/$subscriptionID/resourceGroups/$imageResourceGroup/providers/Microsoft.Compute/galleries/$my
GalleryName/images/$imageDefName"
ReplicationRegion = $location
RunOutputName = $runOutputName
ExcludeFromLatest = $false
}
$disSharedImg = New-AzImageBuilderDistributorObject @disObjParams
Crie um objeto de personalização do Azure Image Builder.
$ImgCustomParams01 = @{
PowerShellCustomizer = $true
CustomizerName = 'settingUpMgmtAgtPath'
RunElevated = $false
Inline = @("mkdir c:\\buildActions", "mkdir c:\\buildArtifacts", "echo Azure-Image-Builder-Was-Here >
c:\\buildActions\\buildActionsOutput.txt")
}
$Customizer01 = New-AzImageBuilderCustomizerObject @ImgCustomParams01
Crie um segundo objeto de personalização do Azure Image Builder.

$ImgCustomParams02 = @{
FileCustomizer = $true
CustomizerName = 'downloadBuildArtifacts'
Destination = 'c:\\buildArtifacts\\index.html'
SourceUri =
'https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/exampleArtifacts
/buildArtifacts/index.html'
}
$Customizer02 = New-AzImageBuilderCustomizerObject @ImgCustomParams02
Crie um modelo do Azure Image Builder.
$ImgTemplateParams = @{
ImageTemplateName = $imageTemplateName
ResourceGroupName = $imageResourceGroup
Source = $srcPlatform
Distribute = $disSharedImg
Customize = $Customizer01, $Customizer02
Location = $location
UserAssignedIdentityId = $identityNameResourceId
}
New-AzImageBuilderTemplate @ImgTemplateParams
Quando concluído, uma mensagem é retornada e um modelo de configuração do construtor de imagem é

criado no $imageResourceGroup .
Para determinar se o processo de criação de modelo foi bem-sucedido, você pode usar o exemplo a seguir.
Get-AzImageBuilderTemplate -ImageTemplateName $imageTemplateName -ResourceGroupName $imageResourceGroup |

Select-Object -Property Name, LastRunStatusRunState, LastRunStatusMessage, ProvisioningState
Em segundo plano, o construtor de imagem também cria um grupo de recursos de preparo em sua assinatura.
Esse grupo de recursos é usado para a compilação da imagem. Ele está no formato:
IT_<DestinationResourceGroup>_<TemplateName> .
WARNING
Não exclua o grupo de recursos de preparo diretamente. Excluir o artefato do modelo de imagem, isso fará com que o
grupo de recursos de preparo seja excluído.
Se o serviço relatar uma falha durante o envio do modelo de configuração de imagem:

Consulte Solucionando problemas de falhas de compilação de imagem de VM do Azure (AIB).
Exclua o modelo usando o exemplo a seguir antes de tentar novamente.
Remove-AzImageBuilderTemplate -ImageTemplateName $imageTemplateName -ResourceGroupName $imageResourceGroup
Iniciar a compilação da imagem

Envie a configuração de imagem para o serviço do construtor de imagem de VM.
Start-AzImageBuilderTemplate -ResourceGroupName $imageResourceGroup -Name $imageTemplateName
Aguarde a conclusão do processo de criação de imagem. Esta etapa pode levar até uma hora.
Se você encontrar erros, examine solução de problemas de falhas de compilação de imagem de VM do Azure
(AIB).

Armazene as credenciais de logon da VM em uma variável. A senha deve ser complexa.
$Cred = Get-Credential
Crie a VM usando a imagem que você criou.
$ArtifactId = (Get-AzImageBuilderRunOutput -ImageTemplateName $imageTemplateName -ResourceGroupName

$imageResourceGroup).ArtifactId
New-AzVM -ResourceGroupName $imageResourceGroup -Image $ArtifactId -Name myWinVM01 -Credential $Cred
Verificar as personalizações
quando criou a VM. Dentro da VM, abra o PowerShell e execute Get-Content conforme mostrado no exemplo a
seguir:
Get-Content -Path C:\buildActions\buildActionsOutput.txt
Você deve ver a saída com base no conteúdo do arquivo criado durante o processo de personalização da
imagem.
Azure-Image-Builder-Was-Here
Na mesma sessão do PowerShell, verifique se a segunda personalização foi concluída com êxito verificando a
presença do arquivo c:\buildArtifacts\index.html , conforme mostrado no exemplo a seguir:
Get-ChildItem c:\buildArtifacts\
O resultado deve ser uma listagem de diretório mostrando o arquivo baixado durante o processo de
personalização da imagem.
Directory: C:\buildArtifacts
Mode LastWriteTime Length Name

---- ------------- ------ ----
-a--- 29/01/2021 10:04 276 index.html
Limpar os recursos
Se os recursos criados neste artigo não forem necessários, você poderá excluí-los executando o exemplo a
seguir.
Excluir o modelo do construtor de imagem
Remove-AzImageBuilderTemplate -ResourceGroupName $imageResourceGroup -Name $imageTemplateName
Excluir o grupo de recursos de imagem

Cau t i on
O exemplo a seguir exclui o grupo de recursos especificado e todos os recursos contidos nele. Se existirem
recursos fora do escopo deste artigo no grupo de recursos especificado, eles também serão excluídos.
Remove-AzResourceGroup -Name $imageResourceGroup
Próximas etapas
Image Builder.
Controles de conformidade regulatória do Azure
Policy para o Construtor de Imagens do Azure
A Conformidade Regulatória no Azure Policy fornece definições de iniciativas criadas e gerenciadas pela
Microsoft, conhecidas como internos, para os domínios de conformidade e os controles de segurança
relacionados a diferentes padrões de conformidade. Esta página lista os domínios de conformidade e os
controles de segurança do Construtor de Imagens do Azure. Você pode atribuir os itens internos a um
controle de segurança individualmente a fim de ajudar a manter seus recursos do Azure em conformidade
com o padrão específico.
O título de cada definição de política interna leva à definição da política no portal do Azure. Use o link na coluna
Versão da Política para ver a origem no repositório GitHub do Azure Policy.
IMPORTANT
Cada controle abaixo está associado com uma ou mais definições do Azure Policy. Essas políticas podem ajudar você a
avaliar a conformidade com o controle. No entanto, geralmente não há uma correspondência um para um ou completa
entre um controle e uma ou mais políticas. Dessa forma, Conformidade no Azure Policy refere-se somente às próprias
políticas. Não garante que você está totalmente em conformidade com todos os requisitos de um controle. Além disso, o
padrão de conformidade inclui controles que não são abordados por nenhuma definição do Azure Policy no momento.
Portanto, a conformidade no Azure Policy é somente uma exibição parcial do status de conformidade geral. As associações
entre os controles e as definições de Conformidade Regulatória do Azure Policy para esses padrões de conformidade
podem ser alteradas ao longo do tempo.
Azure Security Benchmark

O Azure Security Benchmark fornece recomendações sobre como você pode proteger suas soluções de nuvem
no Azure. Para ver como esse serviço é mapeado completamente para o Azure Security Benchmark, confira os
arquivos de mapeamento do Azure Security Benchmark.
Para examinar como as iniciativas internas disponíveis do Azure Policy de todos os serviços do Azure são
mapeadas para esse padrão de conformidade, confira Conformidade regulatória do Azure Policy – Azure
Security Benchmark.
VERSÃ O DA
T ÍT ULO DO P O L ÍT IC A P O L ÍT IC A
DO M ÍN IO ID DO C O N T RO L E C O N T RO L E ( PO RTA L DO A ZURE ) ( GIT HUB)
Segurança de rede NS-2 Conectar redes Os modelos do 1.0.1

privadas Construtor de
Imagens de VM
devem usar o link
privado
Segurança de rede NS-3 Estabelecer o acesso Os modelos do 1.0.1

à rede privada aos Construtor de
serviços do Azure Imagens de VM
devem usar o link
privado
Próximas etapas
Saiba mais sobre a Conformidade Regulatória do Azure Policy.
Confira os internos no repositório Azure Policy GitHub.
Usar o construtor de imagens do Azure para VMs
Linux permitindo o acesso a uma VNET do Azure
existente
Este artigo mostra como você pode usar o construtor de imagens do Azure para criar uma imagem
personalizada do Linux básica que tem acesso a recursos existentes em uma VNET. A VM de compilação que
você cria é implantada em uma VNET nova ou existente que você especificar em sua assinatura. Quando você
usa uma VNET do Azure existente, o serviço do construtor de imagens do Azure não requer conectividade de
rede pública.
IMPORTANT
Pré-requisitos

Primeiro, você deve se registrar para o serviço do construtor de imagem do Azure. O registro concede a
permissão de serviço para criar, gerenciar e excluir um grupo de recursos de preparo. O serviço também tem
direitos para adicionar recursos do grupo que são necessários para a compilação da imagem.

Você usará algumas informações repetidamente. Crie algumas variáveis para armazenar essas informações.
# set your environment variables here!!!!
# destination image resource group

imageResourceGroup=aibImageRG01
# location (see possible locations in main docs)

location=WestUS2
# your subscription
# get the current subID : 'az account show | grep id'
subscriptionID=$(az account show | grep id | tr -d '",' | cut -c7-)

imageName=aibCustomLinuxImg01

runOutputName=aibCustLinManImg01ro
# VNET properties (update to match your existing VNET, or leave as-is for demo)
# VNET name
vnetName=myexistingvnet01
# subnet name
subnetName=subnet01
# VNET resource group name
# NOTE! The VNET must always be in the same region as the AIB service region.
vnetRgName=existingVnetRG
# Existing Subnet NSG Name or the demo will create it
nsgName=aibdemoNsg
Configurar a rede
Se você não tiver um VNET\Subnet\NSG existente, use o script a seguir para criar um.
az group create -n $vnetRgName -l $location
# Create VNET

--resource-group $vnetRgName \
--name $vnetName --address-prefix 10.0.0.0/16 \
--subnet-name $subnetName --subnet-prefix 10.0.0.0/24
# Create base NSG to simulate an existing NSG
az network nsg create -g $vnetRgName -n $nsgName

--vnet-name $vnetName \
--name $subnetName \
--network-security-group $nsgName
# NOTE! The VNET must always be in the same region as the Azure Image Builder service region.
Adicionar regra de grupo de segurança de rede
Essa regra permite a conectividade do balanceador de carga do Azure Image Builder com a VM do proxy. A
porta 60001 é para sistemas operacionais Linux e a porta 60000 é para sistemas operacionais Windows. A VM
proxy conecta-se à VM de compilação usando a porta 22 para Linux OSs ou a porta 5986 para sistemas
operacionais Windows.

--nsg-name $nsgName \
-n AzureImageBuilderNsgRule \
--priority 400 \
--source-address-prefixes AzureLoadBalancer \
--destination-address-prefixes VirtualNetwork \
--destination-port-ranges 60000-60001 --direction inbound \
--access Allow --protocol Tcp \
--description "Allow Image Builder Private Link Access to Proxy VM"
Desabilitar política de serviço particular na sub-rede

--disable-private-link-service-network-policies true
Para obter mais informações sobre a rede do Image Builder, consulte Opções de rede do serviço do Azure Image
Builder.
Modificar o modelo de exemplo e criar função

# download the example and configure it with your vars
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/1a_Creating_a_Cus
tom_Linux_Image_on_Existing_VNET/existingVNETLinux.json -o existingVNETLinux.json
curl
_Roles/aibRoleNetworking.json -o aibRoleNetworking.json
curl
sed -i -e "s/<subscriptionID>/$subscriptionID/g" existingVNETLinux.json

sed -i -e "s/<rgName>/$imageResourceGroup/g" existingVNETLinux.json
sed -i -e "s/<region>/$location/g" existingVNETLinux.json
sed -i -e "s/<imageName>/$imageName/g" existingVNETLinux.json
sed -i -e "s/<runOutputName>/$runOutputName/g" existingVNETLinux.json
sed -i -e "s/<vnetName>/$vnetName/g" existingVNETLinux.json

sed -i -e "s/<subnetName>/$subnetName/g" existingVNETLinux.json
sed -i -e "s/<vnetRgName>/$vnetRgName/g" existingVNETLinux.json

sed -i -e "s/<subscriptionID>/$subscriptionID/g" aibRoleNetworking.json

sed -i -e "s/<vnetRgName>/$vnetRgName/g" aibRoleNetworking.json
Definir permissões no grupo de recursos
# create user assigned identity for image builder

# get identity id
-d '",')

# update the template

sed -i -e "s%<imgBuilderId>%$imgBuilderId%g" existingVNETLinux.json
# make role name unique, to avoid clashes in the same Azure Active Directory domain
netRoleDefName="Azure Image Builder Network Def"$(date +'%s')
# update the definitions

sed -i -e "s/Azure Image Builder Service Networking Role/$netRoleDefName/g" aibRoleNetworking.json
Em vez de conceder menor granularidade ao construtor de imagem e maior privilégio, você pode criar duas
funções. Uma fornece ao Construtor permissões para criar uma imagem, a outra permite que ela Conecte a VM
de compilação e o balanceador de carga à sua VNET.

az role definition create --role-definition ./aibRoleNetworking.json


--role $netRoleDefName \
--scope /subscriptions/$subscriptionID/resourceGroups/$vnetRgName
Para obter mais informações sobre permissões, consulte configurar permissões de serviço do construtor de
imagem do Azure usando CLI do Azure ou configurar permissões de serviço do construtor de imagem do Azure
usando o PowerShell.
Criar a imagem
--properties @existingVNETLinux.json \
--is-full-object \
-n existingVNETLinuxTemplate01
# Wait approximately 1-3 mins (validation, permissions etc.)
-n existingVNETLinuxTemplate01 \
--action Run
# Wait approximately 15 mins
Criar a VM
az vm create \
--name aibImgVm0001 \
--generate-ssh-keys
estabelecida.
*******************************************************
*******************************************************
Limpar os recursos
Se você quiser agora repersonalizar a versão da imagem para criar uma nova versão da mesma imagem, ignore
as próximas etapas e vá para usar o construtor de imagem do Azure para criar outra versão de imagem.
O seguinte exclui a imagem que foi criada, junto com todos os outros arquivos de recurso. Verifique se você
concluiu essa implantação antes de excluir os recursos.
-n existingVNETLinuxTemplate01


--scope /subscriptions/$subscriptionID/resourceGroups/$vnetRgName

az role definition delete --name "$netRoleDefName"
Se você criou uma VNET para este guia de início rápido, poderá excluir a VNET se ela não estiver mais sendo
usada.
Próximas etapas
Usar o construtor de imagens do Azure para VMs
do Windows permitindo o acesso a uma VNET do
Azure existente
Este artigo mostra como você pode usar o construtor de imagens do Azure para criar uma imagem básica do
Windows personalizada que tem acesso a recursos existentes em uma VNET. A VM de compilação que você cria
é implantada em uma VNET nova ou existente que você especificar em sua assinatura. Quando você usa uma
VNET do Azure existente, o serviço do construtor de imagens do Azure não requer conectividade de rede
pública.
IMPORTANT





# Register for Azure Image Builder Feature
Register-AzProviderFeature -FeatureName VirtualMachineTemplatePreview -ProviderNamespace

Get-AzProviderFeature -FeatureName VirtualMachineTemplatePreview -ProviderNamespace

# wait until RegistrationState is set to 'Registered'

Você usará algumas informações repetidamente. Crie algumas variáveis para armazenar essas informações.
# Step 1: Import module

Import-Module Az.Accounts
# Step 2: get existing context

$currentAzContext = Get-AzContext
# destination image resource group

$imageResourceGroup="aibImageRG"
# location (see possible locations in main docs)

$location="westus2"
## if you need to change your subscription: Get-AzSubscription / Select-AzSubscription -SubscriptionName
# get subscription, this will get your current subscription

$subscriptionID=$currentAzContext.Subscription.Id

$imageName="win2019image01"

$runOutputName="win2019ManImg02ro"
# image template name

$imageTemplateName="window2019VnetTemplate03"
# distribution properties object name (runOutput), i.e. this gives you the properties of the managed image
on completion
$runOutputName="winSvrSigR01"
# VNET properties (update to match your existing VNET, or leave as-is for demo)
# VNET name
$vnetName="myexistingvnet01"
# subnet name
$subnetName="subnet01"
# VNET resource group name
$vnetRgName="existingVnetRG"
# Existing Subnet NSG Name or the demo will create it
$nsgName="aibdemoNsg"
# NOTE! The VNET must always be in the same region as the AIB service region.

New-AzResourceGroup -Name $imageResourceGroup -Location $location
Configurar a rede
Se você não tiver um VNET\Subnet\NSG existente, use o script a seguir para criar um.
New-AzResourceGroup -Name $vnetRgName -Location $location
## Create base NSG to simulate an existing NSG

New-AzNetworkSecurityGroup -Name $nsgName -ResourceGroupName $vnetRgName -location $location
$nsg = Get-AzNetworkSecurityGroup -Name $nsgName -ResourceGroupName $vnetRgName
$subnet = New-AzVirtualNetworkSubnetConfig -Name $subnetName -AddressPrefix "10.0.1.0/24" -

PrivateLinkServiceNetworkPoliciesFlag "Disabled" -NetworkSecurityGroup $nsg
New-AzVirtualNetwork -Name $vnetName -ResourceGroupName $vnetRgName -Location $location -AddressPrefix

"10.0.0.0/16" -Subnet $subnet
## NOTE! The VNET must always be in the same region as the Azure Image Builder service region.
Adicionar regra de grupo de segurança de rede

Essa regra permite a conectividade do balanceador de carga do Azure Image Builder com a VM do proxy. A
porta 60001 é para sistemas operacionais Linux e a porta 60000 é para sistemas operacionais Windows. A VM
proxy conecta-se à VM de compilação usando a porta 22 para Linux OSs ou a porta 5986 para sistemas
operacionais Windows.
Get-AzNetworkSecurityGroup -Name $nsgName -ResourceGroupName $vnetRgName | Add-AzNetworkSecurityRuleConfig

-Name AzureImageBuilderAccess -Description "Allow Image Builder Private Link Access to Proxy VM" -Access
Allow -Protocol Tcp -Direction Inbound -Priority 400 -SourceAddressPrefix AzureLoadBalancer -SourcePortRange
* -DestinationAddressPrefix VirtualNetwork -DestinationPortRange 60000-60001 | Set-AzNetworkSecurityGroup
Desabilitar política de serviço particular na sub-rede
$virtualNetwork= Get-AzVirtualNetwork -Name $vnetName -ResourceGroupName $vnetRgName
($virtualNetwork | Select -ExpandProperty subnets | Where-Object {$_.Name -eq $subnetName}

).privateLinkServiceNetworkPolicies = "Disabled"
$virtualNetwork | Set-AzVirtualNetwork
Para obter mais informações sobre a rede do Image Builder, consulte Opções de rede do serviço do Azure Image
Builder.
Modificar o modelo de exemplo e criar função

$templateUrl="https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/1a_
Creating_a_Custom_Win_Image_on_Existing_VNET/existingVNETWindows.json"
$templateFilePath = "existingVNETWindows.json"
$aibRoleNetworkingUrl="https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solutions/1
2_Creating_AIB_Security_Roles/aibRoleNetworking.json"
$aibRoleNetworkingPath = "aibRoleNetworking.json"
$aibRoleImageCreationUrl="https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solution
s/12_Creating_AIB_Security_Roles/aibRoleImageCreation.json"
$aibRoleImageCreationPath = "aibRoleImageCreation.json"
# download configs
Invoke-WebRequest -Uri $templateUrl -OutFile $templateFilePath -UseBasicParsing
Invoke-WebRequest -Uri $aibRoleNetworkingUrl -OutFile $aibRoleNetworkingPath -UseBasicParsing
Invoke-WebRequest -Uri $aibRoleImageCreationUrl -OutFile $aibRoleImageCreationPath -UseBasicParsing
# update AIB image config template

((Get-Content -path $templateFilePath -Raw) -replace '<subscriptionID>',$subscriptionID) | Set-Content -Path
$templateFilePath
((Get-Content -path $templateFilePath -Raw) -replace '<rgName>',$imageResourceGroup) | Set-Content -Path
$templateFilePath
((Get-Content -path $templateFilePath -Raw) -replace '<region>',$location) | Set-Content -Path
$templateFilePath
((Get-Content -path $templateFilePath -Raw) -replace '<runOutputName>',$runOutputName) | Set-Content -Path
$templateFilePath
((Get-Content -path $templateFilePath -Raw) -replace '<imageName>',$imageName) | Set-Content -Path
$templateFilePath
((Get-Content -path $templateFilePath -Raw) -replace '<vnetName>',$vnetName) | Set-Content -Path

$templateFilePath
((Get-Content -path $templateFilePath -Raw) -replace '<subnetName>',$subnetName) | Set-Content -Path
$templateFilePath
((Get-Content -path $templateFilePath -Raw) -replace '<vnetRgName>',$vnetRgName) | Set-Content -Path
$templateFilePath
Criar uma identidade atribuída pelo usuário e definir permissões

# setup role def names, these need to be unique
$timeInt=$(get-date -UFormat "%s")
$imageRoleDefName="Azure Image Builder Image Def"+$timeInt
$networkRoleDefName="Azure Image Builder Network Def"+$timeInt
$idenityName="aibIdentity"+$timeInt
# create user identity

## Add AZ PS module to support AzUserAssignedIdentity
Install-Module -Name Az.ManagedServiceIdentity
# create identity
New-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name $idenityName
$idenityNameResourceId=$(Get-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name

$idenityName).Id
$idenityNamePrincipalId=$(Get-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name
$idenityName).PrincipalId
# update template with identity

((Get-Content -path $templateFilePath -Raw) -replace '<imgBuilderId>',$idenityNameResourceId) | Set-Content
-Path $templateFilePath
# update the role defintion names

((Get-Content -path $aibRoleImageCreationPath -Raw) -replace 'Azure Image Builder Service Image Creation
Role',$imageRoleDefName) | Set-Content -Path $aibRoleImageCreationPath
((Get-Content -path $aibRoleNetworkingPath -Raw) -replace 'Azure Image Builder Service Networking
Role',$networkRoleDefName) | Set-Content -Path $aibRoleNetworkingPath
# update role definitions

((Get-Content -path $aibRoleNetworkingPath -Raw) -replace '<subscriptionID>',$subscriptionID) | Set-Content
-Path $aibRoleNetworkingPath
((Get-Content -path $aibRoleNetworkingPath -Raw) -replace '<vnetRgName>',$vnetRgName) | Set-Content -Path
$aibRoleNetworkingPath
((Get-Content -path $aibRoleImageCreationPath -Raw) -replace '<subscriptionID>',$subscriptionID) | Set-

Content -Path $aibRoleImageCreationPath
((Get-Content -path $aibRoleImageCreationPath -Raw) -replace '<rgName>', $imageResourceGroup) | Set-Content
-Path $aibRoleImageCreationPath
# create role definitions from role configurations examples, this avoids granting contributor to the SPN
New-AzRoleDefinition -InputFile ./aibRoleImageCreation.json
New-AzRoleDefinition -InputFile ./aibRoleNetworking.json
# grant role definition to image builder user identity

New-AzRoleAssignment -ObjectId $idenityNamePrincipalId -RoleDefinitionName $imageRoleDefName -Scope
"/subscriptions/$subscriptionID/resourceGroups/$imageResourceGroup"
New-AzRoleAssignment -ObjectId $idenityNamePrincipalId -RoleDefinitionName $networkRoleDefName -Scope
"/subscriptions/$subscriptionID/resourceGroups/$vnetRgName"
Para obter mais informações sobre permissões, consulte configurar permissões de serviço do construtor de
imagem do Azure usando CLI do Azure ou configurar permissões de serviço do construtor de imagem do Azure
Criar a imagem
New-AzResourceGroupDeployment -ResourceGroupName $imageResourceGroup -TemplateFile $templateFilePath -api-

version "2020-02-14" -imageTemplateName $imageTemplateName -svclocation $location
# note this will take minute, as validation is run (security / dependencies etc.)

Invoke-AzResourceAction -ResourceName $imageTemplateName -ResourceGroupName $imageResourceGroup -
ResourceType Microsoft.VirtualMachineImages/imageTemplates -ApiVersion "2020-02-14" -Action Run -Force
Obter o status e as propriedades da compilação da imagem

Consultar o modelo de imagem para obter o status atual ou da última execução e as configurações do
modelo de imagem
$managementEp = $currentAzureContext.Environment.ResourceManagerUrl
$urlBuildStatus = [System.String]::Format("
{0}subscriptions/{1}/resourceGroups/$imageResourceGroup/providers/Microsoft.VirtualMachineImages/imageTempla
tes/{2}?api-version=2020-02-14", $managementEp, $currentAzureContext.Subscription.Id,$imageTemplateName)
$buildStatusResult = Invoke-WebRequest -Method GET -Uri $urlBuildStatus -UseBasicParsing -Headers

@{"Authorization"= ("Bearer " + $accessToken)} -ContentType application/json
$buildJsonStatus =$buildStatusResult.Content
$buildJsonStatus
A compilação da imagem para este exemplo levará aproximadamente 50 minutos (várias reinicializações,
instalação/reinicialização do Windows Update), quando você consultar o status, você precisa procurar
lastRunStatus, abaixo mostra que a compilação ainda está em execução, se ela tiver sido concluída com êxito, ela
mostraria ' êxito '.
"lastRunStatus": {
"startTime": "2019-08-21T00:39:40.61322415Z",
"endTime": "0001-01-01T00:00:00Z",
"runState": "Running",
"runSubState": "Building",
"message": ""
},
Consultar as propriedades de distribuição

Se você estiver distribuindo para um local de VHD, precisará de propriedades de local de imagem gerenciada ou
status de replicações da Galeria de imagens compartilhadas, você precisa consultar o ' runOutput ', sempre que
tiver um destino de distribuição, terá um runOutput exclusivo para descrever as propriedades do tipo de
distribuição.
$managementEp = $currentAzureContext.Environment.ResourceManagerUrl
$urlRunOutputStatus = [System.String]::Format("
{0}subscriptions/{1}/resourceGroups/$imageResourceGroup/providers/Microsoft.VirtualMachineImages/imageTempla
tes/$imageTemplateName/runOutputs/{2}?api-version=2020-02-14", $managementEp,
$currentAzureContext.Subscription.Id, $runOutputName)
$runOutStatusResult = Invoke-WebRequest -Method GET -Uri $urlRunOutputStatus -UseBasicParsing -Headers

@{"Authorization"= ("Bearer " + $accessToken)} -ContentType application/json
$runOutJsonStatus =$runOutStatusResult.Content
$runOutJsonStatus

Agora que a compilação foi concluída, você pode criar uma VM a partir da imagem. Use os exemplos da
documentação New-AzVM do PowerShell.
Limpar
Excluir artefato de modelo de imagem
# Get ResourceID of the Image Template

$resTemplateId = Get-AzResource -ResourceName $imageTemplateName -ResourceGroupName $imageResourceGroup -
ResourceType Microsoft.VirtualMachineImages/imageTemplates -ApiVersion "2020-02-14"
### Delete Image Template Artifact

Remove-AzResource -ResourceId $resTemplateId.ResourceId -Force
Excluir atribuição de função
## remove role assignments

Remove-AzRoleAssignment -ObjectId $idenityNamePrincipalId -RoleDefinitionName $imageRoleDefName -Scope
Remove-AzRoleAssignment -ObjectId $idenityNamePrincipalId -RoleDefinitionName $networkRoleDefName -Scope
"/subscriptions/$subscriptionID/resourceGroups/$vnetRgName"
## remove definitions
Remove-AzRoleDefinition -Id $imageRoleDefObjId -Force
Remove-AzRoleDefinition -Id $networkRoleObjId -Force
## delete identity
Remove-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name $idenityName -Force
Excluir grupos de recursos
Remove-AzResourceGroup $imageResourceGroup -Force
# delete VNET created

# BEWARE!!!!! In this example, you have either used an existing VNET or created one for this example. Do not
delete your existing VNET. If you want to delete the VNET Resource group used in this example '$vnetRgName',
modify the above code.
Próximas etapas
Opções de rede do serviço do Azure Image Builder
Você precisa optar por implantar o construtor de imagens do Azure com ou sem uma VNET existente.
Implantar sem especificar uma VNET existente

Se você não especificar uma VNET existente, o construtor de imagem do Azure criará uma VNET e uma sub-rede
no grupo de recursos de preparo. Um recurso de IP público é usado com um grupo de segurança de rede para
restringir o tráfego de entrada para o serviço do construtor de imagens do Azure. O IP público facilita o canal
para comandos do Azure Image Builder durante a compilação da imagem. Depois que a compilação for
concluída, a VM, o IP público, os discos e a VNET serão excluídos. Para usar essa opção, não especifique
nenhuma propriedade de VNET.
Implantar usando uma VNET existente

Se você especificar uma VNET e uma sub-rede, o construtor de imagens do Azure implantará a VM de
compilação em sua VNET escolhida. Você pode acessar recursos que podem ser acessados em sua VNET. Você
também pode criar uma VNET em silo que não está conectada a nenhuma outra VNET. Se você especificar uma
VNET, o construtor de imagens do Azure não usará um endereço IP público. A comunicação do serviço do
construtor de imagens do Azure para a VM de compilação usa a tecnologia de link privado do Azure.
Para obter mais informações, consulte um dos exemplos a seguir:
Usar o construtor de imagens do Azure para VMs do Windows permitindo o acesso a uma VNET do Azure
existente
Usar o construtor de imagens do Azure para VMs Linux permitindo o acesso a uma VNET do Azure existente
O que é o Link Privado do Azure?
O link privado do Azure fornece conectividade privada de uma rede virtual para a PaaS (plataforma como um
serviço) do Azure, de Propriedade do cliente ou serviços de parceiros da Microsoft. Ele simplifica a arquitetura
de rede e protege a conexão entre os pontos de extremidade no Azure, eliminando a exposição de dados para a
Internet pública. Para obter mais informações, consulte a documentação do link privado.
Permissões necessárias para uma VNET existente
O construtor de imagens do Azure requer permissões específicas para usar uma VNET existente. Para obter mais
informações, consulte configurar permissões de serviço do construtor de imagem do Azure usando CLI do
Azure ou configurar permissões de serviço do construtor de imagem do Azure usando o PowerShell.
O que é implantado durante uma compilação de imagem?
Usar uma VNET existente significa que o construtor de imagens do Azure implanta uma VM adicional (VM de
proxy) e um Azure Load Balancer (ALB) que está conectado ao link privado. O tráfego do serviço AIB passa pelo
link privado para o ALB. O ALB se comunica com a VM de proxy usando a porta 60001 para o SO Linux ou
60000 para o sistema operacional Windows. O proxy encaminha os comandos para a VM de compilação
usando a porta 22 para o SO Linux ou 5986 para o sistema operacional Windows.
NOTE
A VNET deve estar na mesma região que a região de serviço do construtor de imagens do Azure.
Por que implantar uma VM de proxy?
Quando uma VM sem IP público está atrás de um Load Balancer interno, ela não tem acesso à Internet. O Azure
Load Balancer usado para VNET é interno. A VM de proxy permite o acesso à Internet para a VM de compilação
durante as compilações. Os grupos de segurança de rede associados podem ser usados para restringir o acesso
à VM de compilação.
O tamanho da VM do proxy implantado é o padrão A1_v2 além da VM de compilação. A VM de proxy é usada
para enviar comandos entre o serviço do construtor de imagens do Azure e a VM de compilação. As
propriedades da VM do proxy não podem ser alteradas, incluindo o tamanho ou o sistema operacional. Você
não pode alterar as propriedades da VM do proxy para compilações de imagem do Windows e do Linux.
Parâmetros de modelo de imagem para dar suporte à VNET
"VirtualNetworkConfig": {
"name": "",
"subnetName": "",
"resourceGroupName": ""
},
C O N F IGURA Ç Ã O DESC RIÇ Ã O
name Adicional Nome de uma rede virtual pré-existente.
subnetName Nome da sub-rede na rede virtual especificada. Deve ser

especificado se e somente se o nome for especificado.
resourceGroupName Nome do grupo de recursos que contém a rede virtual

especificada. Deve ser especificado se e somente se o nome
for especificado.
O serviço de vínculo privado requer um IP da VNET e da sub-rede fornecidas. Atualmente, o Azure não dá
suporte a políticas de rede nesses IPs. Portanto, as políticas de rede precisam ser desabilitadas na sub-rede. Para
obter mais informações, consulte a documentação do link privado.
Lista de verificação para usar sua VNET
1. Permitir que Azure Load Balancer (ALB) se comuniquem com a VM de proxy em um NSG
Exemplo de CLI do AZ
Exemplo de PowerShell
2. Desabilitar política de serviço particular na sub-rede
3. Permitir que o construtor de imagens do Azure crie um ALB e adicione VMs à VNET
4. Permitir que o construtor de imagens do Azure Leia/grave imagens de origem e crie imagens
5. Verifique se você está usando VNET na mesma região que a região de serviço do construtor de imagem do
Azure.
Próximas etapas
Para obter mais informações, consulte visão geral do construtor de imagens do Azure.
Configurar permissões de serviço do construtor de
imagem do Azure usando CLI do Azure
O serviço do construtor de imagens do Azure requer a configuração de permissões e privilégios antes de criar
uma imagem. As seções a seguir detalham como configurar possíveis cenários usando CLI do Azure.
IMPORTANT
Pré-requisitos

Criar uma identidade gerenciada atribuída pelo usuário do Azure

O construtor de imagens do Azure exige que você crie uma identidade gerenciada atribuída pelo usuário do
Azure. O construtor de imagens do Azure usa a identidade gerenciada atribuída pelo usuário para ler imagens,
gravar imagens e acessar contas de armazenamento do Azure. Você concede a permissão de identidade para
realizar ações específicas em sua assinatura.
NOTE
Anteriormente, o construtor de imagem do Azure usava o SPN (nome da entidade de serviço) do Azure Image Builder
para conceder permissões aos grupos de recursos de imagem. Usar o SPN será preterido. Em vez disso, use uma
identidade gerenciada atribuída pelo usuário.
O exemplo a seguir mostra como criar uma identidade gerenciada atribuída pelo usuário do Azure. Substitua as
configurações de espaço reservado para definir suas variáveis.
<Resource group> Grupo de recursos onde criar a identidade gerenciada

atribuída pelo usuário.
identityName="aibIdentity"
imageResourceGroup=<Resource group>
az identity create \
--name $identityName
Para obter mais informações sobre identidades atribuídas ao usuário do Azure, consulte a documentação de
identidade gerenciada atribuída pelo usuário do Azure sobre como criar uma identidade.
Permitir que o construtor de imagens distribua imagens

Para o construtor de imagens do Azure distribuir imagens (imagens gerenciadas/Galeria de imagens
compartilhadas), o serviço do construtor de imagens do Azure deve ter permissão para injetar as imagens
nesses grupos de recursos. Para conceder as permissões necessárias, você precisa criar uma identidade
gerenciada atribuída pelo usuário e conceder direitos de ti no grupo de recursos em que a imagem é criada. O
construtor de imagens do Azure não tem permissão para acessar recursos em outros grupos de recursos na
assinatura. Você precisa tomar ações explícitas para permitir o acesso para evitar falhas em suas compilações.
Você não precisa conceder aos direitos de colaborador de identidade gerenciada atribuídos pelo usuário no
grupo de recursos para distribuir imagens. No entanto, a identidade gerenciada atribuída pelo usuário precisa
das seguintes permissões do Azure Actions no grupo de recursos de distribuição:
Microsoft.Compute/images/write
Microsoft.Compute/images/read
Microsoft.Compute/images/delete
Se estiver distribuindo para uma galeria de imagens compartilhada, você também precisará de:
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/images/read
Microsoft.Compute/galleries/images/versions/read
Microsoft.Compute/galleries/images/versions/write
Permissão para personalizar as imagens existentes

Para o construtor de imagens do Azure criar imagens de imagens personalizadas de origem (imagens
gerenciadas/Galeria de imagens compartilhadas), o serviço do construtor de imagens do Azure deve ter
permissão para ler as imagens nesses grupos de recursos. Para conceder as permissões necessárias, você
precisa criar uma identidade gerenciada atribuída pelo usuário e conceder direitos de ti no grupo de recursos
onde a imagem está localizada.
Criar com base em uma imagem personalizada existente:
Crie a partir de uma versão existente da Galeria de imagens compartilhadas:
Permissão para personalizar imagens em seu VNETs

O construtor de imagens do Azure tem a capacidade de implantar e usar uma VNET existente em sua assinatura,
permitindo assim que as personalizações acessem recursos conectados.
grupo de recursos para implantar uma VM em uma VNET existente. No entanto, a identidade gerenciada
atribuída pelo usuário precisa das seguintes permissões do Azure Actions no grupo de recursos de VNET:
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/join/action
Criar uma definição de função do Azure

Os exemplos a seguir criam uma definição de função do Azure das ações descritas nas seções anteriores. Os
exemplos são aplicados no nível do grupo de recursos. Avalie e teste se os exemplos são granulares o suficiente
para suas necessidades. Para seu cenário, talvez seja necessário refiná-lo para uma galeria de imagens
compartilhada específica.
As ações de imagem permitem leitura e gravação. Decida o que é apropriado para o seu ambiente. Por exemplo,
crie uma função para permitir que o construtor de imagens do Azure Leia imagens do grupo de recursos
example-RG-1 e grave imagens no grupo de recursos example-RG-2.
Exemplo de função do Azure de imagem personalizada
O exemplo a seguir cria uma função do Azure para usar e distribuir uma imagem personalizada de origem. Em
seguida, conceda a função personalizada à identidade gerenciada atribuída pelo usuário para o construtor de
imagens do Azure.
Para simplificar a substituição de valores no exemplo, primeiro defina as variáveis a seguir. Substitua as
<Subscription ID> ID da assinatura do Azure
<Resource group> Grupo de recursos para imagem personalizada

# Subscription ID - You can get this using àz account show | grep id` or from the Azure portal.
# Resource group - For Preview, image builder will only support creating custom images in the same Resource
Group as the source managed image.
imageResourceGroup=<Resource group>
# Use *cURL* to download the a sample JSON description

curl
# Create a unique role name to avoid clashes in the same Azure Active Directory domain
# Update the JSON definition using stream editor

# Create a custom role from the sample aibRoleImageCreation.json description file.

# Get the user-assigned managed identity id

imgBuilderCliId=$(az identity show -g $imageResourceGroup -n $identityName | grep "clientId" | cut -c16- |
tr -d '",')
# Grant the custom role to the user-assigned managed identity for Azure Image Builder.
Exemplo de função VNET do Azure existente

O exemplo a seguir cria uma função do Azure para usar e distribuir uma imagem de VNET existente. Em
imagens do Azure.
<Resource group> Grupo de recursos de VNET

# Subscription ID - You can get this using àz account show | grep id` or from the Azure portal.
VnetResourceGroup=<Resource group>
# Use *cURL* to download the a sample JSON description

curl
_Roles/aibRoleNetworking.json -o aibRoleNetworking.json
# Create a unique role name to avoid clashes in the same domain

netRoleDefName="Azure Image Builder Network Def"$(date +'%s')
# Update the JSON definition using stream editor

sed -i -e "s/<subscriptionID>/$subscriptionID/g" aibRoleNetworking.json
sed -i -e "s/<vnetRgName>/$vnetRgName/g" aibRoleNetworking.json
sed -i -e "s/Azure Image Builder Service Networking Role/$netRoleDefName/g" aibRoleNetworking.json
# Create a custom role from the aibRoleNetworking.json description file.

az role definition create --role-definition ./aibRoleNetworking.json
# Get the user-assigned managed identity id

imgBuilderCliId=$(az identity show -g $imageResourceGroup -n $identityName | grep "clientId" | cut -c16- |
tr -d '",')
--scope /subscriptions/$subscriptionID/resourceGroups/$VnetResourceGroup
Usando a identidade gerenciada para acesso de armazenamento do

Azure
Se você quiser Conecte autenticar com o armazenamento do Azure e usar contêineres privados, o Azure Image
Builder precisará de uma identidade gerenciada atribuída pelo usuário. O construtor de imagens do Azure usa a
identidade para autenticar com o armazenamento do Azure.
NOTE
O construtor de imagens do Azure usa apenas a identidade no momento de envio do modelo de imagem. A VM de
compilação não tem acesso à identidade durante a compilação da imagem.
Use CLI do Azure para criar a identidade gerenciada atribuída pelo usuário.

--assignee <Image Builder client ID> \
--role "Storage Blob Data Reader" \
--scope /subscriptions/<Subscription ID>/resourceGroups/<Resource
group>/providers/Microsoft.Storage/storageAccounts/$scriptStorageAcc/blobServices/default/containers/<Storag
e account container>
No modelo do Image Builder, você precisa fornecer a identidade gerenciada atribuída pelo usuário.
"type": "Microsoft.VirtualMachineImages/imageTemplates",
"location": "<Region>",
..
"identity": {
"<Image Builder ID>": {}
}
Substitua as seguintes configurações de espaço reservado:
<Region> Região do modelo
<Resource group> Resource group
<Storage account container> Nome do contêiner da conta de armazenamento
<Subscription ID> Assinatura do Azure
Para obter mais informações sobre como usar uma identidade gerenciada atribuída pelo usuário, consulte criar
uma imagem personalizada que usará uma identidade gerenciada do azure User-Assigned para arquivos do
Conecte Access do armazenamento do Azure. O guia de início rápido explica como criar e configurar a
identidade gerenciada atribuída pelo usuário para acessar uma conta de armazenamento.
Próximas etapas
Configurar permissões de serviço do construtor de
imagem do Azure usando o PowerShell
O serviço do construtor de imagens do Azure requer a configuração de permissões e privilégios antes de criar
uma imagem. As seções a seguir detalham como configurar possíveis cenários usando o PowerShell.
IMPORTANT






Criar uma identidade gerenciada atribuída pelo usuário do Azure

O construtor de imagens do Azure exige que você crie uma identidade gerenciada atribuída pelo usuário do
Azure. O construtor de imagens do Azure usa a identidade gerenciada atribuída pelo usuário para ler imagens,
gravar imagens e acessar contas de armazenamento do Azure. Você concede a permissão de identidade para
realizar ações específicas em sua assinatura.
NOTE
Anteriormente, o construtor de imagem do Azure usava o SPN (nome da entidade de serviço) do Azure Image Builder
para conceder permissões aos grupos de recursos de imagem. Usar o SPN será preterido. Em vez disso, use uma
O exemplo a seguir mostra como criar uma identidade gerenciada atribuída pelo usuário do Azure. Substitua as
<Resource group> Grupo de recursos onde criar a identidade gerenciada

atribuída pelo usuário.

$parameters = @{
Name = 'aibIdentity'
ResourceGroupName = '<Resource group>'
}
# create identity
New-AzUserAssignedIdentity @parameters
Para obter mais informações sobre identidades atribuídas ao usuário do Azure, consulte a documentação de
identidade gerenciada atribuída pelo usuário do Azure sobre como criar uma identidade.
Permitir que o construtor de imagens distribua imagens

Para o construtor de imagens do Azure distribuir imagens (imagens gerenciadas/Galeria de imagens
compartilhadas), o serviço do construtor de imagens do Azure deve ter permissão para injetar as imagens
nesses grupos de recursos. Para conceder as permissões necessárias, você precisa criar uma identidade
gerenciada atribuída pelo usuário e conceder direitos de ti no grupo de recursos em que a imagem é criada. O
construtor de imagens do Azure não tem permissão para acessar recursos em outros grupos de recursos na
assinatura. Você precisa tomar ações explícitas para permitir o acesso para evitar falhas em suas compilações.
grupo de recursos para distribuir imagens. No entanto, a identidade gerenciada atribuída pelo usuário precisa
das seguintes permissões do Azure Actions no grupo de recursos de distribuição:
Microsoft.Compute/images/write
Microsoft.Compute/images/read
Microsoft.Compute/images/delete
Se estiver distribuindo para uma galeria de imagens compartilhada, você também precisará de:
Microsoft.Compute/galleries/images/versions/write
Permissão para personalizar as imagens existentes

Para o construtor de imagens do Azure criar imagens de imagens personalizadas de origem (imagens
gerenciadas/Galeria de imagens compartilhadas), o serviço do construtor de imagens do Azure deve ter
permissão para ler as imagens nesses grupos de recursos. Para conceder as permissões necessárias, você
precisa criar uma identidade gerenciada atribuída pelo usuário e conceder direitos de ti no grupo de recursos
onde a imagem está localizada.
Criar com base em uma imagem personalizada existente:
Crie a partir de uma versão existente da Galeria de imagens compartilhadas:
Permissão para personalizar imagens em seu VNETs

O construtor de imagens do Azure tem a capacidade de implantar e usar uma VNET existente em sua assinatura,
permitindo assim que as personalizações acessem recursos conectados.
grupo de recursos para implantar uma VM em uma VNET existente. No entanto, a identidade gerenciada
atribuída pelo usuário precisa das seguintes permissões do Azure Actions no grupo de recursos de VNET:
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/join/action
Criar uma definição de função do Azure

Os exemplos a seguir criam uma definição de função do Azure das ações descritas nas seções anteriores. Os
exemplos são aplicados no nível do grupo de recursos. Avalie e teste se os exemplos são granulares o suficiente
para suas necessidades. Para seu cenário, talvez seja necessário refiná-lo para uma galeria de imagens
compartilhada específica.
As ações de imagem permitem leitura e gravação. Decida o que é apropriado para o seu ambiente. Por exemplo,
crie uma função para permitir que o construtor de imagens do Azure Leia imagens do grupo de recursos
example-RG-1 e grave imagens no grupo de recursos example-RG-2.
Exemplo de função do Azure de imagem personalizada
O exemplo a seguir cria uma função do Azure para usar e distribuir uma imagem personalizada de origem. Em
imagens do Azure.
<Resource group> Grupo de recursos para imagem personalizada
$sub_id = "<Subscription ID>"

# Resource group - For Preview, image builder will only support creating custom images in the same Resource
Group as the source managed image.
$imageResourceGroup = "<Resource group>"
$identityName = "aibIdentity"
# Use a web request to download the sample JSON description

$sample_uri="https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solutions/12_Creating
_AIB_Security_Roles/aibRoleImageCreation.json"
$role_definition="aibRoleImageCreation.json"
Invoke-WebRequest -Uri $sample_uri -Outfile $role_definition -UseBasicParsing
# Create a unique role name to avoid clashes in the same Azure Active Directory domain
# Update the JSON definition placeholders with variable values

((Get-Content -path $role_definition -Raw) -replace '<subscriptionID>',$sub_id) | Set-Content -Path
$role_definition
((Get-Content -path $role_definition -Raw) -replace '<rgName>', $imageResourceGroup) | Set-Content -Path
$role_definition
((Get-Content -path $role_definition -Raw) -replace 'Azure Image Builder Service Image Creation Role',
$imageRoleDefName) | Set-Content -Path $role_definition
# Create a custom role from the aibRoleImageCreation.json description file.

New-AzRoleDefinition -InputFile $role_definition
# Get the user-identity properties

$identityNameResourceId=$(Get-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name
$identityName).Id
$identityNamePrincipalId=$(Get-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name
$parameters = @{
RoleDefinitionName = $imageRoleDefName
Scope = '/subscriptions/' + $sub_id + '/resourceGroups/' + $imageResourceGroup
}
New-AzRoleAssignment @parameters
Exemplo de função VNET do Azure existente

O exemplo a seguir cria uma função do Azure para usar e distribuir uma imagem de VNET existente. Em
imagens do Azure.
<Resource group> Grupo de recursos de VNET
$sub_id = "<Subscription ID>"

$res_group = "<Resource group>"
$identityName = "aibIdentity"
# Use a web request to download the sample JSON description

$sample_uri="https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solutions/12_Creating
_AIB_Security_Roles/aibRoleNetworking.json"
$role_definition="aibRoleNetworking.json"
Invoke-WebRequest -Uri $sample_uri -Outfile $role_definition -UseBasicParsing
# Create a unique role name to avoid clashes in the same AAD domain
$networkRoleDefName="Azure Image Builder Network Def"+$timeInt
# Update the JSON definition placeholders with variable values

((Get-Content -path $role_definition -Raw) -replace '<subscriptionID>',$sub_id) | Set-Content -Path
$role_definition
((Get-Content -path $role_definition -Raw) -replace '<vnetRgName>', $res_group) | Set-Content -Path
$role_definition
((Get-Content -path $role_definition -Raw) -replace 'Azure Image Builder Service Networking
Role',$networkRoleDefName) | Set-Content -Path $role_definition
# Create a custom role from the aibRoleNetworking.json description file

New-AzRoleDefinition -InputFile $role_definition
# Get the user-identity properties

$identityName).Id
# Assign the custom role to the user-assigned managed identity for Azure Image Builder
$parameters = @{
RoleDefinitionName = $networkRoleDefName
Scope = '/subscriptions/' + $sub_id + '/resourceGroups/' + $res_group
}
New-AzRoleAssignment @parameters
Próximas etapas
Tarefa DevOps do serviço do construtor de imagem
do Azure
Este artigo mostra como usar uma tarefa DevOps do Azure para injetar artefatos de compilação em uma
imagem de VM para que você possa instalar e configurar seu aplicativo e sistema operacional.
Versões da tarefa DevOps

Há duas tarefas de DevOps do AIB (Construtor de imagens de VM) do Azure:
A tarefa ' estável ' de AIB, esta é a compilação estável mais recente que foi testada e a telemetria não
mostra nenhum problema.
Tarefa ' instável ' AIB, isso nos permite colocar as atualizações e os recursos mais recentes, permitir que
os clientes os testem antes de promovê-lo para a tarefa ' estável '. Se não houver nenhum problema
relatado e nossa telemetria não mostrar nenhum problema, aproximadamente 1 semana depois,
promoveremos o código da tarefa para "estável".
Pré-requisitos
Instale a tarefa DevOps estável de Visual Studio Marketplace.
Você deve ter uma conta do VSTS DevOps e um pipeline de compilação criado
Registre e habilite os requisitos do recurso do Image Builder na assinatura usada pelos pipelines:
AZ PowerShell
AZ CLI
Criar uma conta de armazenamento do Azure padrão no grupo de recursos de imagem de origem, você
pode usar outras contas de armazenamento/grupo de recursos. A conta de armazenamento é usada para
transferir os artefatos de compilação da tarefa DevOps para a imagem.
# Az PowerShell
$storageAccName="aibstorage"+$timeInt
$location=westus
# create storage account and blob in resource group
New-AzStorageAccount -ResourceGroupName $strResourceGroup -Name $storageAccName -Location $location -
SkuName Standard_LRS
# Az CLI
location=westus
scriptStorageAcc=aibstordot$(date +'%s')
az storage account create -n $scriptStorageAcc -g $strResourceGroup -l $location --sku Standard_LRS
Adicionar tarefa ao pipeline de liberação

Selecione liberar pipeline > Editar
No agente do usuário, selecione + para adicionar e Pesquisar por Image Builder . Selecione Adicionar .
Defina as seguintes propriedades de tarefa:
Assinatura do Azure
Selecione no menu suspenso a assinatura que você deseja que o construtor de imagem execute. Use a mesma
assinatura em que as imagens de origem estão localizadas e onde as imagens devem ser distribuídas. Você
precisa autorizar o acesso colaborador do Image Builder à assinatura ou ao grupo de recursos.
Grupo de recursos
Use o grupo de recursos em que o artefato do modelo de imagem temporária será armazenado. Ao criar um
artefato de modelo, um grupo de recursos de construtor de imagem temporário adicional
IT_<DestinationResourceGroup>_<TemplateName>_guid é criado. O grupo de recursos temporários armazena os
metadados da imagem, como scripts. No final da tarefa, o artefato do modelo de imagem e o grupo de recursos
do construtor de imagem temporário são excluídos.
Local
O local é a região em que o construtor de imagem será executado. Há suporte apenas para um número definido
de regiões . As imagens de origem devem estar presentes neste local. Por exemplo, se você estiver usando a
Galeria de imagens compartilhadas, uma réplica deverá existir nessa região.
Identidade gerenciada (obrigatória)
O Image Builder requer uma identidade gerenciada, que ela usa para ler imagens personalizadas de origem,
conectar-se ao armazenamento do Azure e criar imagens personalizadas. Veja aqui para obter mais detalhes.
Suporte VNET
Atualmente, a tarefa DevOps não dá suporte à especificação de uma sub-rede existente, isso está no roteiro,
mas se você quiser utilizar uma VNET existente, poderá usar um modelo de ARM, com um modelo de construtor
de imagem aninhado no, consulte os exemplos de modelo do Windows Image Builder sobre como isso é obtido
ou, alternativamente, use AZ AIB PowerShell.
Fonte
As imagens de origem devem ser do OSs do Image Builder com suporte. Você pode escolher as imagens
personalizadas existentes na mesma região em que o Image Builder está em execução:
Imagem gerenciada-você precisa passar o ResourceId, por exemplo:
/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.Compute/images/<imageName
>
Galeria de imagens compartilhadas do Azure-você precisa passar o ResourceId da versão da imagem, por
exemplo:
/subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup/providers/Microsoft.Compute/galleries
/$sigName/images/$imageDefName/versions/<versionNumber>
Se precisar obter a versão mais recente da Galeria de imagens compartilhadas, você poderá ter uma
tarefa AZ PowerShell ou AZ CLI para obter a versão mais recente e definir uma variável DevOps. Use a
variável na tarefa AZ VM Image Builder DevOps. Para obter mais informações, consulte os exemplos.
Comunidade Imagem base há uma lista suspensa de imagens populares. elas sempre usarão a versão '
mais recente ' do sistema operacional com suporte.
Se a imagem base não estiver na lista, você poderá especificar a imagem exata usando
Publisher:Offer:Sku .
Versão da imagem base (opcional)-você pode fornecer a versão da imagem que deseja usar, o padrão é
latest .
Personalizar
Provisionador
Inicialmente, há suporte para dois personalizadores- shell e PowerShell . Somente embutido tem suporte. Se
desejar baixar scripts, você poderá passar comandos embutidos para fazer isso.
Para seu sistema operacional, selecione PowerShell ou Shell.
Windows Update tarefa
Somente para Windows, a tarefa é executada Windows Update no final das personalizações. Ele lida com as
reinicializações necessárias.
A seguinte configuração de Windows Update é executada:
"type": "WindowsUpdate",
"searchCriteria": "IsInstalled=0",
"filters": [
"exclude:$_.Title -like '*Preview*'",
"include:$true"
Ele instala atualizações do Windows importantes e recomendadas que não são Preview.
Manipulando reinicializações
Atualmente, a tarefa DevOps não tem suporte para a reinicialização de compilações do Windows, se você tentar
reinicializar com o código do PowerShell, a compilação falhará. No entanto, você pode usar o código para
reinicializar compilações do Linux.
Caminho de compilação
A tarefa foi projetada para ser capaz de injetar artefatos de versão de compilação DevOps na imagem. Para fazer
isso funcionar, você precisa configurar um pipeline de compilação. Na configuração do pipeline de liberação,
você deve adicionar o repositório dos artefatos de compilação.
Selecione o botão Compilar caminho para escolher a pasta de Build que você deseja que seja colocada na
imagem. A tarefa do construtor de imagem copia todos os arquivos e diretórios dentro dele. Quando a imagem
está sendo criada, o Image Builder implanta os arquivos e diretórios em caminhos diferentes, dependendo do
sistema operacional.
IMPORTANT
Ao adicionar um artefato do repositório, você pode achar que o diretório é prefixado com um sublinhado _. O sublinhado
pode causar problemas com os comandos embutidos. Use as aspas apropriadas nos comandos.
O exemplo a seguir explica como isso funciona:

Os arquivos do Windows existem no C:\ . Um diretório chamado buildArtifacts é criado, o que inclui
o webapp diretório.
Linux-os arquivos existem no /tmp . O webapp diretório é criado, o que inclui todos os arquivos e
diretórios. Você deve mover os arquivos deste diretório. Caso contrário, eles serão excluídos, pois estão
no diretório temporário.
Script de personalização embutido
Windows – você pode inserir comandos embutidos do PowerShell separados por vírgulas. Se você quiser
executar um script em seu diretório de compilação, poderá usar:
& 'c:\buildArtifacts\webapp\webconfig.ps1'
Você pode fazer referência a vários scripts ou adicionar mais comandos, por exemplo:
& 'c:\buildArtifacts\webapp\webconfig.ps1'
& 'c:\buildArtifacts\webapp\installAgent.ps1'
Linux – em sistemas Linux, os artefatos de compilação são colocados no /tmp diretório. No entanto, em
muitos sistemas operacionais Linux, em uma reinicialização, o conteúdo do diretório/tmp é excluído. Se
você quiser que os artefatos existam na imagem, deverá criar outro diretório e copiá-los. Por exemplo:
sudo mkdir /lib/buildArtifacts

sudo cp -r "/tmp/_ImageBuilding/webapp" /lib/buildArtifacts/.
Se você estiver ok usando o diretório "/tmp", poderá usar o código abaixo para executar o script.
# grant execute permissions to execute scripts

sudo chmod +x "/tmp/_ImageBuilding/webapp/coreConfig.sh"
echo "running script"
sudo . "/tmp/AppsAndImageBuilderLinux/_WebApp/coreConfig.sh"
O que acontece com os artefatos de compilação após a criação da imagem?
NOTE
O Image Builder não remove automaticamente os artefatos de compilação, é altamente recomendável que você sempre
tenha código para remover os artefatos de compilação.
Windows-o construtor de imagem implanta arquivos no c:\buildArtifacts diretório. O diretório é

persistido, você deve remover o diretório. Você pode removê-lo no script que você executar. Por exemplo:
# Clean up buildArtifacts directory
Remove-Item -Path "C:\buildArtifacts\*" -Force -Recurse
# Delete the buildArtifacts directory

Remove-Item -Path "C:\buildArtifacts" -Force
Linux-os artefatos de compilação são colocados no /tmp diretório. No entanto, em muitos sistemas
operacionais Linux, em uma reinicialização, o /tmp conteúdo do diretório é excluído. É recomendável
que você tenha código para remover o conteúdo e não confiar no sistema operacional para remover o
conteúdo. Por exemplo:
sudo rm -R "/tmp/AppsAndImageBuilderLinux"
Comprimento total da compilação da imagem

O comprimento total não pode ser alterado na tarefa de pipeline DevOps ainda. Ele usa o padrão de 240
minutos. Se você quiser aumentar o buildTimeoutInMinutes, poderá usar uma tarefa AZ CLI no pipeline de
lançamento. Configure a tarefa para copiar um modelo e enviá-lo. Para obter um exemplo, consulte esta
soluçãoou use AZ PowerShell.
Conta de armazenamento
Selecione a conta de armazenamento que você criou nos pré-requisitos. Se você não o vir na lista, o Image
Builder não terá permissões para ele.
Quando a compilação for iniciada, o construtor de imagem criará um contêiner chamado
imagebuilder-vststask . O contêiner é onde os artefatos de compilação do repositório são armazenados.
NOTE
Você precisa excluir manualmente a conta de armazenamento ou o contêiner após cada compilação.
Distribuir
Há 3 tipos de distribuição com suporte.
Imagem Gerenciada
Identificação
/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.Compute/images/<imageName
>
Locais
Galeria de imagens compartilhadas do Azure
A Galeria de imagens compartilhadas já deve existir.
Identificação
/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.Compute/galleries/<galler
yName>/images/<imageDefName>
Regiões: lista de regiões, separadas por vírgulas. Por exemplo, westus, orientem, centralus
VHD
Você não pode passar nenhum valor para isso, o construtor de imagem emitirá o VHD para o grupo de recursos
do construtor de imagem temporário, IT_<DestinationResourceGroup>_<TemplateName> no contêiner VHDs .
Quando você inicia a compilação da versão, o construtor de imagem emite logs. Quando ele for concluído, ele
emitirá a URL do VHD.
Configurações opcionais
Tamanho da VM -você pode substituir o tamanho da VM, do padrão de Standard_D1_v2. Você pode
substituir para reduzir o tempo total de personalização ou porque deseja criar as imagens que dependem de
determinados tamanhos de VM, como GPU/HPC, etc.
Como ele funciona

Quando você cria a versão, a tarefa cria um contêiner na conta de armazenamento, chamado imagebuilder-
vststask. Ele zips e carrega seus artefatos de compilação e cria um token SAS para o arquivo zip.
A tarefa usa as propriedades passadas para a tarefa para criar o artefato do modelo do Image Builder. A tarefa
faz o seguinte:
Baixa o arquivo zip do artefato de compilação e quaisquer outros scripts associados. Os arquivos são salvos
em uma conta de armazenamento no grupo de recursos Temporary Image Builder
IT_<DestinationResourceGroup>_<TemplateName> .
Cria um t_ prefixado de modelo e um inteiro monotônico de 10 dígitos. O modelo é salvo no grupo de
recursos selecionado. O modelo existe para a duração da compilação no grupo de recursos.
Saída de exemplo:
start reading task parameters...

found build at: /home/vsts/work/r1/a/_ImageBuilding/webapp
end reading parameters
getting storage account details for aibstordot1556933914
created archive /home/vsts/work/_temp/temp_web_package_21475337782320203.zip
Source for image: { type: 'SharedImageVersion',
imageVersionId:
'/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.Compute/galleries/<galleryName>
/images/<imageDefName>/versions/<imgVersionNumber>' }
template name: t_1556938436xxx
starting put template...
Quando o Build da imagem é iniciado, o status de execução é relatado nos logs de liberação:
starting run template...
Quando a compilação da imagem for concluída, você verá uma saída semelhante ao seguinte texto:
2019-05-06T12:49:52.0558229Z starting run template...

2019-05-06T13:36:33.8863094Z run template: Succeeded
2019-05-06T13:36:33.8867768Z getting runOutput for SharedImage_distribute
2019-05-06T13:36:34.6652541Z ==============================================================================
2019-05-06T13:36:34.6652925Z ## task output variables ##
2019-05-06T13:36:34.6658728Z $(imageUri) =
/subscriptions/<subscriptionID>/resourceGroups/aibwinsig/providers/Microsoft.Compute/galleries/my22stSIG/ima
ges/winWAppimages/versions/0.23760.13763
2019-05-06T13:36:34.6659989Z ==============================================================================
2019-05-06T13:36:34.6663500Z deleting template t_1557146959485...
2019-05-06T13:36:34.6673713Z deleting storage blob imagebuilder-vststask\webapp/18-
1/webapp_1557146958741.zip
2019-05-06T13:36:34.9786039Z blob imagebuilder-vststask\webapp/18-1/webapp_1557146958741.zip is deleted
2019-05-06T13:38:37.4884068Z delete template: Succeeded
O modelo de imagem e IT_<DestinationResourceGroup>_<TemplateName> é excluído.

Você pode usar a variável do VSTS ' $ (imageUri) ' e usá-la na próxima tarefa ou simplesmente usar o valor e
compilar uma VM.
Variáveis DevOps de saída

Pub/offer/SKU/versão da imagem do Marketplace de origem:
$ (pirPublisher)
$ (pirOffer)
$ (pirSku)
$ (pirVersion)
URI da imagem-o ResourceId da imagem distribuída:
$ (imageUri)
Posso usar um modelo de imagem existente que já criei, fora do DevOps?
Atualmente, não neste momento.
Posso especificar o nome do modelo de imagem?
Não. Um nome de modelo exclusivo é usado e, em seguida, excluído.
Falha no construtor de imagem. Como posso solucionar problemas?
Se houver uma falha de compilação, a tarefa DevOps não excluirá o grupo de recursos de preparo. Você pode
acessar o grupo de recursos de preparo que contém o log de compilação personalizada.
Você verá um erro no log do DevOps para a tarefa do construtor de imagens de VM e verá o local de
personalização. log. Por exemplo:
Para obter mais informações sobre solução de problemas, consulte solucionar problemas do serviço do
construtor de imagem do Azure.
Depois de investigar a falha, você pode excluir o grupo de recursos de preparo. Primeiro, exclua o artefato de
recurso do modelo de imagem. O artefato é prefixado com t_ e pode ser encontrado no log de compilação da
tarefa DevOps:
...
imageVersionId:
...
...
O artefato de recurso do modelo de imagem está no grupo de recursos especificado inicialmente na tarefa.
Quando você terminar de solucionar o problema, exclua o artefato. Se estiver excluindo usando o portal do
Azure, dentro do grupo de recursos, selecione Mostrar tipos ocultos para exibir o artefato.
Próximas etapas
Visualização: Criar um modelo do Construtor de
Imagens do Azure
O Construtor de Imagens do Azure usa um arquivo .json para passar informações para o serviço do Construtor
de Imagens. Neste artigo, vamos abordar as seções do arquivo json para que você possa criar o seu próprio.
Para ver exemplos completos de arquivos .json, confira o Construtor de Imagens do Azure no GitHub.
Este é o formato de modelo básico:
{
"apiVersion": "2020-02-14",
"location": "<region>",
"tags": {
"<name": "<value>",
"<name>": "<value>"
},
"identity":{},
"dependsOn": [],
"properties": {
"buildTimeoutInMinutes": <minutes>,
"vmProfile":
{
"vmSize": "<vmSize>",
"osDiskSizeGB": <sizeInGB>,
"vnetConfig": {
"subnetId":
"/subscriptions/<subscriptionID>/resourceGroups/<vnetRgName>/providers/Microsoft.Network/virtualNetworks/<vn
etName>/subnets/<subnetName>"
}
},
"source": {},
"customize": {},
"distribute": {}
}
}
Tipo e versão da API

O type é o tipo de recurso, que deve ser "Microsoft.VirtualMachineImages/imageTemplates" . O apiVersion será
alterado ao longo do tempo conforme a API for alterada, mas deve ser "2020-02-14" para a versão prévia.
"apiVersion": "2020-02-14",
Location
O local é a região em que a imagem personalizada será criada. Para a versão prévia do Construtor de Imagens,
há suporte para as seguintes regiões:
Leste dos EUA
Leste dos EUA 2
Centro-Oeste dos EUA
Oeste dos EUA
Oeste dos EUA 2
Norte da Europa
Europa Ocidental
vmProfile
Por padrão, o Construtor de Imagens usará uma VM de build "Standard_D1_v2". Você pode substituir isso. Por
exemplo, se quiser personalizar uma imagem para uma VM GPU, você precisará de um tamanho de VM de GPU.
Isso é opcional.
{
"vmSize": "Standard_D1_v2"
},
osDiskSizeGB
Por padrão, o Construtor de Imagens não vai alterar o tamanho da imagem, ele usará o tamanho da imagem de
origem. Você só pode aumentar o tamanho do disco do sistema operacional (Win e Linux), isso é opcional, e o
valor 0 significa deixar o mesmo tamanho da imagem de origem. Não é possível reduzir o tamanho do disco do
sistema operacional para menor do que o tamanho da imagem de origem.
{
"osDiskSizeGB": 100
},
vnetConfig
Se você não especificar nenhuma propriedade da VNET, o Construtor de Imagens criará a própria VNET, IP
público e NSG. O IP público é usado para que o serviço se comunique com a VM de build. No entanto, se você
não quiser um IP público ou quiser que o Construtor de Imagens tenha acesso aos recursos da VNET existentes,
como servidores de configuração (DSC, Chef, Puppet, Ansible), compartilhamentos de arquivos etc., você poderá
especificar uma VNET. Para obter mais informações, confira a documentação de rede; isso é opcional.
"vnetConfig": {
"subnetId":
"/subscriptions/<subscriptionID>/resourceGroups/<vnetRgName>/providers/Microsoft.Network/virtualNetworks/<vn
etName>/subnets/<subnetName>"
}
}
Marcas
Esses são pares de chave/valor que você pode especificar para a imagem gerada.
Depende de (opcional)
Essa seção opcional pode ser usada para garantir que as dependências sejam concluídas antes de continuar.
"dependsOn": [],
Para obter mais informações, confira Definir dependências de recurso.
Identidade
Necessário-para o construtor de imagem ter permissões para ler/gravar imagens, leia em scripts do
armazenamento do Azure você deve criar uma identidade de User-Assigned do Azure, que tem permissões para
os recursos individuais. Para obter detalhes sobre como as permissões do Image Builder funcionam e as etapas
relevantes, consulte a documentação.
"identity": {
"<imgBuilderId>": {}
}
},
Suporte ao construtor de imagem para uma identidade de User-Assigned:

Dá suporte apenas a uma única identidade
Não dá suporte a nomes de domínio personalizados
Para saber mais, confira O que são identidades gerenciadas para recursos do Azure?. Para obter mais
informações sobre como implantar esse recurso, confira Configurar identidades gerenciadas para recursos do
Azure em uma VM do Azure usando a CLI do Azure.
Propriedades: origem
A seção source contém informações sobre a imagem de origem que será usada pelo Construtor de Imagens.
Atualmente, o Image Builder dá suporte apenas para a criação de imagens de geração do Hyper-V (GEN1) 1
para a Galeria de imagens compartilhada do Azure (SIG) ou a imagem gerenciada. Se você quiser criar imagens
Gen2, precisará usar uma imagem Gen2 de origem e distribuir para o VHD. Depois, você precisará criar uma
imagem gerenciada do VHD e inseri-la no SIG como uma imagem Gen2.
A API requer um 'SourceType' que define a origem para o build da imagem. No momento, há três tipos:
PlatformImage – indica que a imagem de origem é uma imagem do Marketplace.
ManagedImage – use ao iniciar em uma imagem gerenciada normal.
SharedImageVersion – é usado quando você está usando uma versão de imagem em uma Galeria de
Imagens Compartilhadas como a origem.
NOTE
Ao usar imagens personalizadas do Windows existentes, você pode executar o comando Sysprep até 8 vezes em uma
única imagem do Windows, para obter mais informações, consulte a documentação do Sysprep .
Origem da PlatformImage
O Construtor de Imagens do Azure dá suporte ao Windows Server e ao cliente e às imagens do Azure
Marketplace do Linux, confira aqui a lista completa.
"source": {
"type": "PlatformImage",
"sku": "18.04-LTS",
"version": "latest"
},
As propriedades aqui são as mesmas usadas para criar VMs. Usando a CLI do AZ, execute o seguinte para obter
as propriedades:
az vm image list -l westus -f UbuntuServer -p Canonical --output table –-all
Você pode usar 'Latest' na versão. A versão é avaliada quando o build da imagem ocorre, não quando o modelo
é enviado. Se você usar essa funcionalidade com o destino da Galeria de Imagens Compartilhadas, poderá evitar
reenviar o modelo e executar novamente o build da imagem a intervalos para que suas imagens sejam
recriadas com base em imagens mais recentes.
Suporte para informações do plano do Market Place
Você também pode especificar informações de plano, por exemplo:
"source": {
"type": "PlatformImage",
"publisher": "RedHat",
"offer": "rhel-byos",
"sku": "rhel-lvm75",
"version": "latest",
"planInfo": {
"planName": "rhel-lvm75",
"planProduct": "rhel-byos",
"planPublisher": "redhat"
}
Origem da ManagedImage
Define a imagem de origem como uma imagem gerenciada existente de um VHD ou VM generalizado.
NOTE
A imagem gerenciada de origem deve ser de um sistema operacional com suporte e a imagem deve estar na mesma
região que o seu modelo do Azure Image Builder.
"source": {
"type": "ManagedImage",
"imageId":
"/subscriptions/<subscriptionId>/resourceGroups/{destinationResourceGroupName}/providers/Microsoft.Compute/i
mages/<imageName>"
}
O imageId deve ser a ResourceId da imagem gerenciada. Use az image list para listar as imagens disponíveis.
Origem da SharedImageVersion
Define a imagem de origem como uma versão de imagem existente em uma Galeria de Imagens
Compartilhadas.
NOTE
A imagem gerenciada de origem deve ser de um sistema operacional com suporte e a imagem deve estar na mesma
região que o seu modelo do Azure Image Builder, caso contrário, replique a versão da imagem para a região de modelo
do Image Builder.
"source": {
"type": "SharedImageVersion",
"imageVersionID": "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroup>/p
roviders/Microsoft.Compute/galleries/<sharedImageGalleryName>/images/<imageDefinitionName/versions/<imageVer
sion>"
}
O imageVersionId deve ser a ResourceId da versão da imagem. Use az sig image-version list para listar as
versões da imagem.
Propriedades: buildTimeoutInMinutes
Por padrão, o Construtor de Imagens será executado por 240 minutos. Depois disso, ele atingirá o tempo limite
e será interrompido, independentemente de o build da imagem ter sido concluído ou não. Se o tempo limite for
atingido, você verá um erro semelhante a este:
[ERROR] Failed while waiting for packerizer: Timeout waiting for microservice to
[ERROR] complete: 'context deadline exceeded'
Se você não especificar um valor de buildTimeoutInMinutes ou defini-lo como 0, será usado o valor padrão.
Você pode aumentar ou diminuir o valor até o máximo de 960 minutos (16 horas). Para o Windows, não
recomendamos definir esse valor como inferior a 60 minutos. Se você acreditar que está atingindo o tempo
limite, examine os logs para ver se a etapa de personalização está aguardando algo como entrada do usuário.
Se você acreditar que precisa de mais tempo para que as personalizações sejam concluídas, defina isso para o
que você acredita ser necessário, com uma pequena sobrecarga. No entanto, não defina-o muito alto, pois talvez
seja necessário aguardar até que ele atinja o tempo limite antes de ver um erro.
Propriedades: personalizar
O Construtor de Imagens dá suporte a vários "personalizadores". Os personalizadores são funções usadas para
personalizar a imagem, como a execução de scripts ou a reinicialização de servidores.
Ao usar customize :
Você pode usar vários personalizadores, mas eles devem ter um name exclusivo.
Os personalizadores são executados na ordem especificada no modelo.
Se um personalizador falhar, o componente de personalização inteiro falhará e relatará um erro.
É altamente recomendável testar o script cuidadosamente antes de usá-lo em um modelo. A depuração do
script em sua própria VM será mais fácil.
Não coloque dados confidenciais nos scripts.
Os locais de script precisam ser acessíveis publicamente, a menos que você esteja usando MSI.
"customize": [
{
"type": "Shell",
"name": "<name>",
"scriptUri": "<path to script>",
"sha256Checksum": "<sha256 checksum>"
},
{
"type": "Shell",
"name": "<name>",
"inline": [
"<command to run inline>",
]
}
],
A seção de personalizar é uma matriz. O Construtor de Imagens do Azure percorrerá os personalizadores em

ordem sequencial. Qualquer falha em qualquer personalizador causará a falha do processo de build.
NOTE
Comandos embutidos podem ser exibidos na definição do modelo de imagem e por Suporte da Microsoft ao ajudar com
um caso de suporte. Se você tiver informações confidenciais, elas deverão ser movidas para scripts no armazenamento do
Azure, onde o acesso requer autenticação.
Personalizador de Shell
O personalizador de shell dá suporte a scripts Shell em execução. Eles devem estar acessíveis publicamente para
que o IB possa acessá-los.
"customize": [
{
"type": "Shell",
"name": "<name>",
"scriptUri": "<link to script>",
},
],
"customize": [
{
"type": "Shell",
"name": "<name>",
"inline": "<commands to run>"
},
],
Suporte a SO: Linux

Personalizar propriedades:
type – shell
name – nome para acompanhar a personalização
scriptUri – URI para o local do arquivo
inline – matriz de comandos de shell separados por vírgulas.
sha256Checksum – valor da soma de verificação SHA256 do arquivo. Você o gera localmente e, em
seguida, o Construtor de Imagens faz a soma de verificação e a validação.
Para gerar a sha256Checksum, usando um terminal no Mac/Linux, execute: sha256sum <fileName>
NOTE
Comandos embutidos são armazenados como parte da definição do modelo de imagem. você pode vê-los ao despejar a
definição de imagem, e eles também são visíveis para Suporte da Microsoft no caso de um caso de suporte para fins de
solução de problemas. Se você tiver comandos ou valores confidenciais, é altamente recomendável que eles sejam
movidos para scripts e usem uma identidade de usuário para autenticar no armazenamento do Azure.
Privilégios de superusuário
Para que os comandos sejam executados com privilégios de superusuário, eles devem ser prefixados com o
sudo , você pode adicioná-los em scripts ou usá-los como comandos embutidos, por exemplo:
"type": "Shell",
"name": "setupBuildPath",
"inline": [
"sudo mkdir /buildArtifacts",
"sudo cp /tmp/index.html /buildArtifacts/index.html"
Exemplo de um script usando sudo que você pode referenciar usando scriptUri:
#!/bin/bash -e
echo "Telemetry: creating files"

mkdir /myfiles
echo "Telemetry: running sudo 'as-is' in a script"

sudo touch /myfiles/somethingElevated.txt
Personalizador de reinicialização do Windows

O personalizador de reinicialização permite reiniciar uma VM do Windows e aguardar que ela volte a ficar
online, permitindo que você instale software que requer uma reinicialização.
"customize": [
{
"type": "WindowsRestart",
"restartCommand": "shutdown /r /f /t 0",
"restartCheckCommand": "echo Azure-Image-Builder-Restarted-the-VM >
c:\\buildArtifacts\\azureImageBuilderRestart.txt",
"restartTimeout": "5m"
}
],
Suporte a SO: Windows

Digitar : WindowsRestart
restar tCommand – comando para executar a reinicialização (opcional). O padrão é
'shutdown /r /f /t 0 /c \"packer restart\"' .
restar tCheckCommand – comando para verificar se a reinicialização foi bem-sucedida (opcional).
restar tTimeout – tempo limite de reinicialização especificado como uma cadeia de caracteres de magnitude
e unidade. Por exemplo, 5m (5 minutos) ou 2h (2 horas). O padrão é: '5m'
Reinicialização do Linux
Não há nenhum personalizador de reinicialização do Linux, no entanto, se você estiver instalando drivers ou
componentes que exigem uma reinicialização, você poderá instalá-los e invocar uma reinicialização usando o
personalizador de shell. Há um tempo limite de SSH de 20 minutos para a VM de build.
Personalizador do PowerShell
O personalizador de shell dá suporte à execução de scripts do PowerShell e ao comando embutido. Os scripts
devem estar publicamente acessíveis para que o IB possa acessá-los.
"customize": [
{
"type": "PowerShell",
"name": "<name>",
"scriptUri": "<path to script>",
"runElevated": "<true false>",
},
{
"type": "PowerShell",
"name": "<name>",
"inline": "<PowerShell syntax to run>",
"validExitCodes": "<exit code>",
"runElevated": "<true or false>"
}
],
Suporte a SO: Windows e Linux

type – PowerShell.
scriptUri – URI para o local do arquivo de script do PowerShell.
inline – comandos embutidos a serem executados, separados por vírgulas.
validExitCodes – códigos opcionais que podem ser retornados do comando de script/embutido. Isso
evitará a falha relatada do comando de script/embutido.
runElevated – opcional, booliano, suporte para a execução de comandos e scripts com permissões elevadas.
sha256Checksum – valor da soma de verificação SHA256 do arquivo. Você o gera localmente e, em
seguida, o Construtor de Imagens faz a soma de verificação e a validação.
Para gerar o sha256Checksum, usando um PowerShell no Windows Get-hash
Personalizador de arquivo
O personalizador de arquivo permite que o construtor de imagens baixe um arquivo de um GitHub ou
armazenamento do Azure. Se você tiver um pipeline de build de imagem que se baseia em artefatos de build,
poderá definir o personalizador de arquivo para baixar do compartilhamento de build e mover os artefatos para
a imagem.
"customize": [
{
"type": "File",
"name": "<name>",
"sourceUri": "<source location>",
"destination": "<destination>",
}
]
Suporte a SO: Linux e Windows

Propriedades do personalizador de arquivo:
sourceUri – um ponto de extremidade de armazenamento acessível. Pode ser o GitHub ou o
armazenamento do Azure. Você só pode baixar um arquivo, não um diretório inteiro. Se você precisar baixar
um diretório, use um arquivo compactado e descompacte-o usando os personalizadores Shell ou
PowerShell.
NOTE
Se o sourceUri for uma conta de armazenamento do Azure, independentemente de o blob ser marcado como público,
você concederá permissões de identidade de usuário gerenciadas para acesso de leitura no BLOB. Consulte este exemplo
para definir as permissões de armazenamento.
destination – é o caminho de destino completo e o nome do arquivo. Qualquer caminho e subdiretórios

referenciados devem existir. Use os personalizadores Shell ou PowerShell para configurá-los com
antecedência. Você pode usar os personalizadores de script para criar o caminho.
Há suporte para isso em diretórios do Windows e caminhos do Linux, mas há algumas diferenças:
SO Linux – o único caminho em que o construtor de imagens pode gravar em é /tmp.
Windows – nenhuma restrição de caminho, mas o caminho deve existir.
Se houver um erro ao tentar baixar o arquivo, ou colocá-lo em um diretório especificado, a etapa de
personalização falhará e isso estará no arquivo customization.log.
NOTE
O personalizador de arquivos é adequado apenas para downloads de arquivos pequenos <20 MB. Para downloads de
arquivos maiores, use um script ou comando embutido, então use o código para baixar arquivos, como o wget ou o
curl do Linux e o Invoke-WebRequest do Windows.
Personalizador do Windows Update

Este personalizador foi criado com base no Provisionador de do Windows Update da comunidade para o Packer,
que é um projeto de software livre mantido pela comunidade do Packer. A Microsoft testa e valida o
provisionamento com o serviço do Construtor de Imagens e dará suporte à investigação de problemas com ele,
trabalhando para resolvê-los. No entanto, o projeto de software livre não tem suporte oficial da Microsoft. Para
obter a documentação detalhada e ajuda com o Provisionador do Windows Update, confira o repositório do
projeto.
"customize": [
{
"type": "WindowsUpdate",
"searchCriteria": "IsInstalled=0",
"filters": [
"exclude:$_.Title -like '*Preview*'",
"include:$true"
],
"updateLimit": 20
}
],
OS support: Windows
type – WindowsUpdate.
searchCriteria – opcional, define que tipo de atualizações são instaladas (recomendado, importante etc.),
BrowseOnly = 0 e IsInstalled = 0 (recomendado) é o padrão.
filters – opcional, permite que você especifique um filtro para incluir ou excluir atualizações.
updateLimit – opcional, define quantas atualizações podem ser instaladas. O padrão é 1.000.
NOTE
O personalizador de Windows Update poderá falhar se houver reinicializações pendentes do Windows ou se as instalações
do aplicativo ainda estiverem em execução, normalmente você poderá ver esse erro no customization. log,
System.Runtime.InteropServices.COMException (0x80240016): Exception from HRESULT: 0x80240016 . É altamente
recomendável que você considere a adição de uma reinicialização do Windows e/ou o tempo suficiente para que os
aplicativos concluam suas instalações usando os comandos [Sleep] ou Wait (
https://docs.microsoft.com/powershell/module/microsoft.powershell.utility/start-sleep?view=powershell-7) nos comandos
embutidos ou scripts antes de executar Windows Update.
Generalizar
Por padrão, o Construtor de Imagens do Azure também executará o código de "desprovisionamento" no final de
cada fase de personalização de imagem para "generalizar" a imagem. Generalizar é um processo em que a
imagem é configurada para que possa ser reutilizada para criar várias VMs. Para VMs do Windows, o Construtor
de Imagens do Azure usa Sysprep. Para o Linux, o Construtor de Imagens do Azure executa 'waagent-
deprovision'.
Os comandos que o Construtor de Imagens usa para generalizar podem não ser adequados para todas as
situações, portanto, o Construtor de Imagens do Azure permitirá que você os personalize, se necessário.
Se você estiver migrando a personalização existente e estiver usando diferentes comandos Sysprep/waagent,
poderá usar os comandos genéricos do Construtor de Imagens. Se a criação da VM falhar, use seus próprios
comandos Sysprep ou waagent.
Se o Construtor de Imagens do Azure criar uma imagem personalizada do Windows com êxito e você criar uma
VM com base nela, então descobrir que a criação da VM falhou ou não é concluída com êxito, será preciso
examinar a documentação do Sysprep do Windows Server ou gerar uma solicitação de suporte com a equipe
de suporte do Windows Server Sysprep Customer Services, que pode solucionar problemas e recomendar o
uso correto do Sysprep.
Comando Sysprep padrão
Write-Output '>>> Waiting for GA Service (RdAgent) to start ...'

while ((Get-Service RdAgent).Status -ne 'Running') { Start-Sleep -s 5 }
Write-Output '>>> Waiting for GA Service (WindowsAzureTelemetryService) to start ...'
while ((Get-Service WindowsAzureTelemetryService) -and ((Get-Service WindowsAzureTelemetryService).Status -
ne 'Running')) { Start-Sleep -s 5 }
Write-Output '>>> Waiting for GA Service (WindowsAzureGuestAgent) to start ...'
while ((Get-Service WindowsAzureGuestAgent).Status -ne 'Running') { Start-Sleep -s 5 }
Write-Output '>>> Sysprepping VM ...'
if( Test-Path $Env:SystemRoot\system32\Sysprep\unattend.xml ) {
Remove-Item $Env:SystemRoot\system32\Sysprep\unattend.xml -Force
}
& $Env:SystemRoot\System32\Sysprep\Sysprep.exe /oobe /generalize /quiet /quit
while($true) {
$imageState = (Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\State).ImageState
Write-Output $imageState
if ($imageState -eq 'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { break }
Start-Sleep -s 5
}
Write-Output '>>> Sysprep complete ...'
Comando padrão de desprovisionamento do Linux
/usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 && sync
Como substituir os comandos

Para substituir os comandos, use os provisionadores de script PowerShell ou Shell para criar os arquivos de
comando com o nome exato do arquivo e coloque-os nos diretórios corretos:
Windows: c:\DeprovisioningScript.ps1
Linux: /tmp/DeprovisioningScript.sh
O Construtor de Imagens lerá esses comandos, que serão gravados nos logs do AIB, 'customization.log'. Confira
solução de problemas sobre como coletar logs.
Propriedades: distribuição
O Construtor de Imagens do Azure dá suporte a três destinos de distribuição:
managedImage – imagem gerenciada.
sharedImage – Galeria de Imagens Compartilhadas.
VHD – VHD em uma conta de armazenamento.
Você pode distribuir uma imagem para ambos os tipos de destino na mesma configuração.
NOTE
O comando AIB Sysprep padrão não inclui "/Mode: VM", mas isso talvez seja necessário ao criar imagens que terão a
função HyperV instalada. Se você precisar adicionar esse argumento de comando, deverá substituir o comando Sysprep.
Como você pode ter mais de um destino para distribuir, o Construtor de Imagens mantém um estado para cada
destino de distribuição que pode ser acessado consultando o runOutputName . O runOutputName é um objeto que
você pode consultar após a distribuição para obter informações sobre essa distribuição. Por exemplo, você pode
consultar o local do VHD ou as regiões nas quais a versão da imagem foi replicada ou a versão de imagem SIG
criada. Essa é uma propriedade de cada destino de distribuição. O runOutputName deve ser exclusivo para cada
destino de distribuição. Aqui está um exemplo, consultando uma distribuição da Galeria de Imagens
Compartilhadas:
subscriptionID=<subcriptionID>
imageResourceGroup=<resourceGroup of image template>
runOutputName=<runOutputName>
az resource show \
--ids
"/subscriptions/$subscriptionID/resourcegroups/$imageResourceGroup/providers/Microsoft.VirtualMachineImages/
imageTemplates/ImageTemplateLinuxRHEL77/runOutputs/$runOutputName" \
--api-version=2020-02-14
Saída:
{
"id":
"/subscriptions/xxxxxx/resourcegroups/rheltest/providers/Microsoft.VirtualMachineImages/imageTemplates/Image
TemplateLinuxRHEL77/runOutputs/rhel77",
"identity": null,
"kind": null,
"location": null,
"managedBy": null,
"name": "rhel77",
"plan": null,
"properties": {
"artifactId":
"/subscriptions/xxxxxx/resourceGroups/aibDevOpsImg/providers/Microsoft.Compute/galleries/devOpsSIG/images/rh
el/versions/0.24105.52755",
},
"resourceGroup": "rheltest",
"sku": null,
"tags": null,
"type": "Microsoft.VirtualMachineImages/imageTemplates/runOutputs"
}
Distribuição: managedImage
A saída da imagem será um recurso de imagem gerenciada.
{
"type":"managedImage",
"imageId": "<resource ID>",
"runOutputName": "<name>",
"artifactTags": {
"<name": "<value>",
"<name>": "<value>"
}
}
Propriedades de distribuição:
type – managedImage
imageid – ID de recurso da imagem de destino, formato esperado:/subscriptions/ <subscriptionId>
/resourceGroups/ <destinationResourceGroupName>
/Providers/Microsoft.Compute/images/<imageName>
local – local da imagem gerenciada.
runOutputName – nome exclusivo para identificar a distribuição.
ar tifactTags – marcas opcionais de par de chave-valor especificadas pelo usuário.
NOTE
O grupo de recursos de destino deve existir. Se você quiser que a imagem seja distribuída para uma região diferente, isso
aumentará o tempo de implantação.
Distribuição: sharedImage
A Galeria de Imagens Compartilhadas do Azure é um novo serviço de Gerenciamento de Imagens que permite
o gerenciamento de replicação de região de imagem, o controle de versão e o compartilhamento de imagens
personalizadas. O Construtor de Imagens do Azure dá suporte à distribuição com esse serviço, assim, você pode
distribuir imagens para regiões com suporte nas Galerias de Imagens Compartilhadas.
Uma Galeria de Imagens Compartilhadas é composta por:
Galeria – contêiner para várias imagens compartilhadas. Uma galeria é implantada em uma região.
Definições de imagem – um agrupamento conceitual para imagens.
Versões de imagem – esse é um tipo de imagem usado para implantar uma VM ou um conjunto de
dimensionamento. As versões de imagem podem ser replicadas para outras regiões em que as VMs
precisam ser implantadas.
Antes de distribuir para a Galeria de Imagens, você deve criar uma galeria e uma definição de imagem. Confira
Imagens compartilhadas.
{
"type": "SharedImage",
"galleryImageId": "<resource ID>",
"runOutputName": "<name>",
"artifactTags": {
"<name>": "<value>",
"<name>": "<value>"
},
"replicationRegions": [
"<region where the gallery is deployed>",
"<region>"
]
}
Distribuir propriedades para galerias de imagens compartilhadas:

type – sharedImage
galler yImageId – ID da Galeria de imagens compartilhadas, isso pode ser especificado em dois
formatos:
O controle de versão automático-o Image Builder gerará um número de versão monotônico para
você, isso é útil quando você deseja manter a recriação de imagens do mesmo modelo: o formato é:
/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/galleries/<sharedImageGalleryName>/images/<imageG
.
Controle de versão explícito-você pode passar o número de versão que deseja que o construtor de
imagem use. O formato é:
/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.Compute/galleries/<sharedImageGalName>/images/<imageDefName>/version
e.g. 1.1.1>
ar tifactTags – marcas opcionais de par de chave-valor especificadas pelo usuário.
replicationRegions – matriz de regiões para replicação. Uma das regiões deve ser aquela em que a
galeria é implantada. A adição de regiões significa um aumento do tempo de compilação, pois a
compilação não será concluída até que a replicação seja concluída.
excludeFromLatest (opcional) isso permite marcar a versão da imagem que você cria não ser usada
como a versão mais recente na definição SIG, o padrão é ' false '.
storageAccountType (opcional) o AIB dá suporte à especificação desses tipos de armazenamento para
a versão de imagem a ser criada:
"Standard_LRS"
"Standard_ZRS"
NOTE
Se o modelo de imagem e o referenciado image definition não estiverem no mesmo local, você verá um tempo
adicional para criar imagens. Atualmente, o Image Builder não tem um location parâmetro para o recurso de versão da
imagem, nós o pegamos de seu pai image definition . Por exemplo, se uma definição de imagem estiver em westus e
você quiser que a versão da imagem seja replicada para o lesteus, um blob será copiado para o westus, a partir desse, um
recurso de versão da imagem em westus será criado e, em seguida, replicado para o eastus. Para evitar o tempo de
replicação adicional, verifique se o image definition modelo de imagem e está no mesmo local.
Distribuir: VHD
Você pode gerar uma saída para um VHD. Em seguida, você pode copiar o VHD e usá-lo para publicar no Azure
MarketPlace ou usar com Azure Stack.
{
"type": "VHD",
"runOutputName": "<VHD name>",
"tags": {
"<name": "<value>",
"<name>": "<value>"
}
}
Suporte a SO: Windows e Linux

Distribuir parâmetros de VHD:
type – VHD.
tags – marcas opcionais de par de chave-valor especificadas pelo usuário.
O Construtor de Imagens do Azure não permite que o usuário especifique um local de conta de
armazenamento, mas você pode consultar o status de runOutputs para obter o local.
az resource show \
--ids
"/subscriptions/$subscriptionId/resourcegroups/<imageResourceGroup>/providers/Microsoft.VirtualMachineImages
/imageTemplates/<imageTemplateName>/runOutputs/<runOutputName>" | grep artifactUri
NOTE
Depois que o VHD tiver sido criado, copie-o para um local diferente assim que possível. O VHD é armazenado em uma
conta de armazenamento no grupo de recursos temporário criado quando o modelo de imagem é enviado para o serviço
do Construtor de Imagens do Azure. Se você excluir o modelo de imagem, o VHD será perdido.
Operações de modelo de imagem

Iniciando uma compilação de imagem
Para iniciar uma compilação, você precisa invocar ' Run ' no recurso de modelo de imagem, exemplos de run
comandos:

ResourceType Microsoft.VirtualMachineImages/imageTemplates -ApiVersion "2020-02-14" -Action Run -Force
-n helloImageTemplateLinux01 \
--action Run
Cancelando uma compilação de imagem

Se você estiver executando uma compilação de imagem que acredite que está incorreta, aguardando a entrada
do usuário ou se sentir que nunca será concluída com êxito, poderá cancelar a compilação.
A compilação pode ser cancelada a qualquer momento. Se a fase de distribuição foi iniciada, ainda será possível
cancelar, mas você precisará limpar todas as imagens que podem não ser concluídas. O comando cancelar não
aguarda o cancelamento da conclusão, monitore o lastrunstatus.runstate andamento do cancelamento,
usando esses comandosde status.
Exemplos de cancel comandos:

ResourceType Microsoft.VirtualMachineImages/imageTemplates -ApiVersion "2020-02-14" -Action Cancel -Force
-n helloImageTemplateLinux01 \
--action Cancel
Próximas etapas
Há arquivos .json de exemplo para diferentes cenários no Construtor de Imagens do Azure no GitHub.
Visualização: Criar uma imagem do Linux e
distribuí-la para uma Galeria de Imagens
Compartilhadas
Este artigo mostra como usar o Construtor de Imagens do Azure e a CLI do Azure para criar uma versão de
imagem em uma Galeria de Imagens Compartilhadas e distribuir a imagem globalmente. Faça isso também
com o Azure PowerShell.
Usaremos um modelo .json de exemplo para configurar a imagem. O arquivo .json que estamos usando está
aqui: helloImageTemplateforSIG.json.
IMPORTANT


# Resource group name - we are using ibLinuxGalleryRG in this example

location=westus2
sigName=myIbGallery
runOutputName=aibLinuxSIG
az group create -n $sigResourceGroup -l $location

grupo de recursos
az identity create -g $sigResourceGroup -n $idenityName
# get identity id
imgBuilderCliId=$(az identity show -g $sigResourceGroup -n $idenityName | grep "clientId" | cut -c16- | tr -
d '",')

imgBuilderId=/subscriptions/$subscriptionID/resourcegroups/$sigResourceGroup/providers/Microsoft.ManagedIden
tity/userAssignedIdentities/$idenityName
# this command will download an Azure role definition template, and update the template with the parameters
specified earlier.
curl

sed -i -e "s/<rgName>/$sigResourceGroup/g" aibRoleImageCreation.json


Criar uma definição de imagem e uma galeria

az sig create \
Em seguida, crie uma definição de imagem.

--publisher myIbPublisher \
--offer myOffer \
--sku 18.04-LTS \
--os-type Linux
Baixar e configurar o .json

curl
om_Linux_Shared_Image_Gallery_Image/helloImageTemplateforSIG.json -o helloImageTemplateforSIG.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateforSIG.json
sed -i -e "s/<rgName>/$sigResourceGroup/g" helloImageTemplateforSIG.json
sed -i -e "s/<imageDefName>/$imageDefName/g" helloImageTemplateforSIG.json
sed -i -e "s/<sharedImageGalName>/$sigName/g" helloImageTemplateforSIG.json
sed -i -e "s/<region1>/$location/g" helloImageTemplateforSIG.json
sed -i -e "s/<region2>/$additionalregion/g" helloImageTemplateforSIG.json
sed -i -e "s/<runOutputName>/$runOutputName/g" helloImageTemplateforSIG.json
sed -i -e "s%<imgBuilderId>%$imgBuilderId%g" helloImageTemplateforSIG.json

Esta próxima parte criará a versão da imagem na galeria.
--properties @helloImageTemplateforSIG.json \
--is-full-object \
-n helloImageTemplateforSIG01 \
--action Run
Criar a VM
az vm create \
--name myAibGalleryVM \
--image
--generate-ssh-keys
estabelecida.
*******************************************************
*******************************************************
Limpar os recursos
Caso deseje tentar agora personalizar novamente a versão da imagem para criar uma versão da mesma
imagem, ignore as próximas etapas e acesse Usar o Construtor de Imagens do Azure para criar outra versão de
imagem.

Obtenha a versão da imagem criada pelo Construtor de Imagens, que sempre começa com 0. , e exclua a
versão da imagem
sigDefImgVersion=$(az sig image-version list \

--subscription $subscriptionID --query [].'name' -o json | grep 0. | tr -d '"')
--gallery-image-version $sigDefImgVersion \
Exclua a definição da imagem.

Exclua a galeria.
az sig delete -r $sigName -g $sigResourceGroup
az group delete -n $sigResourceGroup -y
Próximas etapas
Visualização: Criar uma imagem do Windows e
distribuí-la para uma Galeria de Imagens
Compartilhadas
Este artigo mostra como você pode usar o Construtor de Imagens do Azure e o Azure PowerShell para criar
uma versão de imagem em uma Galeria de Imagens Compartilhadas e, em seguida, distribuir a imagem
globalmente. Você também pode fazer isso usando a CLI do Azure.
Usaremos um modelo .json para configurar a imagem. O arquivo .json que estamos usando está aqui:
armTemplateWinSIG. JSON. Vamos baixar e editar uma versão local do modelo, assim, este artigo é escrito
usando a sessão local do PowerShell.
O Construtor de Imagens do Azure executa automaticamente sysprep para generalizar a imagem. Esse é um
comando sysprep genérico que você pode substituir, se necessário.
Esteja ciente de quantas vezes você extratifica as personalizações. Você pode executar o comando Sysprep até
oito vezes em uma imagem do Windows. Depois de executar o Sysprep oito vezes, você deverá recriar a
imagem do Windows. Para obter mais informações, confira Limites de quantas vezes você pode executar o
Sysprep.
IMPORTANT

Get-AzProviderFeature -FeatureName VirtualMachineTemplatePreview -ProviderNamespace

Aguarde até que RegistrationState seja Registered para passar para a próxima etapa.
Verifique os registros do provedor. Verifique se cada um retorna Registered .
Get-AzResourceProvider -ProviderNamespace Microsoft.VirtualMachineImages | Format-table -Property
Get-AzResourceProvider -ProviderNamespace Microsoft.Storage | Format-table -Property
Get-AzResourceProvider -ProviderNamespace Microsoft.Compute | Format-table -Property
Get-AzResourceProvider -ProviderNamespace Microsoft.KeyVault | Format-table -Property
Se não retornarem Registered , use o seguinte para registrar os provedores:
Register-AzResourceProvider -ProviderNamespace Microsoft.VirtualMachineImages

Register-AzResourceProvider -ProviderNamespace Microsoft.Storage
Register-AzResourceProvider -ProviderNamespace Microsoft.KeyVault
Criar variáveis
Substitua os valores das variáveis, como username e vmpassword , por suas informações.
# Get existing context

$currentAzContext = Get-AzContext
# Get your current subscription ID.

$subscriptionID=$currentAzContext.Subscription.Id
# Destination image resource group

$imageResourceGroup="aibwinsig"
# Location
$location="westus"
# Image distribution metadata reference name

$runOutputName="aibCustWinManImg02ro"
# Image template name

$imageTemplateName="helloImageTemplateWin02ps"
# Distribution properties object name (runOutput).

# This gives you the properties of the managed image on completion.
$runOutputName="winclientR01"
# Create a resource group for Image Template and Shared Image Gallery
-Name $imageResourceGroup `
-Location $location

grupo de recursos
# setup role def names, these need to be unique
$identityName="aibIdentity"+$timeInt

# create identity
New-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name $identityName

$identityName).Id
Atribuir permissões para identidade para distribuir imagens

Esse comando baixará um modelo de definição de função do Azure e atualizará o modelo com os parâmetros
especificados anteriormente.
$aibRoleImageCreationUrl="https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solution
s/12_Creating_AIB_Security_Roles/aibRoleImageCreation.json"
$aibRoleImageCreationPath = "aibRoleImageCreation.json"
# download config
Invoke-WebRequest -Uri $aibRoleImageCreationUrl -OutFile $aibRoleImageCreationPath -UseBasicParsing
((Get-Content -path $aibRoleImageCreationPath -Raw) -replace '<subscriptionID>',$subscriptionID) | Set-

Content -Path $aibRoleImageCreationPath
((Get-Content -path $aibRoleImageCreationPath -Raw) -replace '<rgName>', $imageResourceGroup) | Set-Content
-Path $aibRoleImageCreationPath
((Get-Content -path $aibRoleImageCreationPath -Raw) -replace 'Azure Image Builder Service Image Creation
Role', $imageRoleDefName) | Set-Content -Path $aibRoleImageCreationPath
# create role definition

New-AzRoleDefinition -InputFile ./aibRoleImageCreation.json
# grant role definition to image builder service principal

New-AzRoleAssignment -ObjectId $identityNamePrincipalId -RoleDefinitionName $imageRoleDefName -Scope
### NOTE: If you see this error: 'New-AzRoleDefinition: Role definition limit exceeded. No more role
definitions can be created.' See this article to resolve:
https://docs.microsoft.com/azure/role-based-access-control/troubleshooting
Criar a Galeria de Imagens Compartilhadas

# Image gallery name
$sigGalleryName= "myIBSIG"
# Image definition name

$imageDefName ="winSvrimage"
# additional replication region

$replRegion2="eastus"
# Create the gallery

New-AzGallery `
-GalleryName $sigGalleryName `
-ResourceGroupName $imageResourceGroup `
-Location $location
# Create the image definition

New-AzGalleryImageDefinition `
-Name $imageDefName `
-OsState generalized `
-OsType Windows `
-Publisher 'myCompany' `
-Offer 'WindowsServer' `
-Sku 'WinSrv2019'
Baixar e configurar o modelo

$templateFilePath = "armTemplateWinSIG.json"
Invoke-WebRequest `
-Uri
"https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/1_Creating_a_Cus
tom_Win_Shared_Image_Gallery_Image/armTemplateWinSIG.json" `
-OutFile $templateFilePath `
-UseBasicParsing
(Get-Content -path $templateFilePath -Raw ) `

-replace '<subscriptionID>',$subscriptionID | Set-Content -Path $templateFilePath
-replace '<rgName>',$imageResourceGroup | Set-Content -Path $templateFilePath
-replace '<runOutputName>',$runOutputName | Set-Content -Path $templateFilePath
-replace '<imageDefName>',$imageDefName | Set-Content -Path $templateFilePath
-replace '<sharedImageGalName>',$sigGalleryName | Set-Content -Path $templateFilePath
-replace '<region1>',$location | Set-Content -Path $templateFilePath
-replace '<region2>',$replRegion2 | Set-Content -Path $templateFilePath
((Get-Content -path $templateFilePath -Raw) -replace '<imgBuilderId>',$identityNameResourceId) | Set-Content
-Path $templateFilePath

Seu modelo deve ser enviado ao serviço. Isso baixará artefatos dependentes (como scripts) e os armazenará no
Grupo de Recursos de preparo, prefixado com IT_ .
New-AzResourceGroupDeployment `
-TemplateFile $templateFilePath `
-apiversion "2019-05-01-preview" `
-imageTemplateName $imageTemplateName `
-svclocation $location
Para criar a imagem, você precisa invocar 'Run' no modelo.
Invoke-AzResourceAction `
-ResourceName $imageTemplateName `
-ResourceType Microsoft.VirtualMachineImages/imageTemplates `
-ApiVersion "2019-05-01-preview" `
-Action Run
Para obter informações sobre as opções para automatizar a obtenção do status do build da imagem, confira o
Leiame para este modelo no GitHub.
Criar a VM
Obtenha a versão da imagem que você criou.
$imageVersion = Get-AzGalleryImageVersion `
-GalleryImageDefinitionName $imageDefName
Crie a VM na segunda região em que a imagem foi replicada.

$vmResourceGroup = "myResourceGroup"


New-AzResourceGroup -Name $vmResourceGroup -Location $replRegion2
# Network pieces
$vnet = New-AzVirtualNetwork -ResourceGroupName $vmResourceGroup -Location $replRegion2 `
$pip = New-AzPublicIpAddress -ResourceGroupName $vmResourceGroup -Location $replRegion2 `
$nsg = New-AzNetworkSecurityGroup -ResourceGroupName $vmResourceGroup -Location $replRegion2 `
$nic = New-AzNetworkInterface -Name myNic -ResourceGroupName $vmResourceGroup -Location $replRegion2 `
# Create a virtual machine configuration using $imageVersion.Id to specify the shared image
Set-AzVMSourceImage -Id $imageVersion.Id | `

New-AzVM -ResourceGroupName $vmResourceGroup -Location $replRegion2 -VM $vmConfig
dir c:\
Você deve ver um diretório chamado buildActions que foi criado durante a personalização da imagem.
Limpar os recursos
Se você quiser agora tentar personalizar novamente a versão da imagem para criar uma versão da mesma
imagem, ignore esta etapa e vá para Usar o Construtor de Imagens do Azure para criar outra versão de
imagem.
Exclua o modelo do grupo de recursos primeiro, caso contrário, o grupo de recursos de preparo (IT_ ) usado
pelo AIB não será limpo.
Obter ResourceID do modelo de imagem.
$resTemplateId = Get-AzResource -ResourceName $imageTemplateName -ResourceGroupName $imageResourceGroup -

ResourceType Microsoft.VirtualMachineImages/imageTemplates -ApiVersion "2019-05-01-preview"
Excluir modelo de imagem.

Remove-AzResource -ResourceId $resTemplateId.ResourceId -Force
Excluir atribuição de função
Remove-AzRoleAssignment -ObjectId $identityNamePrincipalId -RoleDefinitionName $imageRoleDefName -Scope

remover definições
Remove-AzRoleDefinition -Name "$identityNamePrincipalId" -Force -Scope

excluir identidade
Remove-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name $identityName -Force
excluir o grupo de recursos.
Remove-AzResourceGroup $imageResourceGroup -Force
Próximas etapas
Para saber como atualizar a versão de imagem que você criou, confira Usar o Construtor de Imagens do Azure
para criar outra versão de imagem.
Visualização: criar uma nova versão de imagem de
VM de uma versão de imagem existente usando o
construtor de imagem do Azure no Linux
Este artigo mostra como usar uma versão de imagem existente em uma Galeria de imagens compartilhadas,
atualizá-la e publicá-la como uma nova versão de imagem na galeria.
aqui: helloImageTemplateforSIGfromSIG.jsem.



Se você usou criar uma imagem e distribuir para uma galeria de imagens compartilhadas para criar sua galeria
de imagens compartilhadas, você já criou algumas das variáveis que precisamos. Caso contrário, configure
algumas variáveis a serem usadas para este exemplo.
# Resource group name
# Gallery location
location=westus2
# Additional region to replicate the image version to
# Name of the shared image gallery
sigName=myIbGallery
# Name of the image definition to use
runOutputName=aibSIGLinuxUpdate
Obtenha a versão da imagem que você deseja atualizar.
sigDefImgVersionId=$(az sig image-version list \

--subscription $subscriptionID --query [].'id' -o json | grep 0. | tr -d '"' | tr -d '[:space:]')

grupo de recursos
Como você definiu a identidade do usuário no exemplo anterior, só precisa obter a ID do recurso, e então ela
será anexada ao modelo.
#get identity used previously

imgBuilderId=$(az identity list -g $sigResourceGroup --query "[?contains(name, 'aibBuiUserId')].id" -o tsv)
Se você já tiver sua própria galeria de imagens compartilhadas e não seguir o exemplo anterior, será necessário
atribuir permissões para que o Image Builder acesse o grupo de recursos, para que possa acessar a galeria.
Examine as etapas no exemplo criar uma imagem e distribuir para uma galeria de imagens compartilhadas .
Modificar exemplo de helloImage

Você pode examinar o exemplo que estamos prestes a usar abrindo o arquivo. JSON aqui:
helloImageTemplateforSIGfromSIG.js juntamente com a referência de modelo do Image Builder.
Baixe o exemplo. JSON e configure-o com suas variáveis.
curl
om_Linux_Shared_Image_Gallery_Image_from_SIG/helloImageTemplateforSIGfromSIG.json -o
helloImageTemplateforSIGfromSIG.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateforSIGfromSIG.json
sed -i -e "s/<rgName>/$sigResourceGroup/g" helloImageTemplateforSIGfromSIG.json
sed -i -e "s/<imageDefName>/$imageDefName/g" helloImageTemplateforSIGfromSIG.json
sed -i -e "s/<sharedImageGalName>/$sigName/g" helloImageTemplateforSIGfromSIG.json
sed -i -e "s%<sigDefImgVersionId>%$sigDefImgVersionId%g" helloImageTemplateforSIGfromSIG.json
sed -i -e "s/<region1>/$location/g" helloImageTemplateforSIGfromSIG.json
sed -i -e "s/<region2>/$additionalregion/g" helloImageTemplateforSIGfromSIG.json
sed -i -e "s/<runOutputName>/$runOutputName/g" helloImageTemplateforSIGfromSIG.json
sed -i -e "s%<imgBuilderId>%$imgBuilderId%g" helloImageTemplateforSIGfromSIG.json
Criar a imagem
--properties @helloImageTemplateforSIGfromSIG.json \
--is-full-object \
-n helloImageTemplateforSIGfromSIG01
-n helloImageTemplateforSIGfromSIG01 \
--action Run
Aguarde até que a imagem tenha sido criada e replicação antes de passar para a próxima etapa.
Criar a VM
az vm create \
--name aibImgVm001 \
--image
--generate-ssh-keys
Crie uma conexão SSH com a VM usando o endereço IP público da VM.
ssh azureuser@<pubIp>
Você deve ver que a imagem foi personalizada com uma "mensagem do dia" assim que a conexão SSH é
estabelecida.
*******************************************************
*******************************************************
Digite exit para fechar a conexão SSH.

Você também pode listar as versões de imagem que agora estão disponíveis na galeria.
az sig image-version list -g $sigResourceGroup -r $sigName -i $imageDefName -o table
Próximas etapas
Image Builder.
Visualização: criar uma nova versão de imagem de
VM de uma versão de imagem existente usando o
construtor de imagem do Azure no Windows
Este artigo mostra como usar uma versão de imagem existente em uma Galeria de imagens compartilhadas,
atualizá-la e publicá-la como uma nova versão de imagem na galeria.
aqui: helloImageTemplateforSIGfromWinSIG.jsem.
IMPORTANT



Se você usou criar uma imagem e distribuir para uma galeria de imagens compartilhadas para criar sua galeria
de imagens compartilhadas, você já criou as variáveis que precisamos. Caso contrário, configure algumas
variáveis a serem usadas para este exemplo.
# Resource group name - we are using ibsigRG in this example

sigResourceGroup=myIBWinRG
location=westus
sigName=my22stSIG
imageDefName=winSvrimages
runOutputName=w2019SigRo
# User name and password for the VM
username="user name for the VM"
vmpassword="password for the VM"
Obtenha a versão da imagem que você deseja atualizar.
sigDefImgVersionId=$(az sig image-version list \

--subscription $subscriptionID --query [].'id' -o json | grep 0. | tr -d '"' | tr -d '[:space:]')

grupo de recursos
Como você definiu a identidade do usuário no exemplo anterior, só precisa obter a ID do recurso, e então ela
será anexada ao modelo.
#get identity used previously

imgBuilderId=$(az identity list -g $sigResourceGroup --query "[?contains(name, 'aibBuiUserId')].id" -o tsv)
Se você já tiver sua própria galeria de imagens compartilhadas e não seguir o exemplo anterior, será necessário
atribuir permissões para que o Image Builder acesse o grupo de recursos, para que possa acessar a galeria.
Examine as etapas no exemplo criar uma imagem e distribuir para uma galeria de imagens compartilhadas .
Modificar exemplo de helloImage

Você pode examinar o exemplo que estamos prestes a usar abrindo o arquivo. JSON aqui:
helloImageTemplateforSIGfromSIG.js juntamente com a referência de modelo do Image Builder.
Baixe o exemplo. JSON e configure-o com suas variáveis.
curl
om_Win_Shared_Image_Gallery_Image_from_SIG/helloImageTemplateforSIGfromWinSIG.json -o
helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<rgName>/$sigResourceGroup/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<imageDefName>/$imageDefName/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<sharedImageGalName>/$sigName/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s%<sigDefImgVersionId>%$sigDefImgVersionId%g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<region1>/$location/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<region2>/$additionalregion/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s/<runOutputName>/$runOutputName/g" helloImageTemplateforSIGfromWinSIG.json
sed -i -e "s%<imgBuilderId>%$imgBuilderId%g" helloImageTemplateforSIGfromWinSIG.json
Criar a imagem
--properties @helloImageTemplateforSIGfromWinSIG.json \
--is-full-object \
-n imageTemplateforSIGfromWinSIG01
-n imageTemplateforSIGfromWinSIG01 \
--action Run
Aguarde até que a imagem tenha sido criada e replicação antes de passar para a próxima etapa.
Criar a VM
az vm create \
--name aibImgWinVm002 \
--admin-username $username \
--admin-password $vmpassword \
--image
--location $location
dir c:\
Agora você deve ver dois diretórios:

buildActions que foi criado na primeira versão da imagem.
buildActions2 que foi criado como parte acima, atualizando a primeira versão da imagem para criar a
segunda versão da imagem.
Próximas etapas
Image Builder.
Criar uma imagem e usar uma identidade
gerenciada atribuída pelo usuário para acessar
arquivos no armazenamento do Azure
O construtor de imagem do Azure dá suporte ao uso de scripts ou à cópia de arquivos de vários locais, como o
GitHub e o armazenamento do Azure, etc. Para usá-los, eles devem ter sido externamente acessíveis ao
construtor de imagens do Azure, mas você pode proteger os blobs de armazenamento do Azure usando tokens
SAS.
Este artigo mostra como criar uma imagem personalizada usando o construtor de imagem de VM do Azure, em
que o serviço usará uma identidade gerenciada atribuída pelo usuário para acessar arquivos no
armazenamento do Azure para a personalização da imagem, sem a necessidade de tornar os arquivos acessíveis
publicamente ou configurar tokens SAS.
No exemplo a seguir, você criará dois grupos de recursos, um será usado para a imagem personalizada e o
outro hospedará uma conta de armazenamento do Azure, que contém um arquivo de script. Isso simula um
cenário de vida real, no qual você pode ter artefatos de compilação ou arquivos de imagem em diferentes
contas de armazenamento, fora do construtor de imagem. Você criará uma identidade atribuída pelo usuário e
concederá permissões de leitura no arquivo de script, mas não definirá qualquer acesso público a esse arquivo.
Em seguida, você usará o personalizador de Shell para baixar e executar o script da conta de armazenamento.
IMPORTANT



# Image resource group name

imageResourceGroup=aibmdimsi
# storage resource group
strResourceGroup=aibmdimsistor
# Location
location=WestUS2
imageName=aibCustLinuxImgMsi01
runOutputName=u1804ManImgMsiro
subscriptionID=<Your subscription ID>
Crie os grupos de recursos para a imagem e o armazenamento de script.
# create resource group for image template

# create resource group for the script storage
az group create -n $strResourceGroup -l $location
Crie uma identidade atribuída pelo usuário e defina permissões no grupo de recursos.
O Image Builder usará a identidade do usuário fornecida para injetar a imagem no grupo de recursos. Neste
exemplo, você criará uma definição de função do Azure que tem as ações granulares para executar a
distribuição da imagem. A definição de função será então atribuída à identidade do usuário.
# get identity id
-d '",')

# download preconfigured role definition example

curl



--role "Azure Image Builder Service Image Creation Role" \
Crie o armazenamento e copie o script de exemplo para ele do GitHub.
# script storage account

scriptStorageAcc=aibstorscript$(date +'%s')
# script container
scriptStorageAccContainer=scriptscont$(date +'%s')
# script url
scriptUrl=https://$scriptStorageAcc.blob.core.windows.net/$scriptStorageAccContainer/customizeScript.sh

az storage account create -n $scriptStorageAcc -g $strResourceGroup -l $location --sku Standard_LRS
az storage container create -n $scriptStorageAccContainer --fail-on-exist --account-name $scriptStorageAcc
# copy in an example script from the GitHub repo

az storage blob copy start \
--destination-blob customizeScript.sh \
--destination-container $scriptStorageAccContainer \
--account-name $scriptStorageAcc \
--source-uri
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/customizeScript.s
h
Conceda permissão do construtor de imagem para criar recursos no grupo de recursos de imagem. O
--assignee valor é a ID de identidade do usuário.
--role "Storage Blob Data Reader" \
--scope
/subscriptions/$subscriptionID/resourceGroups/$strResourceGroup/providers/Microsoft.Storage/storageAccounts/
$scriptStorageAcc/blobServices/default/containers/$scriptStorageAccContainer
Modificar o exemplo
Baixe o arquivo example. JSON e configure-o com as variáveis que você criou.
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/7_Creating_Custom
_Image_using_MSI_to_Access_Storage/helloImageTemplateMsi.json -o helloImageTemplateMsi.json
sed -i -e "s/<subscriptionID>/$subscriptionID/g" helloImageTemplateMsi.json
sed -i -e "s/<rgName>/$imageResourceGroup/g" helloImageTemplateMsi.json
sed -i -e "s/<region>/$location/g" helloImageTemplateMsi.json
sed -i -e "s/<imageName>/$imageName/g" helloImageTemplateMsi.json
sed -i -e "s%<scriptUrl>%$scriptUrl%g" helloImageTemplateMsi.json
sed -i -e "s%<imgBuilderId>%$imgBuilderId%g" helloImageTemplateMsi.json
sed -i -e "s%<runOutputName>%$runOutputName%g" helloImageTemplateMsi.json
Criar a imagem
--properties @helloImageTemplateMsi.json \
--is-full-object \
-n helloImageTemplateMsi01
-n helloImageTemplateMsi01 \
--action Run
Aguarde a conclusão do build. Isso pode levar cerca de 15 minutos.

Crie uma VM a partir da imagem.
az vm create \
--name aibImgVm00 \
--generate-ssh-keys
Depois que a VM tiver sido criada, inicie uma sessão SSH com a VM.
ssh aibuser@<publicIp>
estabelecida.
*******************************************************
*******************************************************
Limpar
Quando tiver terminado, você poderá excluir os recursos se eles não forem mais necessários.

``àzurecli-interactive
-n helloImageTemplateMsi01
az group delete -n $strResourceGroup
Próximas etapas
Se você tiver problemas para trabalhar com o construtor de imagem do Azure, consulte solução de problemas.
Solucionar problemas do serviço Construtor de
imagens do Azure
Este artigo ajuda você a solucionar problemas e resolver problemas comuns que você pode encontrar ao usar o
serviço do construtor de imagem do Azure.
Falhas de AIB podem ocorrer em duas áreas:
Envio de modelo de imagem
Compilação de imagem
Solucionar erros de envio de modelo de imagem

Os erros de envio do modelo de imagem são retornados somente no envio. Não há um log de erros para erros
de envio de modelo de imagem. Se houve um erro durante o envio, você pode retornar o erro verificando o
status do modelo, examinando especificamente o ProvisioningState e o ProvisioningErrorMessage /
provisioningError .
az image builder show --name $imageTemplateName --resource-group $imageResourceGroup
Get-AzImageBuilderTemplate -ImageTemplateName <imageTemplateName> -ResourceGroupName

<imageTemplateResourceGroup> | Select-Object ProvisioningState, ProvisioningErrorMessage
NOTE
Para o PowerShell, você precisará instalar os módulos do PowerShell do Azure Image Builder.
As seções a seguir incluem diretrizes de resolução de problemas para erros de envio de modelo de imagem
comuns.
Não há suporte para atualização/atualização de modelos de imagem no momento
Erro
'Conflict'. Details: Update/Upgrade of image templates is currently not supported
Causa
O modelo já existe.
Solução
Se você enviar um modelo de configuração de imagem e o envio falhar, um artefato de modelo com falha ainda
existirá. Exclua o modelo com falha.
A operação de recurso foi concluída com o estado de provisionamento de terminal ' Failed '
Erro
Microsoft.VirtualMachineImages/imageTemplates 'helloImageTemplateforSIG01' failed with message '{
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "InternalOperationError",
"message": "Internal error occurred."
Causa
Na maioria dos casos, o erro de falha na implantação do recurso ocorre devido a falta de permissões.
Solução
Dependendo do seu cenário, o construtor de imagem do Azure pode precisar de permissões para:
Imagem de origem ou grupo de recursos da Galeria de imagens compartilhadas
Imagem de distribuição ou recurso da Galeria de imagens compartilhadas
A conta de armazenamento, o contêiner ou o blob que o personalizador de arquivo está acessando.
Para obter mais informações sobre como configurar permissões, consulte configurar permissões de serviço do
construtor de imagem do Azure usando CLI do Azure ou configurar permissões de serviço do construtor de
Erro ao obter imagem gerenciada
Erro
Build (Managed Image) step failed: Error getting Managed Image

'/subscriptions/.../providers/Microsoft.Compute/images/mymanagedmg1': Error getting managed image (...):
compute.
ImagesClient#Get: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service
returned an error.
Status=403 Code="AuthorizationFailed" Message="The client '......' with object id '......' does not have
authorization to perform action 'Microsoft.Compute/images/read' over scope
Causa
Permissões ausentes.
Solução
Dependendo do seu cenário, o construtor de imagem do Azure pode precisar de permissões para:
Imagem de origem ou grupo de recursos da Galeria de imagens compartilhadas
Imagem de distribuição ou recurso da Galeria de imagens compartilhadas
A conta de armazenamento, o contêiner ou o blob que o personalizador de arquivo está acessando.
Falha na etapa de compilação da versão da imagem
Erro
Build (Shared Image Version) step failed for Image Version
'/subscriptions/.../providers/Microsoft.Compute/galleries/.../images/... /versions/0.23768.4001': Error
getting Image Version
'/subscriptions/.../resourceGroups/<rgName>/providers/Microsoft.Compute/galleries/.../images/.../versions/0.
23768.4001': Error getting image version '... :0.23768.4001': compute.GalleryImageVersionsClient#Get:
Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error.
Status=404 Code="ResourceNotFound" Message="The Resource
'Microsoft.Compute/galleries/.../images/.../versions/0.23768.4001' under resource group '<rgName>' was not
found."
Causa
O construtor de imagens do Azure não pode localizar a imagem de origem.
Solução
Verifique se a imagem de origem está correta e se existe no local do serviço do construtor de imagens do Azure.
Baixando o arquivo externo para o arquivo local
Erro
Downloading external file (<myFile>) to local file (xxxxx.0.customizer.fp) [attempt 1 of 10] failed: Error
downloading '<myFile>' to 'xxxxx.0.customizer.fp'..
Causa
O nome ou o local do arquivo está incorreto ou o local não está acessível.
Solução
Verifique se o arquivo está acessível. Verifique se o nome e o local estão corretos.
Solucionar problemas de falhas de compilação

Para falhas de compilação de imagem, você pode obter o erro no lastrunstatus e, em seguida, examinar os
detalhes em customization. log.
az image builder show --name $imageTemplateName --resource-group $imageResourceGroup
Get-AzImageBuilderTemplate -ImageTemplateName <imageTemplateName> -ResourceGroupName

<imageTemplateResourceGroup> | Select-Object LastRunStatus, LastRunStatusMessage
Log de personalização
Quando a compilação da imagem está em execução, os logs são criados e armazenados em uma conta de
armazenamento. O construtor de imagens do Azure cria a conta de armazenamento no grupo de recursos
temporários quando você cria um artefato de modelo de imagem.
O nome da conta de armazenamento usa o seguinte padrão: IT_ <ImageResourceGroupName>
<TemplateName> <GUID>
Por exemplo, IT_aibmdi_helloImageTemplateLinux01.
Você pode exibir a personalização. log na conta de armazenamento no grupo de recursos, selecionando >
BLOBs da conta de armazenamento > packerlogs . Em seguida, selecione diretório > personalização. log .
Noções básicas sobre o log de personalização
O log é detalhado. Ele aborda a compilação da imagem, incluindo quaisquer problemas com a distribuição da
imagem, como a replicação da Galeria de imagens compartilhadas. Esses erros são exibidos na mensagem de
erro do status do modelo de imagem.
O customization. log inclui os seguintes estágios:
1. Implante a VM de compilação e as dependências usando modelos ARM no estágio de grupo de recursos
de preparo IT_. Este estágio inclui várias postagens no provedor de recursos do construtor de imagens do
Azure:
Azure request method="POST"

request="https://management.azure.com/subscriptions/<subID>/resourceGroups/IT_aibImageRG200_window201
9VnetTemplate01_dec33089-1cc3-cccc-cccc-ccccccc/providers/Microsoft.Storage/storageAccounts
..
PACKER OUT ==> azure-arm: Deploying deployment template ...
..
2. Status do estágio de implantações. Este estágio inclui o status de cada implantação de recurso:
PACKER ERR 2020/04/30 23:28:50 packer: 2020/04/30 23:28:50 Azure request method="GET"
request="https://management.azure.com/subscriptions/<subID>/resourcegroups/IT_aibImageRG200_window201
9VnetTemplate01_dec33089-1cc3-4505-ae28-
6661e43fac48/providers/Microsoft.Resources/deployments/pkrdp51lc0339jg/operationStatuses/085861331762
07523519?[REDACTED]" body=""
3. Conecte-se ao estágio Build VM.

Se o Windows, o serviço do construtor de imagem do Azure se conecta usando o WinRM:
PACKER ERR 2020/04/30 23:30:50 packer: 2020/04/30 23:30:50 Waiting for WinRM, up to timeout: 10m0s
..
PACKER OUT azure-arm: WinRM connected.
Se o Linux, o serviço do construtor de imagens do Azure se conectará usando SSH:
PACKER OUT ==> azure-arm: Waiting for SSH to become available...

PACKER ERR 2019/12/10 17:20:51 packer: 2020/04/10 17:20:51 [INFO] Waiting for SSH, up to timeout:
20m0s
PACKER OUT ==> azure-arm: Connected to SSH!
4. Executar o estágio de personalizações. Quando as personalizações são executadas, você pode identificá-
las examinando o customization. log. Procure (telemetria).
(telemetry) Starting provisioner windows-update

(telemetry) ending windows-update
(telemetry) Starting provisioner powershell
(telemetry) ending powershell
(telemetry) Starting provisioner file
(telemetry) ending file
(telemetry) Starting provisioner windows-restart
(telemetry) ending windows-restart
(telemetry) Finalizing. - This means the build hasfinished
5. Estágio de desprovisionamento. O construtor de imagens do Azure adiciona um personalizador oculto.

Essa etapa de desprovisionamento é responsável por preparar a VM para desprovisionamento. Ele
executa o Windows Sysprep (usando c:\DeprovisioningScript.ps1) ou o desprovisionamento do Linux
waagent (usando/tmp/DeprovisioningScript.sh).
Por exemplo:
PACKER ERR 2020/03/04 23:05:04 [INFO] (telemetry) Starting provisioner powershell
PACKER ERR 2020/03/04 23:05:04 packer: 2020/03/04 23:05:04 Found command: if( TEST-PATH
c:\DeprovisioningScript.ps1 ){cat c:\DeprovisioningScript.ps1} else {echo "Deprovisioning script
[c:\DeprovisioningScript.ps1] could not be found. Image build may fail or the VM created from the
Image may not boot. Please make sure the deprovisioning script is not accidentally deleted by a
Customizer in the Template."}
6. Limpar estágio. Depois que a compilação for concluída, os recursos do Azure Image Builder serão
excluídos.
PACKER ERR 2020/02/04 02:04:23 packer: 2020/02/04 02:04:23 Azure request method="DELETE"
request="https://management.azure.com/subscriptions/<subId>/resourceGroups/IT_aibDevOpsImg_t_vvvvvvv_
yyyyyy-de5f-4f7c-92f2-xxxxxxxx/providers/Microsoft.Network/networkInterfaces/pkrnijamvpo08eo?
[REDACTED]" body=""
Dicas para solução de problemas de personalização de

script/embutido
Testar o código antes de fornecê-lo ao construtor de imagens
Certifique-se de que os firewalls e Azure Policy permitem a conectividade com recursos remotos.
Comentários de saída para o console do, como Write-Host usar echo o ou o, permitirá que você pesquise o
customization. log.
Solucionar erros comuns de compilação

Falha no comando de Build do packr
Erro
"lastRunStatus": {
"startTime": "2020-04-30T23:24:06.756985789Z",
"endTime": "2020-04-30T23:39:14.268729811Z",
"runState": "Failed",
"message": "Failed while waiting for packerizer: Microservice has failed: Failed while processing
request: Error when executing packerizer: Packer build command has failed: exit status 1. During the image
build, a failure has occurred, please review the build log to identify which build/customization step
failed. For more troubleshooting steps go to https://aka.ms/azvmimagebuilderts. Image Build log location:
https://xxxxxxxxxx.blob.core.windows.net/packerlogs/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx/customization.log.
OperationId: xxxxxx-5a8c-4379-xxxx-8d85493bc791. Use this operationId to search packer logs."
Causa
Falha na personalização.
Solução
Examine o log para localizar as falhas dos personalizadores. Procure (telemetria).
Por exemplo:
(telemetry) Starting provisioner windows-update
(telemetry) ending windows-update
(telemetry) Starting provisioner powershell
(telemetry) ending powershell
(telemetry) Starting provisioner file
(telemetry) ending file
(telemetry) Starting provisioner windows-restart
(telemetry) ending windows-restart
(telemetry) Finalizing. - This means the build has finished
Tempo limite excedido

Erro
Deployment failed. Correlation ID: xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx. Failed in building/customizing image:

Failed while waiting for packerizer: Timeout waiting for microservice to complete: 'context deadline
exceeded'
Causa
A compilação excedeu o tempo limite da compilação. Esse erro é visto no ' LastRunStatus '.
Solução
1. Examine o customization. log. Identifique o último personalizador a ser executado. Pesquise (telemetry)
iniciando na parte inferior do log.
2. Verifique as personalizações de script. As personalizações podem não estar suprimindo a interação do
usuário para comandos, como quiet opções. Por exemplo, apt-get install -y resulta na execução do
script aguardando a interação do usuário.
3. Se você estiver usando o File personalizador para baixar artefatos maiores que 20 MB, consulte a seção
soluções alternativas.
4. Examine os erros e as dependências no script que podem fazer com que o script aguarde.
5. Se você espera que as personalizações precisem de mais tempo, aumente buildTimeoutInMinutes. O
padrão é quatro horas.
6. Se você tiver ações com uso intensivo de recursos, como baixar gigabytes de arquivos, considere o
tamanho da VM de compilação subjacente. O serviço usa uma VM Standard_D1_v2. A VM tem, 1 vCPU e
3,5 GB de memória. Se você estiver baixando 50 GB, isso provavelmente esgotará os recursos da VM e
causará falhas de comunicação entre o serviço do construtor de imagem do Azure e a VM de compilação.
Repita a compilação com uma VM de memória maior, definindo o VM_Size.
Tempo de download de arquivo longo
Erro
[086cf9c4-0457-4e8f-bfd4-908cfe3fe43c] PACKER OUT

myBigFile.zip 826 B / 826000 B 1.00%
myBigFile.zip 1652 B / 826000 B 2.00%
..
hours later...
..
myBigFile.zip 826000 B / 826000 B 100.00%
Causa
O personalizador de arquivo está baixando um arquivo grande.
Solução
O personalizador de arquivo é adequado apenas para downloads de arquivos pequenos com menos de 20 MB.
Para downloads de arquivos maiores, use um script ou comando embutido. Por exemplo, no Linux, você pode
usar wget ou curl . No Windows, você pode usar o Invoke-WebRequest .
Erro ao aguardar na Galeria de imagens compartilhadas
Erro
Deployment failed. Correlation ID: XXXXXX-XXXX-XXXXXX-XXXX-XXXXXX. Failed in distributing 1 images out of

total 1: {[Error 0] [Distribute 0] Error publishing MDI to shared image
gallery:/subscriptions/<subId>/resourceGroups/xxxxxx/providers/Microsoft.Compute/galleries/xxxxx/images/xxxx
xx, Location:eastus. Error: Error returned from SIG client while publishing MDI to shared image gallery for
dstImageLocation: eastus, dstSubscription: <subId>, dstResourceGroupName: XXXXXX, dstGalleryName: XXXXXX,
dstGalleryImageName: XXXXXX. Error: Error waiting on shared image gallery future for resource group: XXXXXX,
gallery name: XXXXXX, gallery image name: XXXXXX.Error: Future#WaitForCompletion: context has been
cancelled: StatusCode=200 -- Original Error: context deadline exceeded}
Causa
O Image Builder atingiu o tempo limite aguardando a imagem ser adicionada e replicada para a Galeria de
imagens compartilhada (SIG). Se a imagem estiver sendo injetada no SIG, ela poderá ser considerada que a
compilação da imagem foi bem-sucedida. No entanto, o processo geral falhou, pois o construtor de imagem
estava esperando na Galeria de imagens compartilhadas para concluir a replicação. Embora a compilação tenha
falhado, a replicação continua. Você pode obter as propriedades da versão da imagem verificando o runOutput
de distribuição.
$runOutputName=<distributionRunOutput>
az resource show \
--ids
"/subscriptions/$subscriptionID/resourcegroups/$imageResourceGroup/providers/Microsoft.VirtualMachineImages/
imageTemplates/$imageTemplateName/runOutputs/$runOutputName" \
--api-version=2019-05-01-preview
Solução
Aumente o buildTimeoutInMinutes .
Poucos eventos de informações de recursos do Windows
Erro
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER OUT azure-arm: Waiting for operation to complete (system

performance: 1% cpu; 37% memory)...
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER OUT azure-arm: Waiting for the Windows Modules Installer
to exit...
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER ERR 2020/04/30 23:38:58 packer: 2020/04/30 23:38:58 [INFO]
command 'PowerShell -ExecutionPolicy Bypass -OutputFormat Text -File C:/Windows/Temp/packer-windows-update-
elevated.ps1' exited with code: 101
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER OUT ==> azure-arm: Restarting the machine...
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER ERR 2020/04/30 23:38:58 packer: 2020/04/30 23:38:58 [INFO] RPC
endpoint: Communicator ended with: 101
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER ERR 2020/04/30 23:38:58 [INFO] 1672 bytes written for 'stdout'
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER ERR 2020/04/30 23:38:58 [INFO] 0 bytes written for 'stderr'
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER ERR 2020/04/30 23:38:58 [INFO] RPC client: Communicator ended
with: 101
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER ERR 2020/04/30 23:38:58 [INFO] RPC endpoint: Communicator
ended with: 101
ended with: 101
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER OUT ==> azure-arm: Waiting for machine to become available...
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER ERR 2020/04/30 23:38:58 packer-provisioner-windows-update:
2020/04/30 23:38:58 [INFO] 1672 bytes written for 'stdout'
2020/04/30 23:38:58 [INFO] 0 bytes written for 'stderr'
2020/04/30 23:38:58 [INFO] RPC client: Communicator ended with: 101
starting remote command: shutdown.exe -f -r -t 0 -c "packer restart"
command 'shutdown.exe -f -r -t 0 -c "packer restart"' exited with code: 0
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER OUT ==> azure-arm: A system shutdown is in progress.(1115)
with: 0
ended with: 0
starting remote command: shutdown.exe -f -r -t 60 -c "packer restart test"
command 'shutdown.exe -f -r -t 60 -c "packer restart test"' exited with code: 1115
with: 1115
ended with: 1115
2020/04/30 23:38:59 Retryable error: Machine not yet available (exit status 1115)
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER OUT Build 'azure-arm' errored: unexpected EOF
[45f485cf-5a8c-4379-9937-8d85493bc791] PACKER OUT
Causa
Esgotamento de recursos. Esse problema é normalmente visto com Windows Update em execução usando o
tamanho de VM de compilação padrão D1_V2.
Solução
Aumente o tamanho da VM de compilação.
Compilações concluídas, mas nenhum artefato foi criado
Erro
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER OUT Build 'azure-arm' errored: Future#WaitForCompletion:
context has been cancelled: StatusCode=200 -- Original Error: context deadline exceeded
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER ERR ==> Some builds didn't complete successfully and had
errors:
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER OUT
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER ERR 2020/04/30 22:29:23 machine readable: azure-arm,error
[]string{"Future#WaitForCompletion: context has been cancelled: StatusCode=200 -- Original Error: context
deadline exceeded"}
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER OUT ==> Some builds didn't complete successfully and had
errors:
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER ERR ==> Builds finished but no artifacts were created.
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER OUT --> azure-arm: Future#WaitForCompletion: context has been
cancelled: StatusCode=200 -- Original Error: context deadline exceeded
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER ERR 2020/04/30 22:29:23 Cancelling builder after context
cancellation context canceled
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER OUT
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER ERR 2020/04/30 22:29:23 [INFO] (telemetry) Finalizing.
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER OUT ==> Builds finished but no artifacts were created.
[a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER ERR 2020/04/30 22:29:24 waiting for all plugin processes to
complete...
Done exporting Packer logs to Azure for Packer prefix: [a170b40d-2d77-4ac3-8719-72cdc35cf889] PACKER OUT
Causa
Tempo limite causado pela espera dos recursos do Azure necessários para serem criados.
Solução
Execute novamente a compilação para tentar novamente.
Recurso não encontrado
Erro
"lastRunStatus": {
"startTime": "2020-05-01T00:13:52.599326198Z",
"endTime": "2020-05-01T00:15:13.62366898Z",
"runState": "Failed",
"message": "network.InterfacesClient#UpdateTags: Failure responding to request: StatusCode=404 --
Original Error: autorest/azure: Service returned an error. Status=404 Code=\"ResourceNotFound\"
Message=\"The Resource 'Microsoft.Network/networkInterfaces/aibpls7lz2e.nic.4609d697-be0a-4cb0-86af-
49b6fe877fe1' under resource group 'IT_aibImageRG200_window2019VnetTemplate01_9988723b-af56-413a-9006-
84130af0e9df' was not found.\""
},
Causa
Permissões ausentes.
Solução
Verifique novamente se o construtor de imagem do Azure tem todas as permissões necessárias.
Tempo de Sysprep
Erro
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: Write-Output '>>> Waiting for GA Service

(RdAgent) to start ...'
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: while ((Get-Service RdAgent) -and ((Get-
Service RdAgent).Status -ne 'Running')) { Start-Sleep -s 5 }
(WindowsAzureTelemetryService) to start ...'
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: while ((Get-Service
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: while ((Get-Service
WindowsAzureTelemetryService) -and ((Get-Service WindowsAzureTelemetryService).Status -ne 'Running')) {
Start-Sleep -s 5 }
(WindowsAzureGuestAgent) to start ...'
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: while ((Get-Service WindowsAzureGuestAgent)
-and ((Get-Service WindowsAzureGuestAgent).Status -ne 'Running')) { Start-Sleep -s 5 }
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: Write-Output '>>> Sysprepping VM ...'
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: if( Test-Path
$Env:SystemRoot\system32\Sysprep\unattend.xml ) {
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: Remove-Item
$Env:SystemRoot\system32\Sysprep\unattend.xml -Force
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: }
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: &
$Env:SystemRoot\System32\Sysprep\Sysprep.exe /oobe /generalize /quiet /quit
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: while($true) {
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: $imageState = (Get-ItemProperty
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\State).ImageState
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: Write-Output $imageState
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: if ($imageState -eq
'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { break }
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: Start-Sleep -s 5
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: }
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: Write-Output '>>> Sysprep complete ...'
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: >>> Waiting for GA Service (RdAgent) to
start ...
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: >>> Waiting for GA Service
(WindowsAzureTelemetryService) to start ...
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: >>> Waiting for GA Service
(WindowsAzureGuestAgent) to start ...
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: >>> Sysprepping VM ...
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: IMAGE_STATE_COMPLETE
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm: Get-Service : Cannot find any service with
service name 'WindowsAzureGuestAgent'.
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm: At C:\DeprovisioningScript.ps1:6 char:9
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm: + while ((Get-Service
WindowsAzureGuestAgent) -and ((Get-Service Window ...
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm: +
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm: + CategoryInfo :
ObjectNotFound: (WindowsAzureGuestAgent:String) [Get-Service], ServiceCommandException
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm: + FullyQualifiedErrorId :
NoServiceFoundForGivenName,Microsoft.PowerShell.Commands.GetServiceCommand
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm:
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT azure-arm: IMAGE_STATE_UNDEPLOYABLE
...
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER ERR 2020/05/05 22:26:17 Cancelling builder after context
cancellation context canceled
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT Cancelling build after receiving terminated
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER ERR 2020/05/05 22:26:17 packer: 2020/05/05 22:26:17 Cancelling
provisioning due to context cancellation: context canceled
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm:
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER ERR 2020/05/05 22:26:17 packer: 2020/05/05 22:26:17 Cancelling
hook after context cancellation context canceled
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER OUT ==> azure-arm: The resource group was not created by
Packer, deleting individual resources ...
[922bdf36-b53c-4e78-9cd8-6b70b9674685] PACKER ERR ==> azure-arm: The resource group was not created by
Packer, deleting individual resources ...
Causa
A causa pode ser um problema de tempo devido ao tamanho da VM D1_V2. Se as personalizações forem
limitadas e executadas em menos de três segundos, os comandos do Sysprep serão executados pelo construtor
de imagens do Azure para desprovisionar. Quando o construtor de imagem do Azure desprovisiona, o comando
Sysprep verifica o WindowsAzureGuestAgent, que pode não estar totalmente instalado, causando o problema
de tempo.
Solução
Aumente o tamanho da VM. Ou então, você pode adicionar uma personalização de suspensão do PowerShell de
60 segundos para evitar o problema de tempo.
Cancelando o Construtor após o contexto de cancelamento do contexto
Erro
PACKER ERR 2020/03/26 22:11:23 Cancelling builder after context cancellation context canceled
PACKER OUT Cancelling build after receiving terminated
PACKER ERR 2020/03/26 22:11:23 packer-builder-azure-arm plugin: Cancelling hook after context cancellation
context canceled
..
PACKER ERR 2020/03/26 22:11:23 packer-builder-azure-arm plugin: Cancelling provisioning due to context
cancellation: context canceled
PACKER ERR 2020/03/26 22:11:25 packer-builder-azure-arm plugin: [ERROR] Remote command exited without exit
status or exit signal.
PACKER ERR 2020/03/26 22:11:25 packer-builder-azure-arm plugin: [INFO] RPC endpoint: Communicator ended
with: 2300218
PACKER ERR 2020/03/26 22:11:25 [INFO] 148974 bytes written for 'stdout'
PACKER ERR 2020/03/26 22:11:25 [INFO] 0 bytes written for 'stderr'
PACKER ERR 2020/03/26 22:11:25 [INFO] RPC client: Communicator ended with: 2300218
PACKER ERR 2020/03/26 22:11:25 [INFO] RPC endpoint: Communicator ended with: 2300218
Causa
O serviço do construtor de imagem usa a porta 22 (Linux) ou 5986 (Windows) para se conectar à VM de
compilação, isso ocorre quando o serviço está desconectado da VM de compilação durante uma compilação de
imagem. Os motivos para a desconexão podem variar, mas habilitar ou configurar firewalls no script pode
bloquear as portas acima.
Solução
Examine os scripts de alterações/habilitação do firewall ou alterações no SSH ou no WinRM e verifique se as
alterações permitem a conectividade constante entre o serviço e a VM de compilação nas portas acima. Para
obter mais informações sobre a rede do Image Builder, consulte os requisitos.
Tarefa do DevOps
Solucionando problemas da tarefa
A tarefa só falhará se ocorrer um erro durante a personalização, quando isso acontecer, a tarefa relatará falha e
deixará o grupo de recursos de preparo, com os logs, para que você possa identificar o problema.
Para localizar o log, você precisa saber o nome do modelo, entrar no pipeline > compilação com falha > analisar
a tarefa AIB DevOps, em seguida, verá o log e um nome de modelo:
start reading task parameters...
found build at: /home/vsts/work/r1/a/_ImageBuilding/webapp
end reading parameters
getting storage account details for aibstordot1556933914
created archive /home/vsts/work/_temp/temp_web_package_21475337782320203.zip
imageVersionId:
Vá para o portal, procure o nome do modelo no grupo de recursos e procure o grupo de recursos com IT_ *.
Acesse a conta de armazenamento > BLOBs > contêineres > logs.
Solução de problemas de builds bem-sucedidos
Talvez haja alguns casos em que você precise investigar compilações bem-sucedidas e desejar examinar o log.
Conforme mencionado, se a compilação da imagem for bem-sucedida, o grupo de recursos de preparo que
contém os logs será excluído como parte da limpeza. No entanto, o que você pode fazer é introduzir uma
suspensão após o comando embutido e, em seguida, obter os logs à medida que a compilação é pausada. Para
fazer isso, siga estas etapas:
1. Atualize o comando embutido e adicione: Write-Host/Echo "Sleep" – isso permitirá que você pesquise no log
2. Adicione uma suspensão para pelo menos 10mins, você pode usar o comando Start-Sleepou Sleep Linux.
3. Use o método acima para identificar o local do log e, em seguida, continue baixando/verificando o log até
que ele chegue ao estado de suspensão.
A operação foi cancelada
Erro
2020-05-05T18:28:24.9280196Z ##[section]Starting: Azure VM Image Builder Task

2020-05-05T18:28:24.9609966Z ==============================================================================
2020-05-05T18:28:24.9610739Z Task : Azure VM Image Builder Test(Preview)
2020-05-05T18:28:24.9611277Z Description : Build images using Azure Image Builder resource provider.
2020-05-05T18:28:24.9611608Z Version : 1.0.18
2020-05-05T18:28:24.9612003Z Author : Microsoft Corporation
2020-05-05T18:28:24.9612718Z Help : For documentation, and end to end example, please visit:
http://aka.ms/azvmimagebuilderdevops
2020-05-05T18:28:24.9613390Z ==============================================================================
2020-05-05T18:28:26.0651512Z start reading task parameters...
2020-05-05T18:28:26.0673377Z found build at: d:\a\r1\a\_AppsAndImageBuilder\webApp
2020-05-05T18:28:26.0708785Z end reading parameters
2020-05-05T18:28:26.0745447Z getting storage account details for aibstagstor1565047758
2020-05-05T18:28:29.8812270Z created archive d:\a\_temp\temp_web_package_09737279437949953.zip
2020-05-05T18:28:33.1568013Z Source for image: { type: 'PlatformImage',
2020-05-05T18:28:33.1584131Z publisher: 'MicrosoftWindowsServer',
2020-05-05T18:28:33.1585965Z offer: 'WindowsServer',
2020-05-05T18:28:33.1592768Z sku: '2016-Datacenter',
2020-05-05T18:28:33.1594191Z version: '14393.3630.2004101604' }
2020-05-05T18:28:33.1595387Z template name: t_1588703313152
2020-05-05T18:28:33.1597453Z starting put template...
2020-05-05T18:28:52.9278603Z put template: Succeeded
2020-05-05T18:28:52.9281282Z starting run template...
2020-05-05T19:33:14.3923479Z ##[error]The operation was canceled.
2020-05-05T19:33:14.3939721Z ##[section]Finishing: Azure VM Image Builder Task
Causa
Se a compilação não foi cancelada por um usuário, ela foi cancelada pelo agente do usuário DevOps do Azure.
Provavelmente, o tempo limite de uma hora ocorreu devido a recursos de DevOps do Azure. Se você estiver
usando um projeto e um agente privados, obterá 60 minutos de tempo de compilação. Se a compilação exceder
o tempo limite, o DevOps cancelará a tarefa em execução.
Para obter mais informações sobre as limitações e recursos de DevOps do Azure, consulte agentes hospedados
pela Microsoft
Solução
Você pode hospedar seus próprios agentes do DevOps ou procurar reduzir o tempo de sua compilação. Por
exemplo, se você estiver distribuindo para a Galeria de imagens compartilhadas, replique para uma região. Se
você quiser replicar de forma assíncrona.
Logon lento do Windows: ' aguarde o instalador dos módulos do Windows '
Erro
Depois de criar uma imagem do Windows 10 com o Image Builder, crie uma VM a partir da imagem, você o
RDP e tenha que aguardar minutos no primeiro logon visualizando uma tela azul com a mensagem:
Please wait for the Windows Modules Installer
Solução
No início da compilação de imagem, verifique se não há reinicializações pendentes necessárias adicionando um
personalizador de reinicialização do Windows como a última personalização e se toda a instalação do software
foi concluída. Por fim, adicione a opção /Mode: VM ao Sysprep padrão que o AIB usa, veja abaixo, ' VMs criadas
de AIB images não criam com êxito ' > ' substituindo os comandos '
As VMs criadas a partir de imagens AIB não são criadas com êxito
Por padrão, o construtor de imagens do Azure executa o código de desprovisionamento no final de cada fase de
personalização de imagem para generalizar a imagem. Generalizar é um processo em que a imagem é
configurada para ser reutilizada para criar várias VMs e você pode passar configurações de VM, como nome de
host, nome de usuário, etc. Para o Windows, o construtor de imagem do Azure executa o Sysprep e para
execuções do construtor de imagem do Azure do Linux waagent -deprovision .
Para o Windows, o construtor de imagem do Azure usa um comando Sysprep genérico. No entanto, isso pode
não ser adequado para todas as generalizações do Windows bem-sucedidas. O construtor de imagens do Azure
permite que você personalize o comando Sysprep. Observe que o construtor de imagem do Azure é uma
ferramenta de automação de imagem. É responsável pela execução bem-sucedida do comando Sysprep. Mas
você pode precisar de comandos diferentes do Sysprep para tornar sua imagem reutilizável. Para o Linux, o
construtor de imagem do Azure usa um waagent -deprovision+user comando genérico. Para obter mais
informações, consulte Microsoft Azure documentação do agente do Linux.
Se você estiver migrando uma personalização existente e estiver usando diferentes comandos
Sysprep/waagent, poderá experimentar os comandos genéricos do Image Builder. Se a criação da VM falhar, use
os comandos Sysprep/waagent anteriores.
NOTE
Se AIB criar uma imagem personalizada do Windows com êxito e você criar uma VM a partir dela, então, localize a VM
não será criada com êxito (por exemplo, o comando de criação de VM não é concluído/tempo limite), você precisará
examinar a documentação do Sysprep do Windows Server. Ou, você pode gerar uma solicitação de suporte com a equipe
de suporte do Windows Server Sysprep Customer Services, que pode solucionar problemas e avisar sobre o comando
Sysprep correto.
Locais de comando e nomes de FileName

Windows:
c:\DeprovisioningScript.ps1
Linux:
/tmp/DeprovisioningScript.sh
Comando Sysprep: Windows
Write-Output '>>> Waiting for GA Service (RdAgent) to start ...'

while ((Get-Service RdAgent).Status -ne 'Running') { Start-Sleep -s 5 }
Write-Output '>>> Waiting for GA Service (WindowsAzureTelemetryService) to start ...'
while ((Get-Service WindowsAzureTelemetryService) -and ((Get-Service WindowsAzureTelemetryService).Status -
ne 'Running')) { Start-Sleep -s 5 }
Write-Output '>>> Waiting for GA Service (WindowsAzureGuestAgent) to start ...'
while ((Get-Service WindowsAzureGuestAgent).Status -ne 'Running') { Start-Sleep -s 5 }
Write-Output '>>> Sysprepping VM ...'
if( Test-Path $Env:SystemRoot\system32\Sysprep\unattend.xml ) {
Remove-Item $Env:SystemRoot\system32\Sysprep\unattend.xml -Force
}
& $Env:SystemRoot\System32\Sysprep\Sysprep.exe /oobe /generalize /quiet /quit
while($true) {
$imageState = (Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\State).ImageState
Write-Output $imageState
if ($imageState -eq 'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { break }
Start-Sleep -s 5
}
Write-Output '>>> Sysprep complete ...'
Comando de desprovisionamento: Linux
/usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 && sync
Como substituir os comandos

Para substituir os comandos, use os provisionadores do script PowerShell ou Shell para criar os arquivos de
comando com o nome exato do arquivo e coloque-os nos diretórios listados anteriormente. O construtor de
imagens do Azure lê esses comandos e a saída é gravada no customization. log.
Como Obter Suporte

Se você tiver mencionado as diretrizes e ainda não conseguir solucionar o problema, poderá abrir um caso de
suporte. Ao fazer isso, selecione o tópico de suporte e produto correto, fazendo isso envolverá a equipe de
suporte do construtor de imagem de VM do Azure.
Selecionando o produto do caso:
Product Family: Azure

Product: Virtual Machine Running (Window\Linux)
Support Topic: Azure Features
Support Subtopic: Azure Image Builder
Próximas etapas
Como usar o Packer para criar imagens de máquina
virtual Linux no Azure
Cada VM (máquina virtual) no Azure é criada com base em uma imagem que define a distribuição do Linux e a
versão do sistema operacional. As imagens podem incluir configurações e aplicativos pré-instalados. O Azure
Marketplace fornece várias imagens internas e de terceiros para as distribuições e os ambientes de aplicativo
mais comuns ou você pode criar suas próprias imagens personalizadas adequadas às suas necessidades. Este
artigo fornece detalhes sobre como usar a ferramenta de software livre Packer para definir e criar imagens
personalizadas no Azure.
NOTE
Agora, o Azure tem um serviço, o Construtor de Imagens de VM do Azure (versão prévia), para definir e criar suas
próprias imagens personalizadas. O Construtor de Imagens de VM do Azure é compilado no Packer, para que você possa
até mesmo usar com ele seus scripts de provisionamento de shell do Pack. Para começar a usar o construtor de imagens
do Azure, confira criar uma VM do Linux com o construtor de imagens do Azure.
Criar um grupo de recursos do Azure

Durante o processo de build, o Packer cria recursos temporários do Azure conforme cria a VM de origem. Para
capturar essa VM de origem para uso como uma imagem, você precisa definir um grupo de recursos. A saída do
processo de build do Packer é armazenada nesse grupo de recursos.
Crie um grupo de recursos com az group create. O exemplo a seguir cria um grupo de recursos chamado
myResourceGroup na localização eastus:
az group create -n myResourceGroup -l eastus
Criar as credenciais do Azure

O Packer se autentica no Azure usando uma entidade de serviço. Uma entidade de serviço do Azure é uma
identidade de segurança que você pode usar com aplicativos, serviços e ferramentas de automação como o
Packer. Você controla e define as permissões referentes a quais operações a entidade de serviço pode executar
no Azure.
Crie uma entidade de serviço com az ad sp create-for-rbac e gere as credenciais necessárias para o Packer:
az ad sp create-for-rbac --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"
Um exemplo da saída dos comandos anteriores é o seguinte:
{
"client_id": "f5b6a5cf-fbdf-4a9f-b3b8-3c2cd00225a4",
"client_secret": "0e760437-bf34-4aad-9f8d-870be799c55d",
"tenant_id": "72f988bf-86f1-41af-91ab-2d7cd011db47"
}
Para se autenticar no Azure, você também precisa obter sua ID de assinatura do Azure com az account show:
az account show --query "{ subscription_id: id }"
Você pode usar a saída desses dois comandos na próxima etapa.
Definir modelo do Packer

Para criar imagens, você cria um modelo como um arquivo JSON. No modelo, você define construtores e
provisionadores que executam o processo de build real. O Packer tem um provisionador do Azure que permite
definir recursos do Azure, como as credenciais da entidade de serviço criadas na etapa anterior.
Crie um arquivo chamado ubuntu.json e cole o conteúdo a seguir. Insira seus próprios valores para o seguinte:
PA RÂ M ET RO O N DE O BT ER
client_id Primeira linha da saída do comando create az ad sp –

appId
client_secret Segunda linha da saída do comando create az ad sp –

password
tenant_id Terceira linha da saída do comando create az ad sp –

tenant
subscription_id Saída do comando az account show
managed_image_resource_group_name Nome do grupo de recursos que você criou na primeira

etapa
managed_image_name Nome da imagem de disco gerenciado que é criada

{
"builders": [{
"type": "azure-arm",
"client_id": "f5b6a5cf-fbdf-4a9f-b3b8-3c2cd00225a4",
"client_secret": "0e760437-bf34-4aad-9f8d-870be799c55d",
"tenant_id": "72f988bf-86f1-41af-91ab-2d7cd011db47",
"subscription_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"managed_image_resource_group_name": "myResourceGroup",
"managed_image_name": "myPackerImage",
"os_type": "Linux",
"image_publisher": "Canonical",
"image_offer": "UbuntuServer",
"image_sku": "16.04-LTS",
"azure_tags": {
"dept": "Engineering",
"task": "Image deployment"
},
"location": "East US",

"vm_size": "Standard_DS2_v2"
}],
"provisioners": [{
"execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo -E sh '{{ .Path }}'",
"inline": [
"apt-get update",
"apt-get upgrade -y",
"apt-get -y install nginx",
"/usr/sbin/waagent -force -deprovision+user && export HISTSIZE=0 && sync"

],
"inline_shebang": "/bin/sh -x",
"type": "shell"
}]
}
Este modelo cria uma imagem do Ubuntu 16.04 LTS, instala o NGINX e, em seguida, desprovisiona a VM.
NOTE
Se você expandir este modelo para provisionar as credenciais do usuário, ajuste o comando do provisionador que
desprovisiona o agente do Azure para que ele indique -deprovision , em vez de deprovision+user . O sinalizador
+user remove todas as contas de usuário da VM de origem.
Criar uma imagem do Packer

Se você ainda não tiver o Packer instalado no computador local, siga as instruções de instalação do Packer.
Crie a imagem especificando o arquivo de modelo do Packer da seguinte maneira:
./packer build ubuntu.json

azure-arm output will be in this color.
==> azure-arm: Running builder ...

azure-arm: Creating Azure Resource Manager (ARM) client ...
==> azure-arm: Creating resource group ...
==> azure-arm: -> ResourceGroupName : ‘packer-Resource-Group-swtxmqm7ly’
==> azure-arm: -> Location : ‘East US’
==> azure-arm: -> Tags :
==> azure-arm: ->> dept : Engineering
==> azure-arm: ->> task : Image deployment
==> azure-arm: Validating deployment template ...
==> azure-arm: -> DeploymentName : ‘pkrdpswtxmqm7ly’
==> azure-arm: Deploying deployment template ...
==> azure-arm: -> DeploymentName : ‘pkrdpswtxmqm7ly’
==> azure-arm: Getting the VM’s IP address ...
==> azure-arm: -> PublicIPAddressName : ‘packerPublicIP’
==> azure-arm: -> NicName : ‘packerNic’
==> azure-arm: -> Network Connection : ‘PublicEndpoint’
==> azure-arm: -> IP Address : ‘40.76.218.147’
==> azure-arm: Waiting for SSH to become available...
==> azure-arm: Connected to SSH!
==> azure-arm: Provisioning with shell script: /var/folders/h1/ymh5bdx15wgdn5hvgj1wc0zh0000gn/T/packer-
shell868574263
azure-arm: WARNING! The waagent service will be stopped.
azure-arm: WARNING! Cached DHCP leases will be deleted.
azure-arm: WARNING! root password will be disabled. You will not be able to login as root.
azure-arm: WARNING! /etc/resolvconf/resolv.conf.d/tail and /etc/resolvconf/resolv.conf.d/original will
be deleted.
azure-arm: WARNING! packer account and entire home directory will be deleted.
==> azure-arm: Querying the machine’s properties ...
==> azure-arm: -> ComputeName : ‘pkrvmswtxmqm7ly’
==> azure-arm: -> Managed OS Disk : ‘/subscriptions/guid/resourceGroups/packer-Resource-Group-
swtxmqm7ly/providers/Microsoft.Compute/disks/osdisk’
==> azure-arm: Powering off machine ...
==> azure-arm: -> ComputeName : ‘pkrvmswtxmqm7ly’
==> azure-arm: Capturing image ...
==> azure-arm: -> Compute ResourceGroupName : ‘packer-Resource-Group-swtxmqm7ly’
==> azure-arm: -> Compute Name : ‘pkrvmswtxmqm7ly’
==> azure-arm: -> Compute Location : ‘East US’
==> azure-arm: -> Image ResourceGroupName : ‘myResourceGroup’
==> azure-arm: -> Image Name : ‘myPackerImage’
==> azure-arm: -> Image Location : ‘eastus’
==> azure-arm: Deleting resource group ...
==> azure-arm: Deleting the temporary OS disk ...
==> azure-arm: -> OS Disk : skipping, managed disk was used...
Build ‘azure-arm’ finished.
==> Builds finished. The artifacts of successful builds are:

--> azure-arm: Azure.ResourceManagement.VMImage:
ManagedImageResourceGroupName: myResourceGroup
ManagedImageName: myPackerImage
ManagedImageLocation: eastus
São necessários alguns minutos para que o Packer crie a VM, execute os provisionadores e limpe a implantação.
Criar uma VM com base em uma Imagem do Azure

Agora você pode criar uma VM com base na Imagem com az vm create. Especifique a Imagem criada com o
parâmetro --image . O exemplo a seguir cria uma VM chamada myVM com base em myPackerImage e gera as
chaves SSH, caso ainda não existam:
az vm create \
--name myVM \
--image myPackerImage \
--generate-ssh-keys
Se você quiser criar VMs em um grupo de recursos diferente ou a região da imagem Packer, especifique a ID da
imagem em vez do nome da imagem. Você pode obter a ID de imagem com Mostrar de imagem az.
São necessários alguns minutos para criar a VM. Depois que a VM for criada, amote o publicIpAddress exibido
pela CLI do Azure. Esse endereço é usado para acessar o site do NGINX em um navegador da Web.
az vm open-port \
--name myVM \
--port 80
Testar a VM e o NGINX
Agora, abra um navegador da Web e digite http://publicIpAddress na barra de endereços. Forneça seu próprio
endereço de IP público do processo de criação da máquina virtual. A página padrão do NGINX é exibida como
no seguinte exemplo:
Próximas etapas
Você também pode usar scripts de provisionamento do Packer com o Construtor de Imagens de VM do Azure.
PowerShell: como usar o Packer para criar imagens
de máquina virtual no Azure
Cada VM (máquina virtual) no Azure é criada com base em uma imagem que define a distribuição do Windows
e a versão do sistema operacional. As imagens podem incluir configurações e aplicativos pré-instalados. O
Azure Marketplace fornece várias imagens internas e de terceiros para os ambientes de sistema operacional e
de aplicativo mais comuns ou você pode criar suas próprias imagens personalizadas adequadas às suas
necessidades. Este artigo fornece detalhes sobre como usar a ferramenta de software livre Packer para definir e
compilar imagens personalizadas no Azure.
Este artigo foi testado pela última vez em 8/5/2020 usando a versão 1.6.1 do Pack .
NOTE
Agora, o Azure tem um serviço, o Construtor de Imagens de VM do Azure (versão prévia), para definir e criar suas
próprias imagens personalizadas. O Construtor de Imagens de VM do Azure é compilado no Packer, para que você possa
até mesmo usar com ele seus scripts de provisionamento de shell do Pack. Para começar a usar o Construtor de Imagens
de VM do Azure, consulte Criar uma VM do Windows com o Construtor de Imagens de VM do Azure.
Criar um grupo de recursos do Azure

Durante o processo de build, o Packer cria recursos temporários do Azure conforme cria a VM de origem. Para
capturar essa VM de origem para uso como uma imagem, você precisa definir um grupo de recursos. A saída do
processo de build do Packer é armazenada nesse grupo de recursos.
Crie um grupo de recursos com New-AzResourceGroup. O exemplo a seguir cria um grupo de recursos
chamado myPackerGroup no local eastus :
$rgName = "myPackerGroup"
New-AzResourceGroup -Name $rgName -Location $location
Criar as credenciais do Azure

O Packer se autentica no Azure usando uma entidade de serviço. Uma entidade de serviço do Azure é uma
identidade de segurança que você pode usar com aplicativos, serviços e ferramentas de automação como o
Packer. Você controla e define as permissões referentes a quais operações a entidade de serviço pode executar
no Azure.
Crie uma entidade de serviço com New-AzADServicePrincipal. O valor de -DisplayName precisa ser exclusivo.
Substitua-o pelo seu próprio valor, conforme necessário.
$sp = New-AzADServicePrincipal -DisplayName "PackerSP$(Get-Random)"

$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($sp.Secret)
$plainPassword = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
Em seguida, gere a senha e a ID do aplicativo.

$plainPassword
$sp.ApplicationId
Para se autenticar no Azure, você também precisa obter suas IDs de locatário e de assinatura do Azure com Get-
AzSubscription:
Get-AzSubscription
Definir modelo do Packer

Para criar imagens, você cria um modelo como um arquivo JSON. No modelo, você define construtores e
provisionadores que executam o processo de build real. O Packer tem um compilador do Azure que permite
definir recursos do Azure, como as credenciais da entidade de serviço criadas na etapa anterior.
Crie um arquivo chamado windows.json e cole o conteúdo a seguir. Insira seus próprios valores para o seguinte:
PA RÂ M ET RO O N DE O BT ER
client_id Exiba a ID da entidade de serviço com $sp.applicationId
client_secret Exiba a senha gerada automaticamente com

$plainPassword
tenant_id Saída do comando $sub.TenantId
subscription_id Saída do comando $sub.SubscriptionId
managed_image_resource_group_name Nome do grupo de recursos que você criou na primeira

etapa
managed_image_name Nome da imagem de disco gerenciado que é criada

{
"builders": [{
"type": "azure-arm",
"client_id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
"client_secret": "ppppppp-pppp-pppp-pppp-ppppppppppp",
"tenant_id": "zzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz",
"subscription_id": "yyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyy",
"managed_image_resource_group_name": "myPackerGroup",
"managed_image_name": "myPackerImage",
"os_type": "Windows",
"image_publisher": "MicrosoftWindowsServer",
"image_offer": "WindowsServer",
"image_sku": "2016-Datacenter",
"communicator": "winrm",
"winrm_use_ssl": true,
"winrm_insecure": true,
"winrm_timeout": "5m",
"winrm_username": "packer",
"azure_tags": {
"dept": "Engineering",
"task": "Image deployment"
},
"build_resource_group_name": "myPackerGroup",
"vm_size": "Standard_D2_v2"
}],
"provisioners": [{
"type": "powershell",
"inline": [
"Add-WindowsFeature Web-Server",
"while ((Get-Service RdAgent).Status -ne 'Running') { Start-Sleep -s 5 }",
"while ((Get-Service WindowsAzureGuestAgent).Status -ne 'Running') { Start-Sleep -s 5 }",
"& $env:SystemRoot\\System32\\Sysprep\\Sysprep.exe /oobe /generalize /quiet /quit",
"while($true) { $imageState = Get-ItemProperty
HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Setup\\State | Select ImageState;
if($imageState.ImageState -ne 'IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE') { Write-Output
$imageState.ImageState; Start-Sleep -s 10 } else { break } }"
]
}]
}
Este modelo cria uma VM Windows Server 2016, instala o IIS e generaliza a VM com o Sysprep. A instalação do
IIS mostra como você pode usar o provisionador do PowerShell para executar comandos adicionais. A imagem
do Packer final, em seguida, inclui a configuração e instalação de software necessárias.
O agente convidado do Windows participa do processo Sysprep. O agente deve ser totalmente instalado antes
que a VM possa ser tratado por Sysprep. Para garantir que isso seja verdadeiro, todos os serviços de agente
devem estar em execução antes de executar sysprep.exe. O trecho JSON anterior mostra uma maneira de fazer
isso no provisionamento do PowerShell. Esse trecho de código será necessário somente se a VM estiver
configurada para instalar o agente, que é o padrão.
Criar uma imagem do Packer

Se você ainda não tiver o Packer instalado no computador local, siga as instruções de instalação do Packer.
Crie a imagem abrindo um prompt de comando e especificando o arquivo de modelo do Packer da seguinte
maneira:
./packer build windows.json
azure-arm output will be in this color.
==> azure-arm: Running builder ...

azure-arm: Creating Azure Resource Manager (ARM) client ...
==> azure-arm: Creating resource group ...
==> azure-arm: -> ResourceGroupName : ‘packer-Resource-Group-pq0mthtbtt’
==> azure-arm: -> Location : ‘East US’
==> azure-arm: -> Tags :
==> azure-arm: ->> task : Image deployment
==> azure-arm: ->> dept : Engineering
==> azure-arm: -> DeploymentName : ‘pkrdppq0mthtbtt’
==> azure-arm: Getting the certificate’s URL ...
==> azure-arm: -> Key Vault Name : ‘pkrkvpq0mthtbtt’
==> azure-arm: -> Key Vault Secret Name : ‘packerKeyVaultSecret’
==> azure-arm: -> Certificate URL :
‘https://pkrkvpq0mthtbtt.vault.azure.net/secrets/packerKeyVaultSecret/8c7bd823e4fa44e1abb747636128adbb'
==> azure-arm: Setting the certificate’s URL ...
==> azure-arm: Getting the VM’s IP address ...
==> azure-arm: -> PublicIPAddressName : ‘packerPublicIP’
==> azure-arm: -> NicName : ‘packerNic’
==> azure-arm: -> Network Connection : ‘PublicEndpoint’
==> azure-arm: -> IP Address : ‘40.76.55.35’
==> azure-arm: Waiting for WinRM to become available...
==> azure-arm: Connected to WinRM!
==> azure-arm: Provisioning with Powershell...
==> azure-arm: Provisioning with shell script: /var/folders/h1/ymh5bdx15wgdn5hvgj1wc0zh0000gn/T/packer-
powershell-provisioner902510110
azure-arm: #< CLIXML
azure-arm:
azure-arm: Success Restart Needed Exit Code Feature Result
azure-arm: ------- -------------- --------- --------------
azure-arm: True No Success {Common HTTP Features, Default Document, D...
azure-arm: <Objs Version=“1.1.0.1” xmlns=“http://schemas.microsoft.com/powershell/2004/04"><Obj
S=“progress” RefId=“0"><TN RefId=“0”><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T>
</TN><MS><I64 N=“SourceId”>1</I64><PR N=“Record”><AV>Preparing modules for first use.</AV><AI>0</AI><Nil />
<PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj></Objs>
==> azure-arm: Querying the machine’s properties ...
==> azure-arm: -> ComputeName : ‘pkrvmpq0mthtbtt’
==> azure-arm: -> Managed OS Disk : ‘/subscriptions/guid/resourceGroups/packer-Resource-Group-
pq0mthtbtt/providers/Microsoft.Compute/disks/osdisk’
==> azure-arm: Powering off machine ...
==> azure-arm: -> ComputeName : ‘pkrvmpq0mthtbtt’
==> azure-arm: Capturing image ...
==> azure-arm: -> Compute ResourceGroupName : ‘packer-Resource-Group-pq0mthtbtt’
==> azure-arm: -> Compute Name : ‘pkrvmpq0mthtbtt’
==> azure-arm: -> Compute Location : ‘East US’
==> azure-arm: -> Image ResourceGroupName : ‘myResourceGroup’
==> azure-arm: -> Image Name : ‘myPackerImage’
==> azure-arm: -> Image Location : ‘eastus’
==> azure-arm: Deleting resource group ...
==> azure-arm: Deleting the temporary OS disk ...
==> azure-arm: -> OS Disk : skipping, managed disk was used...
Build ‘azure-arm’ finished.
==> Builds finished. The artifacts of successful builds are:

--> azure-arm: Azure.ResourceManagement.VMImage:
ManagedImageResourceGroupName: myResourceGroup
ManagedImageName: myPackerImage
ManagedImageLocation: eastus
São necessários alguns minutos para que o Packer crie a VM, execute os provisionadores e limpe a implantação.
Criar uma VM a partir da imagem do Packer

Agora você pode criar uma VM com base na Imagem com New-AzVM. Se ainda não existirem, os recursos de
rede de suporte serão criados. Quando solicitado, insira um nome de usuário administrativo e senha a serem
criados na VM. O exemplo a seguir cria uma VM nomeada myVM com base em myPackerImage:
New-AzVm `
-Name "myVM" `
-OpenPorts 80 `
-Image "myPackerImage"
Se você quiser criar VMs em um grupo de recursos diferente ou a região da imagem Packer, especifique a ID da
imagem em vez do nome da imagem. Você pode obter a ID de imagem com Get-AzImage.
A criação da VM a partir da imagem de seu Packer demora alguns minutos.
Testar a VM e o servidor Web

Obtenha o endereço IP público da VM com Get-AzPublicIPAddress. O exemplo a seguir obtém o endereço IP
para myPublicIP criado anteriormente:
-Name "myPublicIPAddress" | select "IpAddress"
Para ver sua VM, que inclui a instalação do IIS do provisionador do Packer, em ação, insira o endereço IP público
em um navegador da Web.
Próximas etapas
Você também pode usar scripts de provisionamento do Packer com o Construtor de Imagens de VM do Azure.
O que são conjuntos de escala de máquina virtual?
Os conjuntos de dimensionamento de máquinas virtuais do Azure permitem criar e gerenciar um grupo de VMs
com balanceamento de carga. O número de instâncias de VM pode aumentar ou diminuir automaticamente em
resposta à demanda ou a um agendamento definido. Os conjuntos de dimensionamento fornecem alta
disponibilidade para seus aplicativos e permitem que você gerencie, configure e atualize um grande número de
máquinas virtuais de forma centralizada. Com conjuntos de dimensionamento de máquinas virtuais, você pode
criar serviços em grande escala para áreas como computação, big data e cargas de trabalho de contêiner.
Para que usar Conjuntos de Dimensionamento de Máquinas Virtuais?

Para fornecer redundância e melhorar o desempenho, os aplicativos geralmente são distribuídos entre várias
instâncias. Os clientes podem acessar seu aplicativo por meio de um balanceador de carga que distribui
solicitações para uma das instâncias do aplicativo. Se você precisar fazer manutenção ou atualizar uma instância
do aplicativo, os clientes deverão ser distribuídos para outra instância do aplicativo disponível. Para atender à
demandas de cliente adicionais, talvez seja necessário aumentar o número de instâncias de aplicativos que
executam seu aplicativo.
Os conjuntos de dimensionamento de máquinas virtuais fornecem os recursos de gerenciamento para
aplicativos que são executados em várias VMs, dimensionamento automático de recursos e balanceamento de
carga do tráfego. Os conjuntos de dimensionamento oferecem as principais vantagens abaixo:
Facilidade de criar e gerenciar várias VMs
Quando você tem muitas VMs que executam seu aplicativo, é importante manter uma configuração
consistente em seu ambiente. Para um desempenho confiável do seu aplicativo, o tamanho da VM, a
configuração do disco e a instalação do aplicativo devem corresponder em todas as VMs.
Com conjuntos de dimensionamento, todas as instâncias de VM são criadas da mesma imagem e da
mesma configuração do sistema operacional base. Essa abordagem permite gerenciar facilmente
centenas de VMs sem outras tarefas de configuração ou gerenciamento de rede.
Os conjuntos de dimensionamento dão suporte ao uso do Azure Load Balancer para distribuição de
tráfego básico de camada 4 e ao Gateway de Aplicativo do Azure para distribuição do tráfego de
camada 7 e terminação de TLS mais avançadas.
Fornece alta disponibilidade e resiliência do aplicativo
Os conjuntos de dimensionamento são usados para executar várias instâncias do aplicativo. Se uma
dessas instâncias de VM tem um problema, os clientes continuam a acessar o aplicativo por meio de
uma das outras instâncias de VM com o mínimo de interrupção.
Para obter mais disponibilidade, você pode usar Zonas de disponibilidade para distribuir
automaticamente instâncias de VM em um conjunto de dimensionamento em um único datacenter ou
em vários datacenters.
Permite que seu aplicativo dimensione automaticamente de acordo com as alterações de
demanda de recursos
A demanda do cliente pelo seu aplicativo pode mudar ao longo do dia ou da semana. De acordo com
a demanda do cliente, os conjuntos de dimensionamento podem aumentar o número de instâncias de
VM automaticamente, de acordo com o aumento da demanda de aplicativo, e reduzir o número de
instâncias de VM de acordo com a redução de demanda.
O dimensionamento automático também minimiza o número de instâncias de VM desnecessárias que
executam seu aplicativo quando a demanda está baixa, enquanto os clientes continuam a receber um
nível de desempenho aceitável conforme a demanda cresce e as instâncias de VM adicionais são
adicionadas automaticamente. Esse recurso ajuda a reduzir os custos e a criar recursos do Azure de
forma eficiente conforme a necessidade.
Funciona em larga escala
Os conjuntos de dimensionamento dão suporte a até mil instâncias de VM. Se você criar e carregar
suas próprias imagens VM personalizadas, o limite será de 600 instâncias de VM.
Para obter o melhor desempenho com cargas de trabalho de produção, use o Azure Managed Disks.
Diferenças entre máquinas virtuais e conjuntos de dimensionamento

Os conjuntos de dimensionamento são criados a partir de máquinas virtuais. Com conjuntos de
dimensionamento, as camadas de automação e gerenciamento são fornecidas para executar e dimensionar seus
aplicativos. Você pode criar e gerenciar VMs individuais manualmente, ou integrar ferramentas existentes para
criar um nível de automação semelhante. A tabela a seguir descreve os benefícios dos conjuntos de
dimensionamento em comparação com o gerenciamento manual de várias instâncias de VM.
C O N JUN TO DE ESC A L A DE M Á Q UIN A

C EN Á RIO GRUP O M A N UA L DE VM S VIRT UA L
Adicionar outras instâncias de VM Processo manual de criar, configurar e Criar automaticamente usando a
garantir a conformidade configuração central
Balanceamento e distribuição de Processo manual de criar e configurar Pode criar e integrar com o
tráfego o balanceador de carga do Azure ou o balanceador de carga do Azure ou o
Gateway de Aplicativo Gateway de Aplicativo
automaticamente
Alta disponibilidade e redundância Criar Conjunto de Disponibilidade Distribuição automática de instâncias

manualmente ou distribuir e controlar de VM em Zonas de Disponibilidade
VMs entre Zonas de Disponibilidade ou Conjuntos de Disponibilidade
Dimensionamento de VMs Monitoramento manual e a Dimensionamento automático com

Automação do Azure base em métricas de host, métricas no
convidado, Application Insights ou
agendamento
Não há nenhum custo adicional para usar os conjuntos de dimensionamento. Você paga apenas pelos recursos
de computação subjacentes, como as instâncias de VM, o balanceador de carga ou o armazenamento do disco
gerenciado. Os recursos de automação e gerenciamento, como o dimensionamento automático e a
redundância, não incorrem em nenhum custo adicional pelo uso das VMs.
Como monitorar seus conjuntos de dimensionamento

Use o Azure Monitor para VMs, que tem um processo de integração simples e automatizará a coleção de
importantes contadores de desempenho da CPU, da memória, do disco e da rede das VMs em seu conjunto de
dimensionamento. Ele também inclui funcionalidades de monitoramento adicionais e visualizações predefinidas
que ajudam você a se concentrar na disponibilidade e no desempenho dos seus conjuntos de
dimensionamento.
Habilite o monitoramento do seu aplicativo de conjunto de dimensionamento de máquinas virtuais com o
Application Insights para coletar informações detalhadas sobre seu aplicativo, incluindo exibições de página,
solicitações de aplicativo e exceções. Verifique a disponibilidade do aplicativo configurando um teste de
disponibilidade para simular o tráfego de usuários.
Próximas etapas
Para começar, crie seu primeiro conjunto de dimensionamento de máquinas virtuais no Portal do Azure.
Criar um conjunto de dimensionamento usando o Portal do Azure
Opções de disponibilidade para máquinas virtuais
no Azure
Este artigo fornece uma visão geral dos recursos de disponibilidade das VMs (máquinas virtuais) do Azure.
Alta disponibilidade
As cargas de trabalho normalmente se disseminam entre diferentes máquinas virtuais para obter alta taxa de
transferência, desempenho e para criar redundância no caso de uma VM ser afetada devido a uma atualização
ou outro evento.
Há algumas opções que o Azure fornece para obter alta disponibilidade. Primeiro, vamos falar sobre
construções básicas.
Zonas de disponibilidade
Zonas de disponibilidade expandem o nível de controle de que você precisa para manter a disponibilidade dos
aplicativos e dos dados em suas VMs. Uma zona de disponibilidade é uma zona fisicamente separada, dentro de
uma região do Azure. Há três Zonas de Disponibilidade por região do Azure com suporte.
Cada zona de disponibilidade tem uma rede, resfriamento e fonte de energia distintos. Ao arquitetar suas
soluções para usar VMs replicadas em zonas, você pode proteger seus aplicativos e seus dados contra a perda
de um data center. Se uma zona for comprometida, os aplicativos e os dados replicados ficarão
instantaneamente disponíveis em outra zona.
Saiba mais sobre como implantar uma VM do Windows ou do Linux em uma Zona de Disponibilidade.
Domínios de falha
Um domínio de falha é um grupo lógico de hardwares subjacentes que compartilham a mesma fonte de
alimentação e o mesmo comutador de rede, de forma semelhante a um rack em um datacenter local.
Atualizar domínios
Um domínio de atualização é um grupo lógico de hardwares subjacentes que podem passar por manutenção ou
ser reinicializados ao mesmo tempo.
Essa abordagem garante que pelo menos uma instância do aplicativo sempre permaneça em execução
enquanto a plataforma Windows Azure passar por manutenção periódica. A ordem dos domínios de atualização
sendo reinicializados pode não continuar sequencialmente durante a manutenção, mas apenas um domínio de
atualização é reinicializado por vez.
Conjuntos de Escala de Máquinas Virtuais
disponibilidade para seus aplicativos e permitem que você gerencie, configure e atualize centralmente muitas
VMs. Recomendamos que duas ou mais VMs sejam criadas dentro de um conjunto de dimensionamento para
fornecer um aplicativo altamente disponível e para atender ao SLA de 99,95% do Azure. Não há nenhum custo
para o conjunto de dimensionamento em si, você só paga por cada instância de VM que criar. Quando uma
única VM está usando SSDs premium do Azure, o SLA do Azure se aplica a eventos de manutenção não
planejada. As máquinas virtuais em um conjunto de dimensionamento podem ser implantadas em vários
domínios de atualização e domínios de falha para maximizar a disponibilidade e a resiliência a interrupções
devido a interrupções de data center e eventos de manutenção planejados ou não planejados. As máquinas
virtuais em um conjunto de dimensionamento também podem ser implantadas em uma única zona de
disponibilidade ou regiões. As opções de implantação de zona de disponibilidade podem ser diferentes com
base no modo de orquestração.
Domínios de falha e domínios de atualização
Os conjuntos de dimensionamento de máquinas virtuais simplificam o design para alta disponibilidade
alinhando domínios de falha e domínios de atualização. Você precisará definir apenas a contagem de domínios
de falha para o conjunto de dimensionamento. O número de domínios de falha disponíveis para os conjuntos
de dimensionamento pode variar por região. Consulte gerenciar a disponibilidade de máquinas virtuais no
Azure.
Modos de orquestração para conjuntos de dimensionamento
Os modos de orquestração dos conjuntos de dimensionamento de máquinas virtuais permitem que você tenha
mais controle sobre como as instâncias de máquina virtual são gerenciadas pelo conjunto de dimensionamento.
Você pode habilitar um modo de orquestração uniforme ou flexível em seu conjunto de dimensionamento. A
orquestração uniforme é otimizada para cargas de trabalho sem estado de grande escala com instâncias
idênticas. A orquestração flexível (versão prévia) destina-se à alta disponibilidade em escala com tipos de
máquina virtual idênticos ou múltiplos. Saiba mais sobre esses modos de orquestração e como habilitá-los.
Conjuntos de disponibilidade
Um conjunto de disponibilidade é um agrupamento lógico de VMs que permite que o Azure entenda como o
seu aplicativo foi criado para fornecer redundância e disponibilidade. Recomenda-se que duas ou mais VMs
sejam criadas dentro de um conjunto de disponibilidade para fornecer um aplicativo altamente disponível e
para atender o SLA de 99,95% do Azure. Não há nenhum custo para o conjunto de disponibilidade em si, você
paga apenas por cada instância de VM que criar. Quando uma única VM está usando SSDs premium do Azure, o
SLA do Azure se aplica a eventos de manutenção não planejada.
Em um conjunto de disponibilidade, as VMs são distribuídas automaticamente entre esses domínios de falha.
Essa abordagem limita o impacto de possíveis falhas de hardware físico, interrupções de rede ou interrupções
de energia.
Para VMs que usam Azure Managed Disks, as VMs são alinhadas aos domínios de falha de disco gerenciado
quando usam um conjunto de disponibilidade gerenciada. Esse alinhamento garante que todos os discos
gerenciados anexados a uma VM fiquem no mesmo domínio de falha de disco gerenciado.
Somente as VMs com discos gerenciados podem ser criadas em um conjunto de disponibilidade gerenciado. O
número de domínios de falha de disco gerenciado varia por região - dois ou três domínios de falha de disco
gerenciados por região. Você pode ler mais sobre esses gerenciados domínios de falha de disco para VMs do
Linux ou VMs do Windows.
As VMs em um conjunto de disponibilidade também são distribuídas automaticamente entre domínios de
atualização.
Próximas etapas
Agora você pode começar a usar esses recursos de redundância e disponibilidade para criar seu ambiente do
Azure. Para obter informações de práticas recomendadas, confira Práticas recomendadas de disponibilidade do
Azure.
Otimizar a taxa de transferência de rede para
máquinas virtuais do Azure
Máquinas virtuais do Azure (VM) têm configurações de rede padrão que podem ser mais otimizadas para taxa
de transferência de rede. Este artigo descreve como otimizar a taxa de transferência de rede para VMs Windows
e Linux do Microsoft Azure, incluindo as distribuições principais como o Ubuntu, CentOS e Red Hat.
VM Windows
Se sua VM Windows for compatível com a Rede Acelerada, habilitar esse recurso será a configuração ideal para
a taxa de transferência. Para todas as outras VMs do Windows, usar RSS (Receive Side Scaling) pode alcançar
uma taxa de transferência máxima maior que uma VM sem RSS. RSS pode ser desabilitado por padrão em uma
VM do Windows. Para determinar se o RSS está habilitado, e habilitá-lo se ele estiver desabilitado no momento,
conclua as seguintes etapas:
1. Veja se o RSS está habilitado para um adaptador de rede no comando do PowerShell Get-NetAdapterRss .
Na saída do exemplo seguinte retornada do Get-NetAdapterRss , RSS não está habilitado.
Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : False
2. Para habilitar o RSS, insira o seguinte comando:
Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}
O comando anterior não tem uma saída. O comando alterou configurações de NIC, causando uma perda
de conectividade temporária por aproximadamente um minuto. Aparece uma caixa de diálogo
Reconnecting durante a perda de conectividade. Normalmente, a conectividade for restaurada após a
terceira tentativa.
3. Confirme se o RSS está habilitado na VM inserindo o Get-NetAdapterRss comando novamente. Se for
bem-sucedido, será retornada a seguinte saída de exemplo:
Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : True
VM Linux
RSS está sempre habilitado por padrão em uma VM do Linux do Azure. Kernels do Linux liberados desde
outubro de 2017 incluem novas opções de otimização de rede que permitem que uma VM Linux obtenha maior
taxa de transferência de rede.
Ubuntu para novas implantações
O kernel do Ubuntu Azure é o mais otimizado para o desempenho de rede no Azure. Para obter as otimizações
mais recentes, primeiro instale a versão mais recente com suporte do 18, 4-LTS, da seguinte maneira:
"Publisher": "Canonical",
"Offer": "UbuntuServer",
"Sku": "18.04-LTS",
"Version": "latest"
Depois que a criação for concluída, digite os seguintes comandos para obter as atualizações mais recentes. Essas
etapas também funcionam para VMs executando o kernel do Azure no Ubuntu no momento.
#run as root or preface with sudo

apt-get -y update
apt-get -y upgrade
apt-get -y dist-upgrade
O conjunto de comandos opcional a seguir pode ser útil para implantações do Ubuntu existentes que já têm o
kernel do Azure, mas que falharam ao obter atualizações com erros.
#optional steps may be helpful in existing deployments with the Azure kernel
apt-get -f install
apt-get --fix-missing install
apt-get clean
apt-get -y update
apt-get -y upgrade
apt-get -y dist-upgrade
Atualização de kernel do Azure no Ubuntu para VMs existentes

Um desempenho de taxa de transferência significativo pode ser obtido com o upgrade para o kernel do Linux
no Azure. Para verificar se você tem esse kernel, verifique a versão do kernel. Ele deve ser o mesmo ou posterior
ao exemplo.
#Azure kernel name ends with "-azure"

uname -r
#sample output on Azure kernel:

#4.13.0-1007-azure
Se sua VM não tiver o kernel do Azure, o número de versão geralmente começará com "4.4". Se a VM não tiver
o kernel do Azure, execute os comandos a seguir como raiz:

apt-get update
apt-get upgrade -y
apt-get dist-upgrade -y
apt-get install "linux-azure"
reboot
CentOS
Para obter as otimizações mais recentes, é melhor criar uma VM com a versão mais recente com suporte
especificando os seguintes parâmetros:
"Publisher": "OpenLogic",
"Offer": "CentOS",
"Sku": "7.7",
"Version": "latest"
VMs novas e existentes podem se beneficiar da instalação do LIS (Linux Integration Services) mais recente. A
otimização de taxa de transferência está no LIS, começando a partir de 4.2.2-2, embora as versões posteriores
contenham mais melhorias. Insira os seguintes comandos para instalar o último LIS:
sudo yum update

sudo reboot
sudo yum install microsoft-hyper-v
Red Hat
Para obter as otimizações, é melhor criar uma VM com a versão mais recente com suporte especificando os
seguintes parâmetros:
"Publisher": "RedHat"
"Offer": "RHEL"
"Sku": "7-RAW"
"Version": "latest"
VMs novas e existentes podem se beneficiar da instalação do LIS (Linux Integration Services) mais recente. A
otimização de taxa de transferência é feita no LIS, a partir da versão 4.2. Digite os comandos a seguir para baixar
e instalá-los:
tar xvf lis
cd LISISO
sudo ./install.sh #or upgrade.sh if prior LIS was previously installed
Saiba mais sobre o Linux Integration Services versão 4.2 para o Hyper-V exibindo a página de download.
Próximas etapas
Implantar VMs próximas umas às outras para baixa latência com o grupo de posicionamento de proximidade
Veja o resultado otimizado com o Teste de Largura de Banda/Taxa de Transferência da VM do Azure para seu
cenário.
Leia sobre como a largura de banda é alocada para máquinas virtuais
Saiba mais com as Perguntas frequentes sobre a rede virtual do Azure
Ciclo de vida e estados de máquinas virtuais
As VMs (Máquinas Virtuais) do Azure passam por diferentes estados que podem ser categorizados entre os
estados de provisionamento e energia. A finalidade deste artigo é descrever esses estados e realçar
especificamente quando os clientes são cobrados pelo uso de instância.
Estados de energia
O estado de energia representa o último estado conhecido da VM.
A tabela a seguir fornece uma descrição de cada estado da instância e indica se ele é cobrado pelo uso da instância
ou não.
State
Descrição
Uso da instância cobrado
Iniciando
A VM está iniciando.
"statuses": [
{
"code": "PowerState/starting",
"level": "Info",
"displayStatus": "VM starting"
}
]
Não é cobrado
Executando
Estado de funcionamento normal para uma VM
"statuses": [
{
"code": "PowerState/running",
"level": "Info",
"displayStatus": "VM running"
}
]
Cobrado
Parando
Esse é um estado de transição. Quando concluído, ele será exibido como Parado .
"statuses": [
{
"code": "PowerState/stopping",
"level": "Info",
"displayStatus": "VM stopping"
}
]
Cobrado
Parado
A VM foi desligada de dentro do sistema operacional convidado ou usando as APIs PowerOff.
O hardware ainda estará alocado para a VM e permanecerá no host.
"statuses": [
{
"code": "PowerState/stopped",
"level": "Info",
"displayStatus": "VM stopped"
}
]
Cobrado *
Desalocando
Estado de transição. Quando concluído, a VM será mostrada como Desalocada .
"statuses": [
{
"code": "PowerState/deallocating",
"level": "Info",
"displayStatus": "VM deallocating"
}
]
Não cobrado *
Desalocada
A VM foi parada com êxito e removida do host.
"statuses": [
{
"code": "PowerState/deallocated",
"level": "Info",
"displayStatus": "VM deallocated"
}
]
Não é cobrado
* alguns recursos do Azure, como discos e rede, incorrem em encargos. Licenças de software na instância não
geram encargos.
Estados de provisionamento
Um estado de provisionamento é o status de uma operação iniciada pelo usuário de plano de controle na VM.
Esses estados são separados do estado de energia de uma VM.
Criar : criação da VM.
Atualização : atualiza o modelo para uma VM existente. Algumas alterações que não são no modelo da
VM, como Iniciar/Reiniciar também se enquadram na atualização.
Excluir : exclusão de VM.
Desalocar : é o ponto e que uma VM é interrompida e removida do host. A desalocação de uma VM é
considerada uma atualização, portanto, ela exibirá estados de provisionamento relacionados à
atualização.
Aqui estão os estados operação de transição depois que a plataforma aceitou uma ação iniciada pelo usuário:
State
Descrição
Criando
"statuses": [
{
"code": "ProvisioningState/creating",
"level": "Info",
"displayStatus": "Creating"
}
[
Atualizar
"statuses": [
{
"code": "ProvisioningState/updating",
"level": "Info",
"displayStatus": "Updating"
}
[
Excluir
"statuses": [
{
"code": "ProvisioningState/deleting",
"level": "Info",
"displayStatus": "Deleting"
}
[
Estados de provisionamento do sistema operacional

Descrição
Se uma VM for criada com uma imagem do sistema operacional e não com uma imagem especializada, os
seguintes subestados podem ser observados:
OSProvisioningInprogress
A VM está em execução e a instalação do sistema operacional convidado está em andamento.
"statuses": [
{
"code": "ProvisioningState/creating/OSProvisioningInprogress",
"level": "Info",
"displayStatus": "OS Provisioning In progress"
}
[
OSProvisioningComplete
Estado de curta duração. A VM faz a transição rapidamente para Sucesso , a menos que extensões precisem ser
instalados. A instalação de extensões pode demorar.
"statuses": [
{
"code": "ProvisioningState/creating/OSProvisioningComplete",
"level": "Info",
"displayStatus": "OS Provisioning Complete"
}
[
Obser vação : o provisionamento do sistema operacional poderá fazer a transição para Falha se houver uma
falha de sistema operacional ou o sistema operacional não for instalado no tempo. Os clientes serão cobrados
pela VM implantada na infraestrutura.
Depois que a operação for concluída, a VM fará a transição para um dos seguintes estados:
Êxito : as ações iniciadas pelo usuário foram concluídas.
"statuses": [
{
"code": "ProvisioningState/succeeded",
"level": "Info",
"displayStatus": "Provisioning succeeded",
"time": "time"
}
]
Falha : representa uma operação com falha. Consulte os códigos de erro para obter mais informações e
soluções possíveis.
"statuses": [
{
"code": "ProvisioningState/failed/InternalOperationError",
"level": "Error",
"displayStatus": "Provisioning failed",
"message": "Operation abandoned due to internal error. Please try again later.",
"time": "time"
}
]
Exibição de instância da VM
A API de exibição de instância fornece informações sobre o estado de execução da VM. Para obter mais
informações, consulte a documentação da API Máquinas virtuais – Exibição de instância.
O Gerenciador de recursos do Azure fornece uma interface do usuário simple para exibir o estado de execução
de VM: Resource Explorer.
Os estados de provisionamento são visíveis na exibição de instância e de propriedades da VM. Os estados de
energia estão disponíveis na exibição de instância da VM.
Próximas etapas
Para saber mais sobre como monitorar sua VM, consulte monitorar máquinas virtuais no Azure.
O que são conjuntos de escala de máquina virtual?
disponibilidade para seus aplicativos e permitem que você gerencie, configure e atualize um grande número de
máquinas virtuais de forma centralizada. Com conjuntos de dimensionamento de máquinas virtuais, você pode
criar serviços em grande escala para áreas como computação, big data e cargas de trabalho de contêiner.
Para que usar Conjuntos de Dimensionamento de Máquinas Virtuais?

Para fornecer redundância e melhorar o desempenho, os aplicativos geralmente são distribuídos entre várias
instâncias. Os clientes podem acessar seu aplicativo por meio de um balanceador de carga que distribui
solicitações para uma das instâncias do aplicativo. Se você precisar fazer manutenção ou atualizar uma instância
do aplicativo, os clientes deverão ser distribuídos para outra instância do aplicativo disponível. Para atender à
demandas de cliente adicionais, talvez seja necessário aumentar o número de instâncias de aplicativos que
executam seu aplicativo.
Os conjuntos de dimensionamento de máquinas virtuais fornecem os recursos de gerenciamento para
aplicativos que são executados em várias VMs, dimensionamento automático de recursos e balanceamento de
carga do tráfego. Os conjuntos de dimensionamento oferecem as principais vantagens abaixo:
Facilidade de criar e gerenciar várias VMs
Quando você tem muitas VMs que executam seu aplicativo, é importante manter uma configuração
consistente em seu ambiente. Para um desempenho confiável do seu aplicativo, o tamanho da VM, a
configuração do disco e a instalação do aplicativo devem corresponder em todas as VMs.
Com conjuntos de dimensionamento, todas as instâncias de VM são criadas da mesma imagem e da
mesma configuração do sistema operacional base. Essa abordagem permite gerenciar facilmente
centenas de VMs sem outras tarefas de configuração ou gerenciamento de rede.
Os conjuntos de dimensionamento dão suporte ao uso do Azure Load Balancer para distribuição de
tráfego básico de camada 4 e ao Gateway de Aplicativo do Azure para distribuição do tráfego de
camada 7 e terminação de TLS mais avançadas.
Fornece alta disponibilidade e resiliência do aplicativo
Os conjuntos de dimensionamento são usados para executar várias instâncias do aplicativo. Se uma
dessas instâncias de VM tem um problema, os clientes continuam a acessar o aplicativo por meio de
uma das outras instâncias de VM com o mínimo de interrupção.
Para obter mais disponibilidade, você pode usar Zonas de disponibilidade para distribuir
automaticamente instâncias de VM em um conjunto de dimensionamento em um único datacenter ou
em vários datacenters.
Permite que seu aplicativo dimensione automaticamente de acordo com as alterações de
demanda de recursos
A demanda do cliente pelo seu aplicativo pode mudar ao longo do dia ou da semana. De acordo com
a demanda do cliente, os conjuntos de dimensionamento podem aumentar o número de instâncias de
VM automaticamente, de acordo com o aumento da demanda de aplicativo, e reduzir o número de
instâncias de VM de acordo com a redução de demanda.
O dimensionamento automático também minimiza o número de instâncias de VM desnecessárias que
executam seu aplicativo quando a demanda está baixa, enquanto os clientes continuam a receber um
nível de desempenho aceitável conforme a demanda cresce e as instâncias de VM adicionais são
adicionadas automaticamente. Esse recurso ajuda a reduzir os custos e a criar recursos do Azure de
forma eficiente conforme a necessidade.
Funciona em larga escala
Os conjuntos de dimensionamento dão suporte a até mil instâncias de VM. Se você criar e carregar
suas próprias imagens VM personalizadas, o limite será de 600 instâncias de VM.
Para obter o melhor desempenho com cargas de trabalho de produção, use o Azure Managed Disks.
Diferenças entre máquinas virtuais e conjuntos de dimensionamento

Os conjuntos de dimensionamento são criados a partir de máquinas virtuais. Com conjuntos de
dimensionamento, as camadas de automação e gerenciamento são fornecidas para executar e dimensionar seus
aplicativos. Você pode criar e gerenciar VMs individuais manualmente, ou integrar ferramentas existentes para
criar um nível de automação semelhante. A tabela a seguir descreve os benefícios dos conjuntos de
dimensionamento em comparação com o gerenciamento manual de várias instâncias de VM.
C O N JUN TO DE ESC A L A DE M Á Q UIN A

C EN Á RIO GRUP O M A N UA L DE VM S VIRT UA L
Adicionar outras instâncias de VM Processo manual de criar, configurar e Criar automaticamente usando a
garantir a conformidade configuração central
Balanceamento e distribuição de Processo manual de criar e configurar Pode criar e integrar com o
tráfego o balanceador de carga do Azure ou o balanceador de carga do Azure ou o
Gateway de Aplicativo Gateway de Aplicativo
automaticamente
Alta disponibilidade e redundância Criar Conjunto de Disponibilidade Distribuição automática de instâncias

manualmente ou distribuir e controlar de VM em Zonas de Disponibilidade
VMs entre Zonas de Disponibilidade ou Conjuntos de Disponibilidade
Dimensionamento de VMs Monitoramento manual e a Dimensionamento automático com

Automação do Azure base em métricas de host, métricas no
convidado, Application Insights ou
agendamento
Não há nenhum custo adicional para usar os conjuntos de dimensionamento. Você paga apenas pelos recursos
de computação subjacentes, como as instâncias de VM, o balanceador de carga ou o armazenamento do disco
gerenciado. Os recursos de automação e gerenciamento, como o dimensionamento automático e a
redundância, não incorrem em nenhum custo adicional pelo uso das VMs.
Como monitorar seus conjuntos de dimensionamento

Use o Azure Monitor para VMs, que tem um processo de integração simples e automatizará a coleção de
importantes contadores de desempenho da CPU, da memória, do disco e da rede das VMs em seu conjunto de
dimensionamento. Ele também inclui funcionalidades de monitoramento adicionais e visualizações predefinidas
que ajudam você a se concentrar na disponibilidade e no desempenho dos seus conjuntos de
dimensionamento.
Habilite o monitoramento do seu aplicativo de conjunto de dimensionamento de máquinas virtuais com o
Application Insights para coletar informações detalhadas sobre seu aplicativo, incluindo exibições de página,
solicitações de aplicativo e exceções. Verifique a disponibilidade do aplicativo configurando um teste de
disponibilidade para simular o tráfego de usuários.
Próximas etapas
Para começar, crie seu primeiro conjunto de dimensionamento de máquinas virtuais no Portal do Azure.
Criar um conjunto de dimensionamento usando o Portal do Azure
Gerenciar a disponibilidade de máquinas virtuais do
Linux
Aprenda como configurar e gerenciar várias máquinas virtuais para garantir a alta disponibilidade do aplicativo
Linux no Azure.
Entender as reinicializações de VM - manutenção vs. tempo de

inatividade
Há três cenários que podem afetar a máquina virtual no Azure: manutenção de hardware não planejada, tempo
de inatividade inesperado e manutenção planejada.
O Evento de Manutenção de Hardware Não Planejado ocorre quando a plataforma do Azure prevê
que o hardware ou qualquer componente de plataforma associado a um computador físico está prestes a
falhar. Quando a plataforma previr uma falha, ela emitirá um evento de manutenção de hardware não
planejada para reduzir o impacto em máquinas virtuais hospedadas no hardware. O Azure usa a
tecnologia de Migração ao Vivo para migrar as Máquinas Virtuais do hardware com falha para um
computador físico íntegro. A Migração ao Vivo é uma operação de preservação de VM que só pausa a
Máquina Virtual por um curto período. A memória, os arquivos abertos e as conexões de rede são
mantidos, mas o desempenho pode ser reduzido antes e/ou depois do evento. Em casos em que a
Migração ao Vivo não puder ser usada, a VM terá um Tempo de Inatividade Inesperado, conforme
descrito abaixo.
Um Tempo de Inatividade Inesperado é quando o hardware ou a infraestrutura física para a máquina
virtual falha inesperadamente. Isso inclui falhas na rede local, falhas no disco local ou outras falhas no
nível de rack. Quando detectada, a plataforma do Azure migra automaticamente (repara) a máquina
virtual para um computador físico íntegro no mesmo datacenter. Durante o procedimento de
recuperação, as máquinas virtuais ficarão inativas (reinicialização) e, em alguns casos, perderão a
unidade temporária. O sistema operacional e os discos de dados anexados são sempre preservados.
As máquinas virtuais também podem apresentar tempo de inatividade no caso improvável de uma falha
ou desastre que afete um datacenter inteiro, ou até mesmo uma região inteira. Nestas situações, o Azure
fornece opções de proteção, incluindo zonas disponibilidade e regiões emparelhadas.
Os eventos de Manutenção Planejada são atualizações periódicas feitas pela Microsoft na plataforma
subjacente do Azure para melhorara a confiabilidade, o desempenho e a segurança geral da
infraestrutura da plataforma executada pela máquina virtual. A maioria dessas atualizações é realizada
sem nenhum impacto sobre as máquinas virtuais ou os serviços de nuvem (consulte manutenção que
não exige uma reinicialização). Embora a plataforma do Azure tente usar a Manutenção de Preservação
de VM em todas as ocasiões possíveis, há casos raros em que essas atualizações exigem uma
reinicialização da máquina virtual para aplicar as atualizações necessárias para a infraestrutura
subjacente. Neste caso, você pode executar a Manutenção Planejada do Azure com a operação
Manutenção-Reimplantação ao iniciar a manutenção para as VMs na janela de tempo adequada. Para
saber mais, veja Manutenção planejada para máquinas virtuais.
Para reduzir o impacto do tempo de inatividade devido a um ou mais desses eventos, sugerimos que siga as
práticas recomendadas de alta disponibilidade para suas máquinas virtuais:
Use Zonas de Disponibilidade para proteger contra falhas do datacenter
Configurar diversas máquinas virtuais em um conjunto de disponibilidade para redundância
Usar discos gerenciados para VMs no conjunto de disponibilidade
Usar eventos agendados para responder de forma proativa a eventos que afetam a VM
Configurar cada camada de aplicativo em conjuntos de disponibilidade separados
Combinar o balanceador de carga com conjuntos ou zonas de disponibilidade
Usar as zonas de disponibilidade para se proteger contra falhas no

nível do datacenter
Zonas de disponibilidade expandem o nível de controle de que você precisa para manter a disponibilidade dos
aplicativos e dos dados em suas VMs. As Zonas de Disponibilidade são locais físicos exclusivos em uma região
do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, resfriamento e rede
independentes. Para garantir a resiliência, há um mínimo de três zonas separadas em todas as regiões
habilitadas. A separação física das Zonas de Disponibilidade dentro de uma região protege os aplicativos e
dados contra falhas do datacenter. Serviços com redundância de zona replicam os aplicativos e dados entre
Zonas de Disponibilidade para proteger dos pontos únicos de falha.
Uma zona de disponibilidade em uma região do Azure é uma combinação de um domínio de falha e um
domínio de atualização . Por exemplo, se você criar três ou mais VMs em três zonas em uma região do Azure,
as VMs serão efetivamente distribuídas em três domínios de falha e três domínios de atualização. A plataforma
do Azure reconhece essa distribuição nos domínios de atualização para garantir que as VMs em diferentes
zonas não sejam atualizadas ao mesmo tempo.
Com Zonas de Disponibilidade, o Azure oferece o melhor SLA de tempo de atividade da VM de 99,99% do setor.
Ao arquitetar suas soluções para usar VMs replicadas em zonas, você pode proteger seus aplicativos e dados
contra a perda de um datacenter. Se uma zona for comprometida, os aplicativos e os dados replicados ficarão
instantaneamente disponíveis em outra zona.
Saiba mais sobre como implantar uma VM do Windows ou do Linux em uma Zona de Disponibilidade.
Configurar diversas máquinas virtuais em um conjunto de

disponibilidade para redundância
Os conjuntos de disponibilidade são outra configuração de datacenter para fornecer redundância e
disponibilidade de VM. Essa configuração em um datacenter garante que durante um evento de manutenção
planejada ou não planejada, pelo menos uma máquina virtual estará disponível e atenderá os 99,95% SLA do
Azure. Para saber mais, confira SLA para máquinas virtuais.
IMPORTANT
Uma só máquina virtual de instância em um conjunto de disponibilidade deve usar SSD Premium ou Disco Ultra para
todos os discos do sistema operacional e discos de dados a fim de se qualificar para o SLA para conectividade de máquina
virtual de pelo menos 99,9%.
Uma máquina virtual de instância única com um SSD Standard terá um SLA de pelo menos 99,5%, enquanto uma
máquina virtual de instância única com um HDD Standard terá um SLA de pelo menos 95%. Confira SLA para Máquinas
Virtuais
Cada máquina virtual em seu conjunto de disponibilidade receberá um domínio de atualização e um

domínio de falha da plataforma subjacente do Azure. Para determinado conjunto de disponibilidade, cinco
domínios de atualização não configuráveis pelo usuário são atribuídos por padrão (é possível aumentar as
implantações do Resource Manager para fornecer até 20 domínios de atualização) para indicar grupos de
máquinas virtuais e hardware físico subjacente que pode ser reinicializado ao mesmo tempo. Quando mais do
que cinco máquinas virtuais são configuradas com um único conjunto de disponibilidade, a sexta máquina
virtual será alocada com o mesmo domínio de atualização da primeira máquina virtual, a sétima com o mesmo
domínio de atualização da segunda máquina virtual e assim sucessivamente. A ordem de reinicialização dos
domínios de atualização pode não ser sequencial durante a manutenção planejada, mas apenas um domínio de
atualização é reinicializado por vez. Um domínio de atualização reinicializado recebe 30 minutos para
recuperação antes do início da manutenção em um domínio de atualização diferente.
Os domínios de falha definem o grupo de máquinas virtuais que compartilham uma fonte de energia e chave
de rede comum. Por padrão, as máquinas virtuais configuradas em seu conjunto de disponibilidade são
separadas entre até três domínios de falha para implantações do Resource Manager (dois domínios de falha
para o Clássico). Embora colocar suas máquinas virtuais em um conjunto de disponibilidade não proteja seu
aplicativo de falhas de sistema operacional e nem específicas de aplicativo, isso limita o impacto das potencias
falhas físicas de hardware, panes de rede ou interrupções de energia.
Usar discos gerenciados para VMs no conjunto de disponibilidade

Se você estiver usando VMs com discos não gerenciados, é altamente recomendável converter de não
gerenciado para discos gerenciados para Linux e Windows.
Os discos gerenciados fornecem melhor confiabilidade para os Conjuntos de Disponibilidade, assegurando que
os discos das VMs em um Conjunto de Disponibilidade estejam suficientemente isolados entre si para evitar
pontos únicos de falha. Ele faz isso automaticamente colocando os discos em domínios de falha de
armazenamento diferentes (clusters de armazenamento) e alinhando-os com o domínio de falha da VM. Se um
domínio de falha do armazenamento falhar devido a uma falha de hardware ou software, somente a instância
de VM com discos no domínio de falha do armazenamento falhará.
IMPORTANT
O número de domínios de falha para conjuntos de disponibilidade gerenciados varia por região: dois ou três por região.
Você pode ver o domínio de falha para cada região executando os scripts a seguir.
Get-AzComputeResourceSku | where{$_.ResourceType -eq 'availabilitySets' -and $_.Name -eq 'Aligned'}
az vm list-skus --resource-type availabilitySets --query '[?name==Àligned`].

{Location:locationInfo[0].location, MaximumFaultDomainCount:capabilities[0].value}' -o Table
NOTE
Em determinadas circunstâncias, duas VMs no mesmo conjunto de disponibilidade podem compartilhar um domínio de
falha. Você pode confirmar um domínio de falha compartilhado acessando o seu conjunto de disponibilidade e verificando
a coluna Domínio de Falha . Um domínio de falha compartilhado poderá ser causado pela conclusão da seguinte
sequência quando você tiver implantado as VMs:
1. Implantar a primeira VM.
2. Parar/desalocar a primeira VM.
3. Implantar a segunda VM.
Nessas circunstâncias, o disco do sistema operacional da segunda VM pode ser criado no mesmo domínio de falha que a
primeira VM. Assim, as duas VMs estarão no mesmo domínio de falha. Para evitar esse problema, é recomendável não
parar/desalocar as VMs entre as implantações.
Se você planeja usar VMs com discos não gerenciados, siga abaixo as práticas recomendadas para as contas de
Armazenamento nas quais os discos rígidos virtuais (VHDs) das VMs são armazenados como blobs de página.
1. Manter todos os discos (sistema operacional e dados) associados a uma VM na mesma conta de
armazenamento
2. Examine os limites no número de discos não gerenciados em uma conta de armazenamento do
Azure antes de adicionar mais VHDs a uma conta de armazenamento
3. Use uma conta de armazenamento distinta para cada VM em um conjunto de disponibilidade.
Não compartilhe Contas de armazenamento com várias VMs no mesmo Conjunto de Disponibilidade. É
aceitável que as VMs em diferentes Conjuntos de Disponibilidade compartilhem contas de armazenamento,
desde que as melhores práticas acima sejam seguidas
Usar eventos agendados para responder de forma proativa a eventos

que afetam a VM
Quando você assina eventos agendados, sua VM é notificada sobre eventos de manutenção futura que podem
afetá-la. Quando os eventos agendados são habilitados, sua máquina virtual recebe uma quantidade mínima de
tempo antes que a atividade de manutenção seja realizada. Por exemplo, as atualizações do sistema operacional
do host que podem afetar a VM são colocadas na fila como eventos que especificam o impacto, bem como uma
hora em que a manutenção será realizada, caso nenhuma medida seja tomada. Os eventos de agendamento
também são colocados na fila quando o Azure detecta uma falha de hardware iminente que pode afetar a VM, o
que permite que você decida quando a recuperação deve ser executada. Os clientes podem usar o evento para
executar tarefas antes da manutenção, como salvar o estado, fazer failover para o secundário e assim por diante.
Depois de concluir a lógica para manipular normalmente o evento de manutenção, você poderá aprovar o
evento agendado pendente para permitir que a plataforma continue com a manutenção.
Combinar o balanceador de carga com conjuntos ou zonas de

disponibilidade
Combine o Azure Load Balancer com um conjunto ou uma zona de disponibilidade para obter a melhor
resiliência de aplicativo. O Balanceador de Carga do Azure distribui o tráfego entre as múltiplas máquinas
virtuais. Para as nossas máquinas virtuais de camadas padrões, o Balanceador de carga do Azure está incluso.
Nem todas as camadas de máquinas virtuais incluem o Azure Load Balancer. Para obter mais informações sobre
balanceamento de carga de suas máquinas virtuais, consulte balanceamento de carga de máquinas
vir tuais para Linux ou Windows.
Se o balanceador de carga não estiver configurado para balancear o tráfego entre múltiplas máquinas virtuais,
então qualquer evento de manutenção planejada afetará a única máquina virtual atendendo ao tráfego
causando uma pane na sua camada de aplicativo. Colocar diversas máquinas virtuais na mesma camada sob o
mesmo balanceador de carga e conjunto de disponibilidade habilita o tráfego a ser atendido continuamente
pelo menos por uma instância.
Para obter um tutorial sobre como balancear a carga entre zonas de disponibilidade, consulte tutorial: balancear
carga de VMs entre zonas de disponibilidade com um Standard Load Balancer usando o portal do Azure.
Próximas etapas
Para saber mais sobre o balanceamento de carga das máquinas virtuais, veja Balanceamento de carga de
máquinas virtuais.
altamente disponíveis com a CLI do Azure
Neste tutorial, você aprenderá a aumentar a disponibilidade e a confiabilidade de suas soluções de Máquina
Virtual no Azure usando uma funcionalidade chamada Conjuntos de Disponibilidade. Os Conjuntos de
disponibilidade garantem que as VMs implantadas no Azure sejam distribuídas entre vários clusters de
hardware isolados. Isso garante que, se ocorrer uma falha de hardware ou de software no Azure, apenas um
subconjunto de suas VMs será afetado e a solução geral permanecerá disponível e operacional.
Visão geral
Um Conjunto de disponibilidade é uma funcionalidade de agrupamento lógico que você pode usar no Azure
para garantir que os recursos da VM colocados nele sejam isolados uns dos outros quando forem implantados
em um datacenter do Azure. O Azure garante que as VMs colocadas em um Conjunto de disponibilidade sejam
executadas em vários servidores físicos, racks de computação, unidades de armazenamento e comutadores de
rede. Se uma falha de hardware ou software do Azure ocorrer, apenas um subconjunto de suas VMs será
afetado e seu aplicativo geral permanecerá disponível e ativo para seus clientes. Os Conjuntos de
Disponibilidade são uma funcionalidade essencial quando você deseja compilar soluções de nuvem confiáveis.
e usar duas VMs de back-end que hospedam um banco de dados. Com o Azure, convém definir dois conjuntos
de disponibilidade antes de implantar suas VMs: um conjunto de disponibilidade para a camada "Web" e um
conjunto de disponibilidade para a camada "banco de dados". Ao criar uma nova VM, você pode especificar o
conjunto de disponibilidade como um parâmetro para o comando az vm create e o Azure garantirá
automaticamente que as VMs criadas dentro do conjunto de disponibilidade sejam isoladas em vários recursos
de hardware físico. Se o hardware físico no qual um de seus servidores Web ou VMs do servidor de banco de
dados estiverem em execução enfrentar um problema, você saberá que outras instâncias de seu servidor Web e
VMs de banco de dados permanecerão em execução, pois estão em um hardware diferente.

Crie um conjunto de disponibilidade usando az vm availability-set create. Nesse exemplo, o número de
domínios de atualização e de falha são definidos para 2 para o conjunto de disponibilidade chamado
myAvailabilitySet no grupo de recursos myResourceGroupAvailability.
Primeiro, crie um grupo de recursos com az group create, em seguida, crie um conjunto de disponibilidade:
az group create --name myResourceGroupAvailability --location eastus
--platform-fault-domain-count 2 \
--platform-update-domain-count 2
Os Conjuntos de Disponibilidade permitem que você isole os recursos em "domínios de falha" e "domínios de
atualização". Um domínio de falha representa uma coleção isolada de recursos de servidor + rede +
armazenamento. No exemplo anterior, o conjunto de disponibilidade em pelo menos dois domínios de falha
quando nossas VMs são implantadas. O conjunto de disponibilidade também é distribuído entre dois atualizar
domínios . Dois domínios de atualização garantem que durante a atualização de software do Azure os recursos
de VM estarão isolados, impedindo que todos os softwares que executem em nossa VM sejam atualizados ao
mesmo tempo.

hardware. Uma VM existente não pode ser adicionada a um conjunto de disponibilidade após sua criação.
Quando uma VM é criada com az vm create, você usa o parâmetro --availability-set para especificar o nome
do conjunto de disponibilidade.

az vm create \
--name myVM$i \
--subnet mySubnet \
--image UbuntuLTS \
--generate-ssh-keys
done
Agora há duas máquinas virtuais dentro do conjunto de disponibilidade. Como elas estão no mesmo conjunto
de disponibilidade, o Azure garantirá que as VMs e todos os seus recursos (incluindo discos de dados) sejam
distribuídos entre o hardware físico isolado. Essa distribuição ajuda a garantir uma disponibilidade muito maior
de nossa solução de VM geral.
A distribuição do conjunto de disponibilidade pode ser exibida no portal, vá para grupos de recursos >
myResourceGroupAvailability > myAvailabilitySet. As VMs são distribuídas entre as duas falhas e domínios de
atualização, conforme mostrado no exemplo a seguir:
VMs adicionais podem ser adicionadas ao conjunto de disponibilidade mais tarde, onde os tamanhos de VM
estão disponíveis no hardware. Use az vm availability-set list-sizes para listar todos os tamanhos disponíveis no
cluster de hardware para o conjunto de disponibilidade:
az vm availability-set list-sizes \
--output table
Próximas etapas
Para saber mais sobre as zonas de disponibilidade, confira a Documentação das Zonas de Disponibilidade.
Mais documentação sobre conjuntos de disponibilidade e Zonas de Disponibilidade também está disponível
aqui.
Para experimentar zonas de disponibilidade, visite Criar uma máquina virtual do Linux em uma zona de
altamente disponíveis com o Azure PowerShell
Neste tutorial, você aprenderá a aumentar a disponibilidade e confiabilidade de suas VMs (máquinas virtuais)
usando conjuntos de disponibilidade. Os conjuntos de disponibilidade garantem que as VMs implantadas no
Azure sejam distribuídas entre vários nós de hardware isolados em um cluster.
Visão geral do conjunto de disponibilidade

Um conjunto de disponibilidade é uma funcionalidade de agrupamento lógico para isolar recursos de VM uns
dos outros quando são implantados. O Azure garante que as VMs colocadas em um conjunto de disponibilidade
sejam executadas em vários servidores físicos, racks de computação, unidades de armazenamento e
comutadores de rede. Se ocorrer uma falha de hardware ou de software, somente um subconjunto de suas VMs
será afetado e a solução geral permanecerá operacional. Os conjuntos de disponibilidade são essenciais para a
criação de soluções de nuvem confiáveis.
e duas VMs de back-end. Com o Azure, convém definir dois conjuntos de disponibilidade antes de implantar
suas VMs: um para a camada Web e outro para a camada traseira. Quando você cria uma nova VM, especifica o
conjunto de disponibilidade como um parâmetro. O Azure garante que as VMs estejam isoladas entre vários
recursos de hardware físico. Se o hardware físico no qual um dos seus servidores está sendo executado tiver um
problema, você saberá que as outras instâncias dos seus servidores continuarão em execução porque estão em
um hardware diferente.
Use Conjuntos de Disponibilidade quando você deseja implantar soluções confiáveis baseadas em VM no Azure.


O hardware em um local é dividido em vários domínios de atualização e domínios de falha. Um domínios de
atualização é um grupo de VMs e hardware físico subjacente que podem ser reinicializados simultaneamente.
As VMs no mesmo domínio de falha compartilham armazenamentos comuns, bem como um comutador de
rede e fonte de energia comuns.
É possível criar um conjunto de disponibilidade usando New-AzAvailabilitySet. Neste exemplo, o número de
domínios de atualização e de falha é 2 e o conjunto de disponibilidade é chamado myAvailabilitySet.
Crie um grupos de recursos.
-Name myResourceGroupAvailability `
-Location EastUS
Crie um conjunto de disponibilidade gerenciado usando New-AzAvailabilitySet com o parâmetro -sku aligned .
New-AzAvailabilitySet `
-Sku aligned `

hardware. Não é possível adicionar uma VM existente a um conjunto de disponibilidade após sua criação.
Ao criar uma VM com New-AzVM, você usa o parâmetro -AvailabilitySetName para especificar o nome do
Primeiro, defina o nome de usuário e a senha de um administrador para a VM com Get-Credential:
Agora crie duas VMs com New-AzVM no conjunto de disponibilidade.
for ($i=1; $i -le 2; $i++)

{
New-AzVm `
-Name "myVM$i" `
-PublicIpAddressName "myPublicIpAddress$i" `
-Credential $cred
}
Demora alguns minutos para criar e configurar ambas as VMs. Quando tiver terminado, você terá duas
máquinas virtuais distribuídas entre o hardware subjacente.
Se você analisar o conjunto de disponibilidade no portal acessando Grupos de Recursos >
myResourceGroupAvailability > myAvailabilitySet , verá como as VMs estão distribuídas entre os dois
domínios de atualização e de falha.
Quando cria uma VM dentro de um conjunto de disponibilidade, você precisa saber quais tamanhos de VM
estão disponíveis no hardware. Use o comando Get-AzVMSize para obter todos os tamanhos de máquinas
virtuais disponíveis que você pode implantar no conjunto de disponibilidade.
Get-AzVMSize `
-AvailabilitySetName "myAvailabilitySet"

Também é possível usar o Assistente do Azure para saber mais sobre como melhorar a disponibilidade das suas
VMs. O Assistente do Azure analisa a telemetria de uso e de configuração e, depois, recomenda soluções que
podem ajudar você a melhorar a economia, o desempenho, a disponibilidade e a segurança de seus recursos do
Azure.
Entre no portal do Azure, selecione Todos os ser viços e digite Assistente . O painel do Assistente mostra
recomendações personalizadas para a assinatura selecionada. Para saber mais, veja Introdução ao Assistente do
Azure.
Próximas etapas
Criar um conjunto de dimensionamento da VM
Alterar a conjunto de disponibilidade para uma VM
As etapas a seguir descrevem como alterar o conjunto de disponibilidade de uma VM usando o Azure
PowerShell. Uma VM só pode ser adicionada a um conjunto de disponibilidade quando ela é criada. Para alterar
o conjunto de disponibilidade é necessário excluir e recriar a máquina virtual.
Este artigo se aplica a VMs do Linux e do Windows.
Este artigo foi testado pela última vez em 12/02/2019 usando o Azure Cloud Shell e o módulo do Az PowerShell
versão 1.2.0.
Este exemplo não verifica se a VM está anexada a um balanceador de carga. Se sua VM estiver anexada a um
balanceador de carga, você precisará atualizar o script para lidar com esse caso.
Alterar o conjunto de disponibilidade

O script a seguir fornece um exemplo de como coletar as informações necessárias, como excluir a VM original e
como recriá-la em um novo conjunto de disponibilidade.
# Set variables
$vmName = "myVM"
$newAvailSetName = "myAvailabilitySet"
# Get the details of the VM to be moved to the Availability Set

$originalVM = Get-AzVM `
-Name $vmName
# Create new availability set if it does not exist

$availSet = Get-AzAvailabilitySet `
-Name $newAvailSetName `
-ErrorAction Ignore
if (-Not $availSet) {
$availSet = New-AzAvailabilitySet `
-Location $originalVM.Location `
-Name $newAvailSetName `
-PlatformUpdateDomainCount 2 `
-Sku Aligned
}
# Remove the original VM

Remove-AzVM -ResourceGroupName $resourceGroup -Name $vmName
# Create the basic configuration for the replacement VM.

$newVM = New-AzVMConfig `
-VMName $originalVM.Name `
-VMSize $originalVM.HardwareProfile.VmSize `
-AvailabilitySetId $availSet.Id
# For a Linux VM, change the last parameter from -Windows to -Linux
Set-AzVMOSDisk `
-VM $newVM -CreateOption Attach `
-ManagedDiskId $originalVM.StorageProfile.OsDisk.ManagedDisk.Id `
-Name $originalVM.StorageProfile.OsDisk.Name `
-Windows
-Windows
# Add Data Disks

foreach ($disk in $originalVM.StorageProfile.DataDisks) {
Add-AzVMDataDisk -VM $newVM `
-Name $disk.Name `
-ManagedDiskId $disk.ManagedDisk.Id `
-Caching $disk.Caching `
-Lun $disk.Lun `
-DiskSizeInGB $disk.DiskSizeGB `
-CreateOption Attach
}
# Add NIC(s) and keep the same NIC as primary

foreach ($nic in $originalVM.NetworkProfile.NetworkInterfaces) {
if ($nic.Primary -eq "True")
{
-VM $newVM `
-Id $nic.Id -Primary
}
else
{
-VM $newVM `
-Id $nic.Id
}
}
# Recreate the VM
New-AzVM `
-Location $originalVM.Location `
-VM $newVM `
-DisableBginfoExtension
Próximas etapas
Adicione armazenamento adicional à sua VM incluindo um disco de dadosadicional.
Implantar VMs em grupos de posicionamento por
proximidade usando a CLI do Azure
Para obter as VMs o mais próximo possível, alcançando a menor latência possível, você deve implantá-las em
um grupo de posicionamento de proximidade.
Um grupo de posicionamento por proximidade é um agrupamento lógico usado para garantir que os recursos
de computação do Azure estejam fisicamente localizados próximos uns dos outros. Os grupos de
posicionamento por proximidade são úteis para cargas de trabalho em que a baixa latência é um requisito.
Criar o grupo de posicionamento de proximidade

Crie um grupo de posicionamento de proximidade usando az ppg create .
az group create --name myPPGGroup --location westus

az ppg create \
-n myPPG \
-g myPPGGroup \
-l westus \
-t standard
Lista de grupos de posicionamento por proximidade

Você pode listar todos os seus grupos de posicionamento de proximidade usando a lista AZ PPG.
az ppg list -o table

Crie uma VM dentro do grupo de posicionamento de proximidade usando New AZ VM.
az vm create \
-n myVM \
-g myPPGGroup \
--image UbuntuLTS \
--ppg myPPG \
--size Standard_D1_v2 \
-l westus
Você pode ver a VM no grupo de posicionamento de proximidade usando AZ PPG show.
az ppg show --name myppg --resource-group myppggroup --query "virtualMachines"
Você também pode criar um conjunto de disponibilidade em seu grupo de posicionamento de proximidade. Use
o mesmo --ppg parâmetro com AZ VM Availability – Set Create para criar um conjunto de disponibilidade e
todas as VMs no conjunto de disponibilidade também serão criadas no mesmo grupo de posicionamento de
proximidade.
Você também pode criar um conjunto de dimensionamento em seu grupo de posicionamento de proximidade.
Use o mesmo --ppg parâmetro com AZ vmss Create para criar um conjunto de dimensionamento e todas as
instâncias serão criadas no mesmo grupo de posicionamento de proximidade.
Próximas etapas
Saiba mais sobre os comandos de CLI do Azure para grupos de posicionamento de proximidade.
Criar um grupo de posicionamento por
proximidade usando o portal
NOTE
Os grupos de posicionamento de proximidade não podem ser usados com hosts dedicados.
Se você quiser usar zonas de disponibilidade junto com grupos de posicionamento, precisará certificar-se de que as VMs
no grupo de posicionamento também estejam todas na mesma zona de disponibilidade.
Criar o grupo de posicionamento de proximidade

1. Digite grupo de posicionamento de proximidade na pesquisa.
2. Em Ser viços nos resultados da pesquisa, selecione grupos de posicionamento de proximidade .
3. Na página grupos de posicionamento de proximidade , selecione Adicionar .
4. Na guia Básico , em Detalhes do projeto , verifique se a assinatura correta está selecionada.
5. Em grupo de recursos , selecione criar novo para criar um novo grupo ou selecione um grupo de
recursos vazio que já existe, na lista suspensa.
6. Em região , selecione o local onde você deseja que o grupo de posicionamento de proximidade seja
criado.
7. Em proximidade posição do grupo nome , digite um nome e, em seguida, selecione revisar + criar .
8. Depois que a validação for aprovada, selecione criar para criar o grupo de posicionamento de
proximidade.
1. Ao criar uma VM no portal, vá para a guia avançado .
2. Na seleção de grupo de posicionamento de proximidade , selecione o grupo de posicionamento
correto.
3. Quando terminar de fazer todas as outras seleções necessárias, selecione revisar + criar .
4. Depois de passar na validação, selecione criar para implantar a VM no grupo de posicionamento.
Adicionar VMs em um conjunto de disponibilidade a um grupo de

posicionamento de proximidade
Se a VM fizer parte do conjunto de disponibilidade, você precisará adicionar o conjunto de disponibilidade ao
grupo de posicionamento antes de adicionar as VMs.
1. No portal , pesquise por conjuntos de disponibilidade e selecione seu conjunto de disponibilidade nos
resultados.
2. Stop\deallocate cada VM no conjunto de disponibilidade selecionando a VM, em seguida, selecionando
parar na página da VM e, em seguida, selecione OK para interromper a VM.
3. Na página de seu conjunto de disponibilidade, verifique se todas as VMs têm o status listado como parado
(desalocado) .
4. No menu à esquerda, selecione Configuração .
5. Em grupo de posicionamento de proximidade , selecione um grupo de posicionamento na lista
suspensa e, em seguida, selecione salvar .
6. Selecione visão geral no menu à esquerda para ver a lista de VMs novamente.
7. Selecione cada VM no conjunto de disponibilidade e, em seguida, selecione Iniciar na página para cada VM.
Adicionar VM existente ao grupo de posicionamento

1. Na página da VM, selecione parar .
2. Depois que o status da VM for listado como parado (desalocado) , selecione configuração no menu à
esquerda.
3. Em grupo de posicionamento de proximidade , selecione um grupo de posicionamento na lista
suspensa e, em seguida, selecione salvar .
4. Selecione visão geral no menu à esquerda e, em seguida, selecione Iniciar para reiniciar a VM.
Próximas etapas
Você também pode usar o Azure PowerShell para criar grupos de posicionamento de proximidade.
Implantar VMs em grupos de posicionamento de
proximidade usando o PowerShell
Criar um grupo de posicionamento de proximidade

Crie um grupo de posicionamento por proximidade usando o cmdlet New-AzProximityPlacementGroup.
$resourceGroup = "myPPGResourceGroup"
$ppgName = "myPPG"
$ppg = New-AzProximityPlacementGroup `
-Name $ppgName `
-ProximityPlacementGroupType Standard
Lista de grupos de posicionamento por proximidade

Liste todos os grupos de posicionamento por proximidade usando o cmdlet Get-AzProximityPlacementGroup.
Get-AzProximityPlacementGroup

Crie uma VM no grupo de posicionamento de proximidade usando -ProximityPlacementGroup $ppg.Id para se
referir à ID do grupo de posicionamento de proximidade ao usar New-AzVM para criar a VM.
$vmName = "myVM"
New-AzVm `
-Name $vmName `
-OpenPorts 3389 `
-ProximityPlacementGroup $ppg.Id
Você pode ver a VM no grupo de posicionamento usando Get-AzProximityPlacementGroup.
Get-AzProximityPlacementGroup -ResourceId $ppg.Id |

Format-Table -Property VirtualMachines -Wrap
Mover uma VM existente para um grupo de posicionamento de proximidade
Você também pode adicionar uma VM existente a um grupo de posicionamento de proximidade. Você precisa
stop\deallocate a VM primeiro e, em seguida, atualizar a VM e reiniciar.
$ppg = Get-AzProximityPlacementGroup -ResourceGroupName myPPGResourceGroup -Name myPPG

$vm = Get-AzVM -ResourceGroupName myResourceGroup -Name myVM
Stop-AzVM -Name $vm.Name -ResourceGroupName $vm.ResourceGroupName
Update-AzVM -VM $vm -ResourceGroupName $vm.ResourceGroupName -ProximityPlacementGroupId $ppg.Id
Start-AzVM -Name $vm.Name -ResourceGroupName $vm.ResourceGroupName
Mover uma VM existente para fora de um grupo de posicionamento de proximidade

Para remover uma VM de um grupo de posicionamento de proximidade, você precisa stop\deallocate a VM
primeiro e, em seguida, atualizar a VM e reiniciar.
$ppg = Get-AzProximityPlacementGroup -ResourceGroupName myPPGResourceGroup -Name myPPG

Stop-AzVM -Name $vm.Name -ResourceGroupName $vm.ResourceGroupName
$vm.ProximityPlacementGroup = ""
Update-AzVM -VM $vm -ResourceGroupName $vm.ResourceGroupName
Start-AzVM -Name $vm.Name -ResourceGroupName $vm.ResourceGroupName
Você também pode criar um conjunto de disponibilidade em seu grupo de posicionamento de proximidade. Use
o mesmo -ProximityPlacementGroup parâmetro com o cmdlet New-AzAvailabilitySet para criar um conjunto de
disponibilidade e todas as VMs criadas no conjunto de disponibilidade também serão criadas no mesmo grupo
de posicionamento de proximidade.
Para adicionar ou remover um conjunto de disponibilidade existente em um grupo de posicionamento de
proximidade, primeiro você precisa interromper todas as VMs no conjunto de disponibilidade.
Mover um conjunto de disponibilidade existente para um grupo de posicionamento de proximidade
$avSetName = "myAvailabilitySet"
$avSet = Get-AzAvailabilitySet -ResourceGroupName $resourceGroup -Name $avSetName
$vmIds = $avSet.VirtualMachinesReferences
foreach ($vmId in $vmIDs){
$string = $vmID.Id.Split("/")
$vmName = $string[8]
}
$ppg = Get-AzProximityPlacementGroup -ResourceGroupName myPPG -Name myPPG

Update-AzAvailabilitySet -AvailabilitySet $avSet -ProximityPlacementGroupId $ppg.Id
}
Mover um conjunto de disponibilidade existente para fora de um grupo de posicionamento de proximidade

$avSetName = "myAvailabilitySet"
$avSet = Get-AzAvailabilitySet -ResourceGroupName $resourceGroup -Name $avSetName
$vmIds = $avSet.VirtualMachinesReferences
}
$avSet.ProximityPlacementGroup = ""
Update-AzAvailabilitySet -AvailabilitySet $avSet
}
Você também pode criar um conjunto de dimensionamento em seu grupo de posicionamento de proximidade.
Use o mesmo -ProximityPlacementGroup parâmetro com New-AzVmss para criar um conjunto de
dimensionamento e todas as instâncias serão criadas no mesmo grupo de posicionamento de proximidade.
Para adicionar ou remover um conjunto de dimensionamento existente para um grupo de posicionamento de
proximidade, primeiro você precisa interromper o conjunto de dimensionamento.
Mover um conjunto de dimensionamento existente para um grupo de posicionamento de proximidade
$ppg = Get-AzProximityPlacementGroup -ResourceGroupName myPPG -Name myPPG

$vmss = Get-AzVmss -ResourceGroupName myVMSSResourceGroup -VMScaleSetName myScaleSet
Stop-AzVmss -VMScaleSetName $vmss.Name -ResourceGroupName $vmss.ResourceGroupName
Update-AzVmss -VMScaleSetName $vmss.Name -ResourceGroupName $vmss.ResourceGroupName -
ProximityPlacementGroupId $ppg.Id
Start-AzVmss -VMScaleSetName $vmss.Name -ResourceGroupName $vmss.ResourceGroupName
Mover um conjunto de dimensionamento existente de um grupo de posicionamento de proximidade
$vmss = Get-AzVmss -ResourceGroupName myVMSSResourceGroup -VMScaleSetName myScaleSet

Stop-AzVmss -VMScaleSetName $vmss.Name -ResourceGroupName $vmss.ResourceGroupName
$vmss.ProximityPlacementGroup = ""
Update-AzVmss -VirtualMachineScaleSet $vmss -VMScaleSetName $vmss.Name -ResourceGroupName
$vmss.ResourceGroupName
Start-AzVmss -VMScaleSetName $vmss.Name -ResourceGroupName $vmss.ResourceGroupName
Próximas etapas
Você também pode usar a CLI do Azure para criar grupos de posicionamento por proximidade.
Crie uma máquina virtual do Linux em uma zona de
Este artigo aborda usando o CLI do Azure para criar uma máquina virtual do Linux em uma região de
disponibilidade do Azure. Uma zona de disponibilidade é uma zona fisicamente separada em uma região do
Azure. Use zonas de disponibilidade para proteger seus aplicativos e dados de uma improvável falha ou perda
de um datacenter inteiro.
Para usar uma zona de disponibilidade, crie a máquina virtual em uma região do Azure com suporte.
Verifique se você instalou a versão mais recente da CLI do Azure e entrou em uma conta do Azure com az login.
Verificar a disponibilidade do SKU de VM

A disponibilidade de tamanhos de VM, ou de SKUs, pode variar por região e por zona. Para ajudá-lo a planejar o
uso de Zonas de Disponibilidade, você poderá listar os SKUs de VM disponíveis por região e zona do Azure. Essa
capacidade garante que você escolha um tamanho adequado de VM e obtenha a resiliência desejada entre as
zonas. Para saber mais sobre os diferentes tipos e tamanhos de VM, confira Visão geral de tamanhos de VM.
Você pode exibir os SKUs de VM disponíveis usando o comando az vm list-skus. O exemplo a seguir lista os
SKUs de VM disponíveis na região eastus2:
az vm list-skus --location eastus2 --output table
A saída é semelhante ao exemplo condensado a seguir, que mostra as Zonas de Disponibilidade nas quais cada
tamanho de VM está disponível:
ResourceType Locations Name [...] Tier Size Zones

---------------- --------- ----------------- --------- ------- -------
virtualMachines eastus2 Standard_DS1_v2 Standard DS1_v2 1,2,3
virtualMachines eastus2 Standard_DS2_v2 Standard DS2_v2 1,2,3
[...]
virtualMachines eastus2 Standard_F1s Standard F1s 1,2,3
virtualMachines eastus2 Standard_F2s Standard F2s 1,2,3
[...]
virtualMachines eastus2 Standard_D2s_v3 Standard D2_v3 1,2,3
virtualMachines eastus2 Standard_D4s_v3 Standard D4_v3 1,2,3
[...]
virtualMachines eastus2 Standard_E2_v3 Standard E2_v3 1,2,3
virtualMachines eastus2 Standard_E4_v3 Standard E4_v3 1,2,3

gerenciados. Você deve criar um grupo de recursos antes de criar uma máquina virtual. Neste exemplo,
criaremos um grupo de recursos chamado myResourceGroupVM na região eastus2. Leste dos EUA 2 é uma das
regiões do Azure que dá suporte a zonas de disponibilidade.
az group create --name myResourceGroupVM --location eastus2

Crie uma máquina virtual com o comando az vm create.
Há várias opções disponíveis ao criar uma máquina virtual, como a imagem do sistema operacional, as
credenciais administrativas e o dimensionamento do disco. Neste exemplo, criaremos uma máquina virtual
chamada myVM no Ubuntu. A VM é criada na zona de disponibilidade 1. Por padrão, a VM é criada no tamanho
Standard_DS1_v2.
az vm create --resource-group myResourceGroupVM --name myVM --location eastus2 --image UbuntuLTS --generate-
ssh-keys --zone 1
A criação da VM pode levar alguns minutos. Depois que a VM tiver sido criada, a CLI do Azure envia
informações sobre a VM. Anote o valor zones que indica a zona de disponibilidade no qual a máquina virtual
está em execução.
{
"fqdns": "",
xxxxxxxxxxxx/resourceGroups/myResourceGroupVM/providers/Microsoft.Compute/virtualMachines/myVM",
"macAddress": "00-0D-3A-23-9A-49",
"resourceGroup": "myResourceGroupVM",
"zones": "1"
}
Confirme a zona do disco gerenciado e endereço IP

Quando a VM é implantada em uma zona de disponibilidade, um disco gerenciado para a VM é criado na
mesma zona de disponibilidade. Por padrão, um endereço IP público também é criado nessa região. Para obter
informações sobre esses tópicos, consulte os seguintes recursos.
Para verificar se o disco gerenciado da VM está na zona de disponibilidade, use o comando AZ VM show para
retornar a ID do disco. Neste exemplo, a ID do disco é armazenada em uma variável que é usada em uma etapa
posterior.
osdiskname=$(az vm show -g myResourceGroupVM -n myVM --query "storageProfile.osDisk.name" -o tsv)
Agora você pode obter informações sobre o disco gerenciado:
az disk show --resource-group myResourceGroupVM --name $osdiskname
A saída mostra que o disco gerenciado está na mesma região da disponibilidade da VM:
{
"creationData": {
"imageReference": {
xxxxxxxxxxxx/Providers/Microsoft.Compute/Locations/westeurope/Publishers/Canonical/ArtifactTypes/VMImage/Off
ers/UbuntuServer/Skus/16.04-LTS/Versions/latest",
"lun": null
},
"sourceResourceId": null,
"sourceUri": null,
"storageAccountId": null
},
"diskSizeGb": 30,
"encryptionSettings": null,
xxxxxxxxxxxx/resourceGroups/myResourceGroupVM/providers/Microsoft.Compute/disks/osdisk_761c570dab",
"managedBy": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myResourceGroupVM/providers/Microsoft.Compute/virtualMachines/myVM",
"name": "myVM_osdisk_761c570dab",
"osType": "Linux",
"sku": {
"name": "Premium_LRS",
"tier": "Premium"
},
"tags": {},
"timeCreated": "2018-03-05T22:16:06.892752+00:00",
"type": "Microsoft.Compute/disks",
"zones": [
"1"
]
}
Use o comando az vm list-ip-adresses para retornar o nome do recurso de endereço IP público no myVM. Neste
exemplo, o nome é armazenado em uma variável usada em uma etapa posterior.
ipaddressname=$(az vm list-ip-addresses -g myResourceGroupVM -n myVM --query "

[].virtualMachine.network.publicIpAddresses[].name" -o tsv)
Agora você pode obter informações sobre o endereço IP:
az network public-ip show --resource-group myResourceGroupVM --name $ipaddressname
A saída mostra que o endereço IP está na mesma região da disponibilidade da VM:

{
"dnsSettings": null,
"etag": "W/\"b7ad25eb-3191-4c8f-9cec-c5e4a3a37d35\"",
xxxxxxxxxxxx/resourceGroups/myResourceGroupVM/providers/Microsoft.Network/publicIPAddresses/myVMPublicIP",
"idleTimeoutInMinutes": 4,
"ipAddress": "52.174.34.95",
"ipConfiguration": {
"etag": null,
xxxxxxxxxxxx/resourceGroups/myResourceGroupVM/providers/Microsoft.Network/networkInterfaces/myVMVMNic/ipConf
igurations/ipconfigmyVM",
"name": null,
"privateIpAddress": null,
"privateIpAllocationMethod": null,
"publicIpAddress": null,
"subnet": null
},
"location": "eastUS2",
"name": "myVMPublicIP",
"publicIpAddressVersion": "IPv4",
"resourceGuid": "8c70a073-09be-4504-0000-000000000000",
"tags": {},
"zones": [
"1"
]
}
Próximas etapas
Neste artigo, você aprendeu a criar uma VM em uma zona de disponibilidade. Saiba mais sobre a
disponibilidade de VMs do Azure.
Introdução aos discos gerenciados do Azure
Os Azure Managed Disks são volumes de armazenamento em nível de bloco que são gerenciados pelo Azure e
usados com Máquinas Virtuais do Azure. Os discos gerenciados são como um disco físico em um servidor local,
mas virtualizados. Com os discos gerenciados, basta especificar o tamanho e o tipo de disco e provisioná-lo.
Depois que você provisionar o disco, o Azure cuidará do resto.
Os tipos disponíveis de discos são Discos Ultra, SSD (unidades de estado sólido) Premium, SSDs Standard e HD
(unidades de disco rígido) Standard. Para obter informações sobre cada tipo de disco individual, confira
Selecionar um tipo de disco para VMs IaaS.
Benefícios dos discos gerenciados

Vamos falar sobre alguns benefícios que você ganha usando discos gerenciados.
Altamente durável e disponível
Os discos gerenciados foram criados para oferecer uma disponibilidade de 99,999%. Os discos gerenciados
atingem isso fornecendo três réplicas dos seus dados, possibilitando alta durabilidade. Se uma ou duas réplicas
apresentarem problemas, as réplicas restantes ajudarão a garantir a persistência dos seus dados e a alta
tolerância contra falhas. Esta arquitetura ajudou o Azure a proporcionar consistentemente durabilidade de nível
empresarial para discos IaaS (Infraestrutura como serviço), com uma taxa de falha anualizada líder do setor de
ZERO POR CENTO.
Implantação simples e escalonável de VM
Usando discos gerenciados, é possível criar até 50 mil discos de VM de um tipo em uma assinatura por região,
permitindo que você crie milhares de VMs em uma assinatura única. Esse recurso também aumenta a ainda
mais escalabilidade dos conjuntos de dimensionamento de máquinas virtuais, permitindo que você crie até mil
VMs em um conjunto de dimensionamento de máquinas virtuais usando uma imagem do Marketplace.
Integração com conjuntos de disponibilidade
Os discos gerenciados são integrados a conjuntos de disponibilidade para garantir que os discos de VMs em um
conjunto de disponibilidade estejam suficientemente isolados entre si para evitar pontos únicos de falha. Os
discos são automaticamente colocados em unidades de escala de armazenamento diferentes (carimbos). Se um
carimbo falhar devido a uma falha de hardware ou de software, somente as instâncias da VM com discos nesses
carimbos falharão. Por exemplo, vamos supor que você tenha um aplicativo em execução em cinco VMs, e que
as VMs estejam em um Conjunto de Disponibilidade. Os discos dessas VMs não serão armazenados no mesmo
stamp, portanto, se um stamp ficar inativo, as outras instâncias do aplicativo continuarão em execução.
Integração com as Zonas de Disponibilidade
Os discos gerenciados são compatíveis com as Zonas de Disponibilidade, que são uma oferta de alta
disponibilidade capaz de proteger seus aplicativos contra falhas no datacenter. As Zonas de Disponibilidade são
locais físicos exclusivos em uma região do Azure. Cada zona é composta por um ou mais datacenters equipados
com energia, resfriamento e rede independentes. Para garantir a resiliência, há um mínimo de três zonas
separadas em todas as regiões habilitadas. Com Zonas de Disponibilidade, o Azure oferece o melhor SLA de
tempo de atividade da VM de 99,99% do setor.
Suporte de Backup do Azure
Para proteger contra desastres regionais, o Backup do Azure pode ser usado para criar um trabalho de backup
com backups baseados em tempo e políticas de retenção de backup. Isso permite que você execute restaurações
de VM ou de disco gerenciado fáceis sempre que quiser. No momento, o Backup do Azure dá suporte a
tamanhos de disco de até 32 TiB (tebibytes). Saiba mais sobre o suporte de backup da VM do Azure.
Backup de Disco do Azure
O backup do Azure oferece o backup em disco do Azure (versão prévia) como uma solução de backup nativa
baseada em nuvem que protege seus dados em discos gerenciados. É uma solução simples, segura e econômica
que permite configurar a proteção de discos gerenciados em algumas etapas. O backup em disco do Azure
oferece uma solução completa que fornece gerenciamento de ciclo de vida de instantâneos para discos
gerenciados automatizando a criação periódica de instantâneos e retendo-o para duração configurada usando a
política de backup. Para obter detalhes sobre o backup em disco do Azure, consulte visão geral do backup em
disco do Azure (em versão prévia).
Controle de acesso granular
Use o RBAC (controle de acesso baseado em função) do Azure para atribuir permissões específicas em um disco
gerenciado a um ou mais usuários. Os discos gerenciados expõem uma variedade de operações, incluindo
leitura, gravação (criar/atualizar), exclusão e recuperação de um URI de SAS (assinatura de acesso
compartilhado) para o disco. Conceda acesso somente às operações que uma pessoa necessita para executar
seu trabalho. Por exemplo, se não quiser que uma pessoa copie um disco gerenciado em uma conta de
armazenamento, opte por não conceder acesso à ação de exportação para esse disco gerenciado. Da mesma
forma, se não quiser que uma pessoa use um URI de SAS para copiar um disco gerenciado, opte por não
conceder essa permissão ao disco gerenciado.
Faça upload do seu VHD
O upload direto facilita a transferência do VHD para um disco gerenciado do Azure. Anteriormente, você
precisava seguir um processo mais envolvido que incluía preparar seus dados em uma conta de
armazenamento. Agora, há menos etapas. É mais fácil fazer upload das VMs locais para o Azure e para grandes
discos gerenciados. Além disso, o processo de backup e de restauração foi simplificado. Isso também reduz o
custo ao permitir que você faça upload dos dados para discos gerenciados diretamente sem anexá-los às VMs. É
possível usar o upload direto para carregar VHDs de até 32 TiB de tamanho.
Para saber como transferir seu VHD para o Azure, confira os artigos da CLI ou do PowerShell.
Segurança
Links Privados
O suporte de link privado para discos gerenciados pode ser usado para importar ou exportar um disco
gerenciado interno para sua rede. Os Links Privados permitem que você gere um URI de SAS (Assinatura de
Acesso Compartilhado) com limite de tempo para discos gerenciados e instantâneos desanexados que podem
ser usados para exportar os dados para outras regiões para expansão regional, recuperação de desastre e para
análise forense. Use também o URI de SAS para carregar diretamente o VHD em um disco vazio local. Agora
você pode aproveitar os Links Privados para restringir a exportação e a importação de discos gerenciados para
que isso só possa ocorrer dentro de sua rede virtual do Azure. Os Links Privados oferecem a garantia de que
seus dados trafeguem apenas na rede de backbone protegida da Microsoft.
Para saber como habilitar Links Privados para importar ou exportar um disco gerenciado, consulte os artigos da
CLI ou do Portal.
Criptografia
Os discos gerenciados oferecem dois tipos diferentes de criptografia. O primeiro é a SSE (Criptografia do
Serviço de Armazenamento), executada pelo serviço de armazenamento. O segundo é o ADE (Azure Disk
Encryption), que pode ser habilitado nos discos do sistema operacional e de dados das VMs.
A criptografia no servidor fornece criptografia em repouso e protege seus dados para atender aos
compromissos de conformidade e segurança da sua organização. A criptografia no servidor está habilitada por
padrão para todos os discos gerenciados, instantâneos e imagens em todas as regiões nas quais os discos
gerenciados estão disponíveis. (Os discos temporários, por outro lado, não são criptografados pela criptografia
do lado do servidor, a menos que você habilite a criptografia no host; consulte Funções de disco: discos
temporários).
Você poderá permitir que o Azure gerencie as chaves para você (essas são chaves gerenciadas pela plataforma)
ou você poderá gerenciar as chaves por conta própria (essas são chaves gerenciadas pelo cliente). Veja o artigo
Criptografia no lado do servidor do Armazenamento em Disco do Azure para obter detalhes.
O Azure Disk Encryption permite criptografar os discos do sistema operacional e os discos de dados usados por
uma Máquina Virtual IaaS. Essa criptografia inclui discos gerenciados. No Windows, as unidades são
criptografadas usando a tecnologia de criptografia BitLocker padrão do setor. No Linux, os discos são
criptografados usando a tecnologia DM-Crypt. Esse processo de criptografia é integrado ao Azure Key Vault
para permitir que você controle e gerencie as chaves de criptografia de disco. Para obter mais informações,
confira Azure Disk Encryption para VMs do Linux ou Azure Disk Encryption para VMs do Windows.
Funções do disco
Há três funções principais de disco no Azure: o disco de dados, o disco do SO e o disco temporário. Essas
funções são mapeadas para discos anexados à sua máquina virtual.
Disco de dados
Um disco de dados é um disco gerenciado anexado a uma máquina virtual para armazenar dados de aplicativos
ou outros dados que precisam ser mantidos. Discos de dados são registrados como unidades SCSI e rotulados
com a letra que você escolher. Cada disco de dados tem uma capacidade máxima de 32.767 GiB (gibibytes). O
tamanho da máquina virtual determina quantos discos de dados você pode anexar a ele e o tipo de
armazenamento que pode usar para hospedar os discos.
Disco do sistema operacional
Cada máquina virtual tem um disco de sistema operacional anexado. Esse disco do sistema operacional tem um
SO pré-instalado, que foi selecionado quando a VM foi criada. Esse disco contém o volume de inicialização.
Esse disco tem uma capacidade máxima de 4.095 GiB.
Disco temporário
A maioria das VMs contém um disco temporário, que não é um disco gerenciado. O disco temporário fornece
armazenamento de curto prazo para aplicativos e processos e destina-se apenas a armazenar dados como
arquivos de página ou de permuta. Os dados no disco temporário podem ser perdidos durante um evento de
manutenção ou durante a reimplantação de uma VM. Durante uma reinicialização padrão bem-sucedida da VM,
os dados no disco temporário serão mantidos. Para obter mais informações sobre VMs sem discos temporários,
consulte tamanhos de VM do Azure sem disco temporário local.
Em VMs do Linux do Azure, o disco temporário é normalmente /dev/sdb e em VMs do Windows, o disco
temporário é D: por padrão. O disco temporário não é criptografado pela criptografia do servidor, a menos que
você habilite a criptografia no host.
Instantâneos de disco gerenciado

Um instantâneo de disco gerenciado é uma cópia completa consistente com falhas e somente leitura de um
disco gerenciado que, por padrão, é armazenada como um disco gerenciado padrão. Com os instantâneos, você
pode fazer backup de seus discos gerenciados a qualquer momento. Esses instantâneos existem
independentemente do disco de origem e podem ser usados para criar novos discos gerenciados.
Os instantâneos são cobrados com base no tamanho utilizado. Por exemplo, se você criar um instantâneo de um
disco gerenciado com capacidade provisionada de 64 GiB e tamanho real de dados usados de 10 GiB, esse
instantâneo será cobrado apenas pelo tamanho de dados usados de 10 GiB. Você poderá ver o tamanho
utilizado dos instantâneos examinando o relatório de uso do Azure. Por exemplo, se o tamanho dos dados de
um snapshot usado for 10 GiB, o relatório de uso diário mostrará 10 GiB/(31 dias) = 0,3226 como a
quantidade consumida.
Para saber mais sobre como criar instantâneos para discos gerenciados, confira os seguintes recursos:
Criar um instantâneo de um disco gerenciado no Windows
Criar um instantâneo de um disco gerenciado no Linux
Imagens
Os discos gerenciados também dão suporte à criação de uma imagem personalizada gerenciada. É possível
criar uma imagem do seu VHD personalizado em uma conta de armazenamento ou diretamente de uma VM
generalizada (por meio do sysprep). Esse processo captura uma única imagem. Essa imagem contém todos os
discos gerenciados associados a uma VM, incluindo os discos do SO e de dados. Esta imagem personalizada
gerenciada permite a criação de centenas de VMs usando sua imagem personalizada, sem a necessidade de
copiar ou gerenciar contas de armazenamento.
Para saber mais sobre a criação de imagens, confira os artigos a seguir:
Como capturar uma imagem gerenciada de uma VM generalizada no Azure
Como generalizar e capturar uma máquina virtual Linux usando a CLI do Azure
Imagens versus instantâneos
É importante compreender a diferença entre imagens e instantâneos. Com discos gerenciados é possível
capturar uma imagem de uma VM generalizada que foi desalocada. Essa imagem inclui todos os discos
anexados à VM. É possível usar essa imagem para criar uma VM e isso inclui todos os discos.
Um instantâneo é uma cópia de um disco no momento exato em que o instantâneo é tirado. Ele só se aplica a
um disco. Se você tiver uma VM que tem um disco (o disco do SO), será possível capturar um instantâneo ou
uma imagem dele e criar uma VM com base no instantâneo ou na imagem.
Um instantâneo não tem reconhecimento de nenhum disco, exceto o contido por ele. Isso torna problemático
usá-lo em cenários que precisam da coordenação de vários discos, como distribuição. Os instantâneos
precisariam ser capazes de coordenar uns com os outros e, no momento, não há suporte para isso.
Desempenho e alocação de disco

O diagrama a seguir ilustra a alocação em tempo real de largura de banda e IOPS para discos, usando um
sistema de provisionamento de três níveis:
O provisionamento do primeiro nível define a atribuição de IOPS e de largura de banda por disco. No segundo
nível, o host do servidor de computação implementa o provisionamento de SSD, aplicando-o aos dados
armazenados no SSD do servidor, que inclui discos com armazenamento em cache (ReadWrite e ReadOnly),
bem como discos locais e temporários. Por fim, o provisionamento da rede de VMs ocorre no terceiro nível para
qualquer E/S que o host de computação envia para o back-end do Armazenamento do Azure. Com esse
esquema, o desempenho de uma VM depende de uma variedade de fatores, desde a maneira como a VM usa o
SSD local até o número de discos anexados, bem como o tipo de desempenho e de cache dos discos que ele
anexou.
Como um exemplo dessas limitações, uma VM Standard_DS1v1 é impedida de alcançar o potencial de 5 mil
IOPS de um disco P30, esteja em cache ou não, devido aos limites nos níveis do SSD e de rede:
O Azure usa um canal de rede priorizado para tráfego de disco, que prevalece sobre outra baixa prioridade do
tráfego de rede. Isso ajuda os discos a manter o desempenho esperado em caso de contenções de rede. Da
mesma forma, o Armazenamento do Azure lida com contenções de recursos e com outros problemas em
segundo plano com balanceamento de carga automático. O Armazenamento do Azure aloca os recursos
necessários quando você cria um disco e aplica o balanceamento proativo e reativo de recursos para lidar com o
nível de tráfego. Com isso, os discos podem sustentar seus destinos de IOPS e de taxa de transferência
esperados. Você pode usar as métricas em nível de VM e de disco para acompanhar o desempenho e os alertas
de configuração, conforme necessário.
Confira nosso artigo de design para alto desempenho para aprender as melhores práticas para otimizar as
configurações de VM + Disco para que você possa atingir o desempenho desejado
Próximas etapas
Se você quiser ver um vídeo que entre em mais detalhes sobre os discos gerenciados, confira: Melhor resiliência
de VM do Azure com Managed Disks.
Saiba mais sobre os tipos de disco individual oferecidos pelo Azure, qual tipo é uma boa opção para suas
necessidades e sobre os destinos de desempenho em nosso artigo sobre tipos de disco.
Selecionar um tipo de disco para VMs de IaaS
Quais tipos de disco estão disponíveis no Azure?
Atualmente, o Azure Managed disks oferece quatro tipos de disco, cada tipo destina-se a cenários de clientes
específicos.
Comparação de discos
A tabela a seguir fornece uma comparação de ultra discos, unidades de estado sólido Premium (SSD), SSD
padrão e unidades de disco rígido padrão (HDD) para discos gerenciados para ajudá-lo a decidir o que usar.
DETA L H E DISC O ULT RA SSD P REM IUM SSD STA N DA RD H DD STA N DA RD
Tipo de disco SSD SSD SSD HDD
Cenário Cargas de trabalho Cargas de trabalho Servidores Web, Backup, não crítico,
com uso intensivo de sensíveis à produção aplicativos acesso não frequente
e/s, como SAP Hana, e ao desempenho empresariais pouco
bancos de dados de usados e
camada superior (por desenvolvimento/test
exemplo, SQL, e
Oracle) e outras
cargas de trabalho de
transações pesadas.
Tamanho máximo do 65.536 GiB (GibiByte) 32.767 GiB 32.767 GiB 32.767 GiB
disco
Taxa de transferência 2.000 MB/s 900 MB/s 750 MB/s 500 MB/s
máxima
IOPS Máxima 160.000 20.000 6.000 2.000
Disco Ultra
Os discos Ultra do Azure proporcionam uma alta taxa de transferência, alta IOPS e armazenamento em disco de
baixa latência e consistente para as VMs de IaaS do Azure. Alguns benefícios adicionais de ultra discos incluem a
capacidade de alterar dinamicamente o desempenho do disco, juntamente com suas cargas de trabalho, sem a
necessidade de reiniciar suas máquinas virtuais (VM). Os discos Ultra são adequados para cargas de trabalho de
grande volume de dados, como SAP HANA, bancos de dados de camada superior e cargas de trabalho de
transações pesadas. Os discos Ultra só podem ser usados como discos de dados. É recomendável usar SSDs
Premium como discos de sistema operacional.
Desempenho
Ao provisionar um disco Ultra, você pode configurar a capacidade e o desempenho do disco de forma
independente. Ultra discos vêm em vários tamanhos fixos, variando de 4 GiB até 64 TiB e apresentam um
modelo de configuração de desempenho flexível que permite configurar de forma independente a IOPS e a taxa
de transferência.
Alguns dos principais recursos dos ultra discos são:
Capacidade do disco: ultra disks Capacity varia de 4 GiB até 64 TiB.
IOPS de disco: ultra disks dá suporte a limites de IOPS de 300 IOPS/GiB, até um máximo de 160 K IOPS por
disco. Para obter o IOPS que você provisionou, verifique se os IOPS de disco selecionados são menores do
que o limite de IOPS de VM. O mínimo de IOPS garantido por disco é 2 IOPS/GiB, com uma linha de base
mínima de 100 IOPS. Por exemplo, se você tivesse um ultra GiB de 4 discos, terá um mínimo de 100 IOPS,
em vez de oito IOPS.
Taxa de transferência do disco: com ultra disks, o limite de taxa de transferência de um único disco é 256
KiB/s para cada IOPS provisionado, até um máximo de 2000 MBps por disco (em que MBps = 10 ^ 6 bytes
por segundo). A taxa de transferência mínima garantida por disco é 4KiB/s para cada IOPS provisionado, com
uma linha de base total mínima de 1 MBps.
Ultra discos dão suporte ao ajuste dos atributos de desempenho de disco (IOPS e taxa de transferência) em
tempo de execução sem desanexar o disco da máquina virtual. Depois que uma operação de
redimensionamento de desempenho do disco tiver sido emitida em um disco, poderá levar até uma hora
para que a alteração entre em vigor efetivamente. Há um limite de quatro operações de redimensionamento
de desempenho durante uma janela de 24 horas. É possível que uma operação de redimensionamento de
desempenho falhe devido à falta de capacidade de largura de banda de desempenho.
Tamanho do disco
L IM IT E DE TA XA DE T RA N SF ERÊN C IA
TA M A N H O DO DISC O ( GIB ) L IM IT E DE IO P S ( M B P S)
4 1.200 300
8 2.400 600
16 4.800 1.200
32 9.600 2.000
64 19.200 2.000
128 38.400 2.000
256 76.800 2.000
512 153.600 2.000
1.024 a 65.536 (os tamanhos nesse 160.000 2.000

intervalo aumentam em incrementos
de 1 TiB)
Ultra discos são projetados para fornecer latências de submilissegundos e IOPS de destino e taxa de
transferência descritas na tabela anterior 99,99% do tempo.
Limitações e escopo de GA
Por enquanto, ultra discos têm limitações adicionais, como a seguir:
As únicas opções de redundância de infraestrutura disponíveis atualmente para ultra discos são zonas de
disponibilidade. As VMs que usam qualquer outra opção de redundância não podem anexar um ultra Disk.
A tabela a seguir descreve as regiões em que os ultra discos estão disponíveis, bem como suas opções de
disponibilidade correspondentes:
NOTE
Se uma região na lista a seguir não tiver nenhuma zona de disponibilidade com capacidade de disco ultra, as VMs nessa
região deverão ser implantadas sem nenhuma opção de redundância de infraestrutura para anexar um ultra Disk.
REGIÕ ES O P Ç Õ ES DE REDUN DÂ N C IA
Brazil South Somente VMs únicas (conjuntos de disponibilidade e

conjuntos de dimensionamento de máquinas virtuais não
têm suporte)
Índia Central Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Leste da Ásia Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Centro-Oeste da Alemanha Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Coreia Central Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Centro-Sul dos Estados Unidos Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Governo dos EUA do Arizona Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Gov. dos EUA – Virgínia Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Governo dos EUA do Texas Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Oeste dos EUA Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Austrália Central Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Leste da Austrália Três zonas de disponibilidade
Sudeste Asiático Três zonas de disponibilidade
Centro-Canadá * Três zonas de disponibilidade

Centro dos EUA Três zonas de disponibilidade
Leste dos EUA Três zonas de disponibilidade
Leste dos EUA 2 Três zonas de disponibilidade
França Central Duas zonas de disponibilidade
Japan East Três zonas de disponibilidade
Norte da Europa Três zonas de disponibilidade
Sul do Reino Unido Três zonas de disponibilidade
Europa Ocidental Três zonas de disponibilidade
Oeste dos EUA 2 Três zonas de disponibilidade
* Contate o suporte do Azure para obter acesso a Zonas de Disponibilidade para esta região.
Há suporte apenas na seguinte série de VMs:
ESv3
Easv4
Edsv4
Esv4
DSv3
Dasv4
Ddsv4
Dsv4
FSv2
LSv2
M
Mv2
Nem todo tamanho de VM está disponível em todas as regiões com suporte com ultra discos.
Estão disponíveis somente como discos de dados.
Suporte ao tamanho de setor físico de 4K por padrão. o tamanho do setor 512E está disponível como uma
oferta geralmente disponível (nenhuma inscrição é necessária), mas só está disponível no momento usando
a CLI ou o PowerShell. A maioria dos aplicativos é compatível com tamanhos de setor de 4K, mas alguns
exigem tamanhos de setor de 512 bytes. Um exemplo seria Oracle Database, que requer a versão 12,2 ou
posterior para dar suporte aos discos nativos de 4K. Para versões mais antigas do Oracle DB, é necessário o
tamanho do setor de 512 bytes.
Só pode ser criado como discos vazios.
Atualmente, o não oferece suporte a instantâneos de disco, imagens de VM, conjuntos de disponibilidade,
hosts dedicados do Azure ou Azure Disk Encryption.
Atualmente, o não oferece suporte à integração com o backup do Azure ou Azure Site Recovery.
Dá suporte apenas a leituras não armazenadas em cache e gravações não armazenadas em cache.
O limite máximo atual para IOPS em VMs GA é 80.000.
Os ultra discos do Azure oferecem até 16 TiB por região por assinatura por padrão, mas os ultra discos
oferecem suporte à maior capacidade por solicitação. Para solicitar um aumento na capacidade, entre em
contato com o suporte do Azure.
Se você quiser começar a usar o ultra disks, consulte nosso artigo sobre o assunto: usando os ultra discos do
Azure.
SSD Premium
Os SSDs Premium do Azure oferecem compatibilidade de disco de alto desempenho e baixa latência para VMs
(máquinas virtuais) com cargas de trabalho com uso intensivo de E/S (entrada/saída). Para aproveitar a
velocidade e o desempenho dos discos de armazenamento Premium, você pode migrar os discos de VM
existentes para os SSDs Premium. Os SSDs Premium são adequados para aplicativos de produção críticos. O
SSDs Premium só pode ser usado com a série de VMs que são compatíveis com o armazenamento Premium.
Para saber mais sobre os tipos e tamanhos de VM individuais no Azure para Windows ou Linux, incluindo quais
tamanhos são compatíveis com o armazenamento Premium, consulte tamanhos de máquinas virtuais no Azure.
Neste artigo, você precisa verificar cada artigo de tamanho de VM individual para determinar se ele é
compatível com o armazenamento Premium.
Tamanho do disco
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Tam 4 8 16 32 64 128 256 512 1.0 2.0 4.0 8.1 16. 32.
anh 24 48 96 92 384 767
o
do
disc
o
em
GiB
IOP 120 120 120 120 240 500 1.1 2.3 5.0 7.5 7.5 16. 18. 20,
S 00 00 00 00 00 000 000 000
pro
visi
ona
da
por
disc
o
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Taxa 25 25 25 25 50 100 125 150 200 250 250 500 750 900
sfer
ênci
a
pro
visi
ona
da
por
disc
o
Má 3.5 3.5 3.5 3.5 3.5 3.5 3.5 3.5

xim 00 00 00 00 00 00 00 00
o
de
IOP
S
de
inte
rmit
ênci
a
por
disc
o
Taxa 170 170 170 170 170 170 170 170

sfer
ênci
a
de
inte
rmit
ênci
a
máx
ima
por
disc
o
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Dur 30 30 30 30 30 30 30 30
o
máx
ima
da
inte
rmit
ênci
a
par
a
rese
rva

Bursting
SSD Premium tamanhos menores que p30 agora oferecem intermitência de disco e podem estourar seus IOPS
por disco até 3.500 e sua largura de banda de até 170 MB/s. A intermitência é automatizada e opera com base
em um sistema de crédito. Os créditos são acumulados automaticamente em um Bucket de intermitência
quando o tráfego de disco está abaixo do destino de desempenho provisionado e os créditos são consumidos
automaticamente quando o tráfego ultrapassa o destino, até o limite de intermitência máximo. O limite máximo
de intermitência define o teto de IOPS de disco & largura de banda, mesmo se você tiver créditos de
intermitência a serem consumidos. A intermitência de disco fornece melhor tolerância a alterações imprevisíveis
de padrões de e/s. Você pode aproveitá-lo melhor para inicialização de disco do so e aplicativos com tráfego
com picos.
O suporte a intermitência de discos será habilitado em novas implantações de tamanhos de disco aplicáveis por
padrão, sem a necessidade de ação do usuário. Para discos existentes dos tamanhos aplicáveis, você pode
habilitar a intermitência com uma das duas opções: desanexar e anexar novamente o disco ou parar e reiniciar a
VM conectada. Todos os tamanhos de disco aplicáveis de intermitência começarão com um Bucket de crédito de
intermitência completa quando o disco for anexado a uma máquina virtual que dá suporte a uma duração
máxima no limite de pico de intermitência de 30 minutos. Para saber mais sobre como a intermitência funciona
nos discos do Azure, confira SSD Premium intermitênciaing.
Transactions
Para o SSDs Premium, cada operação de e/s menor ou igual a 256 KiB de taxa de transferência é considerada
uma única operação de e/s. Operações de e/s maiores que 256 KiB de taxa de transferência são consideradas
várias e/SS de tamanho de 256 KiB.
SSD Standard
Os SSDs Standard do Azure são uma opção econômica de armazenamento otimizado para cargas de trabalho
que necessitam de desempenho consistente em níveis de IOPS mais baixos. SSD padrão oferece uma
experiência de bom nível de entrada para aqueles que desejam migrar para a nuvem, especialmente se passar
por problemas com a variação das cargas de trabalho em execução nas soluções de HD no local. Em
comparação com HDDs padrão, o SSDs padrão oferece melhor disponibilidade, consistência, confiabilidade e
latência. Os SSDs Standard são adequado para servidores Web, servidores de aplicativos de IOPS baixo,
aplicativos empresariais pouco usados e cargas de trabalho de Desenvolvimento/Teste. Como HDDs padrão, o
SSDs padrão está disponível em todas as VMs do Azure.
Tamanho do disco
TA
MA
NH
OS
DE
SSD
STA
ND
AR
D E1 E2 E3 E4 E6 E10 E15 E20 E30 E40 E50 E60 E70 E80
Tam 4 8 16 32 64 128 256 512 1.0 2.0 4.0 8.1 16. 32.
anh 24 48 96 92 384 767
o
do
disc
o
em
GiB
IOP Até Até Até Até Até Até Até Até Até Até Até Até Até Até
S 500 500 500 500 500 500 500 500 500 500 500 2.0 4 6
por 00 mil mil
disc
o
Taxa Até Até Até Até Até Até Até Até Até Até Até Até Até Até
de 60 60 60 60 60 60 60 60 60 60 60 400 600 750
tran MB MB MB MB MB MB MB MB MB MB/ MB/ MB/ MB/ MB/
sfer /s /s /s /s /s /s /s /s /s s s s s s
ênci
a
por
disc
o
O SSDs padrão é projetado para fornecer latências de milissegundos de dígito único e a IOPS e a taxa de
transferência até os limites descritos na tabela anterior 99% do tempo. O IOPS e a taxa de transferência reais
podem variar às vezes, dependendo dos padrões de tráfego. SSDs Padrão fornecerão um desempenho mais
consistente do que os discos HD com a menor latência.
Transactions
Para SSDs padrão, cada operação de e/s menor ou igual a 256 KiB de taxa de transferência é considerada uma
única operação de e/s. Operações de e/s maiores que 256 KiB de taxa de transferência são consideradas várias
e/SS de tamanho de 256 KiB. Essas transações têm um impacto de cobrança.
HDD Standard
Os HDs Standard do Azure oferecem compatibilidade de disco confiável e de baixo custo para VMs que
executam cargas de trabalho insensíveis a latência. Com o Armazenamento Standard, os dados são
armazenados em HDs (unidades de disco rígido). A latência, o IOPS e a taxa de transferência de discos de HDD
Standard podem variar mais amplamente em comparação com discos baseados em SSD. HDD Standard discos
são projetados para fornecer latências de gravação em 10 ms e latências de leitura em 20 ms para a maioria das
operações de e/s, no entanto, o desempenho real pode variar dependendo do padrão de tamanho de e/s Ao
trabalhar com VMs, você pode usar discos HDD padrão para cenários de desenvolvimento/teste e cargas de
trabalho menos críticas. Os HDDs padrão estão disponíveis em todas as regiões do Azure e podem ser usados
com todas as VMs do Azure.
Tamanho do disco
T IP O
DE
DISC
O
STA N
DA RD S4 S6 S10 S15 S20 S30 S40 S50 S60 S70 S80
Tama 32 64 128 256 512 1.024 2.048 4.096 8.192 16.38 32.76
nho 4 7
do
Disk
em
GiB
IOPS Até Até Até Até Até Até Até Até Até Até Até
por 500 500 500 500 500 500 500 500 1.300 2.000 2.000
disco
Taxa Até Até Até Até Até Até Até Até Até Até Até
de 60 60 60 60 60 60 60 60 300 500 500
transf MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s
erênci
a por
disco
Transactions
Para HDDs padrão, cada operação de e/s é considerada como uma única transação, independentemente do
tamanho de e/s. Essas transações têm um impacto de cobrança.
Cobrança
Ao usar discos gerenciados, as seguintes considerações de cobrança se aplicam:
Tipo de disco
Tamanho do disco gerenciado
Instantâneos
Transferências de dados de saída
Número de transações
Tamanho do disco gerenciado : discos gerenciados são cobrados no tamanho provisionado. O Azure mapeia
o tamanho provisionado (arredondado) para o tamanho de disco oferecido mais próximo. Para obter detalhes
sobre os tamanhos de disco oferecidos, confira as tabelas anteriores. Cada disco é mapeado para um tamanho
de disco provisionado compatível e é cobrado de acordo. Por exemplo, se você provisionar uma SSD Standard
de 200 GiB, ela será mapeada para a oferta de tamanho de disco E15 (256 GiB). A cobrança por qualquer disco
provisionado é rateada por hora usando o preço mensal da oferta de armazenamento. Por exemplo, se você
provisionou um disco E10 e o excluiu após 20 horas, será cobrado pela a oferta E10 rateada em 20 horas. Isso é
independente da quantidade de dados reais gravados no disco.
Instantâneos : os instantâneos são cobrados com base no tamanho usado. Por exemplo, se você criar um
instantâneo de um disco gerenciado com capacidade provisionada de 64 GiB e tamanho real de dados usados
de 10 GiB, o instantâneo será cobrado apenas pelo tamanho de dados usados de 10 GiB.
Para obter mais informações sobre instantâneos, confira a seção sobre instantâneos Visão geral de discos
gerenciados.
Transferências de dados de saída : as transferências de dados de saída (dados saindo dos datacenters do
Azure) incorrem em cobrança por uso de largura de banda.
Transações : você será cobrado pelo número de transações executadas em um disco gerenciado padrão. Para
SSDs padrão, cada operação de e/s menor ou igual a 256 KiB de taxa de transferência é considerada uma única
operação de e/s. Operações de e/s maiores que 256 KiB de taxa de transferência são consideradas várias e/SS
de tamanho de 256 KiB. Para HDDs padrão, cada operação de e/s é considerada como uma única transação,
independentemente do tamanho de e/s.
Para obter informações detalhadas sobre os preços de Managed Disks, incluindo os custos de transação,
consulte Managed disks preços.
Taxa de reserva de VM de ultra Disk
As VMs do Azure têm a capacidade de indicar se são compatíveis com ultra discos. Uma VM compatível com um
disco ultra aloca a capacidade de largura de banda dedicada entre a instância de VM de computação e a unidade
de escala de armazenamento de bloco para otimizar o desempenho e reduzir a latência. A inclusão desse
recurso na VM resulta em uma cobrança de reserva que será imposta somente se você habilitar o recurso de
disco ultra na VM sem anexar um disco ultra a ela. Quando um disco ultra é anexado à VM compatível com
discos ultra, essa cobrança não é aplicada. Essa cobrança é por vCPU provisionada na VM.
NOTE
Para tamanhos de VM de núcleo restritos, a taxa de reserva é baseada no número real de vCPUs e não nos núcleos
restritos. Para Standard_E32-8s_v3, a taxa de reserva será baseada em núcleos de 32.
Consulte a página de preços dos discos do Azure para obter detalhes de preços do ultra Disk.
Reserva de disco do Azure
A reserva de disco é a opção de comprar um ano de armazenamento em disco com antecedência a um
desconto, reduzindo o custo total. Ao comprar uma reserva de disco, você seleciona um SKU de disco específico
em uma região de destino, por exemplo, 10 p30 (1TiB) do SSDs Premium na região leste dos EUA 2 para um
termo de um ano. A experiência de reserva é semelhante às instâncias de VM (máquina virtual) reservadas.
Você pode agrupar as reservas de VM e disco para maximizar sua economia. Por enquanto, a reserva de discos
do Azure oferece um plano de compromisso de um ano para SKUs de SSD Premium de p30 (1TiB) a P80 (32
TiB) em todas as regiões de produção. Para obter mais detalhes sobre os preços dos discos reservados, consulte
a página de preços dos discos do Azure.
Próximas etapas
Consulte Managed disks preços para começar.
Compartilhar um disco gerenciado do Azure
Os discos compartilhados do Azure são um novo recurso para discos gerenciados do Azure que permite anexar
um disco gerenciado a várias VMs (máquinas virtuais) simultaneamente. Anexar um disco gerenciado a várias
VMs permite implantar novos aplicativos clusterizados ou migrar os existentes para o Azure.
Como ele funciona

As VMs no cluster podem ler ou gravar no disco anexado com base na reserva escolhida pelo aplicativo
clusterizado usando reservas persistentes de SCSI (PR. SCSI). A PR SCSI é um padrão do setor utilizado por
aplicativos executados na Rede de Área de Armazenamento (SAN) local. Habilitar a PR SCSI em um disco
gerenciado permite migrar esses aplicativos para o Azure no estado em que se encontram.
Os Managed disks compartilhados oferecem armazenamento de bloco compartilhado que pode ser acessado
de várias VMs, eles são expostos como LUNs (números de unidade lógica). Os LUNs são apresentados a um
iniciador (VM) de um destino (disco). Esses LUNs são semelhantes ao DAS (armazenamento de conexão direta)
ou a uma unidade local para a VM.
Os discos gerenciados compartilhados não oferecem nativamente um sistema de arquivos totalmente
gerenciado que pode ser acessado usando SMB/NFS. Você precisa usar um Gerenciador de cluster, como o
WSFC (cluster de failover do Windows Server) ou pacemaker, que manipula a comunicação do nó de cluster e o
bloqueio de gravação.
Limitações
A habilitação de discos compartilhados só está disponível para um subconjunto de tipos de disco. No momento,
apenas ultra discos e o SSDs Premium podem habilitar discos compartilhados. Cada disco gerenciado que tem
discos compartilhados habilitados está sujeito às seguintes limitações, organizadas por tipo de disco:
Discos Ultra
Ultra discos têm sua própria lista separada de limitações, não relacionadas a discos compartilhados. Para
limitações de ultra Disk, consulte usando os ultra discos do Azure.
Ao compartilhar ultra disks, eles têm as seguintes limitações adicionais:
Atualmente limitado a suporte a Azure Resource Manager ou SDK.
Somente discos básicos podem ser usados com algumas versões do cluster de failover do Windows Server,
para obter detalhes, consulte requisitos de hardware de clustering de failover e opções de armazenamento.
Ultra discos compartilhados estão disponíveis em todas as regiões que dão suporte a ultra discos por padrão e
não exigem que você se inscreva no Access para usá-los.
SSDs Premium
Só pode ser habilitado em discos de dados, não em discos do sistema operacional.
O cache de host ReadOnly não está disponível para o SSDs Premium com maxShares>1 .
A intermitência de disco não está disponível para o SSDs Premium com maxShares>1 .
Ao usar conjuntos de disponibilidade e conjuntos de dimensionamento de máquinas virtuais com discos
compartilhados do Azure, o alinhamento do domínio de falha de armazenamento com o domínio de falha de
máquina virtual não é imposto para o disco de dados compartilhado.
Ao usar PPG (grupos de posicionamento de proximidade), todas as máquinas virtuais que compartilham um
disco devem fazer parte do mesmo PPG.
Azure Site Recovery suporte ainda não está disponível.
O backup do Azure está disponível por meio do backup em disco do Azure (versão prévia).
O SSDs Premium compartilhado está disponível em todas as regiões em que os discos gerenciados estão
disponíveis.
Requisitos do sistema operacional
Os discos compartilhados dão suporte a vários sistemas operacionais. Consulte as seções do Windows ou Linux
para os sistemas operacionais com suporte.
Tamanhos do disco
Por enquanto, somente os ultra discos e o SSDs Premium podem habilitar discos compartilhados. Tamanhos de
disco diferentes podem ter um maxShares limite diferente, que você não pode exceder ao definir o maxShares
valor. Para o SSDs Premium, os tamanhos de disco que dão suporte ao compartilhamento de discos são P15 e
superior.
Para cada disco, você pode definir um maxShares valor que representa o número máximo de nós que podem
compartilhar o disco simultaneamente. Por exemplo, se você planeja configurar um cluster de failover de 2 nós,
defina maxShares=2 . O valor máximo é um limite superior. Os nós podem ingressar ou sair do cluster (montar
ou desmontar o disco), desde que o número de nós seja menor do que o maxShares valor especificado.
NOTE
O maxShares valor só pode ser definido ou editado quando o disco é desanexado de todos os nós.
Intervalos de SSD Premium

A tabela a seguir ilustra os valores máximos permitidos para os maxShares tamanhos de disco Premium:
TA M A N H O S DO DISC O L IM IT E DE M A XSH A RES
P15, P20 2
P30, P40, P50 5
P60, P70, P80 10
Os limites de IOPS e largura de banda de um disco não são afetados pelo maxShares valor. Por exemplo, o IOPS
máximo de um disco P15 é 1100 se maxShares = 1 ou maxShares > 1.
Intervalos de ultra Disk
O maxShares valor mínimo é 1, enquanto o maxShares valor máximo é 5. Não há restrições de tamanho em
ultra discos, qualquer tamanho de disco pode usar qualquer valor para maxShares , até e incluindo o valor
máximo.
Exemplo de cargas de trabalho

Windows
Os discos compartilhados do Azure têm suporte no Windows Server 2008 e mais recentes. A maioria dos
clusters baseados em Windows se baseia no WSFC, que lida com toda a infraestrutura básica para comunicação
de nó de cluster, permitindo que seus aplicativos aproveitem os padrões de acesso paralelo. O WSFC permite
opções de CSV e não baseadas em CSV, dependendo da sua versão do Windows Server. Para obter mais
detalhes, consulte Criar um cluster de failover.
Alguns aplicativos populares em execução no WSFC incluem:
Criar um FCI com discos compartilhados do Azure (SQL Server em VMs do Azure)
Servidor de arquivos de escalabilidade horizontal (SoFS) [modelo] (https://aka.ms/azure-shared-disk-sofs-
template)
SAP ASCS/SCS [modelo] (https://aka.ms/azure-shared-disk-sapacs-template)
Servidor de arquivos para uso geral (Carga de trabalho de IW)
Disco de perfil de usuário do servidor da área de trabalho remota (RDS UPD)
Linux
Os discos compartilhados do Azure têm suporte em:
SUSE EPU para SAP e SUSE EPU HA 15 SP1 e superior
Ubuntu 18, 4 e superior
Versão prévia de desenvolvedor do RHEL em qualquer uma das versões RHEL 8
Oracle Enterprise Linux
Os clusters do Linux podem utilizar os gerenciadores de cluster, como o Pacemaker. O Pacemaker se baseia no
Corosync, o que permite a comunicação de cluster para aplicativos implantados em ambientes altamente
disponíveis. Alguns sistemas de arquivos clusterizados comuns incluem ocfs2 e gfs2. Você pode usar os
modelos de clustering de reserva persistente de SCSI (RP) e/ou SBD (dispositivo de bloco STONITH) para
arbitrar o acesso ao disco. Ao usar o SCSI PR, você pode manipular reservas e registros usando utilitários como
fence_scsi e sg_persist.
Fluxo de reserva persistente

O diagrama a seguir ilustra um exemplo de aplicativo de banco de dados clusterizado de 2 nós, que utiliza a PR
SCSI para habilitar o failover de um nó para o outro.
O fluxo é da seguinte maneira:
1. O aplicativo clusterizado em execução no Azure VM1 e VM2 registra sua intenção de ler ou gravar no disco.
2. A instância do aplicativo na VM1 usa a reserva exclusiva para gravar no disco.
3. Essa reserva é aplicada ao disco do Azure e agora o banco de dados pode gravar exclusivamente no disco. As
gravações da instância do aplicativo na VM2 não serão realizadas com sucesso.
4. Se a instância do aplicativo na VM1 ficar inativa, a instância na VM2 agora poderá iniciar um failover do
banco de dados e a tomada do controle do disco.
5. Agora essa reserva é aplicada ao disco do Azure e o disco não aceita mais gravações da VM1. Ele só aceitará
gravações da VM2.
6. O aplicativo clusterizado pode concluir o failover do banco de dados e atender às solicitações da VM2.
O diagrama a seguir ilustra outra carga de trabalho clusterizada comum, que consiste em vários nós que leem
os dados do disco para executar processos paralelos, como o treinamento de modelos de aprendizado de
máquina.
O fluxo é da seguinte maneira:
1. O aplicativo clusterizado em execução em todas as VMs registra a intenção de ler ou gravar no disco.
2. A instância do aplicativo na VM1 usa uma reserva exclusiva para gravar no disco, ao abrir as leituras no disco
de outras VMs.
3. Essa reserva é aplicada ao disco do Azure.
4. Todos os nós no cluster agora podem ler no disco. Somente um nó grava os resultados no disco, em nome
de todos os nós no cluster.
Fluxo de reserva de discos ultra
Os discos ultra oferecem uma restrição adicional, para um total de duas restrições. Em virtude disso, o fluxo de
reserva de discos ultra pode funcionar conforme descrito na seção anterior ou pode restringir e distribuir o
desempenho de forma mais granular.
Acelerações de desempenho
SSD Premium acelerações de desempenho
Com o SSD Premium, o IOPS de disco e a taxa de transferência são fixos, por exemplo, IOPS de um p30 é 5000.
Esse valor permanece se o disco é compartilhado entre duas VMs ou 5 VMs. Os limites de disco podem ser
alcançados de uma única VM ou divididas em duas ou mais VMs.
Restrições de desempenho de discos ultra
Os discos ultra têm o recurso exclusivo de permitir que você defina seu desempenho, expondo atributos
modificáveis e permitindo modificá-los. Por padrão, há apenas dois atributos modificáveis, mas os discos ultra
compartilhados têm dois atributos adicionais.
AT RIB UTO DESC RIÇ Ã O
DiskIOPSReadWrite O número total de IOPS permitido em todas as VMs que

montam o disco de compartilhamento com acesso de
gravação.
DiskMBpsReadWrite A taxa de transferência total (MB/s) permitida em todas as

VMs que montam o disco compartilhado com acesso de
gravação.
DiskIOPSReadOnly* O número total de IOPS permitidos em todas as VMs que

montam o disco compartilhado como ReadOnly .
DiskMBpsReadOnly* A taxa de transferência total (MB/s) permitida em todas as

VMs que montam o disco compartilhado como ReadOnly .
* Aplica-se somente aos discos ultra compartilhados

As fórmulas a seguir explicam como os atributos de desempenho podem ser definidos, pois são usuários
modificáveis:
DiskIOPSReadWrite/DiskIOPSReadOnly:
Limites de IOPS de 300 IOPS/GiB, até no máximo 160 mil IOPS por disco
No mínimo 100 IOPS
DiskIOPSReadWrite + DiskIOPSReadOnly tem pelo menos 2 IOPS/GiB
DiskMBpsRead Write/DiskMBpsReadOnly:
O limite de taxa de transferência de um único disco é de 256 KiB/s para cada IOPS provisionado, até
no máximo 2.000 MBps por disco
A taxa de transferência mínima garantida por disco é 4KiB/s para cada IOPS provisionado, com uma
linha de base geral mínima de 1 MBps
Exemplos
Os exemplos a seguir descrevem alguns cenários que mostram como a restrição pode funcionar com discos
ultra compartilhados, especificamente.
C l u st e r d e d o i s n ó s u sa n d o v o l u m e s c o m p a r t i l h a d o s d o c l u st e r
Veja a seguir um exemplo de um WSFC de dois nós usando volumes compartilhados clusterizados. Com essa
configuração, ambas as VMs têm acesso simultâneo de gravação ao disco, o que resulta na ReadWrite divisão
da limitação entre as duas VMs e a ReadOnly limitação não ser usada.
C l u st e r d e d o i s n ó s se m v o l u m e s d e c o m p a r t i l h a m e n t o d e c l u st e r
Este é um exemplo de um WSFC de 2 nós que não está usando volumes compartilhados clusterizados. Com
essa configuração, apenas uma VM tem acesso de gravação no disco. Isso faz com que o ReadWrite acelerador
esteja sendo usado exclusivamente para a VM primária e a ReadOnly limitação somente seja usada pelo
secundário.
C l u st e r L i n u x d e q u a t r o n ó s
Este é um exemplo de um cluster Linux de 4 nós com um único gravador e três leitores de expansão. Com essa
configuração, apenas uma VM tem acesso de gravação no disco. Isso faz com que o ReadWrite acelerador esteja
sendo usado exclusivamente para a VM primária e o ReadOnly acelerador que está sendo dividido pelas VMs
secundárias.
Ultra preços
Os discos ultra compartilhados são cobrados com base na capacidade provisionada, total de IOPS provisionadas
(diskIOPSReadWrite + diskIOPSReadOnly) e total de taxa de transferência provisionada (diskMBpsReadWrite +
diskMBpsReadOnly). Não há custo adicional para cada montagem de VM adicional. Por exemplo, um disco ultra
compartilhado com a seguinte configuração (diskSizeGB: 1024, DiskIOPSReadWrite: 10000,
DiskMBpsReadWrite: 600, DiskIOPSReadOnly: 100, DiskMBpsReadOnly: 1) é cobrado com 1024 GiB, 10100
IOPS e 601 MBps, independentemente de ser montado em duas VMs ou cinco VMs.
Próximas etapas
Se você estiver interessado em habilitar e usar discos compartilhados para seus discos gerenciados, vá para
nosso artigo habilitar disco compartilhado
Habilitar disco compartilhado
Este artigo aborda como habilitar o recurso de discos compartilhados para o Azure Managed disks. Os discos
compartilhados do Azure são um novo recurso para discos gerenciados do Azure que permite anexar um disco
gerenciado a várias VMs (máquinas virtuais) simultaneamente. Anexar um disco gerenciado a várias VMs
permite implantar novos aplicativos clusterizados ou migrar os existentes para o Azure.
Se você estiver procurando informações conceituais sobre discos gerenciados que têm discos compartilhados
habilitados, consulte Azure Shared disks.
Limitações
A habilitação de discos compartilhados só está disponível para um subconjunto de tipos de disco. No momento,
apenas ultra discos e o SSDs Premium podem habilitar discos compartilhados. Cada disco gerenciado que tem
discos compartilhados habilitados está sujeito às seguintes limitações, organizadas por tipo de disco:
Discos Ultra
Ultra discos têm sua própria lista separada de limitações, não relacionadas a discos compartilhados. Para
limitações de ultra Disk, consulte usando os ultra discos do Azure.
Ao compartilhar ultra disks, eles têm as seguintes limitações adicionais:
Ultra discos compartilhados estão disponíveis em todas as regiões que dão suporte a ultra discos por padrão e
não exigem que você se inscreva no Access para usá-los.
SSDs Premium
Só pode ser habilitado em discos de dados, não em discos do sistema operacional.
O cache de host ReadOnly não está disponível para o SSDs Premium com maxShares>1 .
A intermitência de disco não está disponível para o SSDs Premium com maxShares>1 .
Ao usar conjuntos de disponibilidade e conjuntos de dimensionamento de máquinas virtuais com discos
compartilhados do Azure, o alinhamento do domínio de falha de armazenamento com o domínio de falha de
máquina virtual não é imposto para o disco de dados compartilhado.
Ao usar PPG (grupos de posicionamento de proximidade), todas as máquinas virtuais que compartilham um
disco devem fazer parte do mesmo PPG.
Azure Site Recovery suporte ainda não está disponível.
O backup do Azure está disponível por meio do backup em disco do Azure (versão prévia).
O SSDs Premium compartilhado está disponível em todas as regiões em que os discos gerenciados estão
disponíveis.
Sistemas operacionais compatíveis

Os discos compartilhados dão suporte a vários sistemas operacionais. Consulte as seções do Windows e do
Linux do artigo conceitual para os sistemas operacionais com suporte.
Tamanhos do disco
Por enquanto, somente os ultra discos e o SSDs Premium podem habilitar discos compartilhados. Tamanhos de
disco diferentes podem ter um maxShares limite diferente, que você não pode exceder ao definir o maxShares
valor. Para o SSDs Premium, os tamanhos de disco que dão suporte ao compartilhamento de discos são P15 e
superior.
Para cada disco, você pode definir um maxShares valor que representa o número máximo de nós que podem
compartilhar o disco simultaneamente. Por exemplo, se você planeja configurar um cluster de failover de 2 nós,
defina maxShares=2 . O valor máximo é um limite superior. Os nós podem ingressar ou sair do cluster (montar
ou desmontar o disco), desde que o número de nós seja menor do que o maxShares valor especificado.
NOTE
O maxShares valor só pode ser definido ou editado quando o disco é desanexado de todos os nós.
Intervalos de SSD Premium

A tabela a seguir ilustra os valores máximos permitidos para os maxShares tamanhos de disco Premium:
TA M A N H O S DO DISC O L IM IT E DE M A XSH A RES
P15, P20 2
P30, P40, P50 5
P60, P70, P80 10
Os limites de IOPS e largura de banda de um disco não são afetados pelo maxShares valor. Por exemplo, o IOPS
máximo de um disco P15 é 1100 se maxShares = 1 ou maxShares > 1.
Intervalos de ultra Disk
O maxShares valor mínimo é 1, enquanto o maxShares valor máximo é 5. Não há restrições de tamanho em
ultra discos, qualquer tamanho de disco pode usar qualquer valor para maxShares , até e incluindo o valor
máximo.
Implantar discos compartilhados

Implantar um SSD Premium como um disco compartilhado
Para implantar um disco gerenciado com o recurso de disco compartilhado habilitado, use a nova propriedade
maxShares e defina um valor maior que 1. Isso torna o disco compartilhável entre várias VMs.
IMPORTANT
O valor de maxShares só pode ser definido ou alterado quando um disco é desmontado de todas as VMs. Consulte os
tamanhos de disco para os valores permitidos para maxShares .
CLI do Azure
PowerShell
Modelo do Resource Manager
az disk create -g myResourceGroup -n mySharedDisk --size-gb 1024 -l westcentralus --sku Premium_LRS --max-
shares 2
Implantar um ultra Disk como um disco compartilhado

Para implantar um disco gerenciado com o recurso de disco compartilhado habilitado, altere o maxShares
parâmetro para um valor maior que 1. Isso torna o disco compartilhável entre várias VMs.
IMPORTANT
O valor de maxShares só pode ser definido ou alterado quando um disco é desmontado de todas as VMs. Consulte os
tamanhos de disco para os valores permitidos para maxShares .
CLI do Azure
PowerShell
Ex e m p l o d e d i sc o r e g i o n a l
#Creating an Ultra shared Disk

az disk create -g rg1 -n clidisk --size-gb 1024 -l westus --sku UltraSSD_LRS --max-shares 5 --disk-iops-
read-write 2000 --disk-mbps-read-write 200 --disk-iops-read-only 100 --disk-mbps-read-only 1
#Updating an Ultra shared Disk

az disk update -g rg1 -n clidisk --disk-iops-read-write 3000 --disk-mbps-read-write 300 --set
diskIopsReadOnly=100 --set diskMbpsReadOnly=1
#Show shared disk properties:

az disk show -g rg1 -n clidisk
Ex e m p l o d e d i sc o z o n a l
Este exemplo é quase igual ao anterior, exceto que ele cria um disco na zona de disponibilidade 1.
#Creating an Ultra shared Disk

az disk create -g rg1 -n clidisk --size-gb 1024 -l westus --sku UltraSSD_LRS --max-shares 5 --disk-iops-
read-write 2000 --disk-mbps-read-write 200 --disk-iops-read-only 100 --disk-mbps-read-only 1 --zone 1
#Updating an Ultra shared Disk

az disk update -g rg1 -n clidisk --disk-iops-read-write 3000 --disk-mbps-read-write 300 --set
diskIopsReadOnly=100 --set diskMbpsReadOnly=1
#Show shared disk properties:

az disk show -g rg1 -n clidisk
Usando discos compartilhados do Azure com suas VMs

Depois de implantar um disco compartilhado com maxShares>1 o, você pode montar o disco em uma ou mais
de suas VMs.
NOTE
Se você estiver implantando um ultra Disk, verifique se ele corresponde aos requisitos necessários. Consulte usando os
ultra discos do Azure para obter detalhes.
$location = "WestCentralUS"
$vm = New-AzVm -ResourceGroupName $resourceGroup -Name "myVM" -Location $location -VirtualNetworkName

"myVnet" -SubnetName "mySubnet" -SecurityGroupName "myNetworkSecurityGroup" -PublicIpAddressName
"myPublicIpAddress"
$dataDisk = Get-AzDisk -ResourceGroupName $resourceGroup -DiskName "mySharedDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "mySharedDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
update-AzVm -VM $vm -ResourceGroupName $resourceGroup
Comandos de RP do SCSI com suporte

Depois de montar o disco compartilhado em suas VMs em seu cluster, você pode estabelecer o quorum e
ler/gravar no disco usando o SCSI PR. Os seguintes comandos de PR estão disponíveis ao usar os discos
compartilhados do Azure:
Para interagir com o disco, comece com a lista de ações de reserva persistente:
PR_REGISTER_KEY
PR_REGISTER_AND_IGNORE
PR_GET_CONFIGURATION
PR_RESERVE
PR_PREEMPT_RESERVATION
PR_CLEAR_RESERVATION
PR_RELEASE_RESERVATION
Ao usar PR_RESERVE, PR_PREEMPT_RESERVATION ou PR_RELEASE_RESERVATION, forneça um dos seguintes

tipos de reserva persistente:
PR_NONE
PR_WRITE_EXCLUSIVE
PR_EXCLUSIVE_ACCESS
PR_WRITE_EXCLUSIVE_REGISTRANTS_ONLY
PR_EXCLUSIVE_ACCESS_REGISTRANTS_ONLY
PR_WRITE_EXCLUSIVE_ALL_REGISTRANTS
PR_EXCLUSIVE_ACCESS_ALL_REGISTRANTS
Você também precisa fornecer uma chave de reserva persistente ao usar PR_RESERVE,
PR_REGISTER_AND_IGNORE, PR_REGISTER_KEY, PR_PREEMPT_RESERVATION, PR_CLEAR_RESERVATION ou
reserva de PR_RELEASE.
Próximas etapas
Se você preferir usar modelos de Azure Resource Manager para implantar o disco, os seguintes modelos de
exemplo estarão disponíveis:
SSD Premium
Ultra discos regionais
Ultra discos de zona
Criptografia do lado do servidor de
Armazenamento em Disco do Azure
A criptografia do lado do servidor (SSE) ajuda a proteger os dados e atender aos compromissos de
conformidade e segurança de sua organização. A SSE criptografa automaticamente os dados armazenados nos
discos gerenciados do Azure (so e discos de dados) em repouso por padrão, ao mantê-los na nuvem.
Os dados nos discos gerenciados são criptografados de maneira transparente usando a criptografia AES de 256
bits, uma das codificações de bloco mais fortes disponíveis, e são compatíveis com o FIPS 140-2. Para obter
mais informações sobre os módulos criptográficos subjacentes aos discos gerenciados do Azure, veja API de
Criptografia: Próxima geração
A criptografia do lado do servidor não afeta o desempenho dos discos gerenciados e não há nenhum custo
adicional.
NOTE
Discos temporários não são discos gerenciados e não são criptografados pelo SSE, a menos que você habilite a
criptografia no host.
Sobre o gerenciamento de chaves de criptografia

Você pode contar com chaves gerenciadas pela plataforma para a criptografia do disco gerenciado ou gerenciar
a criptografia usando suas próprias chaves. Se você optar por gerenciar a criptografia com suas próprias chaves,
pode especificar uma chave gerenciada pelo cliente a ser usada para criptografar e descriptografar todos os
dados nos discos gerenciados.
As seções a seguir descrevem mais detalhadamente cada uma das opções de gerenciamento de chaves.
Chaves gerenciadas pela plataforma
Por padrão, os discos gerenciados usam chaves de criptografia gerenciadas pela plataforma. Todos os discos
gerenciados, instantâneos, imagens e dados gravados em discos gerenciados existentes são automaticamente
criptografados em repouso com chaves gerenciadas pela plataforma.
Chaves gerenciadas pelo cliente
Você pode optar por gerenciar a criptografia no nível de cada disco gerenciado com suas próprias chaves. A
criptografia do lado do servidor para discos gerenciados com chaves gerenciadas pelo cliente oferece uma
experiência integrada com o Azure Key Vault. É possível importar as chaves RSA para o Key Vault ou gerar novas
chaves RSA no Azure Key Vault.
Os discos gerenciados do Azure tratam a criptografia e a descriptografia de maneira totalmente transparente
com o uso da criptografia de envelope. Ela criptografa dados usando uma DEK (chave de criptografia de dados)
baseada em AES 256 que, por sua vez, é protegida com suas chaves. O serviço de armazenamento gera chaves
de criptografia de dados e as criptografa com chaves gerenciadas pelo cliente usando a criptografia RSA. A
criptografia de envelope permite alternar (mudar) as chaves periodicamente de acordo com as políticas de
conformidade, sem afetar as VMs. Quando você alterna as chaves, o serviço de armazenamento criptografa
novamente as chaves de criptografia de dados com as novas chaves gerenciadas pelo cliente.
Controle total de suas chaves
Você deve conceder acesso a discos gerenciados em seu Key Vault para usar suas chaves para criptografar e
descriptografar o DEK. Isso permite o controle total de dados e chaves. É possível desabilitar as chaves ou
revogar o acesso aos discos gerenciados a qualquer momento. Você também pode auditar o uso da chave de
criptografia com monitoramento do Azure Key Vault para garantir que apenas os discos gerenciados ou outros
serviços confiáveis do Azure acessem as chaves.
Para SSDs premium, SSDs padrão e HDDs padrão: Ao desabilitar ou excluir a chave, todas as VMs com discos
que usam essa chave serão desligadas automaticamente. Depois disso, as VMs não serão utilizáveis, a menos
que a chave seja habilitada novamente ou você atribua uma nova chave.
Para ultra discos: quando você desabilita ou exclui uma chave, qualquer VM com ultra disks usando a chave não
será desligada automaticamente. Depois de desalocar e reiniciar as VMs, os discos deixarão de usar a chave e as
VMs não ficarão online novamente. Para colocar as VMs online novamente, você deve atribuir uma nova chave
ou habilitar a chave existente.
O diagrama a seguir mostra como os discos gerenciados usam o Azure Active Directory e o Azure Key Vault
para fazer solicitações usando a chave gerenciada pelo cliente:
A lista a seguir explica o diagrama mais detalhadamente:

1. Um administrador do Azure Key Vault cria os recursos do Key Vault.
2. O administrador do Key Vault importa as chaves RSA para o Key Vault ou gera novas chaves RSA no Key
Vault.
3. Esse administrador cria uma instância do recurso de conjunto de criptografia de disco, especificando uma ID
do Azure Key Vault e uma URL da chave. O conjunto de criptografia de disco é um novo recurso que
simplifica o gerenciamento de chaves dos discos gerenciados.
4. Quando um conjunto de criptografia de disco é criado, uma identidade gerenciada atribuída ao sistema é
criada no Azure Active Directory (AD) e associada ao conjunto de criptografia de disco.
5. O administrador do Azure Key Vault concede a permissão de identidade gerenciada para realizar operações
no Key Vault.
6. Um usuário da VM cria discos associando-os ao conjunto de criptografia de disco. O usuário da VM também
pode habilitar a criptografia do lado do servidor com chaves gerenciadas pelo cliente para recursos
existentes, associando-as ao conjunto de criptografia de disco.
7. Os discos gerenciados usam a identidade gerenciada para enviar solicitações ao Azure Key Vault.
8. Para leitura ou gravação de dados, os discos gerenciados enviam solicitações ao Azure Key Vault para
criptografar (encapsular) e descriptografar (desencapsular) a chave de criptografia de dados, a fim de
criptografar e descriptografar os dados.
Para revogar o acesso às chaves gerenciadas pelo cliente, confira Azure Key Vault PowerShell e Azure Key Vault
CLI. Revogar o acesso bloqueia o acesso a todos os dados na conta de armazenamento, pois a chave de
criptografia não é acessível pelo Armazenamento do Microsoft Azure.
Restrições
Por enquanto, as chaves gerenciadas pelo cliente têm as seguintes restrições:
Se esse recurso estiver habilitado para o disco, não é possível desabilitá-lo. Se precisar contornar isso, você
deve copiar todos os dados usando o módulo Azure PowerShell ou o CLI do Azure, para um disco gerenciado
totalmente diferente que não esteja usando chaves gerenciadas pelo cliente.
Somente chaves de software e HSM RSA de tamanhos de 2.048 bits, 3.072 bits e 4.096 bits têm suporte, sem
outras chaves ou tamanhos.
As chaves HSM exigem a camada Premium de cofres de chaves do Azure.
Os discos criados a partir de imagens personalizadas criptografadas com criptografia do lado do servidor e
chaves gerenciadas pelo cliente devem ser criptografados usando as mesmas chaves gerenciadas pelo
cliente e estar na mesma assinatura.
Os instantâneos criados a partir de discos criptografados com criptografia do lado do servidor e chaves
gerenciadas pelo cliente devem ser criptografados com as mesmas chaves gerenciadas pelo cliente.
Todos os recursos relacionados às chaves gerenciadas pelo cliente (Azure Key Vaults, conjuntos de
criptografia de disco, VMs, discos e instantâneos) devem estar na mesma assinatura e região.
Discos, instantâneos e imagens criptografados com chaves gerenciadas pelo cliente não podem passar para
outro grupo de recursos e assinatura.
Os discos gerenciados atualmente ou criptografados anteriormente usando Azure Disk Encryption não
podem ser criptografados usando chaves gerenciadas pelo cliente.
Só é possível criar até 1000 conjuntos de criptografia de disco por região por assinatura.
Para obter informações sobre o uso de chaves gerenciadas pelo cliente com galerias de imagens
compartilhadas, confira Preview: Use chaves gerenciadas pelo cliente para criptografar imagens.
Regiões com suporte
As chaves gerenciadas pelo cliente estão disponíveis em todas as regiões em que os discos gerenciados estão
disponíveis.
A rotação de chaves automática está em visualização e só está disponível nas seguintes regiões:
Leste dos EUA
Leste dos EUA 2
Centro-Sul dos Estados Unidos
Oeste dos EUA
Oeste dos EUA 2
Norte da Europa
Europa Ocidental
França Central
IMPORTANT
As chaves gerenciadas pelo cliente contam com as identidades gerenciadas para recursos do Azure, um recurso do Azure
Active Directory (Azure AD). Ao configurar chaves gerenciadas pelo cliente, uma identidade gerenciada é atribuída
automaticamente aos recursos nos bastidores. Se, subsequentemente, você mover a assinatura, o grupo de recursos ou o
disco gerenciado de um diretório do Azure AD para outro, a identidade gerenciada associada a discos gerenciados não
será transferida para o novo locatário, portanto, as chaves gerenciadas pelo cliente poderão deixar de funcionar. Para
obter mais informações, confira Transferência de uma assinatura entre diretórios do Azure Active Directory.
Criptografia em criptografia de host de ponta a ponta para os dados

da VM
Quando você habilita a criptografia no host, essa criptografia é iniciada no host da VM em si, no servidor do
Azure ao qual sua VM está alocada. Os dados para o disco temporário e OS caches de disco do sistema
operacional/dados são armazenados nesse host de VM. Depois de habilitar a criptografia no host, todos esses
dados são criptografados em repouso e os fluxos são criptografados para o serviço de armazenamento, onde
são persistidos. Essencialmente, a criptografia no host criptografa seus dados de ponta a ponta. A criptografia
no host não usa a CPU da VM e não afeta o desempenho da VM.
Discos temporários e discos do sistema operacional efêmero são criptografados em repouso com chaves
gerenciadas pela plataforma quando você habilita a criptografia de ponta a ponta. Os caches do sistema
operacional e dos dados são criptografados em repouso com chaves gerenciadas pelo cliente ou gerenciadas
por plataforma, dependendo do tipo de criptografia de disco selecionado. Por exemplo, se um disco for
criptografado com chaves gerenciadas pelo cliente, o cache do disco será criptografado com chaves gerenciadas
pelo cliente e, se um disco for criptografado com chaves gerenciadas pela plataforma, o cache do disco será
criptografado com chaves gerenciadas pela plataforma.
Restrições
O não oferece suporte a ultra discos.
Não poderá ser habilitado se Azure Disk Encryption (criptografia de VM convidada usando BitLocker/VM-
Decrypt) estiver habilitada em seus conjuntos de dimensionamento de VMs/máquinas virtuais.
Azure Disk Encryption não pode ser habilitada em discos que têm criptografia no host habilitado.
A criptografia pode ser habilitada no conjunto de dimensionamento de máquinas virtuais existente. No
entanto, somente as novas VMs criadas após a habilitação da criptografia são criptografadas
automaticamente.
As VMs existentes devem ser desalocadas e realocadas para serem criptografadas.
Atualmente disponível somente nas seguintes regiões:
Oeste dos EUA
Oeste dos EUA 2
Leste dos EUA
Leste dos EUA 2
Centro do Canadá
Leste do Canadá
França central
Europa Ocidental
Norte da Europa
Leste do Japão
Oeste do Japão
Gov. dos EUA – Virgínia
Governo dos EUA do Arizona
Tamanhos de VM com suporte
Toda a última geração de tamanhos de VM dá suporte à criptografia no host:
TYPE SEM SUP O RT E C O M SUP O RT E
Propósito geral Dv3, Dav4, Dv2, Av2 B, DSv2, Dsv3, DC, DCv2, Dasv4
Otimizado para computação Fsv2
Otimizado para memória Ev3, Eav4 DSv2, Esv3, M, Mv2, Easv4
Otimizado para armazenamento Ls, Lsv2 (discos de NVMe não

criptografados)
GPU NC, NV NCv2, NCv3, ND, NVv3, NVv4, NDv2

(versão prévia)
Computação de alto desempenho H HB, HC, HBv2
Gerações anteriores F, A, D, L, G DS, GS, FS, NVv2
A atualização do tamanho da VM resultará em validação para verificar se o novo tamanho da VM dá suporte ao

recurso EncryptionAtHost.
Criptografia dupla em repouso

Clientes confidenciais de alta segurança que se preocupam com o risco associado a qualquer algoritmo de
criptografia, implementação ou chave em particular comprometidos agora podem optar por uma camada
adicional de criptografia usando um algoritmo/modo de criptografia diferente na camada de infraestrutura
usando chaves de criptografia gerenciadas pela plataforma. Essa nova camada pode ser aplicada ao sistema
operacional persistente e discos de dados, instantâneos e imagens, todos os quais serão criptografados em
repouso com criptografia dupla.
A criptografia dupla está disponível em todas as regiões em que os discos gerenciados estão disponíveis.
Criptografia do lado do servidor versus criptografia de disco do Azure

Azure Disk Encryption aproveita o recurso DM-cript do Linux ou o recurso BitLocker do Windows para
criptografar discos gerenciados com chaves gerenciadas pelo cliente na VM convidada. A criptografia do lado do
servidor com chaves gerenciadas pelo cliente aprimora o ADE, permitindo usar quaisquer tipos de sistema
operacional e imagens para as VMs, criptografando dados no serviço de armazenamento.
IMPORTANT
automaticamente aos recursos nos bastidores. Se, em seguida, você migrar a assinatura, o grupo de recursos ou o disco
gerenciado de um diretório do Azure Active Directory para outro, a identidade gerenciada associada aos discos
gerenciados não será transferida para o novo locatário. Portanto, as chaves gerenciadas pelo cliente podem deixar de
funcionar. Para obter mais informações, confira Transferência de uma assinatura entre diretórios do Azure Active Directory.
Próximas etapas
Habilite a criptografia de ponta a ponta usando a criptografia no host com o módulo Azure PowerShell, o CLI
do Azureou o portal do Azure.
Habilite a criptografia dupla em repouso para discos gerenciados com o módulo Azure PowerShell, o CLI do
Azure ou o portal do Azure.
Habilite chaves gerenciadas pelo cliente para discos gerenciados com o módulo Azure PowerShell, o CLI do
Azure ou o portal do Azure.
Conheça os modelos do Azure Resource Manager para criar discos criptografados com chaves gerenciadas
pelo cliente
O que é o Cofre da Chave do Azure?
Usar o portal do Azure para habilitar a criptografia
do lado do servidor com chaves gerenciadas pelo
cliente para discos gerenciados
Armazenamento em Disco do Azure permite que você gerencie suas próprias chaves ao usar a criptografia do
lado do servidor (SSE) para discos gerenciados, se você escolher. Para obter informações conceituais sobre o
SSE com chaves gerenciadas pelo cliente, bem como outros tipos de criptografia de disco gerenciado, consulte a
seção chaves gerenciadas pelo cliente do nosso artigo sobre criptografia de disco:
Para Linux: chaves gerenciadas pelo cliente
Para Windows: chaves gerenciadas pelo cliente
Restrições
Se esse recurso estiver habilitado para o disco, não é possível desabilitá-lo. Se você precisar solucionar
esse erro, deverá copiar todos os dados para um disco gerenciado totalmente diferente que não esteja
usando chaves gerenciadas pelo cliente:
Para Linux: copiar um disco gerenciado
Para Windows: copiar um disco gerenciado
Somente chaves de software e HSM RSA de tamanhos de 2.048 bits, 3.072 bits e 4.096 bits têm suporte,
sem outras chaves ou tamanhos.
As seções a seguir abordam como habilitar e usar chaves gerenciadas pelo cliente para Managed disks:
A configuração de chaves gerenciadas pelo cliente para seus discos exigirá que você crie recursos em uma
ordem específica, se estiver fazendo isso pela primeira vez. Primeiro, será necessário criar e configurar um
Azure Key Vault.
Configure o seu Cofre da Chave do Azure

1. Entre no Portal do Azure.
2. Procure e selecione cofres de chaves .
IMPORTANT
Seu cofre de chaves do Azure, conjunto de criptografia de disco, VM, discos e instantâneos devem estar na mesma
região e assinatura para que a implantação tenha sucesso.
3. Selecione + Adicionar para criar um novo Key Vault.

4. Criar um grupo de recursos.
5. Insira um nome de Key Vault, selecione uma região e selecione um tipo de preço.
NOTE
Ao criar a instância do Key Vault, habilite a exclusão temporária e a proteção de limpeza. A exclusão temporária
garante que a Key Vault mantenha uma chave excluída para determinado período de retenção (padrão de 90
dias). A proteção de limpeza garante que uma chave excluída não seja excluída permanentemente até que o
período de retenção termine. Essas configurações protegem você contra a perda de dados devido à exclusão
acidental. Essas configurações são obrigatórias ao usar um Key Vault para criptografar discos gerenciados.
6. Selecione revisão + criar , verifique suas opções e, em seguida, selecione criar .

7. Depois que o cofre de chaves concluir a implantação, selecione-o.
8. Selecione chaves em configurações .
9. Selecione Gerar/Impor tar .
10. Deixe o tipo de chave definido como RSA e o tamanho da chave RSA definido como 2048 .
11. Preencha as seleções restantes como desejar e, em seguida, selecione criar .
Configurar o conjunto de criptografia de disco

1. Procure por conjuntos de criptografia de disco e selecione-o.
2. Na folha conjuntos de criptografia de disco , selecione + Adicionar .
3. Selecione seu grupo de recursos, nomeie o conjunto de criptografia e selecione a mesma região que o
cofre de chaves.
4. Para tipo de criptografia , selecione criptografia em repouso com uma chave gerenciada pelo
cliente .
NOTE
Depois de criar um conjunto de criptografia de disco com um tipo de criptografia específico, ele não pode ser
alterado. Se você quiser usar um tipo de criptografia diferente, deverá criar um novo conjunto de criptografia de
disco.
5. Selecione clique para selecionar uma chave .

6. Selecione o cofre de chaves e a chave que você criou anteriormente, bem como a versão.
7. Pressione Selecionar .
8. Selecione Examinar + Criar e Criar .
9. Abra o conjunto de criptografia de disco depois de concluir a criação e selecione o alerta que aparece.
Duas notificações devem ser exibidas e bem sucedidos. Isso permite que você use o conjunto de
criptografia de disco com o cofre de chaves.
Implantar uma máquina virtual

Agora que você criou e configurou o cofre de chaves e o conjunto de criptografia de disco, você pode implantar
uma VM usando a criptografia. O processo de implantação de VM é semelhante ao processo de implantação
padrão, as únicas diferenças são que você precisa implantar a VM na mesma região que seus outros recursos e
optar por usar uma chave gerenciada pelo cliente.
1. Pesquise máquinas vir tuais e selecione + Adicionar para criar uma VM.
2. Na folha básico , selecione a mesma região que o conjunto de criptografia de disco e Azure Key Vault.
3. Preencha os outros valores na folha básica como desejar.
4. Na folha discos , selecione criptografia em repouso com uma chave gerenciada pelo cliente .
5. Selecione o conjunto de criptografia de disco na lista suspensa conjunto de criptografia de disco .
6. Faça as seleções restantes como desejar.
Habilitar em um disco existente
Cau t i on
Habilitar a criptografia de disco em qualquer disco anexado a uma VM exigirá que você interrompa a VM.
1. Navegue até uma VM que está na mesma região que um de seus conjuntos de criptografia de disco.
2. Abra a VM e selecione parar .
3. Após a interrupção da VM, selecione discos e, em seguida, selecione o disco que você deseja criptografar.
4. Selecione criptografia e selecione criptografia em repouso com uma chave gerenciada pelo
cliente e, em seguida, selecione o conjunto de criptografia de disco na lista suspensa.
5. Selecione Salvar .
6. Repita esse processo para todos os outros discos anexados à VM que você gostaria de criptografar.
7. Quando os discos terminarem de alternar para chaves gerenciadas pelo cliente, se não houver nenhum
outro disco anexado que você queira criptografar, você poderá iniciar sua VM.
IMPORTANT
disco gerenciado de um diretório do Azure AD para outro, a identidade gerenciada associada aos discos gerenciados não
Próximas etapas
pelo cliente
Replicar máquinas com discos habilitados para chaves gerenciadas pelo cliente
Configurar a recuperação de desastre de VMs VMware para o Azure usando o PowerShell
Configurar a recuperação de desastres para o Azure para máquinas virtuais do Hyper-V usando o PowerShell
e o Azure Resource Manager
Azure PowerShell-habilitar chaves gerenciadas pelo
cliente com discos gerenciados por criptografia do
lado do servidor
SSE com chaves gerenciadas pelo cliente e outros tipos de criptografia de disco gerenciado, consulte a seção
chaves gerenciadas pelo cliente do nosso artigo sobre criptografia de disco.
Restrições
Se esse recurso estiver habilitado para o disco, não é possível desabilitá-lo. Se uma solução alternativa for
necessária, você deve copiar todos os dados para um disco gerenciado totalmente diferente que não use
chaves gerenciadas pelo cliente.
Configurar um Azure Key Vault e DiskEncryptionSet sem rotação de

chaves automática
Para usar chaves gerenciadas pelo cliente com o SSE, você deve configurar um Azure Key Vault e um recurso
DiskEncryptionSet.
1. Verifique se você instalou a versão mais recente do Azure PowerShell e se está conectado a uma conta do
Azure com Connect-AzAccount
2. Crie uma instância do Azure Key Vault e a chave de criptografia.
Ao criar a instância do Key Vault, habilite a exclusão temporária e a proteção de limpeza. A exclusão
temporária garante que a Key Vault mantenha uma chave excluída para determinado período de retenção
(padrão de 90 dias). A proteção de limpeza garante que uma chave excluída não seja excluída
permanentemente até que o período de retenção termine. Essas configurações protegem você contra a
perda de dados devido à exclusão acidental. Essas configurações são obrigatórias ao usar um Key Vault
para criptografar discos gerenciados.
$ResourceGroupName="yourResourceGroupName"
$LocationName="westcentralus"
$keyVaultName="yourKeyVaultName"
$keyName="yourKeyName"
$keyDestination="Software"
$diskEncryptionSetName="yourDiskEncryptionSetName"
$keyVault = New-AzKeyVault -Name $keyVaultName -ResourceGroupName $ResourceGroupName -Location

$LocationName -EnablePurgeProtection
$key = Add-AzKeyVaultKey -VaultName $keyVaultName -Name $keyName -Destination $keyDestination
3. Crie uma instância de um DiskEncryptionSet.
$desConfig=New-AzDiskEncryptionSetConfig -Location $LocationName -SourceVaultId $keyVault.ResourceId

-KeyUrl $key.Key.Kid -IdentityType SystemAssigned
$des=New-AzDiskEncryptionSet -Name $diskEncryptionSetName -ResourceGroupName $ResourceGroupName -

InputObject $desConfig
4. Conceda o acesso ao recurso DiskEncryptionSet para o Key Vault.
NOTE
Pode levar alguns minutos para o Azure criar a identidade do DiskEncryptionSet no Azure Active Directory. Se
você receber um erro como "não é possível encontrar o objeto Active Directory" ao executar o comando a seguir,
aguarde alguns minutos e tente novamente.
Set-AzKeyVaultAccessPolicy -VaultName $keyVaultName -ObjectId $des.Identity.PrincipalId -

PermissionsToKeys wrapkey,unwrapkey,get
Configurar um Azure Key Vault e DiskEncryptionSet com a rotação de

chaves automática (visualização)
1. Verifique se você instalou a versão mais recente do Azure PowerShelle se está conectado a uma conta do
Azure no com Connect-AzAccount .
Ao criar a instância de Key Vault, você deve habilitar a proteção de limpeza. A proteção de limpeza
garante que uma chave excluída não seja excluída permanentemente até que o período de retenção
termine. Essa configuração protege você contra a perda de dados devido à exclusão acidental e é
obrigatória para criptografar discos gerenciados.

3. Crie um DiskEncryptionSet usando a versão da API 2020-12-01 e definindo a propriedade

rotationToLatestKeyVersionEnabled como true por meio do modelo de Azure Resource Manager
CreateDiskEncryptionSetWithAutoKeyRotation.jsem
New-AzResourceGroupDeployment -ResourceGroupName $ResourceGroupName `

-TemplateUri "https://raw.githubusercontent.com/Azure-Samples/managed-disks-powershell-getting-
started/master/AutoKeyRotation/CreateDiskEncryptionSetWithAutoKeyRotation.json" `
-diskEncryptionSetName $diskEncryptionSetName `
-keyVaultId $($keyVault.ResourceId) `
-keyVaultKeyUrl $($key.Key.Kid) `
-encryptionType "EncryptionAtRestWithCustomerKey" `
-region $LocationName
NOTE
$des=Get-AzDiskEncryptionSet -Name $diskEncryptionSetName -ResourceGroupName $ResourceGroupName

Exemplos
Agora que você criou e configurou esses recursos, você pode usá-los para proteger seus discos gerenciados.
Veja a seguir os scripts de exemplo, cada um com um cenário respectivo, que você pode usar para proteger seus
discos gerenciados.
Crie uma VM usando uma imagem do Marketplace, criptografando o sistema operacional e os discos de
dados com chaves gerenciadas pelo cliente
Copie o script, substitua todos os valores de exemplo pelos seus próprios parâmetros e, em seguida, execute-o.
$VMLocalAdminUser = "yourVMLocalAdminUserName"
$VMLocalAdminSecurePassword = ConvertTo-SecureString <password> -AsPlainText -Force
$LocationName = "yourRegion"
$ResourceGroupName = "yourResourceGroupName"
$ComputerName = "yourComputerName"
$VMName = "yourVMName"
$VMSize = "yourVMSize"
$diskEncryptionSetName="yourdiskEncryptionSetName"
$NetworkName = "yourNetworkName"
$NICName = "yourNICName"
$SubnetName = "yourSubnetName"
$SubnetAddressPrefix = "10.0.0.0/24"
$VnetAddressPrefix = "10.0.0.0/16"
$SingleSubnet = New-AzVirtualNetworkSubnetConfig -Name $SubnetName -AddressPrefix $SubnetAddressPrefix

$Vnet = New-AzVirtualNetwork -Name $NetworkName -ResourceGroupName $ResourceGroupName -Location
$LocationName -AddressPrefix $VnetAddressPrefix -Subnet $SingleSubnet
$NIC = New-AzNetworkInterface -Name $NICName -ResourceGroupName $ResourceGroupName -Location $LocationName -
SubnetId $Vnet.Subnets[0].Id
$Credential = New-Object System.Management.Automation.PSCredential ($VMLocalAdminUser,

$VMLocalAdminSecurePassword);
$VirtualMachine = New-AzVMConfig -VMName $VMName -VMSize $VMSize

$VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName $ComputerName -
Credential $Credential -ProvisionVMAgent -EnableAutoUpdate
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $NIC.Id
$VirtualMachine = Set-AzVMSourceImage -VM $VirtualMachine -PublisherName 'MicrosoftWindowsServer' -Offer
'WindowsServer' -Skus '2012-R2-Datacenter' -Version latest
$diskEncryptionSet=Get-AzDiskEncryptionSet -ResourceGroupName $ResourceGroupName -Name

$diskEncryptionSetName
$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -Name $($VMName +"_OSDisk") -DiskEncryptionSetId

$diskEncryptionSet.Id -CreateOption FromImage
$VirtualMachine = Add-AzVMDataDisk -VM $VirtualMachine -Name $($VMName +"DataDisk1") -DiskSizeInGB 128 -

StorageAccountType Premium_LRS -CreateOption Empty -Lun 0 -DiskEncryptionSetId $diskEncryptionSet.Id
New-AzVM -ResourceGroupName $ResourceGroupName -Location $LocationName -VM $VirtualMachine -Verbose
Crie um disco vazio criptografado usando a criptografia do lado do servidor com chaves gerenciadas pelo
cliente e anexe -o a uma VM
$vmName = "yourVMName"
$LocationName = "westcentralus"
$diskName = "yourDiskName"
$diskSKU = "Premium_LRS"
$diskSizeinGiB = 30
$diskLUN = 1
$vm = Get-AzVM -Name $vmName -ResourceGroupName $ResourceGroupName

$vm = Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Empty -DiskSizeInGB $diskSizeinGiB -
StorageAccountType $diskSKU -Lun $diskLUN -DiskEncryptionSetId $diskEncryptionSet.Id
Update-AzVM -ResourceGroupName $ResourceGroupName -VM $vm
Criptografe os discos gerenciados existentes

Os discos existentes não devem ser anexados a uma VM em execução para que você possa criptografá-los
usando o seguinte script:
$rgName = "yourResourceGroupName"
$diskName = "yourDiskName"
$diskEncryptionSetName = "yourDiskEncryptionSetName"
$diskEncryptionSet = Get-AzDiskEncryptionSet -ResourceGroupName $rgName -Name $diskEncryptionSetName
New-AzDiskUpdateConfig -EncryptionType "EncryptionAtRestWithCustomerKey" -DiskEncryptionSetId

$diskEncryptionSet.Id | Update-AzDisk -ResourceGroupName $rgName -DiskName $diskName
Crie um conjunto de dimensionamento de máquinas virtuais usando uma imagem do Marketplace,

criptografando o sistema operacional e os discos de dados com chaves gerenciadas pelo cliente
$VMLocalAdminUser = "yourLocalAdminUser"
$VMLocalAdminSecurePassword = ConvertTo-SecureString Password@123 -AsPlainText -Force
$ComputerNamePrefix = "yourComputerNamePrefix"
$VMScaleSetName = "yourVMSSName"
$VMSize = "Standard_DS3_v2"
$NetworkName = "yourVNETName"

$ipConfig = New-AzVmssIpConfig -Name "myIPConfig" -SubnetId $Vnet.Subnets[0].Id
$VMSS = New-AzVmssConfig -Location $LocationName -SkuCapacity 2 -SkuName $VMSize -UpgradePolicyMode

'Automatic'
$VMSS = Add-AzVmssNetworkInterfaceConfiguration -Name "myVMSSNetworkConfig" -VirtualMachineScaleSet $VMSS -

Primary $true -IpConfiguration $ipConfig

# Enable encryption at rest with customer managed keys for OS disk by setting DiskEncryptionSetId property
$VMSS = Set-AzVmssStorageProfile $VMSS -OsDiskCreateOption "FromImage" -DiskEncryptionSetId

$diskEncryptionSet.Id -ImageReferenceOffer 'WindowsServer' -ImageReferenceSku '2012-R2-Datacenter' -
ImageReferenceVersion latest -ImageReferencePublisher 'MicrosoftWindowsServer'
$VMSS = Set-AzVmssOsProfile $VMSS -ComputerNamePrefix $ComputerNamePrefix -AdminUsername $VMLocalAdminUser -

AdminPassword $VMLocalAdminSecurePassword
# Add a data disk encrypted at rest with customer managed keys by setting DiskEncryptionSetId property
$VMSS = Add-AzVmssDataDisk -VirtualMachineScaleSet $VMSS -CreateOption Empty -Lun 1 -DiskSizeGB 128 -

StorageAccountType Premium_LRS -DiskEncryptionSetId $diskEncryptionSet.Id

New-AzVmss -VirtualMachineScaleSet $VMSS -ResourceGroupName $ResourceGroupName -VMScaleSetName

$VMScaleSetName
Mude a chave de um DiskEncryptionSet para alternar a chave de todos os recursos que fazem referência ao
DiskEncryptionSet
$keyVault = Get-AzKeyVault -VaultName $keyVaultName -ResourceGroupName $ResourceGroupName
$keyVaultKey = Get-AzKeyVaultKey -VaultName $keyVaultName -Name $keyName
Update-AzDiskEncryptionSet -Name $diskEncryptionSetName -ResourceGroupName $ResourceGroupName -SourceVaultId

$keyVault.ResourceId -KeyUrl $keyVaultKey.Id
Encontre o status da criptografia do lado do servidor de um disco
$DiskName="yourDiskName"
$disk=Get-AzDisk -ResourceGroupName $ResourceGroupName -DiskName $DiskName

$disk.Encryption.Type
IMPORTANT
Próximas etapas
pelo cliente
Usar o CLI do Azure para habilitar a criptografia do
lado do servidor com chaves gerenciadas pelo
cliente para discos gerenciados
SSE com chaves gerenciadas pelo cliente, bem como outros tipos de criptografia de disco gerenciado, consulte a
seção chaves gerenciadas pelo cliente do nosso artigo sobre criptografia de disco.
Restrições
Se esse recurso estiver habilitado para o disco, não é possível desabilitá-lo. Se uma solução alternativa for
necessária, você deve copiar todos os dados para um disco gerenciado totalmente diferente que não use
chaves gerenciadas pelo cliente.
Configurar seu Azure Key Vault e DiskEncryptionSet

Primeiro, você deve configurar um Azure Key Vault e um recurso diskencryptionset.
1. Certifique-se de que você instalou a versão mais recente da CLI do Azure e entrou em uma conta do
Azure com az login.
IMPORTANT
Não use “camel case” (misturar maiúsculas e minúsculas). Isso pode causar problemas ao atribuir discos adicionais
ao recurso no portal do Azure.
subscriptionId=yourSubscriptionID
rgName=yourResourceGroupName
location=westcentralus
keyVaultName=yourKeyVaultName
keyName=yourKeyName
diskEncryptionSetName=yourDiskEncryptionSetName
diskName=yourDiskName
az account set --subscription $subscriptionId
az keyvault create -n $keyVaultName -g $rgName -l $location --enable-purge-protection true --enable-

soft-delete true
az keyvault key create --vault-name $keyVaultName -n $keyName --protection software
keyVaultId=$(az keyvault show --name $keyVaultName --query [id] -o tsv)
keyVaultKeyUrl=$(az keyvault key show --vault-name $keyVaultName --name $keyName --query [key.kid] -o
tsv)
az disk-encryption-set create -n $diskEncryptionSetName -l $location -g $rgName --source-vault

$keyVaultId --key-url $keyVaultKeyUrl
NOTE
desIdentity=$(az disk-encryption-set show -n $diskEncryptionSetName -g $rgName --query

[identity.principalId] -o tsv)
az keyvault set-policy -n $keyVaultName -g $rgName --object-id $desIdentity --key-permissions wrapkey

unwrapkey get
Agora que você criou e configurou esses recursos, você pode usá-los para proteger seus discos gerenciados. Os
links a seguir contêm scripts de exemplo, cada um com um cenário respectivo, que você pode usar para
proteger seus discos gerenciados.
Exemplos
Crie uma VM usando uma imagem do Marketplace, criptografando o sistema operacional e os discos de
dados com chaves gerenciadas pelo cliente
vmName=yourVMName
vmSize=Standard_DS3_V2
image=UbuntuLTS
diskEncryptionSetName=yourDiskencryptionSetName
diskEncryptionSetId=$(az disk-encryption-set show -n $diskEncryptionSetName -g $rgName --query [id] -o tsv)
az vm create -g $rgName -n $vmName -l $location --image $image --size $vmSize --generate-ssh-keys --os-disk-
encryption-set $diskEncryptionSetId --data-disk-sizes-gb 128 128 --data-disk-encryption-sets
$diskEncryptionSetId $diskEncryptionSetId
Criptografe os discos gerenciados existentes

Os discos existentes não devem ser anexados a uma VM em execução para que você possa criptografá-los
usando o seguinte script:
az disk update -n $diskName -g $rgName --encryption-type EncryptionAtRestWithCustomerKey --disk-encryption-

set $diskEncryptionSetId
Crie um conjunto de dimensionamento de máquinas virtuais usando uma imagem do Marketplace,

criptografando o sistema operacional e os discos de dados com chaves gerenciadas pelo cliente
vmssName=yourVMSSName
image=UbuntuLTS
diskEncryptionSetName=yourDiskencryptionSetName

az vmss create -g $rgName -n $vmssName --image UbuntuLTS --upgrade-policy automatic --admin-username
azureuser --generate-ssh-keys --os-disk-encryption-set $diskEncryptionSetId --data-disk-sizes-gb 64 128 --
data-disk-encryption-sets $diskEncryptionSetId $diskEncryptionSetId
Crie um disco vazio criptografado usando a criptografia do lado do servidor com chaves gerenciadas pelo
cliente e anexe -o a uma VM
vmName=yourVMName
diskSkuName=Premium_LRS
diskSizeinGiB=30
diskLUN=2
az disk create -n $diskName -g $rgName -l $location --encryption-type EncryptionAtRestWithCustomerKey --

disk-encryption-set $diskEncryptionSetId --size-gb $diskSizeinGiB --sku $diskSkuName
diskId=$(az disk show -n $diskName -g $rgName --query [id] -o tsv)
az vm disk attach --vm-name $vmName --lun $diskLUN --ids $diskId
Mude a chave de um DiskEncryptionSet para alternar a chave de todos os recursos que fazem referência ao
DiskEncryptionSet
keyName=yourKeyName
keyVaultId=$(az keyvault show --name $keyVaultName--query [id] -o tsv)
keyVaultKeyUrl=$(az keyvault key show --vault-name $keyVaultName --name $keyName --query [key.kid] -o tsv)
az disk-encryption-set update -n keyrotationdes -g keyrotationtesting --key-url $keyVaultKeyUrl --source-

vault $keyVaultId
Encontre o status da criptografia do lado do servidor de um disco
az disk show -g yourResourceGroupName -n yourDiskName --query [encryption.type] -o tsv
IMPORTANT
Próximas etapas
pelo cliente
Use o portal do Azure para habilitar a criptografia
de ponta a ponta usando a criptografia no host
Quando você habilita a criptografia no host, os dados armazenados no host da VM são criptografados em
repouso e os fluxos são criptografados para o serviço de armazenamento. Para obter informações conceituais
sobre criptografia no host, bem como outros tipos de criptografia de disco gerenciado, consulte:
Linux: criptografia na criptografia de ponta a ponta de host para os dados da VM.
Windows: criptografia na criptografia de ponta a ponta de host para os dados da VM.
Restrições
automaticamente.
Oeste dos EUA
Oeste dos EUA 2
Leste dos EUA
Leste dos EUA 2
Centro do Canadá
Leste do Canadá
França central
Europa Ocidental
Norte da Europa
Leste do Japão
Oeste do Japão

criptografados)

(versão prévia)

Pré-requisitos
Para poder usar a criptografia no host para suas VMs ou conjuntos de dimensionamento de máquinas virtuais,
você deve obter o recurso habilitado em sua assinatura. Envie um email para encryptionAtHost@microsoft.com
com suas IDs de assinatura para obter o recurso habilitado para suas assinaturas.
Entre no portal do Azure usando o link fornecido.
IMPORTANT
Você deve usar o link fornecido para acessar o portal do Azure. A criptografia no host não está visível no momento no
portal do Azure público sem usar o link.
Criar um Azure Key Vault e um conjunto de criptografia de disco

Depois que o recurso estiver habilitado, você precisará configurar um Azure Key Vault e um conjunto de
criptografia de disco, se ainda não tiver feito isso.
A configuração de chaves gerenciadas pelo cliente para seus discos exigirá que você crie recursos em uma
ordem específica, se estiver fazendo isso pela primeira vez. Primeiro, será necessário criar e configurar um
Azure Key Vault.
Configure o seu Cofre da Chave do Azure

1. Entre no Portal do Azure.
2. Procure e selecione cofres de chaves .
IMPORTANT
Seu cofre de chaves do Azure, conjunto de criptografia de disco, VM, discos e instantâneos devem estar na mesma
região e assinatura para que a implantação tenha sucesso.
3. Selecione + Adicionar para criar um novo Key Vault.

4. Criar um grupo de recursos.
5. Insira um nome de Key Vault, selecione uma região e selecione um tipo de preço.
NOTE
Ao criar a instância do Key Vault, habilite a exclusão temporária e a proteção de limpeza. A exclusão temporária
garante que a Key Vault mantenha uma chave excluída para determinado período de retenção (padrão de 90
dias). A proteção de limpeza garante que uma chave excluída não seja excluída permanentemente até que o
período de retenção termine. Essas configurações protegem você contra a perda de dados devido à exclusão
acidental. Essas configurações são obrigatórias ao usar um Key Vault para criptografar discos gerenciados.
6. Selecione revisão + criar , verifique suas opções e, em seguida, selecione criar .

7. Depois que o cofre de chaves concluir a implantação, selecione-o.
8. Selecione chaves em configurações .
9. Selecione Gerar/Impor tar .
10. Deixe o tipo de chave definido como RSA e o tamanho da chave RSA definido como 2048 .
11. Preencha as seleções restantes como desejar e, em seguida, selecione criar .
Configurar o conjunto de criptografia de disco

1. Procure por conjuntos de criptografia de disco e selecione-o.
2. Na folha conjuntos de criptografia de disco , selecione + Adicionar .
3. Selecione seu grupo de recursos, nomeie o conjunto de criptografia e selecione a mesma região que o
cofre de chaves.
4. Para tipo de criptografia , selecione criptografia em repouso com uma chave gerenciada pelo
cliente .
NOTE
disco.
5. Selecione clique para selecionar uma chave .

6. Selecione o cofre de chaves e a chave que você criou anteriormente, bem como a versão.
7. Pressione Selecionar .
8. Selecione Examinar + Criar e Criar .
9. Abra o conjunto de criptografia de disco depois de concluir a criação e selecione o alerta que aparece.
Duas notificações devem ser exibidas e bem sucedidos. Isso permite que você use o conjunto de
criptografia de disco com o cofre de chaves.

Você deve implantar uma nova VM para habilitar a criptografia no host, ela não pode ser habilitada em VMs
existentes.
1. Pesquise máquinas vir tuais e selecione + Adicionar para criar uma VM.
2. Crie uma nova máquina virtual, selecione uma região apropriada e um tamanho de VM com suporte.
3. Preencha os outros valores na folha básica como desejar e, em seguida, vá para a folha discos .
4. Na folha discos , selecione Sim para criptografia no host .
5. Faça as seleções restantes como desejar.
6. Conclua o processo de implantação da VM, faça seleções que se ajustam ao seu ambiente.
Agora você implantou uma VM com criptografia no host habilitado, todos os discos associados serão
criptografados usando a criptografia no host.
Próximas etapas
Exemplos de modelo do Azure Resource Manager
Usar o módulo Azure PowerShell para habilitar a
criptografia de ponta a ponta usando criptografia
no host
sobre criptografia no host, bem como outros tipos de criptografia de disco gerenciado, consulte criptografia em
criptografia de host de ponta a ponta para os dados da VM.
Restrições
automaticamente.
Oeste dos EUA
Oeste dos EUA 2
Leste dos EUA
Leste dos EUA 2
Centro do Canadá
Leste do Canadá
França central
Europa Ocidental
Norte da Europa
Leste do Japão
Oeste do Japão

criptografados)

(versão prévia)

Você também pode encontrar os tamanhos de VM programaticamente. Para saber como recuperá-los
programaticamente, consulte a seção localizando tamanhos de VM com suporte .
Pré-requisitos
Criar um Azure Key Vault e DiskEncryptionSet
Depois que o recurso estiver habilitado, você precisará configurar um Azure Key Vault e um DiskEncryptionSet,
se ainda não tiver feito isso.
1. Verifique se você instalou a versão mais recente do Azure PowerShell e se está conectado a uma conta do
Azure com Connect-AzAccount


$desConfig=New-AzDiskEncryptionSetConfig -Location $LocationName -SourceVaultId $keyVault.ResourceId
-KeyUrl $key.Key.Kid -IdentityType SystemAssigned
$des=New-AzDiskEncryptionSet -Name $diskEncryptionSetName -ResourceGroupName $ResourceGroupName -

InputObject $desConfig
NOTE

Habilitar a criptografia no host para discos anexados a VMs e

conjuntos de dimensionamento de máquinas virtuais
Você pode habilitar a criptografia no host definindo uma nova propriedade EncryptionAtHost em securityProfile
de VMs ou conjuntos de dimensionamento de máquinas virtuais usando a API versão 2020-06-01 e superior.
"securityProfile": { "encryptionAtHost": "true" }
Exemplos
Crie uma VM com criptografia no host habilitado com chaves gerenciadas pelo cliente.
Crie uma VM com discos gerenciados usando o URI de recurso do DiskEncryptionSet criado anteriormente para
criptografar o cache do sistema operacional e discos de dados com chaves gerenciadas pelo cliente. Os discos
temporários são criptografados com chaves gerenciadas pela plataforma.
$diskEncryptionSetName="yourdiskEncryptionSetName"


# Enable encryption at host by specifying EncryptionAtHost parameter
$VirtualMachine = New-AzVMConfig -VMName $VMName -VMSize $VMSize -EncryptionAtHost


# Enable encryption with a customer managed key for OS disk by setting DiskEncryptionSetId property
$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -Name $($VMName +"_OSDisk") -DiskEncryptionSetId

$diskEncryptionSet.Id -CreateOption FromImage
# Add a data disk encrypted with a customer managed key by setting DiskEncryptionSetId property

StorageAccountType Premium_LRS -CreateOption Empty -Lun 0 -DiskEncryptionSetId $diskEncryptionSet.Id
New-AzVM -ResourceGroupName $ResourceGroupName -Location $LocationName -VM $VirtualMachine -Verbose
Crie uma VM com criptografia no host habilitado com chaves gerenciadas pela plataforma.
Crie uma VM com criptografia no host habilitada para criptografar o cache de discos de sistema
operacional/dados e discos temporários com chaves gerenciadas pela plataforma.


$VirtualMachine = New-AzVMConfig -VMName $VMName -VMSize $VMSize -EncryptionAtHost

$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -Name $($VMName +"_OSDisk") -CreateOption FromImage

StorageAccountType Premium_LRS -CreateOption Empty -Lun 0
New-AzVM -ResourceGroupName $ResourceGroupName -Location $LocationName -VM $VirtualMachine
Atualize uma VM para habilitar a criptografia no host.
$VM = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $VMName
Stop-AzVM -ResourceGroupName $ResourceGroupName -Name $VMName -Force
Update-AzVM -VM $VM -ResourceGroupName $ResourceGroupName -EncryptionAtHost $true
Verificar o status da criptografia no host de uma VM
$VM = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $VMName
$VM.SecurityProfile.EncryptionAtHost
Crie um conjunto de dimensionamento de máquinas virtuais com criptografia no host habilitado com chaves
gerenciadas pelo cliente.
Crie um conjunto de dimensionamento de máquinas virtuais com discos gerenciados usando o URI de recurso
do DiskEncryptionSet criado anteriormente para criptografar o cache do sistema operacional e dos discos de
dados com chaves gerenciadas pelo cliente. Os discos temporários são criptografados com chaves gerenciadas
pela plataforma.


'Automatic' -EncryptionAtHost


# Enable encryption with a customer managed key for the OS disk by setting DiskEncryptionSetId property
$VMSS = Set-AzVmssStorageProfile $VMSS -OsDiskCreateOption "FromImage" -DiskEncryptionSetId

$diskEncryptionSet.Id -ImageReferenceOffer 'WindowsServer' -ImageReferenceSku '2012-R2-Datacenter' -
ImageReferenceVersion latest -ImageReferencePublisher 'MicrosoftWindowsServer'

# Add a data disk encrypted with a customer managed key by setting DiskEncryptionSetId property

StorageAccountType Premium_LRS -DiskEncryptionSetId $diskEncryptionSet.Id
gerenciadas pela plataforma.
Crie um conjunto de dimensionamento de máquinas virtuais com criptografia no host habilitado para
criptografar o cache de discos de sistema operacional/dados e discos temporários com chaves gerenciadas pela
plataforma.


'Automatic' -EncryptionAtHost

$VMSS = Set-AzVmssStorageProfile $VMSS -OsDiskCreateOption "FromImage" -ImageReferenceOffer 'WindowsServer'

-ImageReferenceSku '2012-R2-Datacenter' -ImageReferenceVersion latest -ImageReferencePublisher
'MicrosoftWindowsServer'


StorageAccountType Premium_LRS

New-AzVmss -VirtualMachineScaleSet $VMSS -ResourceGroupName $ResourceGroupName -VMScaleSetName

$VMScaleSetName
Atualize um conjunto de dimensionamento de máquinas virtuais para habilitar a criptografia no host.
$VMSS = Get-AzVmss -ResourceGroupName $ResourceGroupName -Name $VMScaleSetName
Update-AzVmss -VirtualMachineScaleSet $VMSS -Name $VMScaleSetName -ResourceGroupName $ResourceGroupName -

EncryptionAtHost $true
Verificar o status da criptografia no host para um conjunto de dimensionamento de máquinas virtuais
$VMSS = Get-AzVmss -ResourceGroupName $ResourceGroupName -Name $VMScaleSetName
$VMSS.VirtualMachineProfile.SecurityProfile.EncryptionAtHost
Localizando tamanhos de VM com suporte
Não há suporte para tamanhos de VM herdados. Você pode encontrar a lista de tamanhos de VM com suporte
por meio de:
Chamar a API de SKUs de recursos e verificar se a EncryptionAtHostSupported funcionalidade está definida como
true .
{
"resourceType": "virtualMachines",
"name": "Standard_DS1_v2",
"tier": "Standard",
"size": "DS1_v2",
"family": "standardDSv2Family",
"locations": [
"CentralUSEUAP"
],
"capabilities": [
{
"name": "EncryptionAtHostSupported",
"value": "True"
}
]
}
Ou, chamando o cmdlet Get-AzComputeResourceSku do PowerShell.
$vmSizes=Get-AzComputeResourceSku | where{$_.ResourceType -eq 'virtualMachines' -and

$_.Locations.Contains('CentralUSEUAP')}
foreach($vmSize in $vmSizes)
{
foreach($capability in $vmSize.capabilities)
{
if($capability.Name -eq 'EncryptionAtHostSupported' -and $capability.Value -eq 'true')
{
$vmSize
}
}
Próximas etapas
Agora que você criou e configurou esses recursos, você pode usá-los para proteger seus discos gerenciados. O
link a seguir contém scripts de exemplo, cada um com um cenário respectivo, que você pode usar para proteger
seus discos gerenciados.
Use o CLI do Azure para habilitar a criptografia de
ponta a ponta usando a criptografia no host
sobre criptografia no host, bem como outros tipos de criptografia de disco gerenciado, consulte criptografia em
criptografia de host de ponta a ponta para os dados da VM.
Restrições
automaticamente.
Oeste dos EUA
Oeste dos EUA 2
Leste dos EUA
Leste dos EUA 2
Centro do Canadá
Leste do Canadá
França central
Europa Ocidental
Norte da Europa
Leste do Japão
Oeste do Japão


criptografados)

(versão prévia)

Você também pode encontrar os tamanhos de VM programaticamente. Para saber como recuperá-los
programaticamente, consulte a seção localizando tamanhos de VM com suporte .
Pré-requisitos
Criar um Azure Key Vault e DiskEncryptionSet
Depois que o recurso estiver habilitado, você precisará configurar um Azure Key Vault e um DiskEncryptionSet,
se ainda não tiver feito isso.
1. Certifique-se de que você instalou a versão mais recente da CLI do Azure e entrou em uma conta do
Azure com az login.
IMPORTANT
Não use “camel case” (misturar maiúsculas e minúsculas). Isso pode causar problemas ao atribuir discos adicionais
ao recurso no portal do Azure.
keyName=yourKeyName

soft-delete true
keyVaultId=$(az keyvault show --name $keyVaultName --query [id] -o tsv)
keyVaultKeyUrl=$(az keyvault key show --vault-name $keyVaultName --name $keyName --query [key.kid] -o
tsv)
az disk-encryption-set create -n $diskEncryptionSetName -l $location -g $rgName --source-vault

$keyVaultId --key-url $keyVaultKeyUrl
NOTE


unwrapkey get
Exemplos
Crie uma VM com criptografia no host habilitado com chaves gerenciadas pelo cliente.
Crie uma VM com discos gerenciados usando o URI de recurso do DiskEncryptionSet criado anteriormente para
criptografar o cache do sistema operacional e discos de dados com chaves gerenciadas pelo cliente. Os discos
temporários são criptografados com chaves gerenciadas pela plataforma.
rgName=yourRGName
vmName=yourVMName
location=eastus
vmSize=Standard_DS2_v2
image=UbuntuLTS
az vm create -g $rgName \
-n $vmName \
-l $location \
--encryption-at-host \
--image $image \
--size $vmSize \
--os-disk-encryption-set $diskEncryptionSetId \
--data-disk-sizes-gb 128 128 \
--data-disk-encryption-sets $diskEncryptionSetId $diskEncryptionSetId
Crie uma VM com criptografia no host habilitado com chaves gerenciadas pela plataforma.
Crie uma VM com criptografia no host habilitada para criptografar o cache de discos de sistema
operacional/dados e discos temporários com chaves gerenciadas pela plataforma.
rgName=yourRGName
vmName=yourVMName
location=eastus
vmSize=Standard_DS2_v2
image=UbuntuLTS
az vm create -g $rgName \
-n $vmName \
-l $location \
--image $image \
--size $vmSize \
Atualize uma VM para habilitar a criptografia no host.
rgName=yourRGName
vmName=yourVMName
az vm update -n $vmName \
-g $rgName \
--set securityProfile.encryptionAtHost=true
Verificar o status da criptografia no host de uma VM
rgName=yourRGName
vmName=yourVMName
az vm show -n $vmName \
-g $rgName \
--query [securityProfile.encryptionAtHost] -o tsv
Crie um conjunto de dimensionamento de máquinas virtuais com discos gerenciados usando o URI de recurso
do DiskEncryptionSet criado anteriormente para criptografar o cache do sistema operacional e dos discos de
dados com chaves gerenciadas pelo cliente. Os discos temporários são criptografados com chaves gerenciadas
pela plataforma.
rgName=yourRGName
location=westus2
image=UbuntuLTS
az vmss create -g $rgName \

-n $vmssName \
--image UbuntuLTS \
--upgrade-policy automatic \
--os-disk-encryption-set $diskEncryptionSetId \
--data-disk-encryption-sets $diskEncryptionSetId $diskEncryptionSetId
gerenciadas pela plataforma.
Crie um conjunto de dimensionamento de máquinas virtuais com criptografia no host habilitado para
criptografar o cache de discos de sistema operacional/dados e discos temporários com chaves gerenciadas pela
plataforma.
rgName=yourRGName
location=westus2
image=UbuntuLTS
az vmss create -g $rgName \

-n $vmssName \
--image UbuntuLTS \
--upgrade-policy automatic \
Atualize um conjunto de dimensionamento de máquinas virtuais para habilitar a criptografia no host.
rgName=yourRGName
vmssName=yourVMName
az vmss update -n $vmssName \

-g $rgName \
--set virtualMachineProfile.securityProfile.encryptionAtHost=true
Verificar o status da criptografia no host para um conjunto de dimensionamento de máquinas virtuais

rgName=yourRGName
vmssName=yourVMName
az vmss show -n $vmssName \

-g $rgName \
--query [virtualMachineProfile.securityProfile.encryptionAtHost] -o tsv
Localizando tamanhos de VM com suporte

Não há suporte para tamanhos de VM herdados. Você pode encontrar a lista de tamanhos de VM com suporte
por meio de:
Chamar a API de SKUs de recursos e verificar se a EncryptionAtHostSupported funcionalidade está definida como
true .
{
"resourceType": "virtualMachines",
"tier": "Standard",
"size": "DS1_v2",
"family": "standardDSv2Family",
"locations": [
"CentralUSEUAP"
],
"capabilities": [
{
"name": "EncryptionAtHostSupported",
"value": "True"
}
]
}
Ou, chamando o cmdlet Get-AzComputeResourceSku do PowerShell.

{
{
if($capability.Name -eq 'EncryptionAtHostSupported' -and $capability.Value -eq 'true')
{
$vmSize
}
}
Próximas etapas
Agora que você criou e configurou esses recursos, você pode usá-los para proteger seus discos gerenciados. O
link a seguir contém scripts de exemplo, cada um com um cenário respectivo, que você pode usar para proteger
seus discos gerenciados.
Usar o portal do Azure para habilitar a criptografia
dupla em repouso para discos gerenciados
O Armazenamento em Disco do Azure dá suporte à criptografia dupla em repouso para discos gerenciados.
Para obter informações conceituais sobre a criptografia dupla em repouso, bem como outros tipos de
criptografia de disco gerenciado, consulte a seção criptografia dupla em repouso do nosso artigo sobre
criptografia de disco.
Introdução
IMPORTANT
Você deve usar o link fornecido para acessar o portal do Azure. A criptografia dupla em repouso não está visível
no momento no portal do Azure público sem usar o link.
2. Procure e selecione conjuntos de criptografia de disco .
3. Selecione + Adicionar .
4. Selecione uma das regiões com suporte.
5. Para tipo de criptografia , selecione criptografia dupla com chaves gerenciadas por plataforma e
NOTE
disco.
6. Preencha as informações restantes.
7. Selecione um Azure Key Vault e uma chave ou crie um novo, se necessário.
NOTE
Se você criar uma instância de Key Vault, deverá habilitar a exclusão reversível e limpar a proteção. Essas
configurações são obrigatórias ao usar um Key Vault para criptografar discos gerenciados e protegê-lo contra a
perda de dados devido à exclusão acidental.
8. Selecione Criar .
9. Navegue até o conjunto de criptografia de disco que você criou e selecione o erro que é exibido. Isso irá
configurar o conjunto de criptografia de disco para funcionar.
Uma notificação deve aparecer e ter sucesso. Isso permitirá que você use o conjunto de criptografia de
disco com o cofre de chaves.
10. Navegue até o disco.

11. Selecione criptografia .
12. Para tipo de criptografia , selecione criptografia dupla com chaves gerenciadas por plataforma e
13. Selecione o conjunto de criptografia de disco.
Agora você habilitou a criptografia dupla em repouso no disco gerenciado.

Próximas etapas
Azure PowerShell-habilitar chaves gerenciadas pelo cliente com discos gerenciados por criptografia do lado
do servidor
Habilitar chaves gerenciadas pelo cliente com criptografia do lado do servidor-exemplos
Usar o módulo Azure PowerShell para habilitar a
criptografia dupla em repouso para discos
gerenciados
Pré-requisitos
Instale a versão mais recente do Azure PowerShelle entre em uma conta do Azure usando Connect-AzAccount.
Introdução
$LocationName="westus2"

$LocationName -EnableSoftDelete -EnablePurgeProtection
2. Crie um DiskEncryptionSet com EncryptionType definido como

EncryptionAtRestWithPlatformAndCustomerKeys. Use a versão de API 2020-05-01 no modelo de Azure
Resource Manager (ARM).
New-AzResourceGroupDeployment -ResourceGroupName $ResourceGroupName `

-TemplateUri "https://raw.githubusercontent.com/Azure-Samples/managed-disks-powershell-getting-
started/master/DoubleEncryption/CreateDiskEncryptionSetForDoubleEncryption.json" `
-diskEncryptionSetName $diskEncryptionSetName `
-keyVaultId $keyVault.ResourceId `
-keyVaultKeyUrl $key.Key.Kid `
-encryptionType "EncryptionAtRestWithPlatformAndCustomerKeys" `
-region $LocationName

NOTE
$des=Get-AzDiskEncryptionSet -name $diskEncryptionSetName -ResourceGroupName $ResourceGroupName

Próximas etapas
Azure PowerShell-habilitar chaves gerenciadas pelo cliente com discos gerenciados por criptografia do lado
do servidor
Usar o CLI do Azure para habilitar a criptografia
dupla em repouso para discos gerenciados
Pré-requisitos
Instale o CLI do Azure mais recente e faça logon em uma conta do Azure com AZ login.
Introdução
keyName=yourKeyName

soft-delete true
2. Crie um DiskEncryptionSet com EncryptionType definido como

EncryptionAtRestWithPlatformAndCustomerKeys. Use a versão de API 2020-05-01 no modelo de Azure
Resource Manager (ARM).
az deployment group create -g $rgName \

--template-uri "https://raw.githubusercontent.com/Azure-Samples/managed-disks-powershell-getting-
started/master/DoubleEncryption/CreateDiskEncryptionSetForDoubleEncryption.json" \
--parameters "diskEncryptionSetName=$diskEncryptionSetName"
"encryptionType=EncryptionAtRestWithPlatformAndCustomerKeys" "keyVaultId=$keyVaultId"
"keyVaultKeyUrl=$keyVaultKeyUrl" "region=$location"

NOTE


unwrapkey get
Próximas etapas
Habilitar chaves gerenciadas pelo cliente com criptografia do lado do servidor-exemplos
Cenários do Azure Disk Encryption em VMs Linux
O Azure Disk Encryption para VMs (máquinas virtuais) do Linux usa o recurso DM-Crypt do Linux para fornecer
criptografia de disco completa do disco do sistema operacional e discos de dados. Além disso, ele fornece
criptografia do disco temporário ao usar o recurso EncryptFormatAll.
O Azure Disk Encryption é integrado ao Azure Key Vault para ajudar você a controlar e gerenciar as chaves de
criptografia de disco e os segredos. Para obter uma visão geral do serviço, confira Azure Disk Encryption para
VMs Linux.
Você só pode aplicar a criptografia de disco a máquinas virtuais de tamanhos de VM e sistemas operacionais
com suporte. Você também deve atender aos seguintes pré-requisitos:
Requisitos adicionais para VMs
Requisitos de rede
Em todos os casos, você deve tirar um instantâneo e/ou criar um backup antes que os discos sejam
criptografados. Os backups garantem que uma opção de recuperação seja possível, no caso de uma falha
inesperada durante a criptografia. VMs com discos gerenciados exigem um backup antes que a criptografia
ocorra. Depois que um backup é feito, você poderá usar o cmdlet Set-AzVMDiskEncryptionExtension para
criptografar discos gerenciados, especificando o parâmetro -skipVmBackup. Para obter mais informações sobre
como fazer backup e restaurar VMs criptografadas, consulte o artigo Backup do Microsoft Azure.
WARNING
continuar usando essa opção para criptografar a VM. Confira Azure Disk Encryption com o Azure AD (versão
anterior) para detalhes.
Ao criptografar volumes do sistema operacional Linux, a VM deve ser considerada não disponível. É altamente
recomendável evitar logons SSH enquanto a criptografia estiver em andamento para evitar problemas ao bloquear
os arquivos abertos que precisarão ser acessados durante o processo de criptografia. Para verificar o progresso,
use o cmdlet Get-AzVMDiskEncryptionStatus do PowerShell ou o comando vm encryption show da CLI. Esse
processo deve levar algumas horas para um volume do sistema operacional de 30 GB, mais algum tempo para
criptografar volumes de dados. O tempo para criptografia de volume de dados será proporcional ao tamanho e à
quantidade dos volumes de dados, a menos que a opção EncryptFormatAll seja usada.
Desabilitar criptografia nas VMs do Linux tem suporte apenas para volumes de dados. Não haverá suporte em
dados ou volumes de SO, se o volume de SO tiver sido criptografado.
Instalar ferramentas e conectar-se ao Azure

O Azure Disk Encryption pode ser habilitado e gerenciado por meio da CLI do Azure e do Azure PowerShell. Para
fazer isso, você deve instalar as ferramentas localmente e conectar-se à sua assinatura do Azure.
CLI do Azure
O CLI 2.0 do Azure é uma ferramenta de linha de comando para gerenciar recursos do Azure. A CLI é projetada
para consultar dados com flexibilidade, dar suporte a operações de longa execução como processos
desbloqueados e facilitar o script. Você pode instalá-la localmente seguindo as etapas em Instalar a CLI do
Azure.
Para Entrar na assinatura do Azure com a CLI do Azure, use o comando az login.
az login
Se você deseja selecionar um locatário a ser usado para entrar, use:
az login --tenant <tenant>
Se você tiver várias assinaturas e quiser especificar uma lista específica, obtenha a lista de assinaturas com az
account list e especifique com az account set.
az account list
az account set --subscription "<subscription name or ID>"
Para obter mais informações, consulte Introdução à CLI do Azure 2.0.

Azure PowerShell
O módulo az do Azure PowerShell fornece um conjunto de cmdlets que usa o modelo do Azure Resource
Manager para gerenciar os recursos do Azure. Você pode usá-lo em seu navegador com o Azure Cloud Shell ou
você pode instalá-lo em seu computador local usando as instruções em Instalar o módulo do Azure PowerShell.
Se você já tiver instalado localmente, verifique se que você usar a versão mais recente do SDK do Azure
PowerShell para configurar o Azure Disk Encryption. Baixe a última versão do Azure PowerShell.
Para Entrar em sua conta do Azure com o Azure PowerShell, use o cmdlet Connect-AzAccount.
Connect-AzAccount
Se você tiver várias assinaturas e quiser especificar uma, use o cmdlet Get-AzSubscription para listá-las, seguido
pelo cmdlet Set-AzContext:
Set-AzContext -Subscription -Subscription <SubscriptionId>
A execução do cmdlet Get-AzContext verificará se a assinatura correta foi selecionada.

Para confirmar que os cmdlets do Azure Disk Encryption estão instalados, use o cmdlet Get-command:
Get-command *diskencryption*
Para saber mais, confira Introdução ao Azure PowerShell.
Habilitar a criptografia em uma VM Linux existente ou em execução

Nesse cenário, é possível habilitar a criptografia usando o modelo do Resource Manager, os cmdlets do
PowerShell ou os comandos da CLI. Se você precisar de informações de esquema para a extensão de máquina
virtual, consulte o Azure Disk Encryption para extensão do Linux artigo.
IMPORTANT
É obrigatório tirar um instantâneo e/ou fazer backup de uma instância de VM baseada em disco gerenciado fora do Azure
Disk Encryption e antes de habilitá-lo. Um instantâneo do disco gerenciado pode ser obtido do portal ou por meio do
Backup do Azure. Backups asseguram que uma opção de recuperação é possível no caso de qualquer falha inesperada
durante a criptografia. Depois que um backup é feito, o cmdlet Set-AzVMDiskEncryptionExtension pode ser usado para
criptografar discos gerenciados especificando o parâmetro -skipVmBackup. O comando Set-
AzVMDiskEncryptionExtension falhará nas VMs baseadas em disco gerenciado até que um backup seja feito e esse
parâmetro tenha sido especificado.
Criptografar ou desabilitar a criptografia pode fazer com que a VM seja reiniciada.
Habilitar criptografia em uma VM Linux existente ou em execução usando a CLI do Azure

É possível habilitar a criptografia de disco no VHD criptografado, instalando e usando a ferramenta de linha de
comando da CLI do Azure. Você pode usá-lo em seu navegador com o Azure Cloud Shell, ou você pode instalá-
lo em seu computador local e usá-lo em qualquer sessão do PowerShell. Para habilitar a criptografia em VMs
Linux existentes ou em execução no Azure, use os seguintes comandos da CLI:
Use o comando az vm encryption enable para habilitar a criptografia em uma máquina virtual em execução no
Azure.
Criptografar uma VM em execução:
az vm encryption enable --resource-group "MyVirtualMachineResourceGroup" --name "MySecureVM" --disk-

encryption-keyvault "MySecureVault" --volume-type [All|OS|Data]
Criptografar uma VM em execução usando KEK:

encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --key-encryption-keyvault
"MySecureVaultContainingTheKEK" --volume-type [All|OS|Data]
NOTE
A sintaxe para o valor do parâmetro diskvacryption-keyvault é a cadeia de caracteres do identificador
completo:/subscriptions/[subscription-id-guid]/resourceGroups/[resource-group-
name]/providers/Microsoft.KeyVault/vaults/[keyvault-name]
A sintaxe para o valor do parâmetro key-encryption-key é o URI completo para KEK, como em: https://[keyvault-
name].vault.azure.net/keys/[kekname]/[kek-unique-id]
Verificar se os discos estão criptografados: Para verificar o status de criptografia de uma VM, use o
comando az vm encryption show.
az vm encryption show --name "MySecureVM" --resource-group "MyVirtualMachineResourceGroup"
Desabilitar criptografia: para desabilitar a criptografia, use o comando az vm encryption disable.

Desabilitar criptografia somente é permitida em volumes de Dados para VMs do Linux.
az vm encryption disable --name "MySecureVM" --resource-group "MyVirtualMachineResourceGroup" --

volume-type "data"
Habilitar criptografia em uma VM Linux existente ou em execução usando o PowerShell

Use o cmdlet Set-AzVMDiskEncryptionExtension para habilitar a criptografia em uma máquina virtual em
execução no Azure. Tire um instantâneo e/ou faça backup da VM com o Backup do Azure antes que os discos
sejam criptografados. O parâmetro -skipVmBackup já está especificado nos scripts do PowerShell para
criptografar uma VM Linux em execução.
Criptografar uma VM em execução: o script abaixo inicializa as variáveis e executa o cmdlet Set-
AzVMDiskEncryptionExtension. O grupo de recursos, a VM e o cofre de chaves já foram criados como
pré-requisitos. Substitua MyVirtualMachineResourceGroup, MySecureVM e MySecureVault por seus
valores. Modifique o parâmetro -VolumeType para especificar quais discos você está criptografando.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MySecureVM';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$sequenceVersion = [Guid]::NewGuid();
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $vmName -

DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId -
VolumeType '[All|OS|Data]' -SequenceVersion $sequenceVersion -skipVmBackup;
Criptografar uma VM em execução usando KEK: Talvez seja necessário adicionar o parâmetro -
VolumeType se você estiver criptografando discos de dados e não o disco de SO.
$vmName = 'MyExtraSecureVM';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;

KeyEncryptionKeyUrl $keyEncryptionKeyUrl -KeyEncryptionKeyVaultId $KeyVaultResourceId -VolumeType
'[All|OS|Data]' -SequenceVersion $sequenceVersion -skipVmBackup;
NOTE
Verificar se os discos estão criptografados: para verificar o status de criptografia de uma VM, use o
cmdlet Get-AzVmDiskEncryptionStatus.
Get-AzVmDiskEncryptionStatus -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName 'MySecureVM'
Desabilitar criptografia de disco: para desabilitar a criptografia, use o cmdlet Disable-

AzVMDiskEncryption. Desabilitar criptografia somente é permitida em volumes de Dados para VMs do
Linux.
Disable-AzVMDiskEncryption -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName 'MySecureVM'
Habilitar criptografia em uma VM Linux existente ou em execução com um modelo

Você pode habilitar a criptografia de disco em uma VM Linux existente ou em execução no Azure usando o
1. Clique em Implantar no Azure no modelo de início rápido do Azure.
2. Selecione a assinatura, o grupo de recursos, o local do grupo de recursos, os parâmetros, os termos
legais e o contrato. Clique em Criar para habilitar a criptografia na VM em execução ou existente.
A tabela a seguir lista os parâmetros de modelo do Resource Manager existente para VMs em execução ou
existentes:
PA RÂ M ET RO DESC RIÇ Ã O
vmName Nome da VM para executar a operação de criptografia.
keyVaultName Nome do cofre de chaves em que a chave de criptografia

deve ser carregada. É possível obtê-lo usando o cmdlet
(Get-AzKeyVault -ResourceGroupName
<MyKeyVaultResourceGroupName>). Vaultname
ou o comando
az keyvault list --resource-group
"MyKeyVaultResourceGroupName"
da CLI do Azure.
keyVaultResourceGroup Nome do grupo de recursos que contém o cofre de chaves.
keyEncryptionKeyURL URL da chave de criptografia de chave usada para

criptografar a chave de criptografia. Esse parâmetro será
opcional se você selecionar nokek na lista suspensa
UseExistingKek. Se selecionar kek na lista suspensa
UseExistingKek, você deverá inserir o valor
keyEncryptionKeyURL.
volumeType Tipo de volume em que a operação de criptografia é

executada. Os valores válidos são OS, Data e All.
forceUpdateTag Passe um valor exclusivo como um GUID sempre que a

execução da operação precise ser forçada.
local Local de todos os recursos.
Para obter mais informações sobre como configurar o modelo de criptografia de disco de VM Linux, confira
Azure Disk Encryption para Linux.
Usar o recurso EncryptFormatAll para discos de dados em VMs Linux

O parâmetro Encr yptFormatAll reduz o tempo de criptografia dos discos de dados do Linux. As partições que
atendem a determinados critérios serão formatadas junto com seus sistemas de arquivos atuais e remontadas
para o local no qual estavam antes da execução do comando. Se você quiser excluir um disco de dados que
atenda aos critérios, será possível desmontá-lo antes de executar o comando.
Depois de executar esse comando, todas as unidades que foram montadas anteriormente serão formatadas e a
camada de criptografia será iniciada sobre a unidade agora vazia. Quando essa opção for selecionada, o disco
temporário anexado à VM também será criptografado. Se o disco temporário for reiniciado, ele será
reformatado e criptografado novamente para a VM pela solução do Azure Disk Encryption na próxima
oportunidade. Depois que o disco de recursos é criptografado, o agente Linux do Microsoft Azure não poderá
gerenciar o disco de recursos e habilitar o arquivo de permuta, mas você poderá configurar manualmente o
arquivo de permuta.
WARNING
O EncryptFormatAll não deverá ser usado quando houver dados necessários nos volumes de dados de uma VM. É
possível excluir discos da criptografia, desmontando-os. Primeiro será necessário testar o EncryptFormatAll, primeiro em
uma VM de teste, e compreender o parâmetro de recurso e a respectiva implicação antes de testá-lo na VM de produção.
A opção EncryptFormatAll formata o disco de dados e todos os dados nele serão perdidos. Antes de prosseguir, verifique
se os discos que deseja excluir estão corretamente desmontados.
Se você estiver configurando esse parâmetro ao atualizar as configurações de criptografia, isso poderá levar a um reinício
antes da criptografia real. Nesse caso, é recomendável também remover o disco que você não quer que seja formatado no
arquivo fstab. Da mesma forma, é necessário adicionar a partição que deseja criptografar ao arquivo fstab antes de iniciar
a operação de criptografia.
Critérios do EncryptFormatAll
O parâmetro passa por todas as partições e criptografa-as desde que atendam a todos os critérios abaixo:
Não é uma partição de inicialização/SO/raiz
Ainda não está criptografado
Não é um volume BEK
Não é um volume RAID
Não é um volume LVM
Está montado
Criptografe os discos que compõem o volume RAID ou LVM em vez do volume RAID ou LVM.
Usar o parâmetro EncryptFormatAll com a CLI do Azure
Use o comando az vm encryption enable para habilitar a criptografia em uma máquina virtual em execução no
Azure.
Criptografe uma VM em execução usando Encr yptFormatAll:

encryption-keyvault "MySecureVault" --volume-type "data" --encrypt-format-all
Usar o parâmetro EncryptFormatAll com um cmdlet do PowerShell

Use o cmdlet Set-AzVMDiskEncryptionExtension com o parâmetro EncryptFormatAll.
Criptografe uma VM em execução usando Encr yptFormatAll: por exemplo, o script abaixo inicializa as
variáveis e executa o cmdlet Set-AzVMDiskEncryptionExtension com o parâmetro EncryptFormatAll. O grupo de
recursos, a VM e o cofre de chaves já foram criados como pré-requisitos. Substitua
MyVirtualMachineResourceGroup, MySecureVM e MySecureVault por seus valores.
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $vmName -DiskEncryptionKeyVaultUrl

$diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId -VolumeType "data" -
EncryptFormatAll
Usar o parâmetro EncryptFormatAll com LVM (Gerenciador de Volume Lógico )

É recomendável uma configuração LVM-on-crypt. Para todos os exemplos a seguir, substitua o caminho do
dispositivo e os pontos de montagem pelo que melhor adequar-se ao seu caso de uso. Essa configuração pode
ser feita da seguinte maneira:
1. Adicione os discos de dados que irão compor a VM.
2. Formatar, montar e adicionar esses discos ao arquivo fstab.
3. Escolha um padrão de partição, crie uma partição que abranja toda a unidade e, em seguida, formate a
partição. Usamos symlinks gerados pelo Azure aqui. O uso de symlinks evita problemas relacionados à
alteração de nomes de dispositivos. Para obter mais informações, consulte o artigo Solucionar problemas
de Nomes do Dispositivo.
parted /dev/disk/azure/scsi1/lun0 mklabel gpt

parted -a opt /dev/disk/azure/scsi1/lun0 mkpart primary ext4 0% 100%
mkfs -t ext4 /dev/disk/azure/scsi1/lun0-part1
4. Monte os discos:
mount /dev/disk/azure/scsi1/lun0-part1 /mnt/mountpoint
Adicione ao arquivo fstab:
echo "/dev/disk/azure/scsi1/lun0-part1 /mnt/mountpoint ext4 defaults,nofail 0 2" >> /etc/fstab
5. Execute o cmdlet Set-AzVMDiskEncryptionExtension do Azure PowerShell com -EncryptFormatAll para

criptografar esses discos.
$KeyVault = Get-AzKeyVault -VaultName "MySecureVault" -ResourceGroupName "MySecureGroup"
Set-AzVMDiskEncryptionExtension -ResourceGroupName "MySecureGroup" -VMName "MySecureVM" -

DiskEncryptionKeyVaultUrl $KeyVault.VaultUri -DiskEncryptionKeyVaultId $KeyVault.ResourceId -
EncryptFormatAll -SkipVmBackup -VolumeType Data
Se você quiser usar uma KEK (chave de criptografia de chave), passe o URI de sua KEK e o ResourceID do
seu cofre de chaves para os parâmetros -KeyEncryptionKeyUrl e -KeyEncryptionKeyVaultId,
respectivamente:
$KeyVault = Get-AzKeyVault -VaultName "MySecureVault" -ResourceGroupName "MySecureGroup"
$KEKKeyVault = Get-AzKeyVault -VaultName "MyKEKVault" -ResourceGroupName "MySecureGroup"
$KEK = Get-AzKeyVaultKey -VaultName "myKEKVault" -KeyName "myKEKName"

DiskEncryptionKeyVaultUrl $KeyVault.VaultUri -DiskEncryptionKeyVaultId $KeyVault.ResourceId -
EncryptFormatAll -SkipVmBackup -VolumeType Data -KeyEncryptionKeyUrl $$KEK.id -
KeyEncryptionKeyVaultId $KEKKeyVault.ResourceId
6. Configure a LVM sobre esses novos discos. Observe que as unidades criptografadas serão
desbloqueadas após a VM concluir a inicialização. Portanto, a montagem de LVM também deverá ser
subsequentemente atrasada.
VMs criadas usando as chaves de criptografia e o VHD criptografado

pelo cliente
Nesse cenário, é possível habilitar a criptografia usando cmdlets do PowerShell ou comandos da CLI.
Use as instruções nos mesmos scripts de criptografia do Disco do Azure para preparar imagens previamente
criptografadas que podem ser usadas no Azure. Depois que a imagem for criada, você poderá usar as etapas na
próxima seção para criar uma VM do Azure criptografada.
Preparar um VHD Linux previamente criptografado
IMPORTANT
É obrigatório tirar um instantâneo e/ou fazer backup de uma instância de VM baseada em disco gerenciado fora do Azure
Disk Encryption e antes de habilitá-lo. Um instantâneo do disco gerenciado pode ser obtido do portal ou pode ser usado
o Backup do Azure. Backups asseguram que uma opção de recuperação é possível no caso de qualquer falha inesperada
durante a criptografia. Depois que um backup é feito, o cmdlet Set-AzVMDiskEncryptionExtension pode ser usado para
criptografar discos gerenciados especificando o parâmetro -skipVmBackup. O comando Set-
AzVMDiskEncryptionExtension falhará nas VMs baseadas em disco gerenciado até que um backup seja feito e esse
parâmetro tenha sido especificado.
Criptografar ou desabilitar a criptografia pode fazer com que a VM seja reiniciada.
Usar o Azure PowerShell para criptografar VMs com VHDs previamente criptografados
É possível habilitar a criptografia de disco no VHD criptografado usando o cmdlet do PowerShell Set-
AzVMOSDisk. O exemplo abaixo fornece alguns parâmetros comuns.
$VirtualMachine = New-AzVMConfig -VMName "MySecureVM" -VMSize "Standard_A1"

$VirtualMachine = Set-AzVMOSDisk -VM $VirtualMachine -Name "SecureOSDisk" -VhdUri "os.vhd" Caching ReadWrite
-Linux -CreateOption "Attach" -DiskEncryptionKeyUrl
"https://mytestvault.vault.azure.net/secrets/Test1/514ceb769c984379a7e0230bddaaaaaa" -
DiskEncryptionKeyVaultId "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myresourcegroup/providers/Microsoft.KeyVault/vaults/mytestvault"
New-AzVM -VM $VirtualMachine -ResourceGroupName "MyVirtualMachineResourceGroup"
Habilitar criptografia em um disco de dados adicionado recentemente

É possível adicionar um novo disco de dados usando az vm disk attach ou por meio do portal do Azure. Antes
de poder criptografar, primeiro será necessário montar o disco de dados anexado recentemente. É necessário
solicitar a criptografia da unidade de dados, pois a unidade ficará inutilizável enquanto a criptografia estiver em
andamento.
Habilitar criptografia em um disco adicionado recentemente com CLI do Azure
Se a VM tiver sido previamente criptografada com "Todos", então o parâmetro --volume-type deverá
permanecer como "Todos". Todos inclui o sistema operacional e os discos de dados. Se a VM tiver sido
previamente criptografada com um tipo de volume de "SO", então o parâmetro --volume-type deverá ser
alterado para "Todos" para que o sistema operacional e o novo disco de dados sejam incluídos. Se a VM foi
criptografada apenas com o tipo de volume "Dados", ela poderá permanecer como "Dados", conforme
demonstrado abaixo. Adicionar e anexar um novo disco de dados a uma VM não é preparação suficiente para
criptografia. O disco anexado recentemente também deve ser formatado e montado adequadamente na VM
antes de habilitar a criptografia. No Linux, o disco deve ser montado em /etc/fstab com um nome do dispositivo
de bloco persistente.
Em contraste com a sintaxe do PowerShell, a CLI não exige que o usuário forneça uma versão de sequência
exclusiva ao habilitar a criptografia. A CLI gera e usa automaticamente o próprio valor de versão de sequência
exclusivo.
Criptografe volumes de dados de uma VM em execução:

encryption-keyvault "MySecureVault" --volume-type "Data"
Criptografe volumes de dados de uma VM em execução usando KEK:

"MySecureVaultContainingTheKEK" --volume-type "Data"
Habilitar criptografia em um disco adicionado recentemente com Azure PowerShell

Ao usar o PowerShell para criptografar um novo disco para Linux, uma nova versão da sequência deverá ser
especificada. A versão da sequência deverá ser exclusiva. O script abaixo gera um GUID para a versão da
sequência. Tire um instantâneo e/ou faça backup da VM com o Backup do Azure antes que os discos sejam
criptografados. O parâmetro -skipVmBackup já está especificado nos scripts do PowerShell para criptografar um
disco de dados recém-adicionado.
Criptografe volumes de dados de uma VM em execução: o script abaixo inicializa as variáveis e
executa o cmdlet Set-AzVMDiskEncryptionExtension. O grupo de recursos, a VM e o cofre de chaves já
devem ter sido criados como pré-requisitos. Substitua MyVirtualMachineResourceGroup, MySecureVM e
MySecureVault por seus valores. Valores aceitáveis para o parâmetro do tipo de volume são Todos, SO e
Dados. Se a VM tiver sido criptografada anteriormente com um tipo de volume de "SO" ou "Todos", então
o parâmetro -VolumeType deverá ser alterado para "Todos" para que o sistema operacional e o novo
disco de dados sejam incluídos.

VolumeType 'data' –SequenceVersion $sequenceVersion -skipVmBackup;
Criptografe volumes de dados de uma VM em execução usando KEK: Valores aceitáveis para o
parâmetro do tipo de volume são Todos, SO e Dados. Se a VM foi criptografada anteriormente com um
tipo de volume de "OS" ou “ALL”, então o parâmetro -VolumeType deverá ser alterado para All para que
ambos o sistema operacional e o novo disco de dados sejam incluídos.

'data' –SequenceVersion $sequenceVersion -skipVmBackup;
NOTE
A sintaxe para o valor do parâmetro disk-encryption-keyvault é a cadeia de caracteres do identificador completo:
/subscriptions/[subscription-id-guid]/resourceGroups/[KVresource-group-
Desabilitar criptografia para VMs do Linux

É possível desabilitar a criptografia usando o Azure PowerShell, a CLI do Azure ou com um modelo do Resource
Manager.
IMPORTANT
Desabilitar criptografia com Azure Disk Encryption em VMs do Linux tem suporte apenas para volumes de dados. Não
haverá suporte em dados ou volumes de SO, se o volume de SO tiver sido criptografado.
Desabilitar a criptografia de disco com o Azure PowerShell: para desabilitar a criptografia, use o
cmdlet Disable-AzVMDiskEncryption.
Disable-AzVMDiskEncryption -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName 'MySecureVM' [-

VolumeType DATA]
Desabilitar a criptografia com a CLI do Azure: para desabilitar a criptografia, use o comando az vm
encryption disable.

volume-type DATA
Desabilitar criptografia com um modelo do Resource Manager : Use o modelo Desabilitar a

criptografia em uma VM do Linux em execução para desabilitar a criptografia.
1. Clique em Implantar no Azure .
2. Selecione a assinatura, o grupo de recursos, o local, a VM, os termos legais e o contrato.
Cenários sem suporte

O Azure Disk Encryption não funciona para os seguintes cenários, recursos e tecnologia do Linux:
criptografia de VM de camada básica ou VMs criadas por meio do método de criação de VM clássico.
Desabilitação da criptografia em uma unidade do sistema operacional ou unidade de dados de uma VM
Linux quando a unidade do sistema operacional é criptografada.
Criptografando a unidade do sistema operacional para conjuntos de dimensionamento de máquinas virtuais
do Linux.
Criptografia de imagens personalizadas em VMs Linux.
Integração ao sistema de gerenciamento de chaves local.
Arquivos do Azure (sistema de arquivo compartilhado).
NFS (Network File System).
Volumes dinâmicos.
Discos do SO Efêmero.
Criptografia de sistemas de arquivos compartilhados/distribuídos como (mas não se limitando a): DFS, GFS,
DRDB e CephFS.
Movendo uma VM criptografada para outra assinatura ou região.
Criar uma imagem ou um instantâneo de uma VM criptografada e usá-la para implantar VMs adicionais.
Kdump (kernel de despejo de memória).
Oracle ACFS (Sistema de Arquivos de Cluster do ASM).
VMs Gen2 (consulte: Suporte para VMs de geração 2 no Azure).
Os discos NVMe das VMs da série Lsv2 (consulte: Lsv2-Series).
Uma VM com "pontos de montagem aninhados"; ou seja, vários pontos de montagem em um só caminho
(como "/1stmountpoint/data/2stmountpoint").
Uma VM com uma unidade de dados montada na parte superior de uma pasta do sistema operacional.
Uma VM na qual um volume lógico (disco do sistema operacional) foi estendido usando um disco de dados.
VMs da série M com discos Acelerador de Gravação.
Aplicando ADE a uma VM que tem discos criptografados com criptografia do lado do servidor com chaves
gerenciadas pelo cliente (SSE + CMK). A aplicação de SSE + CMK a um disco de dados em uma VM
criptografada com ADE também é um cenário sem suporte.
Migrar uma VM criptografada com ADE ou já foi criptografada com Ade, para a criptografia do lado do
servidor com chaves gerenciadas pelo cliente.
Tamanhos de VM do Azure sem disco temporário local; especificamente, DV4, Dsv4, Ev4 e Esv4.
Criptografia de VMs em clusters de failover.
Próximas etapas
Azure Disk Encryption scripts de exemplo
Guia de solução de problemas do Azure Disk Encryption
Cenários de Azure Disk Encryption em VMs
Windows
Azure Disk Encryption para VMs (máquinas virtuais) do Windows usa o recurso BitLocker do Windows para
fornecer criptografia de disco completa do disco do sistema operacional e do disco de dados. Além disso, ele
fornece criptografia do disco temporário quando o parâmetro VolumeType é All.
O Azure Disk Encryption é integrado ao Azure Key Vault para ajudar você a controlar e gerenciar as chaves de
criptografia de disco e os segredos. Para obter uma visão geral do serviço, consulte Azure Disk Encryption para
VMs do Windows.
Você só pode aplicar a criptografia de disco a máquinas virtuais de tamanhos de VM e sistemas operacionais
com suporte. Você também deve atender aos seguintes pré-requisitos:
Requisitos de rede
Requisitos de Política de Grupo
IMPORTANT
continuar usando essa opção para criptografar a VM. Confira Azure Disk Encryption com o Azure AD (versão
anterior) para detalhes.
Você deve fazer um instantâneo e/ou criar um backup antes que os discos sejam criptografados. Os backups
garantem que uma opção de recuperação seja possível, no caso de uma falha inesperada durante a criptografia.
VMs com discos gerenciados exigem um backup antes que a criptografia ocorra. Depois que um backup é feito,
você poderá usar o cmdlet Set-AzVMDiskEncryptionExtension para criptografar discos gerenciados, especificando
o parâmetro -skipVmBackup. Para obter mais informações sobre como fazer backup e restaurar VMs
criptografadas, consulte fazer backup e restaurar a VM do Azure criptografada.
Criptografar ou desabilitar a criptografia pode fazer com que uma VM seja reinicializada.

O Azure Disk Encryption pode ser habilitado e gerenciado por meio da CLI do Azure e do Azure PowerShell. Para
fazer isso, você deve instalar as ferramentas localmente e conectar-se à sua assinatura do Azure.
CLI do Azure
O CLI 2.0 do Azure é uma ferramenta de linha de comando para gerenciar recursos do Azure. A CLI é projetada
para consultar dados com flexibilidade, dar suporte a operações de longa execução como processos
desbloqueados e facilitar o script. Você pode instalá-la localmente seguindo as etapas em Instalar a CLI do
Azure.
Para Entrar na assinatura do Azure com a CLI do Azure, use o comando az login.
az login
Se você deseja selecionar um locatário a ser usado para entrar, use:

az login --tenant <tenant>
Se você tiver várias assinaturas e quiser especificar uma lista específica, obtenha a lista de assinaturas com az
account list e especifique com az account set.
az account list
az account set --subscription "<subscription name or ID>"
Para obter mais informações, consulte Introdução à CLI do Azure 2.0.

Azure PowerShell
O módulo az do Azure PowerShell fornece um conjunto de cmdlets que usa o modelo do Azure Resource
Manager para gerenciar os recursos do Azure. Você pode usá-lo em seu navegador com o Azure Cloud Shell ou
você pode instalá-lo em seu computador local usando as instruções em Instalar o módulo do Azure PowerShell.
Se você já tiver instalado localmente, verifique se que você usar a versão mais recente do SDK do Azure
PowerShell para configurar o Azure Disk Encryption. Baixe a última versão do Azure PowerShell.
Para Entrar em sua conta do Azure com o Azure PowerShell, use o cmdlet Connect-AzAccount.
Connect-AzAccount
Se você tiver várias assinaturas e quiser especificar uma, use o cmdlet Get-AzSubscription para listá-las, seguido
pelo cmdlet Set-AzContext:
Set-AzContext -Subscription -Subscription <SubscriptionId>
A execução do cmdlet Get-AzContext verificará se a assinatura correta foi selecionada.

Para confirmar que os cmdlets do Azure Disk Encryption estão instalados, use o cmdlet Get-command:
Get-command *diskencryption*
Para saber mais, confira Introdução ao Azure PowerShell.
Habilitar a criptografia em uma VM do Windows existente ou em

execução
Nesse cenário, é possível habilitar a criptografia usando o modelo do Resource Manager, os cmdlets do
PowerShell ou os comandos da CLI. Se você precisar de informações de esquema para a extensão de máquina
virtual, consulte o Azure Disk Encryption para extensão do artigo Windows.
Habilitar criptografia em VMs existentes ou em execução com Azure PowerShell
Use o cmdlet set-AzVMDiskEncryptionExtension para habilitar a criptografia em uma máquina virtual IaaS em
execução no Azure.
AzVMDiskEncryptionExtension. O grupo de recursos, a VM e o cofre de chaves já devem ter sido criados
como pré-requisitos. Substitua MyKeyVaultResourceGroup, MyVirtualMachineResourceGroup,
MySecureVM e MySecureVault por seus valores.
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -

DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -DiskEncryptionKeyVaultId $KeyVaultResourceId;

KeyEncryptionKeyUrl $keyEncryptionKeyUrl -KeyEncryptionKeyVaultId $KeyVaultResourceId;
NOTE
Verifique se os discos estão criptografados: Para verificar o status de criptografia de uma VM IaaS,
use o cmdlet Get-AzVmDiskEncryptionStatus .

AzVMDiskEncryption. Desabilitar a criptografia de disco de dados na VM do Windows quando os discos
de dados e o sistema operacional foram criptografados não funciona conforme o esperado. Desabilite a
criptografia em todos os discos em vez disso.
Habilitar a criptografia em VMs existentes ou em execução com o CLI do Azure

Use o comando az vm encryption enable para habilitar a criptografia em uma máquina virtual da IaaS em
encryption-keyvault "MySecureVault" --volume-type [All|OS|Data]

"MySecureVaultContainingTheKEK" --volume-type [All|OS|Data]
NOTE
use o comando AZ VM Encryption show .

Desabilitar a criptografia de disco de dados na VM do Windows quando os discos de dados e o sistema
operacional foram criptografados não funciona conforme o esperado. Desabilite a criptografia em todos
os discos em vez disso.

volume-type [ALL, DATA, OS]
Usando o modelo do Gerenciador de Recursos

É possível habilitar a criptografia de disco em VMs do Windows da IaaS em execução ou existentes no Azure
usando o modelo do Resource Manager para criptografar uma VM do Windows em execução.
1. No modelo de início rápido do Azure, clique em Implantar no Azure .
2. Selecione a assinatura, o grupo de recursos, o local, as configurações, os termos legais e o contrato.
Clique em Comprar para habilitar a criptografia na VM da IaaS em execução ou existente.
A tabela a seguir lista os parâmetros de modelo do Resource Manager existentes para as VMs em execução ou
existentes:
vmName Nome da VM para executar a operação de criptografia.

keyVaultName Nome do cofre de chaves no qual a chave do BitLocker deve

ser carregada. É possível obtê-lo, usando o cmdlet
ou o comando
az keyvault list --resource-group
"MyKeyVaultResourceGroup"
da CLI do Azure
keyVaultResourceGroup Nome do grupo de recursos que contém o cofre de chaves
keyEncryptionKeyURL A URL da chave de criptografia de chave, no formato https://

< keyvault-name > . Vault.Azure.net/Key/ < Key-Name > .
Se você não quiser usar um KEK, deixe esse campo em
branco.

executada. Os valores válidos são OS, Data e All.
forceUpdateTag Passe um valor exclusivo como um GUID sempre que a

execução da operação precise ser forçada.
resizeOSDisk A partição do SO deve ser redimensionada para ocupar o

VHD do SO completo antes de dividir o volume do sistema.
local Local de todos os recursos.
Habilitar a criptografia em discos de NVMe para VMs Lsv2

Este cenário descreve a habilitação de Azure Disk Encryption em discos de NVMe para VMs da série Lsv2. A série
Lsv2 apresenta o armazenamento de NVMe local. Os discos do NVMe local são temporários e os dados serão
perdidos nesses discos se você parar/desalocar sua VM (consulte: Lsv2-Series).
Para habilitar a criptografia em discos do NVMe:
1. Inicialize os discos do NVMe e crie volumes NTFS.
2. Habilite a criptografia na VM com o parâmetro Volumetype definido como todos. Isso habilitará a
criptografia para todos os discos de sistema operacional e de dados, incluindo volumes apoiados por discos
de NVMe. Para obter informações, consulte habilitar a criptografia em uma VM do Windows existente ou em
execução.
A criptografia persistirá nos discos de NVMe nos seguintes cenários:
Reinicialização da VM
Refazer imagem do VMSS
Sistema operacional de permuta
Os discos de NVMe não serão inicializados nos seguintes cenários:
Iniciar VM após desalocação
Recuperação de serviço
Backup
Nesses cenários, os discos de NVMe precisam ser inicializados depois que a VM é iniciada. Para habilitar a
criptografia nos discos do NVMe, execute o comando para habilitar Azure Disk Encryption novamente depois
que os discos de NVMe forem inicializados.
Além dos cenários listados na seção cenários sem suporte , a criptografia de discos de NVMe não tem suporte
para:
VMs criptografadas com Azure Disk Encryption com o AAD (versão anterior)
Discos de NVMe com espaços de armazenamento
Azure Site Recovery de SKUs com discos de NVMe (consulte matriz de suporte para recuperação de desastre
de VM do Azure entre regiões do Azure: máquinas replicadas-armazenamento).
Novas VMs da IaaS criadas a partir de chaves de criptografia e VHD

criptografado pelo cliente
Nesse cenário, você pode criar uma nova VM de um VHD previamente criptografado e as chaves de criptografia
associadas usando cmdlets do PowerShell ou comandos da CLI.
Use as instruções em preparar um VHD do Windows previamente criptografado. Depois que a imagem for
criada, você poderá usar as etapas na próxima seção para criar uma VM do Azure criptografada.
Criptografar VMs com VHDs previamente criptografados com Azure PowerShell

-Windows -CreateOption "Attach" -DiskEncryptionKeyUrl
000000000000/resourceGroups/myKVresourcegroup/providers/Microsoft.KeyVault/vaults/mytestvault"

É possível adicionar um novo disco a uma VM do Windows usando o PowerShell ou por meio do portal do
Azure.
Ao usar o PowerShell para criptografar um novo disco para VMs do Windows, uma nova versão de sequência
deve ser especificada. A versão da sequência deverá ser exclusiva. O script abaixo gera um GUID para a versão
da sequência. Em alguns casos, um disco de dados adicionado recentemente pode ser criptografado
automaticamente pela extensão do Azure Disk Encryption. A criptografia automática geralmente ocorre quando
a VM é reinicializada depois que o novo disco fica online. Isso geralmente é causado porque "All" foi
especificado para o tipo de volume quando a criptografia de disco foi executada anteriormente na VM. Se a
criptografia automática ocorrer em um disco de dados recém-adicionado, recomendamos executar o cmdlet
Set-AzVmDiskEncryptionExtension novamente com a nova versão de sequência. Se o seu novo disco de dados
for criptografado automaticamente e você não quiser ser criptografado, primeiro descriptografe todas as
unidades e criptografe novamente com uma nova versão de sequência, especificando o SO para o tipo de
volume.
AzVMDiskEncryptionExtension. O grupo de recursos, a VM e o cofre de chaves já devem ter sido criados
como pré-requisitos. Substitua MyKeyVaultResourceGroup, MyVirtualMachineResourceGroup,
MySecureVM e MySecureVault por seus valores. Este exemplo usa "All" para o parâmetro -VolumeType,
que inclui ambos os volumes de Dados e SO. Se você quiser apenas criptografar o volume do SO, use
"OS" para o parâmetro -VolumeType.

VolumeType "All" –SequenceVersion $sequenceVersion;
Criptografar uma VM em execução usando KEK: Este exemplo usa "All" para o parâmetro -
VolumeType, que inclui ambos os volumes de Dados e SO. Se você quiser apenas criptografar o volume
do SO, use "OS" para o parâmetro -VolumeType.

"All" –SequenceVersion $sequenceVersion;
NOTE

O comando da CLI do Azure fornecerá automaticamente uma nova versão da sequência quando você executar o
comando para habilitar a criptografia. Os exemplos usam "All" para o parâmetro do tipo de volume. Talvez seja
necessário alterar o parâmetro do tipo de volume para disco do SO. Em contraste com a sintaxe do PowerShell,
a CLI não exige que o usuário forneça uma versão de sequência exclusiva ao habilitar a criptografia. A CLI gera e
usa automaticamente o próprio valor de versão de sequência exclusivo.

encryption-keyvault "MySecureVault" --volume-type "All"

"MySecureVaultContainingTheKEK" --volume-type "All"
Desabilitar criptografia
Manager. Desabilitar a criptografia de disco de dados na VM do Windows quando os discos de dados e o
sistema operacional foram criptografados não funciona conforme o esperado. Desabilite a criptografia em todos
os discos em vez disso.
Desabilitar a criptografia de disco com o Azure PowerShell: para desabilitar a criptografia, use o
cmdlet Disable-AzVMDiskEncryption.
Disable-AzVMDiskEncryption -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName 'MySecureVM' -

VolumeType "all"
encryption disable.

volume-type "all"
Desabilitar criptografia com um modelo do Resource Manager :

1. Clique em Implantar no Azure no modelo Desabilitar criptografia de disco na VM do Windows em
execução.
2. Selecione a assinatura, o grupo de recursos, o local, a VM, o tipo de volume, os termos legais e o
contrato.
3. Clique em Comprar para desabilitar a criptografia de disco em uma VM do Windows em execução.
Cenários sem suporte

Azure Disk Encryption não funciona para os seguintes cenários, recursos e tecnologia:
criptografia de VM de camada básica ou VMs criadas por meio do método de criação de VM clássico.
Criptografia de VMs configuradas com sistemas RAID baseados em software.
Criptografia de VMs configuradas com o Espaços de Armazenamento Diretos (S2D) ou versões do Windows
Server anteriores a 2016 configuradas com espaços de armazenamento do Windows.
Integração ao sistema de gerenciamento de chaves local.
Arquivos do Azure (sistema de arquivo compartilhado).
NFS (Network File System).
Volumes dinâmicos.
Contêineres do Windows Server, que criam volumes dinâmicos para cada contêiner.
Discos do SO Efêmero.
Criptografia de sistemas de arquivos compartilhados/distribuídos como (mas não se limitando a) DFS, GFS,
DRDB e CephFS.
Movendo VMs criptografadas para outra assinatura ou região.
Criar uma imagem ou um instantâneo de uma VM criptografada e usá-la para implantar VMs adicionais.
VMs Gen2 (consulte: suporte para VMs de geração 2 no Azure)
VMs da série M com discos Acelerador de Gravação.
Aplicando ADE a uma VM que tem discos criptografados com criptografia do lado do servidor com chaves
gerenciadas pelo cliente (SSE + CMK). A aplicação de SSE + CMK a um disco de dados em uma VM
criptografada com ADE também é um cenário sem suporte.
Migrar uma VM criptografada com ADE ou já foi criptografada com Ade, para a criptografia do lado do
servidor com chaves gerenciadas pelo cliente.
Tamanhos de VM do Azure sem disco temporário local; especificamente, DV4, Dsv4, Ev4 e Esv4.
Criptografia de VMs em clusters de failover.
Próximas etapas
Início Rápido: criar e criptografar uma VM do Linux
com a CLI do Azure
rápido mostra como usar a CLI do Azure para criar e criptografar uma VM (máquina virtual) do Linux.
Se você optar por instalar e usar a CLI do Azure localmente, este início rápido exigirá a execução da CLI do Azure

az group create --name "myResourceGroup" --location "eastus"

Crie uma VM com az vm create. O exemplo a seguir cria uma VM chamada myVM.
az vm create \
--name "myVM" \
--image "Canonical:UbuntuServer:16.04-LTS:latest" \
--size "Standard_D2S_V3"\
--generate-ssh-keys
{
"fqdns": "",
"id":
"macAddress": "00-0D-3A-23-9A-49",
}
Criar um Key Vault configurado para chaves de criptografia

A criptografia de disco do Azure armazena sua chave de criptografia em um Azure Key Vault. Crie um Key Vault
com az keyvault create. Para habilitar o Key Vault para armazenar chaves de criptografia, use o parâmetro --
enabled-for-disk-encryption.
IMPORTANT
Cada cofre de chaves deve ter um nome exclusivo no Azure. Nos exemplos a seguir, substitua pelo nome que você
escolher.
az keyvault create --name "<your-unique-keyvault-name>" --resource-group "myResourceGroup" --location

"eastus" --enabled-for-disk-encryption
Criptografar a máquina virtual

Criptografe sua VM com az vm encryption, fornecendo um nome exclusivo ao Key Vault com o parâmetro --
disk-encryption-keyvault.
az vm encryption enable -g "MyResourceGroup" --name "myVM" --disk-encryption-keyvault "<your-unique-

keyvault-name>"
Após alguns instantes, o processo retorna a mensagem "A solicitação de criptografia foi aceita. Use o comando
'show' para monitorar o progresso.". O comando "show" é az vm show.
az vm encryption show --name "myVM" -g "MyResourceGroup"
Quando a criptografia estiver ativada, você verá o seguinte na saída retornada:
"EncryptionOperation": "EnableEncryption"
Limpar os recursos
a VM e o Key Vault.
az group delete --name "myResourceGroup"
Próximas etapas
Neste guia de início rápido, você criou uma máquina virtual, um Key Vault habilitado para chaves de criptografia
e criptografou a VM. Avance para o próximo artigo a fim de saber mais sobre o Azure Disk Encryption para VMs
Linux.
Início Rápido: Criar e criptografar uma VM do
Windows com a CLI do Azure
rápido mostra como usar a CLI do Azure para criar e criptografar uma VM (máquina virtual) do Windows Server
2016.
Pré-requisitos

Este artigo exige a versão 2.0.30 ou posterior da CLI do Azure. Se você está usando o Azure Cloud Shell, a


Crie uma VM com az vm create. O exemplo a seguir cria uma VM chamada myVM. Este exemplo usa o
azureuser para um nome de usuário administrativo e myPassword12 como a senha.
az vm create \
--name myVM \
--image win2016datacenter \
--admin-password myPassword12
{
"fqdns": "",
"id":
"macAddress": "00-0D-3A-23-9A-49",
}

com az keyvault create. Para habilitar o Key Vault para armazenar chaves de criptografia, use o parâmetro --
enabled-for-disk-encryption.
IMPORTANT
Cada Key Vault deve ter um nome exclusivo. O exemplo a seguir cria um Key Vault chamado myKV, mas você deve
colocar um nome diferente.
az keyvault create --name "myKV" --resource-group "myResourceGroup" --location eastus --enabled-for-disk-

encryption

Criptografe sua VM com az vm encryption, fornecendo um nome exclusivo ao Key Vault com o parâmetro --
disk-encryption-keyvault.
az vm encryption enable -g MyResourceGroup --name MyVM --disk-encryption-keyvault myKV
Você pode verificar que a criptografia está habilitada na sua VM com show az vm
az vm encryption show --name MyVM -g MyResourceGroup
Você verá o seguinte retornado na saída:
"EncryptionOperation": "EnableEncryption"
Limpar os recursos
a VM e o Key Vault.

Próximas etapas
e criptografou a VM. Avance para o próximo artigo a fim de saber mais sobre os pré-requisitos do Azure Disk
Encryption para VMs IaaS.
Início Rápido: Criar e criptografar uma VM do Linux
no Azure com o Azure PowerShell
PowerShell ou em scripts. Este início rápido mostra como usar o módulo do Azure PowerShell para criar uma
máquina virtual (VM) do Linux, criar um Key Vault para o armazenamento de chaves de criptografia e
criptografar a VM. Este início rápido usa a imagem do marketplace do Ubuntu 16.04 LTS do Canonical e um
tamanho Standard_D2S_V3 de VM.


Crie uma máquina virtual do Azure com o New-AzVM, transmitindo-o para o objeto de configuração da VM
criada anteriormente.
New-AzVM -Name MyVm -Credential $cred -ResourceGroupName MyResourceGroup -Image

Canonical:UbuntuServer:18.04-LTS:latest -Size Standard_D2S_V3

com New-AzKeyVault. Para habilitar o Key Vault para armazenar chaves de criptografia, use o parâmetro -
EnabledForDiskEncryption.
IMPORTANT
Cada cofre de chaves deve ter um nome exclusivo no Azure. Nos exemplos a seguir, substitua pelo nome que você
escolher.
New-AzKeyvault -name "<your-unique-keyvault-name>" -ResourceGroupName "myResourceGroup" -Location EastUS -

EnabledForDiskEncryption

Criptografe sua VM com Set-AzVmDiskEncryptionExtension.
Set-AzVmDiskEncryptionExtension requer alguns valores do seu objeto Key Vault. Você pode obter esses
valores, transmitindo o nome exclusivo do Key Vault para Get-AzKeyvault.
$KeyVault = Get-AzKeyVault -VaultName "<your-unique-keyvault-name>" -ResourceGroupName "MyResourceGroup"
Set-AzVMDiskEncryptionExtension -ResourceGroupName MyResourceGroup -VMName "MyVM" -DiskEncryptionKeyVaultUrl

$KeyVault.VaultUri -DiskEncryptionKeyVaultId $KeyVault.ResourceId -SkipVmBackup -VolumeType All
Após alguns minutos, o processo retornará o seguinte:

--------- ------------------- ---------- ------------
True OK OK
Você pode verificar o processo de criptografia executando Get-AzVmDiskEncryptionStatus.
Get-AzVmDiskEncryptionStatus -VMName MyVM -ResourceGroupName MyResourceGroup
OsVolumeEncrypted : EncryptionInProgress
DataVolumesEncrypted : NotMounted
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : OS disk encryption started
Limpar os recursos
Próximas etapas
e criptografou a VM. Avance para o próximo artigo a fim de saber mais sobre o Azure Disk Encryption para VMs
Linux.
Início Rápido: Criar e criptografar uma máquina
virtual do Windows no Azure com o PowerShell
PowerShell ou em scripts. Este início rápido mostra como usar o módulo do Azure PowerShell para criar uma
máquina virtual (VM) do Windows, criar um Key Vault para o armazenamento de chaves de criptografia e
criptografar a VM.


Crie a máquina virtual do Azure com New-AzVM. Você deve fornecer credenciais para o cmdlet.
New-AzVM -Name MyVm -Credential $cred -ResourceGroupName MyResourceGroup -Image win2016datacenter -Size
Standard_D2S_V3

com New-AzKeyVault. Para habilitar o Key Vault para armazenar chaves de criptografia, use o parâmetro -
EnabledForDiskEncryption.
IMPORTANT
Cada Key Vault deve ter um nome exclusivo. O exemplo a seguir cria um Key Vault chamado myKV, mas você deve
colocar um nome diferente.
New-AzKeyvault -name MyKV -ResourceGroupName myResourceGroup -Location EastUS -EnabledForDiskEncryption

Criptografe sua VM com Set-AzVmDiskEncryptionExtension.
Set-AzVmDiskEncryptionExtension requer alguns valores do seu objeto Key Vault. Você pode obter esses
valores, transmitindo o nome exclusivo do Key Vault para Get-AzKeyvault.
$KeyVault = Get-AzKeyVault -VaultName MyKV -ResourceGroupName MyResourceGroup
Set-AzVMDiskEncryptionExtension -ResourceGroupName MyResourceGroup -VMName MyVM -DiskEncryptionKeyVaultUrl

$KeyVault.VaultUri -DiskEncryptionKeyVaultId $KeyVault.ResourceId
Após alguns minutos, o processo retornará o seguinte:

--------- ------------------- ---------- ------------
True OK OK
Você pode verificar o processo de criptografia executando Get-AzVmDiskEncryptionStatus.
Get-AzVmDiskEncryptionStatus -VMName MyVM -ResourceGroupName MyResourceGroup
OsVolumeEncrypted : Encrypted
DataVolumesEncrypted : NoDiskFound
ProgressMessage : Provisioning succeeded
Limpar os recursos
Próximas etapas
e criptografou a VM. Avance para o próximo artigo a fim de saber mais sobre os pré-requisitos do Azure Disk
Encryption para VMs IaaS.
virtual com o portal do Azure
interface de usuário baseada em navegador para criar as VMS e seus recursos relacionados. Neste início rápido,
você usará o portal do Azure para implantar uma VM (máquina virtual) do Linux executando o Ubuntu 18.04
LTS, criar um cofre de chaves para o armazenamento de chaves de criptografia e criptografar a VM.
Entrar no Azure
Entre no portal do Azure.

2. Na página Novo, em Popular, selecione Ubuntu Ser ver 18.04 LTS .
3. Na guia Informações Básicas, em Detalhes do projeto, confirme se a assinatura correta está selecionada.
4. Em "Grupo de Recursos", selecione Criar . Insira myResourceGroup como o nome e selecione OK .
5. Para Nome da máquina vir tual , insira MyVM.
6. Em Região , selecione EUA (Leste dos EUA) .
7. Verifique se o Tamanho é Standard D2s v3.
8. Em Conta de administrador , selecione Senha como o Tipo de autenticação . Digite um nome de
usuário e uma senha.
WARNING
A guia "Discos" apresenta o campo "Tipo de Criptografia" em Opções de disco . Esse campo é usado para
especificar as opções de criptografia dos Managed Disks + CMK, não do Azure Disk Encryption.
Para evitar confusões, sugerimos que você ignore completamente a guia Discos ao seguir este tutorial.
9. Selecione a guia "Gerenciamento" e verifique se você tem uma Conta de Armazenamento de Diagnóstico.
Se você não tiver contas de armazenamento, selecione Criar , nomeie sua conta de armazenamento
myStorageAccount e selecione "OK"
10. Clique em "Examinar + Criar".
próxima seção.

1. Depois que a implantação da VM estiver concluída, selecione Ir para o recurso .
2. No lado esquerdo, selecione Discos .
3. Na barra superior, selecione Configurações Adicionais .
4. Em Configurações de criptografia > Discos para criptografia , selecione Discos do sistema
operacional e de dados .
5. Em Configurações de criptografia , escolha Selecionar um cofre de chaves e uma chave para
criptografia .
6. Na tela Selecionar chave no Azure Key Vault , selecione Criar .
7. À esquerda de Cofre de chaves e chave , selecione Clique aqui para selecionar uma chave .
8. Em Selecionar chave no Azure Key Vault , no campo Key Vault , selecione Criar .
9. Na tela Criar um cofre de chaves , verifique se o Grupo de Recursos é myResourceGroup e dê um
nome ao cofre de chaves. Cada cofre de chaves no Azure deve ter um nome exclusivo.
10. Na guia Políticas de Acesso , marque a caixa Azure Disk Encr yption para a criptografia de
volume .
11. Selecione Examinar + criar .
12. Depois que o cofre de chaves passar na validação, selecione Criar . Isso retornará você para a tela
Selecionar chave no Azure Key Vault .
13. Deixe o campo Chave em branco e escolha Selecionar .
14. Na parte superior da tela de criptografia, clique em Salvar . Um pop-up avisará que a VM será
reinicializada. Clique em Sim .
Limpar os recursos
exclua-os. Para fazer isso, selecione o grupo de recursos da máquina virtual, selecione Excluir, em seguida,
confirme o nome do grupo de recursos a excluir.
Próximas etapas
Neste início rápido, você criou um Key Vault habilitado para chaves de criptografia, criou uma máquina virtual e
habilitou-a para criptografia.
virtual do Windows com o portal do Azure
interface de usuário baseada em navegador para criar as VMS e seus recursos relacionados. Neste início rápido,
você usará o portal do Azure para implantar uma máquina virtual do Windows, criar um cofre de chaves para o
armazenamento de chaves de criptografia e criptografar a VM.
Entrar no Azure
Entre no portal do Azure.

2. Na página Novo, em Popular, selecione Datacenter do Windows Ser ver 2016 .
3. Na guia Básico, em Detalhes do projeto, verifique se a assinatura correta está selecionada.
4. Em "Grupo de Recursos", selecione Criar . Insira myResourceGroup como o nome e selecione OK .
5. Para Nome da máquina vir tual , insira MyVM.
6. Em Região , selecione EUA (Leste dos EUA) .
7. Confirme se o Tamanho é Standard D2s v3.
8. Em Conta do administrador , selecione Senha . Digite um nome de usuário e uma senha.
WARNING
A guia "Discos" apresenta o campo "Tipo de Criptografia" em Opções de disco . Esse campo é usado para
especificar as opções de criptografia dos Managed Disks + CMK, não do Azure Disk Encryption.
Para evitar confusões, sugerimos que você ignore completamente a guia Discos ao seguir este tutorial.
9. Selecione a guia "Gerenciamento" e verifique se você tem uma Conta de Armazenamento de Diagnóstico.
Se não tiver contas de armazenamento, selecione "Criar", dê um nome à nova conta e selecione "OK"
10. Clique em "Examinar + Criar".

próxima seção.

1. Depois que a implantação da VM estiver concluída, selecione Ir para o recurso .
2. No lado esquerdo, selecione Discos .
3. Na barra superior, selecione Configurações Adicionais .
4. Em Configurações de criptografia > Discos para criptografia , selecione Discos do sistema
operacional e de dados .
5. Em Configurações de criptografia , escolha Selecionar um cofre de chaves e uma chave para
criptografia .
6. Na tela Selecionar chave no Azure Key Vault , selecione Criar .
7. À esquerda de Cofre de chaves e chave , selecione Clique aqui para selecionar uma chave .
8. Em Selecionar chave no Azure Key Vault , no campo Key Vault , selecione Criar .
9. Na tela Criar um cofre de chaves , verifique se o Grupo de Recursos é myResourceGroup e dê um
nome ao cofre de chaves. Cada cofre de chaves no Azure deve ter um nome exclusivo.
10. Na guia Políticas de Acesso , marque a caixa Azure Disk Encr yption para a criptografia de
volume .
12. Depois que o cofre de chaves passar na validação, selecione Criar . Isso retornará você para a tela
Selecionar chave no Azure Key Vault .
13. Deixe o campo Chave em branco e escolha Selecionar .
14. Na parte superior da tela de criptografia, clique em Salvar . Um pop-up avisará que a VM será
reinicializada. Clique em Sim .
Limpar os recursos
exclua-os. Para fazer isso, selecione o grupo de recursos da máquina virtual, selecione Excluir, em seguida,
confirme o nome do grupo de recursos a excluir.
Próximas etapas
Neste guia de início rápido, você criou um Key Vault habilitado para chaves de criptografia, criou uma máquina
virtual e habilitou a máquina virtual para criptografia.
Criar e configurar um cofre de chaves para Azure
Disk Encryption
O Azure Disk Encryption usa o Azure Key Vault para ajudar você a controlar e gerenciar os segredos e chaves de
criptografia de disco. Para obter mais informações sobre cofres-chave, consulte Introdução ao Cofre de Chaves
do Azure e Proteja seu cofre de chaves.
WARNING
continuar usando essa opção para criptografar a VM. Veja Criação e configuração de um cofre de chaves para Azure
Disk Encryption com o Azure AD (versão anterior) para saber detalhes.
Criar e configurar um cofre de chaves para usar com Azure Disk Encryption envolve três etapas:
1. Criar um grupo de recursos, se necessário.
2. Criando um cofre de chaves.
3. Definir as políticas de acesso avançado do cofre de chaves.
Esses passos estão ilustrados nos seguintes guias de início rápido:
Criar e criptografar uma VM do Linux com a CLI do Azure
Criar e criptografar uma VM do Linux com o Azure PowerShell
Caso queira, também é possível gerar ou importar uma KEK (chave de criptografia de chave).
NOTE
As etapas neste artigo são automatizadas no Script de CLI de pré-requisitos do Azure Disk Encryption e no Script do
PowerShell de pré-requisitos do Azure Disk Encryption.

As etapas neste artigo podem ser concluídas com a CLI do Azure, o módulo AZ do Azure PowerShell ou o portal
do Azure.
Embora o portal possa ser acessado através do navegador, a CLI do Azure e o Azure PowerShell exigem a
instalação local; veja Azure Disk Encryption para Linux: Instalação de ferramentas para saber detalhes.
Conectar-se à sua conta do Azure
Antes de usar a CLI do Azure ou o Azure PowerShell, é necessário se conectar a sua assinatura do Azure. Você
faz isso Entrando com a CLI do Azure, Entrando com Azure Powershell ou fornecendo suas credenciais para o
portal do Azure quando solicitado.
az login
Connect-AzAccount

Se você já tiver um grupo de recursos, poderá pular para Criar um cofre de chaves.
Um grupo de recursos é um contêiner lógico no qual os recursos do Azure são implantados e gerenciados.
Crie um grupo de recursos usando o comando az group create da CLI do Azure, o comando New-
AzResourceGroup do Azure PowerShell ou por meio do portal do Azure.
CLI do Azure
az group create --name "myResourceGroup" --location eastus
Azure PowerShell
Criar um cofre de chave

Se você já tiver um cofre de chaves, poderá pular para definir políticas de acesso avançado do cofre de chaves.
Crie um cofre de chaves usando o comando az keyvault create da CLI do Azure, o comando New-AzKeyvault do
Azure PowerShell, o portal do Azure ou um modelo do Resource Manager.
WARNING
O cofre de chaves e as VMs devem estar na mesma assinatura. Além disso, para garantir que os segredos de criptografia
não ultrapassem os limites regionais, o Azure Disk Encryption exige que o Key Vault e as VMs estejam localizados na
mesma região. Crie e use um Key Vault que esteja na mesma assinatura e na mesma região que as VMs a ser
criptografadas.
Cada Key Vault deve ter um nome exclusivo. Substitua pelo nome do seu cofre de chaves nos exemplos a seguir.
CLI do Azure
Ao criar um cofre de chaves usando a CLI do Azure, adicione o sinalizador "--enabled-for-disk-encryption".

Azure PowerShell
Ao criar um cofre de chaves usando o Azure PowerShell, adicione o sinalizador "-EnabledForDiskEncryption".
New-AzKeyvault -name "<your-unique-keyvault-name>" -ResourceGroupName "myResourceGroup" -Location "eastus" -


Você também pode criar um cofre de chaves usando o modelo do Resource Manager.
2. Selecione a assinatura, o grupo de recursos, a localização do grupo de recursos, o nome do Key Vault, a ID do
Objeto, os termos legais e o contrato e clique em Comprar .
Definir as políticas de acesso avançado do cofre de chaves

A plataforma Azure precisa acessar as chaves de criptografia ou os segredos no cofre de chaves para
disponibilizá-los para a máquina virtual para inicialização e descriptografar os volumes.
Se você não habilitou o cofre de chaves para criptografia de disco, implantação ou implantação de modelo no
momento da criação (conforme demonstrado na etapa anterior), você deve atualizar as políticas de acesso
avançado dele.
CLI do Azure
Use atualização de keyvault az para habilitar a criptografia de disco para o Cofre de chaves.
Habilite o cofre de chaves para criptografia de disco: habilitado para criptografia de disco é
necessária.
az keyvault update --name "<your-unique-keyvault-name>" --resource-group "MyResourceGroup" --enabled-

for-disk-encryption "true"
Ative o cofre de chaves para implantação, se necessário: Permite que o provedor de recursos
Microsoft.Compute recupere segredos desse cofre de chaves quando esse cofre de chaves é mencionado
na criação de recursos, por exemplo, ao criar uma máquina virtual.

for-deployment "true"
Habilite o cofre de chaves para implantação de modelo, se necessário: permitem que o

Gerenciador de recursos para recuperar segredos do cofre.

for-template-deployment "true"
Azure PowerShell
Use o cmdlet de cofre de chaves Set-AzKeyVaultAccessPolicy do PowerShell para habilitar a criptografia de disco
para o cofre da chaves.
Ative o Key Vault para criptografia de disco: EnabledForDiskEncryption é necessário para a
criptografia do Azure Disk.
Set-AzKeyVaultAccessPolicy -VaultName "<your-unique-keyvault-name>" -ResourceGroupName

"MyResourceGroup" -EnabledForDiskEncryption

"MyResourceGroup" -EnabledForDeployment
Ative o cofre de chaves para implantação de modelos, se necessário: Permite que o Azure
Resource Manager obtenha segredos desse cofre de chaves quando esse cofre de chaves for mencionado
em uma implantação de modelo.

"MyResourceGroup" -EnabledForTemplateDeployment
Portal do Azure
1. Selecione o cofre de chaves, vá para Políticas de Acesso e Clique para mostrar as políticas de
acesso avançado .
2. Selecione a caixa rotulada habilitar o acesso ao Azure Disk Encr yption para criptografia de
volume .
3. Selecione habilitar o acesso às máquinas vir tuais do Azure para implantação e/ou habilitar
acesso ao Azure Resource Manager para implantação de modelo , se necessário.
4. Clique em Salvar .
Configurar uma KEK (chave de criptografia)

Se você quiser usar uma chave de criptografia (KEK) para uma camada adicional de segurança para chaves de
criptografia, adicione uma KEK ao seu cofre de chaves. Quando uma chave de criptografia de chave é
especificada, o Azure Disk Encryption usa essa chave para agrupar os segredos de criptografia antes de gravar
no Key Vault.
Você pode gerar uma nova KEK usando o comando az keyvault key create da CLI do Azure, o cmdlet Add-
AzKeyVaultKey do Azure PowerShell ou o portal do Azure. Você deve gerar uma chave do tipo RSA. O Azure
Disk Encryption ainda não é compatível com o uso de chaves de Curva Elíptica.
Em vez disso, você pode importar uma KEK do HSM de gerenciamento de chaves local. Para obter mais
informações, consulte documentação do cofre de chaves.
As URLs de KEK do cofre de chaves devem ser submetidas ao controle de versão. O Azure impõe essa restrição
de controle de versão. Para um segredo válido e URLs KEK, confira os seguintes exemplos:
Exemplo de uma URL secreta válida:
https://contosovault.vault.azure.net/secrets/EncryptionSecretWithKek/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Exemplo de uma URL de KEK válida:
https://contosovault.vault.azure.net/keys/diskencryptionkek/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
o Azure Disk Encryption não dá suporte à especificação de números de portas como parte de segredos do cofre
de chaves e URLs KEK. Para exemplos de URLs do cofre de chaves não suportados e suportados, consulte os
seguintes exemplos:
URL aceitável do cofre de chaves:
https://contosovault.vault.azure.net/secrets/contososecret/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
URL inaceitável do cofre de chaves:
https://contosovault.vault.azure.net:443/secrets/contososecret/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
CLI do Azure
Use o comando az keyvault key create da CLI do Azure para gerar uma nova KEK e armazená-la no cofre de
chaves.
az keyvault key create --name "myKEK" --vault-name "<your-unique-keyvault-name>" --kty RSA
Em vez disso, você pode importar uma chave privada usando o comando az keyvault key import da CLI do
Azure:
Em ambos os casos, você fornecerá o nome da KEK ao parâmetro KEK az vm encryption enable da CLI do Azure.

keyvault-name>" --key-encryption-key "myKEK"
Azure PowerShell
Use o cmdlet Add-AzKeyVaultKey do Azure PowerShell para gerar uma nova KEK e armazená-la no cofre de
chaves.
Add-AzKeyVaultKey -Name "myKEK" -VaultName "<your-unique-keyvault-name>" -Destination "HSM"
Em vez disso, você pode importar uma chave privada usando o comando az keyvault key import do Azure
PowerShell.
Em ambos os casos, você fornecerá a ID do cofre de chaves da KEK e a URL da KEK para os parâmetros Set-
AzVMDiskEncryptionExtension -KeyEncryptionKeyVaultId e -KeyEncryptionKeyUrl do Azure PowerShell.
Observe que este exemplo pressupõe que você esteja usando o mesmo cofre de chaves para a chave de
criptografia de disco e a KEK.
$KeyVault = Get-AzKeyVault -VaultName "<your-unique-keyvault-name>" -ResourceGroupName "myResourceGroup"

$KEK = Get-AzKeyVaultKey -VaultName "<your-unique-keyvault-name>" -Name "myKEK"

$KeyVault.VaultUri -DiskEncryptionKeyVaultId $KeyVault.ResourceId -KeyEncryptionKeyVaultId
$KeyVault.ResourceId -KeyEncryptionKeyUrl $KEK.Id -SkipVmBackup -VolumeType All
Próximas etapas
Script da CLI dos pré-requisitos do Azure Disk Encryption
Script do PowerShell dos pré-requisitos do Azure Disk Encryption
Aprenda sobre Cenários do Azure Disk Encryption em VMs do Linux
Saiba como solucionar problemas do Azure Disk Encryption
Leia os Scripts de exemplo do Azure Disk Encryption
Criar e configurar um cofre de chaves para o Azure
Disk Encryption
WARNING
continuar usando essa opção para criptografar a VM. Veja Criação e configuração de um cofre de chaves para Azure
Disk Encryption com o Azure AD (versão anterior) para saber detalhes.
Criar e configurar um cofre de chaves para usar com Azure Disk Encryption envolve três etapas:
NOTE
Você deve selecionar a opção nas configurações da política de acesso Azure Key Vault para habilitar o acesso a Azure Disk
Encryption para criptografia de volume. Se você tiver habilitado o firewall no cofre de chaves, deverá ir para a guia rede no
cofre de chaves e habilitar o acesso aos serviços confiáveis da Microsoft.
1. Criar um grupo de recursos, se necessário.

2. Criando um cofre de chaves.
3. Definir as políticas de acesso avançado do cofre de chaves.
Esses passos estão ilustrados nos seguintes guias de início rápido:
Criar e criptografar uma VM do Windows com a CLI do Azure
Criar e criptografar uma VM do Windows com o Azure PowerShell
NOTE

As etapas neste artigo podem ser concluídas com a CLI do Azure, o módulo AZ do Azure PowerShell ou o portal
do Azure.
Embora o portal possa ser acessado através do navegador, a CLI do Azure e o Azure PowerShell exigem a
instalação local; veja Azure Disk Encryption para Windows: Instalação de ferramentas para saber detalhes.
Conectar-se à sua conta do Azure
Antes de usar a CLI do Azure ou o Azure PowerShell, é necessário se conectar a sua assinatura do Azure. Você
faz isso Entrando com a CLI do Azure, Entrando com Azure Powershell ou fornecendo suas credenciais para o
portal do Azure quando solicitado.
az login
Connect-AzAccount

Se você já tiver um grupo de recursos, poderá pular para Criar um cofre de chaves.
Um grupo de recursos é um contêiner lógico no qual os recursos do Azure são implantados e gerenciados.
Crie um grupo de recursos usando o comando az group create da CLI do Azure, o comando New-
AzResourceGroup do Azure PowerShell ou por meio do portal do Azure.
CLI do Azure
az group create --name "myResourceGroup" --location eastus
Azure PowerShell
Criar um cofre de chave

Se você já tiver um cofre de chaves, poderá pular para definir políticas de acesso avançado do cofre de chaves.
Crie um cofre de chaves usando o comando az keyvault create da CLI do Azure, o comando New-AzKeyvault do
Azure PowerShell, o portal do Azure ou um modelo do Resource Manager.
WARNING
O cofre de chaves e as VMs devem estar na mesma assinatura. Além disso, para garantir que os segredos de criptografia
não ultrapassem os limites regionais, o Azure Disk Encryption exige que o Key Vault e as VMs estejam localizados na
mesma região. Crie e use um Key Vault que esteja na mesma assinatura e na mesma região que as VMs a ser
criptografadas.
Cada Key Vault deve ter um nome exclusivo. Substitua pelo nome do seu cofre de chaves nos exemplos a seguir.
CLI do Azure
Ao criar um cofre de chaves usando a CLI do Azure, adicione o sinalizador "--enabled-for-disk-encryption".

Azure PowerShell
Ao criar um cofre de chaves usando o Azure PowerShell, adicione o sinalizador "-EnabledForDiskEncryption".
New-AzKeyvault -name "<your-unique-keyvault-name>" -ResourceGroupName "myResourceGroup" -Location "eastus" -

Você também pode criar um cofre de chaves usando o modelo do Resource Manager.
2. Selecione a assinatura, o grupo de recursos, a localização do grupo de recursos, o nome do Key Vault, a ID do
Objeto, os termos legais e o contrato e clique em Comprar .

disponibilizá-los para a máquina virtual para inicialização e descriptografar os volumes.
Se você não habilitou o cofre de chaves para criptografia de disco, implantação ou implantação de modelo no
momento da criação (conforme demonstrado na etapa anterior), você deve atualizar as políticas de acesso
avançado dele.
CLI do Azure
necessária.

for-disk-encryption "true"

for-deployment "true"


for-template-deployment "true"
Azure PowerShell

"MyResourceGroup" -EnabledForDiskEncryption
"MyResourceGroup" -EnabledForDeployment

"MyResourceGroup" -EnabledForTemplateDeployment
Portal do Azure
1. Selecione o cofre de chaves, vá para Políticas de Acesso e Clique para mostrar as políticas de
acesso avançado .
2. Selecione a caixa rotulada habilitar o acesso ao Azure Disk Encr yption para criptografia de
volume .
Configurar uma KEK (chave de criptografia)

criptografia, adicione uma KEK ao seu cofre de chaves. Quando uma chave de criptografia de chave é
especificada, o Azure Disk Encryption usa essa chave para agrupar os segredos de criptografia antes de gravar
no Key Vault.
Você pode gerar uma nova KEK usando o comando az keyvault key create da CLI do Azure, o cmdlet Add-
AzKeyVaultKey do Azure PowerShell ou o portal do Azure. Você deve gerar uma chave do tipo RSA. O Azure
Disk Encryption ainda não é compatível com o uso de chaves de Curva Elíptica.
Em vez disso, você pode importar uma KEK do HSM de gerenciamento de chaves local. Para obter mais
informações, consulte documentação do cofre de chaves.
As URLs de KEK do cofre de chaves devem ser submetidas ao controle de versão. O Azure impõe essa restrição
Exemplo de uma URL de KEK válida:
o Azure Disk Encryption não dá suporte à especificação de números de portas como parte de segredos do cofre
de chaves e URLs KEK. Para exemplos de URLs do cofre de chaves não suportados e suportados, consulte os
seguintes exemplos:
URL aceitável do cofre de chaves:
URL inaceitável do cofre de chaves:
CLI do Azure
Use o comando az keyvault key create da CLI do Azure para gerar uma nova KEK e armazená-la no cofre de
chaves.
az keyvault key create --name "myKEK" --vault-name "<your-unique-keyvault-name>" --kty RSA
Em vez disso, você pode importar uma chave privada usando o comando az keyvault key import da CLI do
Azure:
Em ambos os casos, você fornecerá o nome da KEK ao parâmetro KEK az vm encryption enable da CLI do Azure.

keyvault-name>" --key-encryption-key "myKEK"
Azure PowerShell
Use o cmdlet Add-AzKeyVaultKey do Azure PowerShell para gerar uma nova KEK e armazená-la no cofre de
chaves.
Add-AzKeyVaultKey -Name "myKEK" -VaultName "<your-unique-keyvault-name>" -Destination "HSM"
Em vez disso, você pode importar uma chave privada usando o comando az keyvault key import do Azure
PowerShell.
Em ambos os casos, você fornecerá a ID do cofre de chaves da KEK e a URL da KEK para os parâmetros Set-
AzVMDiskEncryptionExtension -KeyEncryptionKeyVaultId e -KeyEncryptionKeyUrl do Azure PowerShell.
Observe que este exemplo pressupõe que você esteja usando o mesmo cofre de chaves para a chave de
criptografia de disco e a KEK.
$KeyVault = Get-AzKeyVault -VaultName "<your-unique-keyvault-name>" -ResourceGroupName "myResourceGroup"

$KEK = Get-AzKeyVaultKey -VaultName "<your-unique-keyvault-name>" -Name "myKEK"

$KeyVault.VaultUri -DiskEncryptionKeyVaultId $KeyVault.ResourceId -KeyEncryptionKeyVaultId
$KeyVault.ResourceId -KeyEncryptionKeyUrl $KEK.Id -SkipVmBackup -VolumeType All
Próximas etapas
Conheça os Cenários de Azure Disk Encryption em VMs Windows
Saiba como solucionar problemas do Azure Disk Encryption
Leia os Scripts de exemplo do Azure Disk Encryption
Azure Disk Encryption scripts de exemplo para VMs
Linux
Este artigo fornece scripts de exemplo para a preparação de VHDs e outras tarefas criptografados previamente.
NOTE
Todos os scripts referem-se à versão mais recente e não AAD do ADE, exceto quando indicado.
Exemplos de scripts do PowerShell para Azure Disk Encryption

Listar todas as VMs criptografadas na assinatura
Você pode encontrar todas as VMs com criptografia de ADE e a versão de extensão, em todos os grupos
de recursos presentes em uma assinatura, usando este script do PowerShell.
Como alternativa, esses cmdlets mostrarão todas as VMs com criptografia de ADE (mas não a versão de
extensão):
$osVolEncrypted = {(Get-AzVMDiskEncryptionStatus -ResourceGroupName $_.ResourceGroupName -VMName

$_.Name).OsVolumeEncrypted}
$dataVolEncrypted= {(Get-AzVMDiskEncryptionStatus -ResourceGroupName $_.ResourceGroupName -VMName
$_.Name).DataVolumesEncrypted}
Get-AzVm | Format-Table @{Label="MachineName"; Expression={$_.Name}}, @{Label="OsVolumeEncrypted";
Expression=$osVolEncrypted}, @{Label="DataVolumesEncrypted"; Expression=$dataVolEncrypted}
Listar todas as instâncias VMSS criptografadas em sua assinatura

Você pode encontrar todas as instâncias de VMSS criptografadas por ADE e a versão de extensão, em
todos os grupos de recursos presentes em uma assinatura, usando este script do PowerShell.
Listar todos os segredos de criptografia de disco usados para criptografar VMs em um cofre
de chaves
Get-AzKeyVaultSecret -VaultName $KeyVaultName | where

{$_.Tags.ContainsKey('DiskEncryptionKeyFileName')} | format-table @{Label="MachineName"; Expression=
{$_.Tags['MachineName']}}, @{Label="VolumeLetter"; Expression={$_.Tags['VolumeLetter']}},
@{Label="EncryptionKeyURL"; Expression={$_.Id}}
Usando o script do PowerShell de pré -requisitos do Azure Disk Encryption

Se você já estiver familiarizado com os pré-requisitos do Azure Disk Encryption, use o script do PowerShell de
pré-requisitos do Azure Disk Encryption. Para obter um exemplo de como usar esse script do PowerShell,
confira o Guia de início rápido para criptografar uma VM. Você pode remover os comentários de uma seção do
script, começando na linha 211, para criptografar todos os discos de VMs existentes em um grupo de recursos
existente.
A tabela a seguir mostra quais parâmetros podem ser usados no script do PowerShell:
PA RÂ M ET RO DESC RIÇ Ã O O B RIGATÓ RIO ?
$resourceGroupName Nome do grupo de recursos ao qual o Verdadeiro

KeyVault pertence. Um grupo de
recursos com esse nome será criado
caso ele ainda não exista.
$keyVaultName Nome do KeyVault no qual as chaves Verdadeiro

de criptografia devem ser colocadas.
Um cofre com esse nome será criado
$location Local do KeyVault. Verifique se o Verdadeiro

KeyVault e as VMs a serem
criptografadas estão no mesmo local.
Obtenha uma lista de locais com
Get-AzLocation .
$subscriptionId Identificador da assinatura do Azure a Verdadeiro

ser usada. Você pode obter sua ID de
assinatura com Get-AzSubscription .
$aadAppName Nome do aplicativo do Azure AD que Falso

será usado para gravar segredos no
KeyVault. Será criado um novo
aplicativo com esse nome caso ele não
exista. Se esse aplicativo já existir, passe
o parâmetro aadClientSecret para o
script.
$aadClientSecret Segredo do cliente do aplicativo do Falso

Azure AD que já foi criado.
$keyEncryptionKeyName Nome da chave de criptografia da Falso

chave opcional no KeyVault. Uma
chave com esse nome será criada caso
ela ainda não exista.
Criptografar ou descriptografar VMs sem um aplicativo do Azure AD

Habilitar a criptografia de disco em uma VM Linux existente ou em execução
Desabilitar criptografia em uma VM do Linux em execução
Criptografar ou descriptografar VMs com um aplicativo do Azure AD (versão anterior)
Habilitar a criptografia de disco em uma VM Linux existente ou em execução
Desabilitar criptografia em uma VM do Linux em execução
Criar um novo disco gerenciado criptografado a partir de um blob de armazenamento/VHD previamente
criptografado
Cria um disco gerenciado criptografado fornecido usando um VHD pré-criptografado e as
configurações de criptografia correspondentes
Criptografando uma unidade do sistema operacional em uma VM do

Linux em execução
Pré -requisitos para a criptografia de disco do sistema operacional
A VM deve usar uma distribuição compatível com a criptografia de disco do sistema operacional, conforme
listado no Azure Disk Encryption sistemas operacionais com suporte
A VM deve ser criada com base na imagem do Marketplace no Azure Resource Manager.
VM do Azure com, no mínimo, 4 GB de RAM (o tamanho recomendável é de 7 GB).
(Para RHEL e CentOS) Desabilite o SELinux. Para desabilitar SELinux, confira "4.4.2. Desabilitando o SELinux"
no Guia do Administrador e Usuário do SELinux na VM.
Depois de desabilitar o SELinux, reinicialize a VM pelo menos uma vez.
Etapas
1. Crie uma VM usando uma das distribuições especificadas anteriormente.
Para o CentOS 7.2, há suporte para a criptografia de disco do sistema operacional por meio de uma
imagem especial. Para usar essa imagem, especifique "7.2n" como o SKU quando você criar a VM:
Set-AzVMSourceImage -VM $VirtualMachine -PublisherName "OpenLogic" -Offer "CentOS" -Skus "7.2n" -

Version "latest"
2. Configure a VM de acordo com suas necessidades. Se você for criptografar todas as unidades (sistema
operacional + dados), as unidades de dados precisarão ser especificadas e montadas em /etc/fstab.
NOTE
Use UUID=... para especificar unidades de dados em/etc/fstab em vez de especificar o nome do dispositivo de
blocos (por exemplo, /dev/sdb1). Durante a criptografia, a ordem das é alterada na VM. Se a VM se basear em
uma ordem específica de dispositivos de blocos, ela não conseguirá montá-los após a criptografia.
3. Saia das sessões do SSH.

4. Para criptografar o SO, especifique volumeType como Todos ou SO ao habilitar a criptografia.
NOTE
Todos os processos de espaço de usuário que não estão sendo executados como serviços systemd deverão ser
encerrados com um SIGKILL . Reinicialize a VM. Ao habilitar a criptografia de disco do sistema operacional em
uma VM em execução, planeje o tempo de inatividade da VM.
5. Periodicamente, monitore o progresso da criptografia usando as instruções da próxima seção.

6. Depois que Get-AzVmDiskEncryptionStatus Mostrar "VMRestartPending", reinicie a VM conectando-se a
ela ou usando o portal, o PowerShell ou a CLI.
C:\> Get-AzVmDiskEncryptionStatus -ResourceGroupName $ResourceGroupName -VMName $VMName

-ExtensionName $ExtensionName
OsVolumeEncrypted : VMRestartPending
ProgressMessage : OS disk successfully encrypted, reboot the VM
Antes de reinicializar, recomendamos que você salve os diagnósticos de inicialização da VM.

Monitorando o progresso da criptografia do sistema operacional
Você pode monitorar o progresso de criptografia do sistema operacional de três maneiras:
Use o cmdlet Get-AzVmDiskEncryptionStatus e verifique o campo ProgressMessage:
Depois que a VM atingir a "Criptografia de disco do sistema operacional iniciada", levará cerca de 40 a 50
minutos em uma VM com backup de armazenamento Premium.
Devido ao problema 388 no WALinuxAgent, OsVolumeEncrypted e DataVolumesEncrypted são mostrados
como Unknown em algumas distribuições. Com a versão 2.1.5 WALinuxAgent e posterior, esse problema é
corrigido automaticamente. Caso você veja Unknown na saída, poderá verificar o status da criptografia de
disco usando o Explorador de Recursos do Azure.
Vá para Explorador de Recursos do Azure e expanda essa hierarquia no painel de seleção à esquerda:
|-- subscriptions
|-- [Your subscription]
|-- resourceGroups
|-- [Your resource group]
|-- providers
|-- Microsoft.Compute
|-- virtualMachines
|-- [Your virtual machine]
|-- InstanceView
Em InstanceView, role a tela para baixo para ver o status da criptografia das unidades.
Examine o diagnóstico de inicialização. As mensagens da extensão ADE devem ser prefixadas com
[AzureDiskEncryption] .
Entre na VM via SSH e obtenha o log de extensão de:

/var/log/azure/Microsoft.Azure.Security.AzureDiskEncryptionForLinux
É recomendado que você não entre na máquina virtual enquanto a criptografia do sistema operacional
está em andamento. Copie os logs apenas quando os outros dois métodos falharem.

A preparação para VHDs previamente criptografados pode variar dependendo da distribuição. Exemplos sobre a
preparação do Ubuntu 16, openSUSE 13.2 e CentOS 7 estão disponíveis.
Ubuntu 16
Configure a criptografia durante a instalação da distribuição, realizando as seguintes etapas:
1. Selecione Configurar volumes criptografados ao particionar os discos.
2. Crie uma unidade de inicialização separada que não deverá ser criptografada. Criptografe a unidade de
inicialização.
3. Forneça uma senha. Essa é a senha que você enviou para o cofre de chaves.
4. Conclua o particionamento.
5. Quando você inicializar a VM e precisar fornecer uma frase secreta, use a senha que forneceu na etapa 3.
6. Prepare a VM para upload no Azure usando estas instruções. Não execute a última etapa
(desprovisionamento da VM) ainda.
Configure a criptografia para trabalhar com o Azure, executando as seguintes etapas:
1. Crie um arquivo em /usr/local/sbin/azure_crypt_key.sh com o conteúdo no script a seguir. Preste atenção
ao KeyFileName, pois esse é o nome do arquivo de frase secreta usado pelo Azure.
#!/bin/sh
MountPoint=/tmp-keydisk-mount
KeyFileName=LinuxPassPhraseFileName
echo "Trying to get the key from disks ..." >&2
mkdir -p $MountPoint
modprobe vfat >/dev/null 2>&1
modprobe ntfs >/dev/null 2>&1
sleep 2
OPENED=0
cd /sys/block
for DEV in sd*; do
echo "> Trying device: $DEV ..." >&2

mount -t vfat -r /dev/${DEV}1 $MountPoint >/dev/null||
mount -t ntfs -r /dev/${DEV}1 $MountPoint >/dev/null
if [ -f $MountPoint/$KeyFileName ]; then
cat $MountPoint/$KeyFileName
umount $MountPoint 2>/dev/null
OPENED=1
break
fi
umount $MountPoint 2>/dev/null
done
if [ $OPENED -eq 0 ]; then

echo "FAILED to find suitable passphrase file ..." >&2
echo -n "Try to enter your password: " >&2
read -s -r A </dev/console
echo -n "$A"
else
echo "Success loading keyfile!" >&2
fi
2. Altere a configuração de criptografia em /etc/crypttab . Ele deverá ser parecido com:
xxx_crypt uuid=xxxxxxxxxxxxxxxxxxxxx none luks,discard,keyscript=/usr/local/sbin/azure_crypt_key.sh
3. Adicione permissões executáveis ao script:
chmod +x /usr/local/sbin/azure_crypt_key.sh
4. Edite /etc/initramfs-tools/modules acrescentando linha:
vfat
ntfs
nls_cp437
nls_utf8
nls_iso8859-1
5. Execute update-initramfs -u -k all para atualizar o initramfs para fazer com que o keyscript entre em
vigor.
6. Agora, você poderá desprovisionar a VM.
7. Continue na próxima etapa e carregue o VHD no Azure.
openSUSE 13.2
Para configurar a criptografia durante a instalação da distribuição, execute as seguintes etapas:
1. Ao particionar os discos, selecione Criptografar o Grupo de Volumes e digite uma senha. Essa é a
senha que você carregará no cofre de chaves.
2. Inicialize a VM usando uma senha.
3. Prepare a VM para carregamento no Azure seguindo as instruções em Preparar uma máquina virtual do
SLES ou openSUSE para o Azure. Não execute a última etapa (desprovisionamento da VM) ainda.
Para configurar a criptografia para funcionar com o Azure, execute as seguintes etapas:
1. Edite o /etc/dracut.conf e adicione a seguinte linha:
add_drivers+=" vfat ntfs nls_cp437 nls_iso8859-1"
2. Comente essas linhas ao final do arquivo /usr/lib/dracut/modules.d/90crypt/module-setup.sh:
# inst_multiple -o \
# $systemdutildir/system-generators/systemd-cryptsetup-generator \
# $systemdutildir/systemd-cryptsetup \
# $systemdsystemunitdir/systemd-ask-password-console.path \
# $systemdsystemunitdir/systemd-ask-password-console.service \
# $systemdsystemunitdir/cryptsetup.target \
# $systemdsystemunitdir/sysinit.target.wants/cryptsetup.target \
# systemd-ask-password systemd-tty-ask-password-agent
# inst_script "$moddir"/crypt-run-generator.sh /sbin/crypt-run-generator
3. Acrescente a seguinte linha no início do arquivo /usr/lib/dracut/modules.d/90crypt/parse-crypt.sh:
DRACUT_SYSTEMD=0
E altere todas as ocorrências de:
if [ -z "$DRACUT_SYSTEMD" ]; then
para:
if [ 1 ]; then
4. Edite/usr/lib/Dracut/modules.d/90crypt/cryptroot-Ask.sh e acrescente-o a "# Open LUKS Device":
mkdir -p $MountPoint >&2
modprobe vfat >/dev/null >&2
modprobe ntfs >/dev/null >&2
for SFS in /dev/sd*; do
echo "> Trying device:$SFS..." >&2
mount ${SFS}1 $MountPoint -t vfat -r >&2 ||
mount ${SFS}1 $MountPoint -t ntfs -r >&2
echo "> keyfile got..." >&2
cp $MountPoint/$KeyFileName /tmp-keyfile >&2
luksfile=/tmp-keyfile
umount $MountPoint >&2
break
fi
done
5. Execute /usr/sbin/dracut -f -v para atualizar o initrd.

6. Agora é possível desprovisionar a VM e carregar o VHD no Azure.
CentOS 7 e RHEL 7
Para configurar a criptografia durante a instalação da distribuição, execute as seguintes etapas:
1. Selecione Criptografar meus dados ao particionar os discos.
2. Verifique se a opção Criptografar está selecionada para a partição raiz.
3. Forneça uma senha. Essa é a frase secreta que você enviará ao cofre de chaves.
4. Quando você inicializar a VM e precisar fornecer uma frase secreta, use a senha que forneceu na etapa 3.
5. Prepare a VM para carregamento no Azure usando as instruções de "CentOS 7.0+" em Preparar uma
máquina virtual baseada em CentOS para o Azure. Não execute a última etapa (desprovisionamento da
VM) ainda.
6. Agora é possível desprovisionar a VM e carregar o VHD no Azure.
Para configurar a criptografia para funcionar com o Azure, execute as seguintes etapas:
1. Edite o /etc/dracut.conf e adicione a seguinte linha:
add_drivers+=" vfat ntfs nls_cp437 nls_iso8859-1"
2. Comente essas linhas ao final do arquivo /usr/lib/dracut/modules.d/90crypt/module-setup.sh:
# inst_multiple -o \
# $systemdutildir/system-generators/systemd-cryptsetup-generator \
# $systemdutildir/systemd-cryptsetup \
# $systemdsystemunitdir/systemd-ask-password-console.path \
# $systemdsystemunitdir/systemd-ask-password-console.service \
# $systemdsystemunitdir/cryptsetup.target \
# $systemdsystemunitdir/sysinit.target.wants/cryptsetup.target \
# systemd-ask-password systemd-tty-ask-password-agent
# inst_script "$moddir"/crypt-run-generator.sh /sbin/crypt-run-generator
3. Acrescente a seguinte linha no início do arquivo /usr/lib/dracut/modules.d/90crypt/parse-crypt.sh:
DRACUT_SYSTEMD=0
E altere todas as ocorrências de:

if [ -z "$DRACUT_SYSTEMD" ]; then
para
if [ 1 ]; then
4. Edite/usr/lib/Dracut/modules.d/90crypt/cryptroot-Ask.sh e acrescente o seguinte após o "# Open LUKS

Device":
mkdir -p $MountPoint >&2
modprobe vfat >/dev/null >&2
modprobe ntfs >/dev/null >&2
for SFS in /dev/sd*; do
echo "> Trying device:$SFS..." >&2
mount ${SFS}1 $MountPoint -t vfat -r >&2 ||
mount ${SFS}1 $MountPoint -t ntfs -r >&2
echo "> keyfile got..." >&2
cp $MountPoint/$KeyFileName /tmp-keyfile >&2
luksfile=/tmp-keyfile
umount $MountPoint >&2
break
fi
done
5. Execute o "/usr/sbin/Dracut-f-v" para atualizar o initrd.
Carregue o VHD criptografado para uma conta de armazenamento do

Azure
Depois que a criptografia de DM-Crypt estiver habilitada, o VHD criptografado local precisará ser carregado em
sua conta de armazenamento.
Add-AzVhd [-Destination] <Uri> [-LocalFilePath] <FileInfo> [[-NumberOfUploaderThreads] <Int32> ] [[-

BaseImageUriToPatch] <Uri> ] [[-OverWrite]] [ <CommonParameters>]
Carregar o segredo da VM previamente criptografada no cofre de

chaves
Ao criptografar usando um aplicativo do Azure AD (versão anterior), você precisa carregar o segredo da
criptografia de disco já obtido, como um segredo no cofre de chaves. O cofre de chaves deve ter criptografia de
disco e permissões habilitadas para o cliente do Azure AD.
$AadClientId = "My-AAD-Client-Id"
$AadClientSecret = "My-AAD-Client-Secret"
$key vault = New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $ResourceGroupName -Location

$Location
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $ResourceGroupName -

ServicePrincipalName $AadClientId -PermissionsToKeys all -PermissionsToSecrets all
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $ResourceGroupName -
Segredo de criptografia de disco não criptografado com uma KEK

Para configurar o segredo em seu cofre de chaves, use set-AzKeyVaultSecret. A frase secreta é codificada como
uma cadeia de caracteres Base64 e, em seguida, carregada no cofre de chaves. Além disso, verifique se as
seguintes marcas estão definidas ao criar o segredo no cofre de chaves.
# This is the passphrase that was provided for encryption during the distribution installation
$passphrase = "contoso-password"
$tags = @{"DiskEncryptionKeyEncryptionAlgorithm" = "RSA-OAEP"; "DiskEncryptionKeyFileName" =

"LinuxPassPhraseFileName"}
$secretName = [guid]::NewGuid().ToString()
$secretValue = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($passphrase))
$secureSecretValue = ConvertTo-SecureString $secretValue -AsPlainText -Force
$secret = Set-AzKeyVaultSecret -VaultName $KeyVaultName -Name $secretName -SecretValue $secureSecretValue -

tags $tags
$secretUrl = $secret.Id
Use o $secretUrl na próxima etapa para anexar o disco do sistema operacional sem usar KEK.
Segredo de criptografia de disco criptografado com uma KEK
Antes de carregar o segredo no cofre de chaves, opcionalmente, você pode criptografá-lo usando uma chave de
criptografia de chave. Use a API de encapsulamento para primeiro criptografar o segredo usando a chave de
criptografia de chave. A saída dessa operação de encapsulamento é uma cadeia de caracteres codificada de URL
base64, que você pode carregar como um segredo usando o Set-AzKeyVaultSecret cmdlet.
Add-AzKeyVaultKey -VaultName $KeyVaultName -Name "keyencryptionkey" -Destination Software

$KeyEncryptionKey = Get-AzKeyVaultKey -VaultName $KeyVault.OriginalVault.Name -Name "keyencryptionkey"
$apiversion = "2015-06-01"
##############################
# Get Auth URI
##############################
$uri = $KeyVault.VaultUri + "/keys"

$headers = @{}
$response = try { Invoke-RestMethod -Method GET -Uri $uri -Headers $headers } catch {
$_.Exception.Response }
$authHeader = $response.Headers["www-authenticate"]
$authUri = [regex]::match($authHeader, 'authorization="(.*?)"').Groups[1].Value
Write-Host "Got Auth URI successfully"
##############################
# Get Auth Token
##############################
$uri = $authUri + "/oauth2/token"

$body = "grant_type=client_credentials"
$body += "&client_id=" + $AadClientId
$body += "&client_secret=" + [Uri]::EscapeDataString($AadClientSecret)
$body += "&resource=" + [Uri]::EscapeDataString("https://vault.azure.net")
$headers = @{}
$response = Invoke-RestMethod -Method POST -Uri $uri -Headers $headers -Body $body
$access_token = $response.access_token
Write-Host "Got Auth Token successfully"
##############################
# Get KEK info
##############################
$uri = $KeyEncryptionKey.Id + "?api-version=" + $apiversion

$headers = @{"Authorization" = "Bearer " + $access_token}
$response = Invoke-RestMethod -Method GET -Uri $uri -Headers $headers
$keyid = $response.key.kid
Write-Host "Got KEK info successfully"
##############################
# Encrypt passphrase using KEK
##############################
$passphraseB64 = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Passphrase))
$uri = $keyid + "/encrypt?api-version=" + $apiversion
$headers = @{"Authorization" = "Bearer " + $access_token; "Content-Type" = "application/json"}
$bodyObj = @{"alg" = "RSA-OAEP"; "value" = $passphraseB64}
$body = $bodyObj | ConvertTo-Json
$wrappedSecret = $response.value
Write-Host "Encrypted passphrase successfully"
##############################
# Store secret
##############################
$uri = $KeyVault.VaultUri + "/secrets/" + $secretName + "?api-version=" + $apiversion
$secretAttributes = @{"enabled" = $true}
$secretTags = @{"DiskEncryptionKeyEncryptionAlgorithm" = "RSA-OAEP"; "DiskEncryptionKeyFileName" =
$bodyObj = @{"value" = $wrappedSecret; "attributes" = $secretAttributes; "tags" = $secretTags}
$response = Invoke-RestMethod -Method PUT -Uri $uri -Headers $headers -Body $body
Write-Host "Stored secret successfully"
$secretUrl = $response.id
Use $KeyEncryptionKey e $secretUrl na próxima etapa para anexar o disco do sistema operacional usando KEK.
Especificar uma URL secreta ao anexar um disco do sistema

operacional
Sem usar uma KEK
Enquanto você está anexando o disco do sistema operacional, é necessário passar $secretUrl . A URL foi gerada
na seção "Segredo de criptografia de disco não criptografado com uma KEK".
Set-AzVMOSDisk `
-VM $VirtualMachine `
-Name $OSDiskName `
-SourceImageUri $VhdUri `
-VhdUri $OSDiskUri `
-Linux `
-DiskEncryptionKeyVaultId $KeyVault.ResourceId `
-DiskEncryptionKeyUrl $SecretUrl
Usando uma KEK

Ao anexar o disco do sistema operacional, passe $KeyEncryptionKey e $secretUrl . A URL foi gerada na seção
"Segredo de criptografia de disco criptografado com KEK".
Set-AzVMOSDisk `
-Name $OSDiskName `
-SourceImageUri $CopiedTemplateBlobUri `
-Linux `
-DiskEncryptionKeyUrl $SecretUrl `
-KeyEncryptionKeyVaultId $KeyVault.ResourceId `
-KeyEncryptionKeyURL $KeyEncryptionKey.Id
Este artigo fornece scripts de exemplo para a preparação de VHDs e outras tarefas criptografados previamente.
NOTE
Todos os scripts referem-se à versão mais recente e não AAD do ADE, exceto quando indicado.
Exemplos de scripts do PowerShell para Azure Disk Encryption

Listar todas as VMs criptografadas na assinatura
Você pode encontrar todas as VMs com criptografia de ADE e a versão de extensão, em todos os grupos
de recursos presentes em uma assinatura, usando este script do PowerShell.
Como alternativa, esses cmdlets mostrarão todas as VMs com criptografia de ADE (mas não a versão de
extensão):
$osVolEncrypted = {(Get-AzVMDiskEncryptionStatus -ResourceGroupName $_.ResourceGroupName -VMName

$_.Name).OsVolumeEncrypted}
$dataVolEncrypted= {(Get-AzVMDiskEncryptionStatus -ResourceGroupName $_.ResourceGroupName -VMName
$_.Name).DataVolumesEncrypted}
Get-AzVm | Format-Table @{Label="MachineName"; Expression={$_.Name}}, @{Label="OsVolumeEncrypted";
Expression=$osVolEncrypted}, @{Label="DataVolumesEncrypted"; Expression=$dataVolEncrypted}
Listar todas as instâncias VMSS criptografadas em sua assinatura

Você pode encontrar todas as instâncias de VMSS criptografadas por ADE e a versão de extensão, em
todos os grupos de recursos presentes em uma assinatura, usando este script do PowerShell.
Listar todos os segredos de criptografia de disco usados para criptografar VMs em um cofre
de chaves
Get-AzKeyVaultSecret -VaultName $KeyVaultName | where {$_.Tags.ContainsKey('DiskEncryptionKeyFileName')} |

format-table @{Label="MachineName"; Expression={$_.Tags['MachineName']}}, @{Label="VolumeLetter";
Expression={$_.Tags['VolumeLetter']}}, @{Label="EncryptionKeyURL"; Expression={$_.Id}}
Usando o script do PowerShell de pré -requisitos do Azure Disk Encryption

Se você já estiver familiarizado com os pré-requisitos do Azure Disk Encryption, use o script do PowerShell de
pré-requisitos do Azure Disk Encryption. Para obter um exemplo de como usar esse script do PowerShell,
confira o Guia de início rápido para criptografar uma VM. Você pode remover os comentários de uma seção do
script, começando na linha 211, para criptografar todos os discos de VMs existentes em um grupo de recursos
existente.
A tabela a seguir mostra quais parâmetros podem ser usados no script do PowerShell:

$resourceGroupName Nome do grupo de recursos ao qual o Verdadeiro

KeyVault pertence. Um grupo de
recursos com esse nome será criado
$keyVaultName Nome do KeyVault no qual as chaves Verdadeiro

de criptografia devem ser colocadas.
Um cofre com esse nome será criado
$location Local do KeyVault. Verifique se o Verdadeiro

KeyVault e as VMs a serem
criptografadas estão no mesmo local.
Obtenha uma lista de locais com
Get-AzLocation .
$subscriptionId Identificador da assinatura do Azure a Verdadeiro

ser usada. Você pode obter sua ID de
assinatura com Get-AzSubscription .
$aadAppName Nome do aplicativo do Azure AD que Falso

será usado para gravar segredos no
KeyVault. Será criado um novo
aplicativo com esse nome caso ele não
exista. Se esse aplicativo já existir, passe
o parâmetro aadClientSecret para o
script.
$aadClientSecret Segredo do cliente do aplicativo do Falso

Azure AD que já foi criado.
$keyEncryptionKeyName Nome da chave de criptografia da Falso

chave opcional no KeyVault. Uma
chave com esse nome será criada caso
ela ainda não exista.
Modelos do Gerenciador de Recursos

Criptografar ou descriptografar VMs sem um aplicativo do Azure AD
Habilitar a criptografia de disco em uma VM do Windows existente ou em execução
Desabilitar a criptografia em uma VM do Windows em execução
Criptografar ou descriptografar VMs com um aplicativo do Azure AD (versão anterior)
Habilitar a criptografia de disco em uma VM do Windows existente ou em execução
Desabilitar a criptografia em uma VM do Windows em execução
Criar um novo disco gerenciado criptografado a partir de um blob de armazenamento/VHD previamente
criptografado
Cria um disco gerenciado criptografado fornecido usando um VHD pré-criptografado e as
configurações de criptografia correspondentes
Preparar um VHD do Windows previamente criptografado

As seções a seguir são necessárias para preparar um VHD do Windows previamente criptografado para
implantação como um VHD criptografado no Azure IaaS. Use as informações para preparar e inicializar uma
nova VHD (VM do Windows) no Azure Site Recovery ou no Azure. Para obter mais informações sobre como
preparar e carregar um VHD, consulte Carregar um VHD generalizado e usá-lo para criar novas VMs no Azure.
Atualizar a política de grupo para permitir não TPM na proteção do sistema operacional
Configure a política de grupo do BitLocker Criptografia de Unidade de Disco BitLocker , que você
encontrará em Política de Computador Local > Configuração do Computador > Modelos
Administrativos > Componentes do Windows . Alterar essa configuração para unidades do sistema
operacional > exigir autenticação adicional na inicialização > permitir BitLocker sem um TPM
compatível , conforme mostrado na figura a seguir:
Instalar componentes de recursos do BitLocker

Para o Windows Server 2012 e versões posteriores, use o seguinte comando:
dism /online /Enable-Feature /all /FeatureName:BitLocker /quiet /norestart
Para o Windows Server 2008 R2, use o seguinte comando:
ServerManagerCmd -install BitLockers
Preparar o volume do sistema operacional para o BitLocker usando bdehdcfg
Para compactar a partição do SO e preparar o computador para BitLocker, execute o bdehdcfg, se necessário:
bdehdcfg -target c: shrink -quiet
Proteger o volume do sistema operacional usando o BitLocker

Use o manage-bde comando para habilitar a criptografia no volume de inicialização usando um protetor de
chave externa. Também coloque a chave externa (arquivo .bek) na unidade ou no volume. A criptografia é
habilitada no volume de inicialização/sistema após a próxima reinicialização.
manage-bde -on %systemdrive% -sk [ExternalDriveOrVolume]
reboot
NOTE
Prepare a VM com um VHD de dados/recursos separado para obter a chave externa usando o BitLocker.
Carregue o VHD criptografado para uma conta de armazenamento do

Azure
Depois que a criptografia de DM-Crypt estiver habilitada, o VHD criptografado local precisará ser carregado em
sua conta de armazenamento.
Add-AzVhd [-Destination] <Uri> [-LocalFilePath] <FileInfo> [[-NumberOfUploaderThreads] <Int32> ] [[-

BaseImageUriToPatch] <Uri> ] [[-OverWrite]] [ <CommonParameters>]
Carregar o segredo da VM previamente criptografada no cofre de

chaves
O segredo de criptografia de disco que você obteve anteriormente deve ser carregado como um segredo no
cofre de chaves. Isso requer a concessão da permissão Set Secret e a permissão wrapkey para a conta que
carregará os segredos.
# Typically, account Id is the user principal name (in user@domain.com format)

$upn = (Get-AzureRmContext).Account.Id
Set-AzKeyVaultAccessPolicy -VaultName $kvname -UserPrincipalName $acctid -PermissionsToKeys wrapKey -
PermissionsToSecrets set
# In cloud shell, the account ID is a managed service identity, so specify the username directly
# $upn = "user@domain.com"
# Set-AzKeyVaultAccessPolicy -VaultName $kvname -UserPrincipalName $acctid -PermissionsToKeys wrapKey -
PermissionsToSecrets set
# When running as a service principal, retrieve the service principal ID from the account ID, and set access
policy to that
# $acctid = (Get-AzureRmContext).Account.Id
# $spoid = (Get-AzureRmADServicePrincipal -ServicePrincipalName $acctid).Id
# Set-AzKeyVaultAccessPolicy -VaultName $kvname -ObjectId $spoid -BypassObjectIdValidation -
PermissionsToKeys wrapKey -PermissionsToSecrets set
Segredo de criptografia de disco não criptografado com uma KEK

Para configurar o segredo em seu cofre de chaves, use set-AzKeyVaultSecret. A frase secreta é codificada como
uma cadeia de caracteres Base64 e, em seguida, carregada no cofre de chaves. Além disso, verifique se as
seguintes marcas estão definidas ao criar o segredo no cofre de chaves.
$tags = @{"DiskEncryptionKeyEncryptionAlgorithm" = "RSA-OAEP"; "DiskEncryptionKeyFileName" =

$secretValue = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($passphrase))
$secureSecretValue = ConvertTo-SecureString $secretValue -AsPlainText -Force
$secret = Set-AzKeyVaultSecret -VaultName $KeyVaultName -Name $secretName -SecretValue $secureSecretValue -

tags $tags
$secretUrl = $secret.Id
Use o $secretUrl na próxima etapa para anexar o disco do sistema operacional sem usar KEK.
Segredo de criptografia de disco criptografado com uma KEK
Antes de carregar o segredo no cofre de chaves, opcionalmente, você pode criptografá-lo usando uma chave de
criptografia de chave. Use a API de encapsulamento para primeiro criptografar o segredo usando a chave de
criptografia de chave. A saída dessa operação de encapsulamento é uma cadeia de caracteres codificada de URL
base64, que você pode carregar como um segredo usando o Set-AzKeyVaultSecret cmdlet.

$KeyEncryptionKey = Get-AzKeyVaultKey -VaultName $KeyVault.OriginalVault.Name -Name "keyencryptionkey"
$apiversion = "2015-06-01"
##############################
# Get Auth URI
##############################
$uri = $KeyVault.VaultUri + "/keys"

$headers = @{}
$response = try { Invoke-RestMethod -Method GET -Uri $uri -Headers $headers } catch {
$_.Exception.Response }
$authHeader = $response.Headers["www-authenticate"]
$authUri = [regex]::match($authHeader, 'authorization="(.*?)"').Groups[1].Value
Write-Host "Got Auth URI successfully"
##############################
# Get Auth Token
##############################
$uri = $authUri + "/oauth2/token"

$body = "grant_type=client_credentials"
$body += "&client_id=" + $AadClientId
$body += "&client_secret=" + [Uri]::EscapeDataString($AadClientSecret)
$body += "&resource=" + [Uri]::EscapeDataString("https://vault.azure.net")
$headers = @{}
$access_token = $response.access_token
Write-Host "Got Auth Token successfully"
##############################
# Get KEK info
##############################
##############################
$uri = $KeyEncryptionKey.Id + "?api-version=" + $apiversion

$headers = @{"Authorization" = "Bearer " + $access_token}
$response = Invoke-RestMethod -Method GET -Uri $uri -Headers $headers
$keyid = $response.key.kid
Write-Host "Got KEK info successfully"
##############################
# Encrypt passphrase using KEK
##############################
$passphraseB64 = [Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($Passphrase))
$uri = $keyid + "/encrypt?api-version=" + $apiversion
$bodyObj = @{"alg" = "RSA-OAEP"; "value" = $passphraseB64}
$wrappedSecret = $response.value
Write-Host "Encrypted passphrase successfully"
##############################
# Store secret
##############################
$uri = $KeyVault.VaultUri + "/secrets/" + $secretName + "?api-version=" + $apiversion
$secretAttributes = @{"enabled" = $true}
$secretTags = @{"DiskEncryptionKeyEncryptionAlgorithm" = "RSA-OAEP"; "DiskEncryptionKeyFileName" =
$bodyObj = @{"value" = $wrappedSecret; "attributes" = $secretAttributes; "tags" = $secretTags}
$response = Invoke-RestMethod -Method PUT -Uri $uri -Headers $headers -Body $body
Write-Host "Stored secret successfully"
$secretUrl = $response.id
Use $KeyEncryptionKey e $secretUrl na próxima etapa para anexar o disco do sistema operacional usando KEK.
Especificar uma URL secreta ao anexar um disco do sistema

operacional
Sem usar uma KEK
Enquanto você está anexando o disco do sistema operacional, é necessário passar $secretUrl . A URL foi gerada
na seção "Segredo de criptografia de disco não criptografado com uma KEK".
Set-AzVMOSDisk `
-Name $OSDiskName `
-SourceImageUri $VhdUri `
-Windows `
-DiskEncryptionKeyUrl $SecretUrl
Usando uma KEK

Ao anexar o disco do sistema operacional, passe $KeyEncryptionKey e $secretUrl . A URL foi gerada na seção
"Segredo de criptografia de disco criptografado com KEK".
Set-AzVMOSDisk `
-Name $OSDiskName `
-SourceImageUri $CopiedTemplateBlobUri `
-Windows `
-DiskEncryptionKeyUrl $SecretUrl `
-KeyEncryptionKeyVaultId $KeyVault.ResourceId `
-KeyEncryptionKeyURL $KeyEncryptionKey.Id
Azure Disk Encryption em uma rede isolada
Quando a conectividade estiver restrita por requisitos de proxy, firewall ou NSG (grupo de segurança de rede), a
capacidade da extensão para executar as tarefas necessárias poderá ser interrompida. Essa interrupção pode
resultar em mensagens de status como "Status da extensão não disponível na VM".
Gerenciamento de pacotes
Azure Disk Encryption depende de vários componentes, que são normalmente instalados como parte da
habilitação de ADE, se ainda não estiverem presentes. Quando por trás de um firewall ou de outra forma isolada
da Internet, esses pacotes devem ser pré-instalados ou disponíveis localmente.
Aqui estão os pacotes necessários para cada distribuição. Para obter uma lista completa dos tipos de volume e
distribuições com suporte, consulte VMs e sistemas operacionais com suporte.
Ubuntu 14, 4, 16, 4, 18, 4 : lsscsi, psmisc, at, cryptsetup-bin, Python-in, Python-seis, procps, grub-pc-bin
CentOS 7,2-7,7 : lsscsi, psmisc, lvm2, UUID, em, patch, cryptsetup, cryptsetup-recriptografar, pyparted,
procps-ng, util-linux
CentOS 6,8 : lsscsi, psmisc, lvm2, UUID, at, cryptsetup – recriptografar, pyparted, Python-seis
RedHat 7,2-7,7 : lsscsi, psmisc, lvm2, UUID, em, patch, cryptsetup, cryptsetup-recriptografar, procps-ng, util-
linux
RedHat 6,8 : lsscsi, psmisc, lvm2, UUID, at, patch, cryptsetup – recriptografar
openSUSE 42,3, SLES 12-SP4, 12-SP3 : lsscsi, cryptsetup
No Red Hat, quando um proxy é necessário, é preciso garantir que o gerenciador de assinaturas e o yum sejam
configurados corretamente. Para saber mais, confira How to troubleshoot subscription-manager and yum
problems (Como solucionar problemas do gerenciador de assinaturas e do yum).
Quando os pacotes são instalados manualmente, eles também devem ser atualizados manualmente conforme
novas versões são lançadas.
Grupos de Segurança de Rede

Qualquer configuração do grupo de segurança de rede aplicada ainda deve permitir que o ponto de
extremidade atenda aos pré-requisitos da configuração de rede documentada para criptografia de disco.
Consulte Azure Disk Encryption: requisitos de rede
Azure Disk Encryption com o Azure AD (versão anterior)

Se você estiver usando Azure Disk Encryption com o Azure AD (versão anterior), a biblioteca de Azure Active
Directory precisará ser instalada manualmente para todos os distribuições (além dos pacotes apropriados para
o distribuição, conforme listado acima).
Quando a criptografia é habilitada com credenciais do Azure AD, a VM de destino deve permitir a conectividade
com pontos de extremidade do Azure Active Directory e pontos de extremidade do Key Vault. Os pontos de
extremidade de autenticação Azure Active Directory atuais são mantidos nas seções 56 e 59 da documentação
Microsoft 365 URLs e intervalos de endereços IP . As instruções do Key Vault são fornecidas na documentação
sobre como Acessar o Azure Key Vault por trás de um firewall.
A máquina virtual deve ser capaz de acessar o ponto de extremidade do serviço de metadados de instância do
Azure , que usa um endereço IP não roteável conhecido ( 169.254.169.254 ) que pode ser acessado somente de
dentro da VM. Não há suporte para as configurações de proxy que alteram o tráfego HTTP local para esse
endereço (por exemplo, a adição de um cabeçalho X-Forwarded-For).
Próximas etapas
Veja mais etapas para a solução de problemas de criptografia de disco do Azure
Criptografia de dados em repouso do Azure
Verificar o status da criptografia para Linux
O escopo deste artigo é validar o status de criptografia de uma máquina virtual usando métodos diferentes: o
portal do Azure, o PowerShell, a CLI do Azure ou o sistema operacional da VM (máquina virtual).
Você pode validar o status de criptografia durante ou após a criptografia realizando uma das seguintes ações:
Verificar os discos anexados a uma VM específica.
Consultar as configurações de criptografia em cada disco, independentemente de o disco estar anexado ou
desanexado.
Esse cenário se aplica às extensões de passagem dupla e de passagem única do Azure Disk Encryption. As
distribuições do Linux são o único ambiente para esse cenário.
NOTE
Estamos usando variáveis em todo o artigo. Substitua os valores adequadamente.
Portal
Na portal do Azure, dentro da seção Extensões , selecione a extensão Azure Disk Encryption na lista. As
informações para Mensagem de status indicam o status de criptografia atual:
Na lista de extensões, você verá a versão de extensão do Azure Disk Encryption correspondente. A versão 0.x
corresponde à passagem dupla do Azure Disk Encryption e a versão 1.x corresponde à passagem única do
Azure Disk Encryption.
Você pode obter mais detalhes selecionando a extensão e, em seguida, selecionando Exibir o status
detalhado . O status detalhado do processo de criptografia é exibido no formato JSON.
Outra maneira de validar o status de criptografia é observando a seção Configurações de disco .
NOTE
Esse status significa que as configurações de criptografia estão registradas nos discos, não que eles foram realmente
criptografados no nível do sistema operacional.
Por concepção, essas configurações são registradas nos discos primeiro e eles são criptografados posteriormente. Se o
processo de criptografia falhar, esse processo de registro nos discos poderá ser concluído, mas o mesmo não ocorre para
o processo de criptografia.
Para confirmar se os discos estão realmente criptografados, você pode verificar a criptografia de cada disco no nível do
PowerShell
Você pode validar o status de criptografia geral de uma VM criptografada usando os seguintes comandos do
PowerShell:
$VMNAME="VMNAME"
$RGNAME="RGNAME"
Get-AzVmDiskEncryptionStatus -ResourceGroupName ${RGNAME} -VMName ${VMNAME}
Você pode capturar as configurações de criptografia de cada disco usando os comandos do PowerShell a seguir.
Passagem única
Em uma passagem, as configurações de criptografia são registradas em cada um dos discos (SO e dados). Você
pode capturar as configurações de criptografia para um disco do sistema operacional em uma passagem única,
da seguinte maneira:
$RGNAME = "RGNAME"
$VMNAME = "VMNAME"
$VM = Get-AzVM -Name ${VMNAME} -ResourceGroupName ${RGNAME}

$Sourcedisk = Get-AzDisk -ResourceGroupName ${RGNAME} -DiskName $VM.StorageProfile.OsDisk.Name
Write-Host
"===========================================================================================================
=================================================="
Write-Host "Encryption Settings:"
Write-Host
"===========================================================================================================
=================================================="
Write-Host "Enabled:" $Sourcedisk.EncryptionSettingsCollection.Enabled
Write-Host "Version:" $Sourcedisk.EncryptionSettingsCollection.EncryptionSettingsVersion
Write-Host "Source Vault:"
$Sourcedisk.EncryptionSettingsCollection.EncryptionSettings.DiskEncryptionKey.SourceVault.Id
Write-Host "Secret URL:"
$Sourcedisk.EncryptionSettingsCollection.EncryptionSettings.DiskEncryptionKey.SecretUrl
Write-Host "Key URL:" $Sourcedisk.EncryptionSettingsCollection.EncryptionSettings.KeyEncryptionKey.KeyUrl
Write-Host
"===========================================================================================================
=================================================="
Se não houver configurações de criptografia registradas no disco, a saída estará vazia:
Use os seguintes comandos para capturar as configurações de criptografia para discos de dados:
$RGNAME = "RGNAME"
$VMNAME = "VMNAME"
$VM = Get-AzVM -Name ${VMNAME} -ResourceGroupName ${RGNAME}

clear
foreach ($i in $VM.StorageProfile.DataDisks|ForEach-Object{$_.Name})
{
Write-Host
"===========================================================================================================
=================================================="
Write-Host
"===========================================================================================================
=================================================="
Write-Host "Checking Disk:" $i
$Disk=(Get-AzDisk -ResourceGroupName ${RGNAME} -DiskName $i)
Write-Host "Encryption Enable: " $Sourcedisk.EncryptionSettingsCollection.Enabled
Write-Host "Encryption KeyEncryptionKey: "
$Sourcedisk.EncryptionSettingsCollection.EncryptionSettings.KeyEncryptionKey.KeyUrl;
Write-Host "Encryption DiskEncryptionKey: "
$Sourcedisk.EncryptionSettingsCollection.EncryptionSettings.DiskEncryptionKey.SecretUrl;
Write-Host
"===========================================================================================================
=================================================="
}
Passagem dupla
Em uma passagem dupla, as configurações de criptografia são registradas no modelo de VM e não em cada
disco individual.
Para verificar se as configurações de criptografia foram registradas em uma passagem dupla, use os seguintes
comandos:
$RGNAME = "RGNAME"
$VMNAME = "VMNAME"
$vm = Get-AzVm -ResourceGroupName ${RGNAME} -Name ${VMNAME};

$Sourcedisk = Get-AzDisk -ResourceGroupName ${RGNAME} -DiskName $VM.StorageProfile.OsDisk.Name
clear
Write-Host
"===========================================================================================================
=================================================="
Write-Host
"===========================================================================================================
=================================================="
Write-Host
"===========================================================================================================
=================================================="
Discos desconectados
Verifique as configurações de criptografia de discos que não estão anexados a uma VM.
Discos gerenciados
$Sourcedisk = Get-AzDisk -ResourceGroupName ${RGNAME} -DiskName ${TARGETDISKNAME}

Write-Host
"===========================================================================================================
=================================================="
Write-Host
"===========================================================================================================
=================================================="
Write-Host
"===========================================================================================================
=================================================="
CLI do Azure
Você pode validar o status de criptografia geral de uma VM criptografada usando os seguintes comandos da CLI
do Azure:
VMNAME="VMNAME"
RGNAME="RGNAME"
az vm encryption show --name ${VMNAME} --resource-group ${RGNAME} --query "substatus"
Passagem única
Você pode validar as configurações de criptografia de cada disco usando os seguintes comandos da CLI do
Azure:
az vm encryption show -g ${RGNAME} -n ${VMNAME} --query "disks[*].[name, statuses[*].displayStatus]" -o

table
IMPORTANT
Se as configurações de criptografia não estiverem registradas no disco, você verá o texto O disco não está
criptografado .
Use os comandos a seguir para obter configurações detalhadas de status e de criptografia.

Disco do sistema operacional:
RGNAME="RGNAME"
VMNAME="VNAME"
disk=àz vm show -g ${RGNAME} -n ${VMNAME} --query storageProfile.osDisk.name -o tsv`

for disk in $disk; do \
echo
"===========================================================================================================
=================================================="
echo -ne "Disk Name: "; az disk show -g ${RGNAME} -n ${disk} --query name -o tsv; \
echo -ne "Encryption Enabled: "; az disk show -g ${RGNAME} -n ${disk} --query
encryptionSettingsCollection.enabled -o tsv; \
echo -ne "Version: "; az disk show -g ${RGNAME} -n ${TARGETDISKNAME} --query
encryptionSettingsCollection.encryptionSettingsVersion -o tsv; \
echo -ne "Disk Encryption Key: "; az disk show -g ${RGNAME} -n ${disk} --query
encryptionSettingsCollection.encryptionSettings[].diskEncryptionKey.secretUrl -o tsv; \
echo -ne "key Encryption Key: "; az disk show -g ${RGNAME} -n ${disk} --query
encryptionSettingsCollection.encryptionSettings[].keyEncryptionKey.keyUrl -o tsv; \
echo
"===========================================================================================================
=================================================="
done
Discos de dados:
RGNAME="RGNAME"
VMNAME="VMNAME"
az vm encryption show --name ${VMNAME} --resource-group ${RGNAME} --query "substatus"
for disk in àz vm show -g ${RGNAME} -n ${VMNAME} --query storageProfile.dataDisks[].name -o tsv`; do \

echo
"===========================================================================================================
=================================================="; \
echo
"===========================================================================================================
=================================================="
done
Passagem dupla
az vm encryption show --name ${VMNAME} --resource-group ${RGNAME} -o table
Você também pode verificar as configurações de criptografia no perfil de armazenamento do modelo de VM do

disco do sistema operacional:
disk=àz vm show -g ${RGNAME} -n ${VMNAME} --query storageProfile.osDisk.name -o tsv`

for disk in $disk; do \
echo
"===========================================================================================================
=================================================="; \
echo
"===========================================================================================================
=================================================="
done
Discos desconectados
Verifique as configurações de criptografia de discos que não estão anexados a uma VM.
Discos gerenciados
RGNAME="RGNAME"
TARGETDISKNAME="DISKNAME"
echo
"===========================================================================================================
=================================================="
echo -ne "Disk Name: "; az disk show -g ${RGNAME} -n ${TARGETDISKNAME} --query name -o tsv; \
echo -ne "Encryption Enabled: "; az disk show -g ${RGNAME} -n ${TARGETDISKNAME} --query
echo -ne "Disk Encryption Key: "; az disk show -g ${RGNAME} -n ${TARGETDISKNAME} --query
echo -ne "key Encryption Key: "; az disk show -g ${RGNAME} -n ${TARGETDISKNAME} --query
echo
"===========================================================================================================
=================================================="
Discos não gerenciados
Discos não gerenciados são arquivos VHD armazenados como blobs de páginas nas contas de armazenamento
do Microsoft Azure.
Para obter os detalhes de um disco específico, você precisa fornecer:
A ID da conta de armazenamento que contém o disco.
Uma cadeia de conexão para essa conta de armazenamento específica.
O nome do contêiner que armazena o disco.
O nome do disco.
Este comando lista todas as IDs de todas as suas contas de armazenamento:
az storage account list --query [].[id] -o tsv
As IDs da conta de armazenamento são listadas no seguinte formato:

/subscriptions/ <subscription id> /ResourceGroups/ <resource group name>
/Providers/Microsoft.Storage/storageAccounts/<storage account name>
Selecione a ID apropriada e armazene-a em uma variável:
id="/subscriptions/<subscription id>/resourceGroups/<resource group

name>/providers/Microsoft.Storage/storageAccounts/<storage account name>"
Esse comando obtém a cadeia de conexão para uma conta de armazenamento específica e a armazena em uma
variável:
ConnectionString=$(az storage account show-connection-string --ids $id --query connectionString -o tsv)
O seguinte comando lista todos os contêineres em uma conta de armazenamento:
az storage container list --connection-string $ConnectionString --query [].[name] -o tsv
O contêiner usado para discos normalmente é denominado "vhds".

Armazene o nome do contêiner em uma variável:
ContainerName="name of the container"
Use este comando para listar todos os BLOBs em um contêiner específico:
az storage blob list -c ${ContainerName} --connection-string $ConnectionString --query [].[name] -o tsv
Escolha o disco que você deseja consultar e armazene o nome dele em uma variável:
DiskName="diskname.vhd"
Consultar as configurações de criptografia de disco:

az storage blob show -c ${ContainerName} --connection-string ${ConnectionString} -n ${DiskName} --query
metadata.DiskEncryptionSettings
Sistema operacional
Validar se as partições de disco de dados estão criptografadas (e o disco do sistema operacional não está).
Quando uma partição ou um disco está criptografado, ele é exibido como um tipo cr ypt . Quando não estiver
criptografado, ele será exibido como um tipo par t/disk .
lsblk
Você pode obter mais detalhes de configuração usando a variante lsblk a seguir.
Você verá uma camada de tipo cr ypt que é montada pela extensão. O exemplo a seguir mostra volumes lógicos
e discos normais com cr ypto_LUKS FSTYPE .
lsblk -o NAME,TYPE,FSTYPE,LABEL,SIZE,RO,MOUNTPOINT
Como uma etapa extra, você pode validar se o disco de dados tem alguma chave carregada:
cryptsetup luksDump /dev/VGNAME/LVNAME
cryptsetup luksDump /dev/sdd1
E você pode verificar quais dispositivos dm estão listados como cr ypt :
dmsetup ls --target crypt

Próximas etapas
Configurar o LVM e o RAID em dispositivos
criptografados
Este artigo é um processo passo a passo sobre como executar o LVM (gerenciamento de volume lógico) e RAID
em dispositivos criptografados. O processo se aplica aos seguintes ambientes:
Distribuições Linux
RHEL 7.6 +
Ubuntu 18.04 +
SUSE 12 +
Azure Disk Encryption extensão de passagem única
Extensão de passagem dupla Azure Disk Encryption
Cenários
Os procedimentos neste artigo dão suporte aos seguintes cenários:
Configurar o LVM sobre dispositivos criptografados (LVM-on-cript)
Configurar o RAID sobre dispositivos criptografados (RAID em criptografia)
Depois que o dispositivo ou dispositivos subjacentes forem criptografados, você poderá criar as estruturas LVM
ou RAID sobre essa camada criptografada.
Os volumes físicos (PVs) são criados na parte superior da camada criptografada. Os volumes físicos são usados
para criar o grupo de volumes. Você cria os volumes e adiciona as entradas necessárias em/etc/fstab.
De forma semelhante, o dispositivo RAID é criado no topo da camada criptografada nos discos. Um sistema de
arquivos é criado na parte superior do dispositivo RAID e adicionado ao/etc/fstab como um dispositivo normal.
Considerações
Recomendamos que você use LVM em cript. O RAID é uma opção quando o LVM não pode ser usado devido a
limitações específicas de aplicativo ou ambiente.
Você usará a opção Encr yptFormatAll . Para obter mais informações sobre essa opção, consulte usar o recurso
EncryptFormatAll para discos de dados em VMs do Linux.
Embora você possa usar esse método quando também estiver criptografando o sistema operacional, estamos
apenas criptografando as unidades de dados aqui.
Os procedimentos pressupõem que você já tenha revisado os pré-requisitos em cenários de Azure Disk
Encryption em VMs do Linux e no início rápido: criar e criptografar uma VM do linux com o CLI do Azure.
A Azure Disk Encryption versão de passagem dupla está em um caminho de substituição e não deve mais ser
usada em novas criptografias.
Etapas gerais
Quando você estiver usando as configurações "incompreensíveis", use o processo descrito nos procedimentos a
seguir.
NOTE
Estamos usando variáveis em todo o artigo. Substitua os valores adequadamente.

Os comandos a seguir são opcionais, mas é recomendável aplicá-los em uma VM (máquina virtual) implantada
recentemente.
PowerShell:
New-AzVm -ResourceGroupName ${RGNAME} `

-Name ${VMNAME} `
-Location ${LOCATION} `
-Size ${VMSIZE} `
-Image ${OSIMAGE} `
-Credential ${creds} `
-Verbose
CLI do Azure:
az vm create \
-n ${VMNAME} \
-g ${RGNAME} \
--image ${OSIMAGE} \
--admin-username ${username} \
--admin-password ${password} \
-l ${LOCATION} \
--size ${VMSIZE} \
-o table
Anexar discos à VM
Repita os comandos a seguir para o $N número de novos discos que você deseja anexar à VM.
PowerShell:
$storageType = 'Standard_LRS'
$dataDiskName = ${VMNAME} + '_datadisk0'
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $LOCATION -CreateOption Empty -DiskSizeGB 5
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName ${RGNAME}
$vm = Get-AzVM -Name ${VMNAME} -ResourceGroupName ${RGNAME}
$vm = Add-AzVMDataDisk -VM $vm -Name $dataDiskName -CreateOption Attach -ManagedDiskId $dataDisk1.Id -Lun 0
Update-AzVM -VM ${VM} -ResourceGroupName ${RGNAME}
CLI do Azure:
az vm disk attach \
-g ${RGNAME} \
--vm-name ${VMNAME} \
--name ${VMNAME}datadisk1 \
--size-gb 5 \
--new \
-o table
Verifique se os discos estão anexados à VM

PowerShell:
$VM = Get-AzVM -ResourceGroupName ${RGNAME} -Name ${VMNAME}

$VM.StorageProfile.DataDisks | Select-Object Lun,Name,DiskSizeGB
CLI do Azure:
az vm show -g ${RGNAME} -n ${VMNAME} --query storageProfile.dataDisks -o table
Portal:
sistema operacional:
lsblk
Configurar os discos a serem criptografados
Essa configuração é feita no nível do sistema operacional. Os discos correspondentes são configurados para
uma criptografia tradicional por meio de Azure Disk Encryption:
Os sistemas de arquivos são criados em cima dos discos.
Pontos de montagem temporários são criados para montar os sistemas de arquivos.
Os sistemas de arquivos são configurados em/etc/fstab para serem montados no momento da inicialização.
Verifique a letra do dispositivo atribuída aos novos discos. Neste exemplo, estamos usando quatro discos de
dados.
lsblk
Criar um sistema de arquivos na parte superior de cada disco

Esse comando itera a criação de um sistema de arquivos EXT4 em cada disco definido na parte "em" do ciclo
"for".
for disk in c d e f; do echo mkfs.ext4 -F /dev/sd${disk}; done |bash
Localize o identificador universal exclusivo (UUID) dos sistemas de arquivos que você criou recentemente, crie
uma pasta temporária, adicione as entradas correspondentes em/etc/fstab e monte todos os sistemas de
arquivos.
Esse comando também itera em cada disco definido na parte "em" do ciclo "for":
for disk in c d e f; do diskuuid="$(blkid -s UUID -o value /dev/sd${disk})"; \
mkdir /tempdata${disk}; \
echo "UUID=${diskuuid} /tempdata${disk} ext4 defaults,nofail 0 0" >> /etc/fstab; \
mount -a; \
done
Verificar se os discos estão montados corretamente
lsblk
Verifique também se os discos estão configurados:
cat /etc/fstab
Criptografar os discos de dados

PowerShell usando uma chave de criptografia de chave (KEK):
$sequenceVersion = [Guid]::NewGuid()
Set-AzVMDiskEncryptionExtension -ResourceGroupName $RGNAME `
-VMName ${VMNAME} `
-DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl `
-DiskEncryptionKeyVaultId $KeyVaultResourceId `
-KeyEncryptionKeyUrl $keyEncryptionKeyUrl `
-KeyEncryptionKeyVaultId $KeyVaultResourceId `
-VolumeType 'DATA' `
-EncryptFormatAll `
-SequenceVersion $sequenceVersion `
-skipVmBackup;
CLI do Azure usando um KEK:

az vm encryption enable \
--resource-group ${RGNAME} \
--name ${VMNAME} \
--disk-encryption-keyvault ${KEYVAULTNAME} \
--key-encryption-key ${KEYNAME} \
--key-encryption-keyvault ${KEYVAULTNAME} \
--volume-type "DATA" \
--encrypt-format-all \
-o table
Verificar o status de criptografia

Continue para a próxima etapa somente quando todos os discos forem criptografados.
PowerShell:
Get-AzVmDiskEncryptionStatus -ResourceGroupName ${RGNAME} -VMName ${VMNAME}
CLI do Azure:
az vm encryption show -n ${VMNAME} -g ${RGNAME} -o table
Portal:
Nível do sistema operacional:
lsblk
A extensão adicionará os sistemas de arquivos ao/var/lib/azure_disk_encryption_config/azure_crypt_mount
(uma criptografia antiga) ou a/etc/crypttab (novas criptografias).
NOTE
Não modifique nenhum desses arquivos.
Esse arquivo cuidará da ativação desses discos durante o processo de inicialização para que o LVM ou o RAID
possam usá-los mais tarde.
Não se preocupe com os pontos de montagem neste arquivo. Azure Disk Encryption perderá a capacidade de
obter os discos montados como um sistema de arquivos normal depois de criarmos um volume físico ou um
dispositivo RAID sobre esses dispositivos criptografados. (Isso removerá o formato do sistema de arquivos
usado durante o processo de preparação.)
Remover as pastas temporárias e as entradas de fstab temporárias
Desmonte os sistemas de arquivos nos discos que serão usados como parte do LVM.
for disk in c d e f; do unmount /tempdata${disk}; done
E remova as entradas/etc/fstab:
vi /etc/fstab
Verifique se os discos não estão montados e se as entradas em/etc/fstab foram removidas
lsblk
E verifique se os discos estão configurados:
cat /etc/fstab
Etapas para LVM-on-cript

Agora que os discos subjacentes estão criptografados, você pode criar as estruturas LVM.
Em vez de usar o nome do dispositivo, use os caminhos/dev/mapper para cada um dos discos para criar um
volume físico (na camada cript sobre o disco, não no próprio disco).
Configurar o LVM na parte superior das camadas criptografadas
Criar os volumes físicos
Você receberá um aviso perguntando se está OK para apagar a assinatura do sistema de arquivos. Continue
inserindo y ou use echo "y" , conforme mostrado:
echo "y" | pvcreate /dev/mapper/c49ff535-1df9-45ad-9dad-f0846509f052

echo "y" | pvcreate /dev/mapper/6712ad6f-65ce-487b-aa52-462f381611a1
echo "y" | pvcreate /dev/mapper/ea607dfd-c396-48d6-bc54-603cf741bc2a
echo "y" | pvcreate /dev/mapper/4159c60a-a546-455b-985f-92865d51158c
NOTE
Os nomes de/dev/mapper/Device aqui precisam ser substituídos para seus valores reais com base na saída de lsblk .
Verificar as informações de volumes físicos

pvs
Criar o grupo de volumes

Crie o grupo de volumes usando os mesmos dispositivos já inicializados:
vgcreate vgdata /dev/mapper/
Verifique as informações do grupo de volumes
vgdisplay -v vgdata
pvs
Criar volumes lógicos
lvcreate -L 10G -n lvdata1 vgdata

lvcreate -L 7G -n lvdata2 vgdata
Verificar os volumes lógicos criados
lvdisplay
lvdisplay vgdata/lvdata1
lvdisplay vgdata/lvdata2
Criar sistemas de arquivos sobre as estruturas para volumes lógicos
echo "yes" | mkfs.ext4 /dev/vgdata/lvdata1

echo "yes" | mkfs.ext4 /dev/vgdata/lvdata2
Criar os pontos de montagem para os novos sistemas de arquivos
mkdir /data0
mkdir /data1
Adicionar os novos sistemas de arquivos ao/etc/fstab e montá-los
echo "/dev/mapper/vgdata-lvdata1 /data0 ext4 defaults,nofail 0 0" >>/etc/fstab

echo "/dev/mapper/vgdata-lvdata2 /data1 ext4 defaults,nofail 0 0" >>/etc/fstab
mount -a
Verificar se os novos sistemas de arquivos estão montados
lsblk -fs
df -h
Nessa variação de lsblk , estamos listando os dispositivos que mostram as dependências na ordem inversa. Essa
opção ajuda a identificar os dispositivos agrupados pelo volume lógico em vez dos nomes de dispositivo/dev/sd
[disco] originais.
É importante garantir que a opção nofail seja adicionada às opções de ponto de montagem dos volumes LVM
criados na parte superior de um dispositivo criptografado por meio de Azure Disk Encryption. Isso impede que
o sistema operacional fique preso durante o processo de inicialização (ou no modo de manutenção).
Se você não usar a opção nofalhar :
O sistema operacional nunca entrará no estágio em que Azure Disk Encryption é iniciado e os discos de
dados são desbloqueados e montados.
Os discos criptografados serão desbloqueados no final do processo de inicialização. Os volumes LVM e os
sistemas de arquivos serão montados automaticamente até que Azure Disk Encryption Desbloqueie-os.
Você pode testar a reinicialização da VM e validar se os sistemas de arquivos também estão automaticamente
montados após o tempo de inicialização. Esse processo pode levar vários minutos, dependendo do número e
dos tamanhos dos sistemas de arquivos.
Reinicialize a VM e verifique após a reinicialização
shutdown -r now
lsblk
df -h
Etapas para RAID-on-cript.

Agora que os discos subjacentes estão criptografados, você pode continuar criando as estruturas RAID. O
processo é o mesmo do LVM, mas em vez de usar o nome do dispositivo, use os caminhos/dev/mapper para
cada disco.
Configurar o RAID sobre a camada criptografada dos discos
mdadm --create /dev/md10 \

--level 0 \
--raid-devices=4 \
/dev/mapper/c49ff535-1df9-45ad-9dad-f0846509f052 \
/dev/mapper/6712ad6f-65ce-487b-aa52-462f381611a1 \
/dev/mapper/ea607dfd-c396-48d6-bc54-603cf741bc2a \
/dev/mapper/4159c60a-a546-455b-985f-92865d51158c
NOTE
Os nomes de/dev/mapper/Device aqui precisam ser substituídos pelos valores reais, com base na saída de lsblk .
Verificar/monitorar a criação de RAID
watch -n1 cat /proc/mdstat

mdadm --examine /dev/mapper/[]
mdadm --detail /dev/md10
Criar um sistema de arquivos na parte superior do novo dispositivo RAID
mkfs.ext4 /dev/md10
Crie um novo ponto de montagem para o sistema de arquivos, adicione o novo sistema de arquivos
ao/etc/fstab e monte-o:
for device in md10; do diskuuid="$(blkid -s UUID -o value /dev/${device})"; \
mkdir /raiddata; \
echo "UUID=${diskuuid} /raiddata ext4 defaults,nofail 0 0" >> /etc/fstab; \
mount -a; \
done
Verifique se o novo sistema de arquivos está montado:
lsblk -fs
df -h
É importante certificar-se de que a opção nofail seja adicionada às opções de ponto de montagem dos volumes
RAID criados na parte superior de um dispositivo criptografado por meio de Azure Disk Encryption. Isso impede
que o sistema operacional fique preso durante o processo de inicialização (ou no modo de manutenção).
Se você não usar a opção nofalhar :
O sistema operacional nunca entrará no estágio em que Azure Disk Encryption é iniciado e os discos de
dados são desbloqueados e montados.
Os discos criptografados serão desbloqueados no final do processo de inicialização. Os volumes RAID e os
sistemas de arquivos serão montados automaticamente até que Azure Disk Encryption Desbloqueie-os.
Você pode testar a reinicialização da VM e validar se os sistemas de arquivos também estão automaticamente
montados após o tempo de inicialização. Esse processo pode levar vários minutos, dependendo do número e
dos tamanhos dos sistemas de arquivos.
shutdown -r now
E quando você pode fazer logon:
lsblk
df -h
Próximas etapas
Redimensionar dispositivos de gerenciamento de volume lógico criptografados com Azure Disk Encryption
Como redimensionar dispositivos de gerenciamento
de volume lógico que usam Azure Disk Encryption
Neste artigo, você aprenderá a redimensionar discos de dados que usam Azure Disk Encryption. Para
redimensionar os discos, você usará o LVM (gerenciamento de volume lógico) no Linux. As etapas se aplicam a
vários cenários.
Você pode usar esse processo de redimensionamento nos seguintes ambientes:
Distribuições do Linux:
Red Hat Enterprise Linux (RHEL) 7 ou posterior
Ubuntu 16 ou posterior
SUSE 12 ou posterior
Azure Disk Encryption versões:
Extensão de passagem única
Extensão de passagem dupla
Pré-requisitos
Este artigo supõe que você:
Uma configuração de LVM existente. Para obter mais informações, consulte Configurar o LVM em uma
VM do Linux.
Discos que já estão criptografados pelo Azure Disk Encryption. Para obter mais informações, consulte
Configurar LVM e RAID em dispositivos criptografados.
Experiência com o Linux e o LVM.
Experiência usando caminhos /dev/disk/scsi1/ para discos de dados no Azure. Para obter mais
informações, consulte solucionar problemas de nome do dispositivo VM Linux.
Cenários
Os procedimentos neste artigo se aplicam aos seguintes cenários:
Configurações tradicionais de LVM e LVM-criptografadas
Criptografia LVM tradicional
LVM em cript
Configurações tradicionais de LVM e LVM -criptografadas
As configurações de LVM e LVM tradicionais estendem um volume lógico (LV) quando o grupo de volumes (VG)
tem espaço disponível.
Criptografia LVM tradicional
Na criptografia LVM tradicional, os LVs são criptografados. O disco inteiro não está criptografado.
Usando a criptografia LVM tradicional, você pode:
Estenda o LV quando você adicionar um novo volume físico (VP).
Estenda o LV ao redimensionar um PV existente.
LVM em cript
O método recomendado para a criptografia de disco é LVM-on-Encrypt. Esse método criptografa todo o disco,
não apenas o LV.
Ao usar LVM-on-cript, você pode:
Estenda o LV quando você adicionar um novo VP.
Estenda o LV ao redimensionar um PV existente.
NOTE
Não é recomendável misturar criptografia de LVM tradicional e LVM em cript na mesma VM.
As seções a seguir fornecem exemplos de como usar o LVM e o LVM em cript. Os exemplos usam valores
preexistentes para discos, PVs, VGs, LVs, sistemas de arquivos, UUIDs (identificadores universalmente exclusivos)
e pontos de montagem. Substitua esses valores pelos seus próprios valores para se ajustar ao seu ambiente.
Estender um LV quando o VG tiver espaço disponível
A maneira tradicional de redimensionar o LVs é estender um LV quando o VG tem espaço disponível. Você pode
usar esse método para discos não criptografados, volumes tradicionais criptografados por LVM e configurações
de LVM em cript.
1. Verifique o tamanho atual do sistema de arquivos que você deseja aumentar:
df -h /mountpoint
2. Verifique se o VG tem espaço suficiente para aumentar o LV:
vgs
Você também pode usar vgdisplay :
vgdisplay vgname
3. Identifique qual LV precisa ser redimensionado:
lsblk
Para LVM-on-cript, a diferença é que essa saída mostra que a camada criptografada está no nível do
disco.
4. Verifique o tamanho do LV:
lvdisplay lvname
5. Aumente o tamanho do LV usando -r para redimensionar o sistema de arquivos online:
lvextend -r -L +2G /dev/vgname/lvname
6. Verifique os novos tamanhos para o LV e o sistema de arquivos:
df -h /mountpoint
A saída de tamanho indica que o LV e o sistema de arquivos foram redimensionados com êxito.
Você pode verificar as informações de LV novamente para confirmar as alterações no nível do LV:
lvdisplay lvname
Estender um volume LVM tradicional adicionando um novo VP

Quando você precisar adicionar um novo disco para aumentar o tamanho do VG, estenda o volume do LVM
tradicional adicionando um novo VP.
1. Verifique o tamanho atual do sistema de arquivos que você deseja aumentar:
df -h /mountpoint
2. Verifique a configuração atual do PV:
pvs
3. Verifique as informações de VG atuais:
vgs
4. Verifique a lista de discos atual. Identifique os discos de dados verificando os dispositivos em

/dev/disk/Azure/scsi1/.
ls -l /dev/disk/azure/scsi1/
5. Verifique a saída de lsblk :
lsbk
6. Anexe o novo disco à VM seguindo as instruções em anexar um disco de dados a uma VM do Linux.
7. Verifique a lista de discos e observe o novo disco.
lsbk
8. Crie um novo VP sobre o novo disco de dados:
pvcreate /dev/newdisk
Esse método usa o disco inteiro como um PV sem uma partição. Como alternativa, você pode usar
fdisk o para criar uma partição e usar essa partição para o pvcreate .
9. Verifique se o PV foi adicionado à lista de PV:
pvs
10. Estenda o VG adicionando o novo PV a ele:
vgextend vgname /dev/newdisk
11. Verifique o novo tamanho de VG:
vgs
12. Use lsblk para identificar o LV que precisa ser redimensionado:
lsblk
13. Estenda o tamanho do LV usando o -r para aumentar o sistema de arquivos online:
lvextend -r -L +2G /dev/vgname/lvname
14. Verifique os novos tamanhos do LV e do sistema de arquivos:
df -h /mountpoint
IMPORTANT
Quando a criptografia de dados do Azure é usada em configurações de LVM tradicionais, a camada criptografada
é criada no nível LV, não no nível do disco.
Neste ponto, a camada criptografada é expandida para o novo disco. O disco de dados real não tem configurações
de criptografia no nível da plataforma, portanto, seu status de criptografia não é atualizado.
Esses são alguns dos motivos pelos quais o LVM-on-cript é a abordagem recomendada.
15. Verifique as informações de criptografia do portal:

Para atualizar as configurações de criptografia no disco, adicione um novo LV e habilite a extensão na VM.
16. Adicione um novo LV, crie um sistema de arquivos nele e adicione-o ao /etc/fstab .
17. Defina a extensão de criptografia novamente. Desta vez, você carimbará as configurações de criptografia
no novo disco de dados no nível da plataforma. Aqui está um exemplo de CLI:
az vm encryption enable -g ${RGNAME} --name ${VMNAME} --disk-encryption-keyvault "<your-unique-

keyvault-name>"
18. Verifique as informações de criptografia do portal:
Depois que as configurações de criptografia forem atualizadas, você poderá excluir o novo LV. Exclua também a
entrada do /etc/fstab e /etc/crypttab que você criou.
Siga estas etapas para concluir a limpeza:

1. Desmonte o LV:
umount /mountpoint
2. Feche a camada criptografada do volume:
cryptsetup luksClose /dev/vgname/lvname
3. Exclua o LV:
lvremove /dev/vgname/lvname
Estender um volume LVM tradicional redimensionando um PV existente

Alguns cenários de IM, suas limitações podem exigir que você redimensione um disco existente. Aqui está como:
1. Identifique os discos criptografados:
lsblk -fs
2. Verifique as informações de PV:
pvs
Os resultados na imagem mostram que todo o espaço em todos os PVs está sendo usado no momento.
3. Verifique as informações de VG:
vgs
vgdisplay -v vgname
4. Verifique os tamanhos de disco. Você pode usar fdisk ou lsblk para listar os tamanhos de unidade.
for disk in `ls -l /dev/disk/azure/scsi1/* | awk -F/ '{print $NF}'` ; do echo "fdisk -l /dev/${disk}
| grep ^Disk "; done | bash
lsblk -o "NAME,SIZE"
Aqui identificamos quais PVs estão associadas a quais LVs usando lsblk -fs . Você pode identificar as
associações executando lvdisplay .
lvdisplay --maps VG/LV

lvdisplay --maps datavg/datalv1
Nesse caso, todas as quatro unidades de dados fazem parte do mesmo VG e um único LV. Sua
configuração pode ser diferente.
5. Verifique a utilização atual do sistema de arquivos:
df -h /datalvm*
6. Redimensione os discos de dados seguindo as instruções em expandir um disco gerenciado do Azure.

Você pode usar o portal, a CLI ou o PowerShell.
IMPORTANT
Não é possível redimensionar discos virtuais enquanto a VM está em execução. Desaloque sua VM para esta
etapa.
7. Inicie a VM e verifique os novos tamanhos usando fdisk .

for disk in `ls -l /dev/disk/azure/scsi1/* | awk -F/ '{print $NF}'` ; do echo "fdisk -l /dev/${disk}
| grep ^Disk "; done | bash
lsblk -o "NAME,SIZE"
Nesse caso, /dev/sdd foi redimensionado de 5 a 20 g.

8. Verifique o tamanho atual do VP:
pvdisplay /dev/resizeddisk
Embora o disco tenha sido redimensionado, o PV ainda tem o tamanho anterior.

9. Redimensione o PV:
pvresize /dev/resizeddisk
10. Verifique o tamanho do PV:
pvdisplay /dev/resizeddisk
Aplique o mesmo procedimento para todos os discos que você deseja redimensionar.
11. Verifique as informações de VG.
vgdisplay vgname
O VG agora tem espaço suficiente para ser alocado para o LVs.

12. Redimensione o LV:
lvresize -r -L +5G vgname/lvname

lvresize -r -l +100%FREE /dev/datavg/datalv01
13. Verifique o tamanho do sistema de arquivos:
df -h /datalvm2
Estender um volume LVM-on-cript adicionando um novo VP

Você também pode estender um volume LVM-on-cript adicionando um novo VP. Esse método segue com mais
detalhes as etapas em Configurar LVM e RAID em dispositivos criptografados. Consulte as seções que explicam
como adicionar um novo disco e configurá-lo em uma configuração LVM em criptografia.
Você pode usar esse método para adicionar espaço a um LV existente. Ou você pode criar um novo VGs ou LVs.
1. Verifique o tamanho atual de seu VG:
vgdisplay vgname
2. Verifique o tamanho do sistema de arquivos e o LV que você deseja expandir:
lvdisplay /dev/vgname/lvname
df -h mountpoint
3. Adicione um novo disco de dados à VM e identifique-o.

Antes de adicionar o novo disco, verifique os discos:
fdisk -l | egrep ^"Disk /"

Esta é outra maneira de verificar os discos antes de adicionar o novo disco:
lsblk
Para adicionar o novo disco, você pode usar o PowerShell, o CLI do Azure ou o portal do Azure. Para
obter mais informações, consulte anexar um disco de dados a uma VM do Linux.
O esquema de nome de kernel aplica-se ao dispositivo recém-adicionado. Uma nova unidade
normalmente é atribuída à próxima letra disponível. Nesse caso, o disco adicionado é sdd .
4. Verifique os discos para certificar-se de que o novo disco foi adicionado:
lsblk
5. Crie um sistema de arquivos na parte superior do disco adicionado recentemente. Corresponda o disco
aos dispositivos vinculados /dev/disk/azure/scsi1/ .
ls -la /dev/disk/azure/scsi1/
mkfs.ext4 /dev/disk/azure/scsi1/${disk}
6. Crie um ponto de montagem temporário para o novo disco adicionado:

newmount=/data4
mkdir ${newmount}
7. Adicione o sistema de arquivos criado recentemente ao /etc/fstab .
blkid /dev/disk/azure/scsi1/lun4| awk -F\" '{print "UUID="$2" '${newmount}' "$4" defaults,nofail 0

0"}' >> /etc/fstab
8. Monte o sistema de arquivos recém-criado:
mount -a
9. Verifique se o novo sistema de arquivos está montado:
df -h
lsblk
10. Reinicie a criptografia que você iniciou anteriormente para unidades de dados.
TIP
Para LVM-on-cript, recomendamos que você use o EncryptFormatAll . Caso contrário, você poderá ver uma
criptografia dupla enquanto configura discos adicionais.
Para obter mais informações, consulte Configurar LVM e RAID em dispositivos criptografados.
Aqui está um exemplo:
az vm encryption enable \
--resource-group ${RGNAME} \
--name ${VMNAME} \
--disk-encryption-keyvault ${KEYVAULTNAME} \
--key-encryption-key ${KEYNAME} \
--key-encryption-keyvault ${KEYVAULTNAME} \
--volume-type "DATA" \
--encrypt-format-all \
-o table
Quando a criptografia for concluída, você verá uma camada cript no disco recém-adicionado:
lsblk
11. Desmonte a camada criptografada do novo disco:
umount ${newmount}
12. Verifique as informações atuais do PV:
pvs
13. Crie um VP sobre a camada criptografada do disco. Pegue o nome do dispositivo do lsblk comando
anterior. Adicione um /dev/ mapeador na frente do nome do dispositivo para criar o PV:
pvcreate /dev/mapper/mapperdevicename
Você verá um aviso sobre como apagar a ext4 fs assinatura atual. Esse aviso é esperado. Responda a
essa pergunta com y .
14. Verifique se o novo PV foi adicionado à configuração LVM:
pvs
15. Adicione o novo PV ao VG que você precisa aumentar.
vgextend vgname /dev/mapper/nameofhenewpv
16. Verifique o novo tamanho e o espaço livre do VG:
vgdisplay vgname
Observe o aumento da Total PE contagem e o Free PE / Size .

17. Aumente o tamanho do LV e do sistema de arquivos. Use a -r opção em lvextend . Neste exemplo,
estamos adicionando o espaço total disponível no VG para o LV especificado.
lvextend -r -l +100%FREE /dev/vgname/lvname
Siga as próximas etapas para verificar as alterações.

1. Verifique o tamanho do LV:
lvdisplay /dev/vgname/lvname
2. Verifique o novo tamanho do sistema de arquivos:
df -h mountpoint
3. Verifique se a camada LVM está na parte superior da camada criptografada:
lsblk
Se você usar lsblk sem opções, verá os pontos de montagem várias vezes. O comando classifica por
dispositivo e LVs.
Talvez você queira usar o lsblk -fs . Nesse comando, -fs inverte a ordem de classificação para que os
pontos de montagem sejam mostrados uma vez. Os discos são mostrados várias vezes.
lsblk -fs
Estender um LVM em um volume criptografado redimensionando um PV existente

1. Identifique os discos criptografados:
lsblk
lsblk -s
2. Verifique as informações de PV:
pvs
3. Verifique suas informações de VG:
vgs
4. Verifique suas informações de LV:
lvs
5. Verifique a utilização do sistema de arquivos:
df -h /mountpoint(s)
6. Verifique os tamanhos dos discos:
fdisk
lsblk
7. Redimensione o disco de dados. Você pode usar o portal, a CLI ou o PowerShell. Para obter mais
informações, consulte a seção Disk-reresize em expandir discos rígidos virtuais em uma VM do Linux.
IMPORTANT
Não é possível redimensionar discos virtuais enquanto a VM está em execução. Desaloque sua VM para esta
etapa.
8. Verifique os tamanhos dos discos:
fdisk
lsblk
Nesse caso, ambos os discos foram redimensionados de 2 GB para 4 GB. Mas o tamanho do sistema de
arquivos, LV e PV permanecem os mesmos.
9. Verifique o tamanho atual do VP. Lembre-se de que, em LVM-on-cript, o VP é o /dev/mapper/ dispositivo,
não o /dev/sd* dispositivo.
pvdisplay /dev/mapper/devicemappername
10. Redimensione o PV:
pvresize /dev/mapper/devicemappername
11. Verifique o novo tamanho VP:
pvdisplay /dev/mapper/devicemappername
12. Redimensione a camada criptografada no PV:
cryptsetup resize /dev/mapper/devicemappername
Aplique o mesmo procedimento para todos os discos que você deseja redimensionar.
13. Verifique suas informações de VG:
vgdisplay vgname
O VG agora tem espaço suficiente para ser alocado para o LVs.
14. Verifique as informações de LV:
lvdisplay vgname/lvname
df -h /mountpoint
16. Redimensione o LV:
lvresize -r -L +2G /dev/vgname/lvname

Aqui, usamos a -r opção para também redimensionar o sistema de arquivos.
17. Verifique as informações de LV:
lvdisplay vgname/lvname
df -h /mountpoint
Aplique o mesmo procedimento de redimensionamento a qualquer outro LV que o exija.
Próximas etapas
Solucionar problemas Azure Disk Encryption
Redimensionar um disco do sistema operacional
com partição GPT
NOTE
Este artigo se aplica somente a discos do sistema operacional que tenham uma partição GPT (tabela de partição GUID).
Este artigo descreve como aumentar o tamanho de um disco do sistema operacional com GPT no Linux.
Identificar se o disco do sistema operacional tem uma partição MBR

ou GPT
Use o parted comando para identificar se a partição de disco foi criada com uma partição MBR (registro
mestre de inicialização) ou uma partição GPT.
Partição MBR
Na saída a seguir, a tabela de par tição mostra um valor de msdos . Esse valor identifica uma partição MBR.
[user@myvm ~]# parted -l /dev/sda

Disk /dev/sda: 107GB
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 525MB 524MB primary ext4 boot
2 525MB 34.4GB 33.8GB primary ext4
[user@myvm ~]#
Partição GPT
Na saída a seguir, a tabela de par tição mostra um valor de gpt . Esse valor identifica uma partição GPT.
[user@myvm ~]# parted -l /dev/sda

Disk /dev/sda: 68.7GB
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags

1 1049kB 525MB 524MB fat16 EFI System Partition boot
2 525MB 1050MB 524MB xfs
3 1050MB 1052MB 2097kB bios_grub
4 1052MB 68.7GB 67.7GB lvm
Se sua VM (máquina virtual) tiver uma partição GPT no disco do sistema operacional, aumente o tamanho do
disco do sistema operacional.
Aumentar o tamanho do disco do sistema operacional

As instruções a seguir se aplicam a distribuições endossadas pelo Linux.
NOTE
Antes de prosseguir, faça uma cópia de backup de sua VM ou tire um instantâneo do disco do sistema operacional.
Ubuntu
Para aumentar o tamanho do disco do sistema operacional no Ubuntu 16. x e 18. x:
1. Pare a VM.
2. Aumente o tamanho do disco do sistema operacional no portal.
3. Reinicie a VM e entre na VM como um usuário raiz .
4. Verifique se o disco do sistema operacional agora exibe um tamanho maior do sistema de arquivos.
No exemplo a seguir, o disco do sistema operacional foi redimensionado do portal para 100 GB. O sistema de
arquivos /dev/sda1 montado em / mostra agora 97 GB.
user@myvm:~# df -Th
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 314M 0 314M 0% /dev
tmpfs tmpfs 65M 2.3M 63M 4% /run
/dev/sda1 ext4 97G 1.8G 95G 2% /
tmpfs tmpfs 324M 0 324M 0% /dev/shm
tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs tmpfs 324M 0 324M 0% /sys/fs/cgroup
/dev/sda15 vfat 105M 3.6M 101M 4% /boot/efi
/dev/sdb1 ext4 20G 44M 19G 1% /mnt
tmpfs tmpfs 65M 0 65M 0% /run/user/1000
user@myvm:~#
SUSE
Para aumentar o tamanho do disco do sistema operacional no SUSE 12 SP4, SUSE SLES 12 para SAP, SUSE SLES
15 e SUSE SLES 15 para SAP:
1. Pare a VM.
3. Reinicie a VM.
Quando a VM for reiniciada, conclua estas etapas:
1. Acesse sua VM como um usuário raiz usando este comando:
# sudo -i
2. Use o comando a seguir para instalar o pacote growpar t , que você usará para redimensionar a partição:
# zypper install growpart
3. Use o lsblk comando para localizar a partição montada na raiz do sistema de arquivos ( / ). Nesse caso,
vemos que a partição 4 do dispositivo SDA está montada em / :
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 48G 0 disk
├─sda1 8:1 0 2M 0 part
├─sda2 8:2 0 512M 0 part /boot/efi
├─sda3 8:3 0 1G 0 part /boot
└─sda4 8:4 0 28.5G 0 part /
sdb 8:16 0 4G 0 disk
└─sdb1 8:17 0 4G 0 part /mnt/resource
4. Redimensione a partição necessária usando o growpart comando e o número da partição determinados

na etapa anterior:
# growpart /dev/sda 4
CHANGED: partition=4 start=3151872 old: size=59762655 end=62914527 new: size=97511391 end=100663263
5. Execute o lsblk comando novamente para verificar se a partição foi aumentada.

A saída a seguir mostra que a partição /dev/sda4 foi redimensionada para 46,5 GB:
linux:~ # lsblk
sda 8:0 0 48G 0 disk
├─sda1 8:1 0 2M 0 part
├─sda2 8:2 0 512M 0 part /boot/efi
├─sda3 8:3 0 1G 0 part /boot
└─sda4 8:4 0 46.5G 0 part /
sdb 8:16 0 4G 0 disk
└─sdb1 8:17 0 4G 0 part /mnt/resource
6. Identifique o tipo de sistema de arquivos no disco do sistema operacional usando o lsblk comando
com o -f sinalizador:
linux:~ # lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1
├─sda2 vfat EFI AC67-D22D /boot/efi
├─sda3 xfs BOOT 5731a128-db36-4899-b3d2-eb5ae8126188 /boot
└─sda4 xfs ROOT 70f83359-c7f2-4409-bba5-37b07534af96 /
sdb
└─sdb1 ext4 8c4ca904-cd93-4939-b240-fb45401e2ec6 /mnt/resource
7. Com base no tipo de sistema de arquivos, use os comandos apropriados para redimensionar o sistema
de arquivos.
Para xfs , use este comando:
#xfs_growfs /
Saída de exemplo:
linux:~ # xfs_growfs /
meta-data=/dev/sda4 isize=512 agcount=4, agsize=1867583 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0 spinodes=0 rmapbt=0
= reflink=0
data = bsize=4096 blocks=7470331, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=3647, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 7470331 to 12188923
Para ext4 , use este comando:
#resize2fs /dev/sda4
8. Verifique o maior tamanho do sistema de arquivos para o DF-ésimo usando este comando:
#df -Thl
Saída de exemplo:
linux:~ # df -Thl
devtmpfs devtmpfs 445M 4.0K 445M 1% /dev
tmpfs tmpfs 458M 0 458M 0% /dev/shm
tmpfs tmpfs 458M 14M 445M 3% /run
tmpfs tmpfs 458M 0 458M 0% /sys/fs/cgroup
/dev/sda4 xfs 47G 2.2G 45G 5% /
/dev/sda3 xfs 1014M 86M 929M 9% /boot
/dev/sda2 vfat 512M 1.1M 511M 1% /boot/efi
/dev/sdb1 ext4 3.9G 16M 3.7G 1% /mnt/resource
No exemplo anterior, podemos ver que o tamanho do sistema de arquivos para o disco do sistema
operacional aumentou.
RHEL com LVM
1. Acesse sua VM como um usuário raiz usando este comando:
[root@dd-rhel7vm ~]# sudo -i
2. Use o lsblk comando para determinar qual volume lógico (LV) está montado na raiz do sistema de
arquivos ( / ). Nesse caso, vemos que o rootvg-rootlv está montado em / . Se você quiser outro sistema
de arquivos, substitua o LV e o ponto de montagem ao longo deste artigo.
[root@dd-rhel7vm ~]# lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
fd0
sda
├─sda1 vfat C13D-C339 /boot/efi
├─sda2 xfs 8cc4c23c-fa7b-4a4d-bba8-4108b7ac0135 /boot
├─sda3
└─sda4 LVM2_member zx0Lio-2YsN-ukmz-BvAY-LCKb-kRU0-ReRBzh
├─rootvg-tmplv xfs 174c3c3a-9e65-409a-af59-5204a5c00550 /tmp
├─rootvg-usrlv xfs a48dbaac-75d4-4cf6-a5e6-dcd3ffed9af1 /usr
├─rootvg-optlv xfs 85fe8660-9acb-48b8-98aa-bf16f14b9587 /opt
├─rootvg-homelv xfs b22432b1-c905-492b-a27f-199c1a6497e7 /home
├─rootvg-varlv xfs 24ad0b4e-1b6b-45e7-9605-8aca02d20d22 /var
└─rootvg-rootlv xfs 4f3e6f40-61bf-4866-a7ae-5c6a94675193 /
3. Verifique se há espaço livre no grupo de volumes LVM (VG) que contém a partição raiz. Se houver espaço
livre, pule para a etapa 12.
[root@dd-rhel7vm ~]# vgdisplay rootvg

--- Volume group ---
VG Name rootvg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 7
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 6
Open LV 6
Max PV 0
Cur PV 1
Act PV 1
VG Size <63.02 GiB
PE Size 4.00 MiB
Total PE 16132
Alloc PE / Size 6400 / 25.00 GiB
Free PE / Size 9732 / <38.02 GiB
VG UUID lPUfnV-3aYT-zDJJ-JaPX-L2d7-n8sL-A9AgJb
Neste exemplo, o PE/tamanho de linha livre mostra que há 38, 2 GB livres no grupo de volumes. Você
não precisa redimensionar o disco antes de adicionar espaço ao grupo de volumes.
4. Para aumentar o tamanho do disco do sistema operacional no RHEL 7. x com LVM:
a. Pare a VM.
b. Aumente o tamanho do disco do sistema operacional no portal.
c. Inicie a VM.
5. Quando a VM for reiniciada, conclua a seguinte etapa:
Instale o pacote Cloud-utils-growpar t para fornecer o comando growpar t , que é necessário para
aumentar o tamanho do disco do sistema operacional e o manipulador GDisk para layouts de disco
GPT. Esses pacotes são pré-instalados na maioria das imagens do Marketplace.
[root@dd-rhel7vm ~]# yum install cloud-utils-growpart gdisk
6. Determine qual disco e partição contém o volume físico LVM ou volumes (VP) no grupo de volumes
denominado rootvg usando o pvscan comando. Observe o tamanho e o espaço livre listados entre os
colchetes ([ e ] ).
[root@dd-rhel7vm ~]# pvscan
PV /dev/sda4 VG rootvg lvm2 [<63.02 GiB / <38.02 GiB free]
7. Verifique o tamanho da partição usando lsblk .
[root@dd-rhel7vm ~]# lsblk /dev/sda4

sda4 8:4 0 63G 0 part
├─rootvg-tmplv 253:1 0 2G 0 lvm /tmp
├─rootvg-usrlv 253:2 0 10G 0 lvm /usr
├─rootvg-optlv 253:3 0 2G 0 lvm /opt
├─rootvg-homelv 253:4 0 1G 0 lvm /home
├─rootvg-varlv 253:5 0 8G 0 lvm /var
└─rootvg-rootlv 253:6 0 2G 0 lvm /
8. Expanda a partição que contém esse VP usando growpart o, o nome do dispositivo e o número da
partição. Isso expandirá a partição especificada para usar todo o espaço contíguo livre no dispositivo.
[root@dd-rhel7vm ~]# growpart /dev/sda 4

CHANGED: partition=4 start=2054144 old: size=132161536 end=134215680 new: size=199272414
end=201326558
9. Verifique se a partição foi redimensionada para o tamanho esperado usando o lsblk comando
novamente. Observe que, no exemplo sda4 foi alterado de 63 gb para 95 GB.
[root@dd-rhel7vm ~]# lsblk /dev/sda4

sda4 8:4 0 95G 0 part
├─rootvg-tmplv 253:1 0 2G 0 lvm /tmp
├─rootvg-usrlv 253:2 0 10G 0 lvm /usr
├─rootvg-optlv 253:3 0 2G 0 lvm /opt
├─rootvg-homelv 253:4 0 1G 0 lvm /home
├─rootvg-varlv 253:5 0 8G 0 lvm /var
└─rootvg-rootlv 253:6 0 2G 0 lvm /
10. Expanda o VP para usar o restante da partição recentemente expandida:
[root@dd-rhel7vm ~]# pvresize /dev/sda4

Physical volume "/dev/sda4" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
11. Verifique se o novo tamanho de VP é o tamanho esperado, comparando-o aos valores originais
[tamanho/livre] :
[root@dd-rhel7vm ~]# pvscan

PV /dev/sda4 VG rootvg lvm2 [<95.02 GiB / <70.02 GiB free]
12. Expanda o volume lógico desejado (LV) pelo valor desejado. O valor não precisa ser todo o espaço livre
no grupo de volumes. No exemplo a seguir, /dev/mapper/rootvg-rootlv é redimensionado de 2 GB
para 12 GB (um aumento de 10 GB). Este comando também redimensionará o sistema de arquivos.
[root@dd-rhel7vm ~]# lvresize -r -L +10G /dev/mapper/rootvg-rootlv
Saída de exemplo:
[root@dd-rhel7vm ~]# lvresize -r -L +10G /dev/mapper/rootvg-rootlv
Size of logical volume rootvg/rootlv changed from 2.00 GiB (512 extents) to 12.00 GiB (3072 extents).
Logical volume rootvg/rootlv successfully resized.
meta-data=/dev/mapper/rootvg-rootlv isize=512 agcount=4, agsize=131072 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=0 spinodes=0
data = bsize=4096 blocks=524288, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 524288 to 3145728
13. O lvresize comando chama automaticamente o comando de redimensionamento apropriado para o

sistema de arquivos no LV. Verifique se /dev/mapper/rootvg-rootlv , que está montado em / , tem um
tamanho de sistema de arquivos maior usando este comando:
[root@dd-rhel7vm ~]# df -Th /
Saída de exemplo:
[root@dd-rhel7vm ~]# df -Th /

/dev/mapper/rootvg-rootlv xfs 12G 71M 12G 1% /
[root@dd-rhel7vm ~]#
NOTE
Para usar o mesmo procedimento para redimensionar qualquer outro volume lógico, altere o nome LV na etapa 12.
RHEL BRUTO
NOTE
Sempre tire um instantâneo da VM antes de aumentar o tamanho do disco do sistema operacional.
Para aumentar o tamanho do disco do sistema operacional em uma partição do RHEL RAW:
1. Pare a VM.
3. Inicie a VM.
Quando a VM reiniciar, execute as etapas a seguir:
1. Acesse sua VM como usuário raiz usando o comando a seguir:
sudo su
2. Instale o pacote gptfdisk necessário para aumentar o tamanho do disco do sistema operacional.
yum install gdisk -y
3. Para ver todos os setores disponíveis no disco, execute o seguinte comando:

gdisk -l /dev/sda
4. Você verá os detalhes informando o tipo de partição. Verifique se ele é GPT. Identifique a partição raiz.
Não altere nem exclua a partição de inicialização (partição de inicialização do BIOS) e a partição do
sistema (' partição do sistema EFI ')
5. Use o comando a seguir para iniciar o particionamento pela primeira vez.
gdisk /dev/sda
6. Agora, você verá uma mensagem solicitando o próximo comando (' Command:? para obter ajuda ').
7. Você receberá um aviso informando "aviso! O cabeçalho secundário é colocado muito cedo no disco!
Deseja corrigir esse problema? (S/N): ". Você precisa pressionar ' Y '
8. Você deverá ver uma mensagem informando que as verificações finais foram concluídas e solicitando
confirmação. Pressione ' Y '
9. Verificar se tudo aconteceu corretamente usando o comando partprobe
partprobe
10. As etapas acima garantiram que o cabeçalho GPT secundário seja colocado no final. A próxima etapa é
iniciar o processo de redimensionamento usando a ferramenta GDisk novamente. Use o comando a
seguir.
gdisk /dev/sda
11. No menu comando, pressione ' p ' para ver a lista de partições. Identificar a partição raiz (nas etapas,
sda2 é considerado como a partição raiz) e a partição de inicialização (nas etapas, sda3 é considerado
como a partição de inicialização)
12. Pressione ' d' para excluir a partição e selecione o número da partição atribuído para inicialização (neste
exemplo, é ' 3 ')
d
3
13. Pressione ' d' para excluir a partição e selecione o número da partição atribuído para inicialização (neste
exemplo, é ' 2 ')
d
2
14. Para recriar a partição raiz com um tamanho maior, pressione ' n', insira o número da partição que você
excluiu anteriormente para a raiz (' 2 ' para este exemplo) e escolha o primeiro setor como ' valor padrão
', último setor como ' último valor do setor-tamanho da inicialização ' (' 4096 neste caso ' correspondente
à inicialização de 2MB) e código hexadecimal como ' 8300 '
n
2
(Enter default)
(Calculateed value of Last sector value - 4096)
8300
15. Para recriar a partição de inicialização, pressione ' n', insira o número da partição que você excluiu
anteriormente para a inicialização (' 3 ' para este exemplo) e escolha o primeiro setor como ' valor
padrão ', último setor como ' valor padrão ' e código hex como ' EF02 '
n
3
(Enter default)
(Enter default)
EF02
16. Grave as alterações com o comando ' w ' e pressione ' Y ' para confirmar
w
Y
17. Execute o comando ' partprobe ' para verificar a estabilidade do disco
partprobe
18. A reinicialização da VM e o tamanho da partição raiz teria sido aumentado
reboot
19. Execute o comando xfs_growfs na partição para redimensioná-lo
xfs_growfs /dev/sda2
20. Verifique se o novo tamanho é refletido usando o comando DF :
[root@vm-dd-cent7 ~]# df -hl

devtmpfs 452M 0 452M 0% /dev
tmpfs 464M 0 464M 0% /dev/shm
tmpfs 464M 6.8M 457M 2% /run
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/sda2 48G 2.1G 46G 5% /
/dev/sda1 494M 65M 430M 13% /boot
/dev/sda15 495M 12M 484M 3% /boot/efi
/dev/sdb1 3.9G 16M 3.7G 1% /mnt/resource
tmpfs 93M 0 93M 0% /run/user/1000
Guia de solução de problemas do Azure Disk
Encryption para VMs do Linux
Este guia destina-se a profissionais de TI, analistas de segurança da informação e administradores de nuvem
cujas organizações usam o Azure Disk Encryption. Este artigo é para ajudar na solução de problemas
relacionados à criptografia de disco.
Antes de executar qualquer uma das etapas abaixo, primeiro verifique se as VMs que você está tentando
criptografar estão entre os tamanhos e sistemas operacionais de VM com suporte e se você atendeu a todos os
pré-requisitos:
Requisitos de rede
Solução de problemas de criptografia de disco do SO Linux

A criptografia de disco do SO (sistema operacional) Linux deve desmontar a unidade do SO antes de executá-lo
por meio do processo de criptografia de disco completo. Se não for possível desmontar a unidade, é provável
que ocorra uma mensagem de erro de "falha ao desmontar após ...".
Esse erro pode ocorrer quando a criptografia de disco do sistema operacional é tentada em uma VM com um
ambiente que foi alterado da imagem da Galeria de estoque com suporte. Desvios da imagem compatível
podem interferir com a capacidade da extensão de desmontar a unidade do SO. Exemplos de desvios podem
incluir os seguintes itens:
Imagens personalizadas que não correspondem mais a um sistema de arquivos ou esquema de
particionamento suportado.
Não há suporte para aplicativos grandes, como SAP, MongoDB, Apache Cassandra e Docker, quando eles
estão instalados e executados no sistema operacional antes da criptografia. A Criptografia de Disco do Azure
não consegue encerrar esses processos com segurança, conforme necessário na preparação da unidade do
sistema operacional para criptografia de disco. Se ainda houver processos ativos mantendo alças de arquivos
abertos na unidade do sistema operacional, a unidade do sistema operacional não poderá ser desmontada,
resultando em uma falha na criptografia da unidade do sistema operacional.
Scripts personalizados que são executados próximos à hora de encerramento da criptografia que está sendo
habilitada ou se qualquer outra alteração estiver sendo feita na VM durante o processo de criptografia. Esse
conflito pode acontecer quando um modelo do Azure Resource Manager define múltiplas extensões para
executar simultaneamente ou quando uma extensão de script personalizada ou outra ação é executada
simultaneamente com a criptografia de disco. Serializar e isolar tais etapas pode resolver o problema.
O SELinux (Security Enhanced Linux) não foi desabilitado antes da habilitação da criptografia, fazendo com
que a etapa de desmontagem falhe. O SELinux pode ser reabilitado após a conclusão da criptografia.
O disco do SO usa um esquema LVM (Gerenciador de Volume Lógico). Embora o suporte ao disco de dados
LVM limitado esteja disponível, um disco de SO LVM, não.
Os requisitos mínimos de memória não são atendidos (7 GB é sugerido para criptografia de disco do SO).
As unidades de dados são montadas recursivamente no diretório /mnt/ ou uma na outra (por exemplo,
/mnt/data1, /mnt/data2, /data3 + /data3/data4).
Atualizar o kernel padrão para o Ubuntu 14.04 LTS
A imagem do Ubuntu 14.04 LTS é fornecida com uma versão padrão do kernel de 4.4. Esta versão do kernel tem
um problema conhecido no qual o Encerrador de Memória Insuficiente encerra incorretamente o comando dd
durante o processo de criptografia do sistema operacional. Esse bug foi corrigido no mais recente kernel do
Linux ajustado para o Azure. Para evitar esse erro, antes de habilitar a criptografia na imagem, atualize para o
kernel ajustado para o Azure 4.15 ou posterior usando os comandos a seguir:
sudo apt-get update

sudo apt-get install linux-azure
sudo reboot
Depois de reiniciar a VM para o novo kernel, a nova versão do kernel pode ser confirmada usando:
uname -a
Atualizar o agente de máquina virtual do Azure e as versões de

extensão
Azure Disk Encryption operações podem falhar em imagens de máquina virtual usando versões sem suporte do
agente de máquina virtual do Azure. Imagens do Linux com versões de agente anteriores a 2.2.38 devem ser
atualizadas antes de habilitar a criptografia. Para obter mais informações, consulte como atualizar o agente
Linux do Azure em uma VM e o suporte de versão mínima para agentes de máquina virtual no Azure.
A versão correta da extensão de agente convidado Microsoft. Azure. Security. AzureDiskEncryption ou Microsoft.
Azure. Security. AzureDiskEncryptionForLinux também é necessária. As versões de extensão são mantidas e
atualizadas automaticamente pela plataforma quando os pré-requisitos do agente de máquina virtual do Azure
são satisfeitos e uma versão com suporte do agente de máquina virtual é usada.
A extensão Microsoft. OSTCExtensions. AzureDiskEncryptionForLinux foi preterida e não é mais suportada.
Não é possível criptografar discos do Linux

Em alguns casos, a criptografia de disco do Linux parece estar paralisada na "criptografia de disco do OS
iniciada" e o SSH está desabilitado. O processo de criptografia pode levar entre 3 e 16 horas para ser concluído
em uma imagem da galeria de estoque. Se discos de dados com diversos terabytes forem adicionados, o
processo poderá levar dias.
A sequência de criptografia de disco do SO Linux desmonta a unidade do SO temporariamente. Em seguida, ela
realiza a criptografia bloco a bloco de todo o disco do SO, antes de remontá-lo em seu estado criptografado. A
criptografia de disco do Linux não permite o uso simultâneo da VM enquanto a criptografia está em andamento.
As características de desempenho da VM podem fazer uma diferença significativa no tempo necessário para
concluir a criptografia. Essas características incluem o tamanho do disco e se a conta de armazenamento é
padrão ou premium (SSD).
Enquanto a unidade do sistema operacional está sendo criptografada, a VM entra em um estado de manutenção
e desabilita o SSH para evitar qualquer interrupção no processo em andamento. Para verificar o status de
criptografia, use o comando Azure PowerShell Get-AzVmDiskEncryptionStatus e verifique o campo
ProgressMessage . O ProgressMessage relatará uma série de status, pois os dados e os discos do sistema
operacional são criptografados:
PS > Get-AzVMDiskEncryptionStatus -ResourceGroupName "MyResourceGroup" -VMName "myVM"
DataVolumesEncrypted : EncryptionInProgress
OsVolumeEncryptionSettings :
ProgressMessage : Transitioning
ProgressMessage : Encryption succeeded for data volumes
ProgressMessage : Provisioning succeeded
O ProgressMessage permanecerá no sistema operacional criptografia de disco iniciado para a maior

parte do processo de criptografia. Quando a criptografia for concluída e for bem-sucedida, ProgressMessage
retornará:
OsVolumeEncrypted : Encrypted
ProgressMessage : Encryption succeeded for all volumes
Depois que essa mensagem estiver disponível, espera-se que a unidade do SO criptografada esteja pronta para
uso e que a VM esteja pronta para ser usada novamente.
Se as informações de inicialização, a mensagem de progresso ou um erro relatar que a criptografia do sistema
operacional falhou no meio desse processo, restaure a VM para o instantâneo ou backup feito imediatamente
antes da criptografia. Um exemplo de mensagem é o erro "falha ao desmontar", que é descrito neste guia.
Antes de tentar novamente a criptografia, reavalie as características da VM e verifique se todos os pré-requisitos
estão satisfeitos.
Solucionando problemas do Azure Disk Encryption por trás de um

firewall
Consulte criptografia de disco em uma rede isolada
Solução de problemas de status de criptografia

O portal pode exibir um disco como criptografado mesmo após ele ter sido descriptografado na VM. Isso pode
ocorrer quando comandos de baixo nível são usados para descriptografar diretamente o disco de dentro da VM,
em vez de usar os comandos de gerenciamento do Azure Disk Encryption de nível superior. Os comandos de
nível superior não apenas descriptografam o disco de dentro da VM, mas fora da VM eles também atualizam
configurações importantes de criptografia de nível de plataforma e configurações de extensão associadas à VM.
Se eles não forem mantidos alinhados, a plataforma não poderá relatar o status de criptografia nem provisionar
a VM corretamente.
Para desabilitar Azure Disk Encryption com o PowerShell, use Disable-AzVMDiskEncryption seguido por
Remove-AzVMDiskEncryptionExtension. A execução de Remove-AzVMDiskEncryptionExtension falhará antes de
a criptografia ser desabilitada.
Para desabilitar o Azure Disk Encryption com a CLI, use az vm encryption disable.
Próximas etapas
Neste documento, você aprendeu mais sobre alguns problemas comuns no Azure Disk Encryption e como
solucioná-los. Para saber mais sobre esse serviço e seus recursos, confira os seguintes artigos:
Aplicar a criptografia de disco na Central de Segurança do Azure
Guia de solução de problemas do Azure Disk
Encryption
Este guia destina-se a profissionais de TI, analistas de segurança da informação e administradores de nuvem
cujas organizações usam o Azure Disk Encryption. Este artigo é para ajudar na solução de problemas
relacionados à criptografia de disco.
Antes de executar qualquer uma das etapas abaixo, primeiro verifique se as VMs que você está tentando
criptografar estão entre os tamanhos e sistemas operacionais de VM com suporte e se você atendeu a todos os
pré-requisitos:
Requisitos de rede
Requisitos da política de grupo
Solucionando problemas do Azure Disk Encryption por trás de um

firewall
Quando a conectividade estiver restrita por requisitos de proxy, firewall ou NSG (grupo de segurança de rede), a
capacidade da extensão para executar as tarefas necessárias poderá ser interrompida. Essa interrupção pode
resultar em mensagens de status como "Status da extensão não disponível na VM". Em cenários esperados, a
criptografia não é concluída. As seções que se seguem têm alguns problemas comuns de firewall que podem
ser investigados.
Qualquer configuração do grupo de segurança de rede aplicada ainda deve permitir que o ponto de
extremidade atenda aos pré-requisitos da configuração de rede documentada para criptografia de disco.
Azure Key Vault por trás de um firewall
Quando a criptografia é habilitada com credenciais do Azure AD, a VM de destino deve permitir a conectividade
com pontos de extremidade do Azure Active Directory e pontos de extremidade do Key Vault. Os pontos de
extremidade de autenticação Azure Active Directory atuais são mantidos nas seções 56 e 59 da documentação
Microsoft 365 URLs e intervalos de endereços IP . As instruções do Key Vault são fornecidas na documentação
sobre como Acessar o Azure Key Vault por trás de um firewall.
A VM precisa conseguir acessar o ponto de extremidade do Serviço de Metadados de Instância do Azure, que
usa um endereço IP não roteável conhecido ( 169.254.169.254 ) que pode ser acessado somente na VM. Não há
suporte para as configurações de proxy que alteram o tráfego HTTP local para esse endereço (por exemplo, a
adição de um cabeçalho X-Forwarded-For).
Solução de problemas de Server Core do Windows Server 2016

No Windows Server 2016 Server Core, o componente bdehdcfg não está disponível por padrão. Esse
componente é exigido pelo Azure Disk Encryption. É usado para dividir o volume do sistema do volume do
sistema operacional, o que é feito apenas uma vez para o tempo de vida da VM. Esses binários não são
necessários durante as operações posteriores de criptografia.
Para contornar esse problema, copie os quatro arquivos a seguir de uma VM do Data Center do Windows
Server 2016 para o mesmo local no Núcleo do Servidor:
\windows\system32\bdehdcfg.exe
\windows\system32\bdehdcfglib.dll
\windows\system32\en-US\bdehdcfglib.dll.mui
\windows\system32\en-US\bdehdcfg.exe.mui
1. Insira o seguinte comando:
bdehdcfg.exe -target default
2. Esse comando cria uma partição de sistema de 550 MB. Reinicialize o sistema.
3. Use DiskPart para verificar os volumes e continue.
Por exemplo:
DISKPART> list vol
Volume ### Ltr Label Fs Type Size Status Info

---------- --- ----------- ----- ---------- ------- --------- --------
Volume 0 C NTFS Partition 126 GB Healthy Boot
Volume 1 NTFS Partition 550 MB Healthy System
Volume 2 D Temporary S NTFS Partition 13 GB Healthy Pagefile
Solução de problemas de status de criptografia

O portal pode exibir um disco como criptografado mesmo após ele ter sido descriptografado na VM. Isso pode
ocorrer quando comandos de baixo nível são usados para descriptografar diretamente o disco de dentro da VM,
em vez de usar os comandos de gerenciamento do Azure Disk Encryption de nível superior. Os comandos de
nível superior não apenas descriptografam o disco de dentro da VM, mas fora da VM eles também atualizam
configurações importantes de criptografia de nível de plataforma e configurações de extensão associadas à VM.
Se eles não forem mantidos alinhados, a plataforma não poderá relatar o status de criptografia nem provisionar
a VM corretamente.
Para desabilitar Azure Disk Encryption com o PowerShell, use Disable-AzVMDiskEncryption seguido por
Remove-AzVMDiskEncryptionExtension. A execução de Remove-AzVMDiskEncryptionExtension falhará antes de
a criptografia ser desabilitada.
Para desabilitar o Azure Disk Encryption com a CLI, use az vm encryption disable.
Próximas etapas
Neste documento, você aprendeu mais sobre alguns problemas comuns no Azure Disk Encryption e como
solucioná-los. Para saber mais sobre esse serviço e seus recursos, confira os seguintes artigos:
Perguntas frequentes do Azure Disk Encryption
para máquinas virtuais
Este artigo responde a perguntas frequentes sobre o Azure Disk Encryption para máquinas virtuais (VMs) Linux.
Para obter mais informações sobre esse serviço, consulte Visão geral do Azure Disk Encryption.
O que é Azure Disk Encryption para VMs Linux?

O Azure Disk Encryption para VMs Linux usa o recurso dm-crypt do Linux para fornecer criptografia completa
do disco do sistema operacional* e discos de dados. Além disso, ele fornece criptografia do disco temporário ao
usar o recurso EncryptFormatAll. O conteúdo é transmitido criptografado da VM para ao back-end do
Armazenamento. Assim, é fornecida uma criptografia de ponta a ponta com uma chave gerenciada pelo cliente.
Consulte Sistemas operacionais e VMs com suporte.
Onde o Azure Disk Encryption está na GA (disponibilidade geral)?

O Azure Disk Encryption para VMs Linux está em disponibilidade geral em todas as regiões públicas do Azure.
Quais experiências de usuário estão disponíveis com o Azure Disk

Encryption?
A GA do Azure Disk Encryption dá suporte a modelos do Azure Resource Manager, ao Azure PowerShell e à CLI
do Azure. As diferentes experiências de usuário oferecem flexibilidade. Você tem três opções diferentes para
habilitar a criptografia de disco para suas VMs. Para saber mais sobre a experiência do usuário e as orientações
passo a passo disponíveis no Azure Disk Encryption, consulte Cenários do Azure Disk Encryption para Linux.
Quanto custa o Azure Disk Encryption?

Não há nenhum encargo para criptografar discos de VM com o Azure Disk Encryption, mas há encargos
associados ao uso do Azure Key Vault. Para obter mais informações sobre os custos do Cofre de Chaves do
Azure, consulte a página de preços Cofre de chaves.
Como posso começar a usar o Azure Disk Encryption?

Para começar, leia as visão geral do Azure Disk Encryption.
Quais tamanhos de VM e sistemas operacionais dão suporte ao Azure

Disk Encryption?
O artigo Visão geral do Azure Disk Encryption lista os tamanhos de VM e os sistemas operacionais de VM
compatíveis com o Azure Disk Encryption.
Posso criptografar volumes de dados e de inicialização com o Azure

Disk Encryption?
Sim, você pode criptografar volumes de dados junto com os de inicialização ou apenas volumes de dados sem
precisar criptografar o volume do sistema operacional primeiro.
Depois de criptografar o volume do sistema operacional, não é possível desabilitar a criptografia no volume do
sistema operacional. Em VMs Linux em um conjunto de dimensionamento, somente o volume de dados pode
ser criptografado.
Posso criptografar um volume não montado com o Azure Disk

Encryption?
Não, o Azure Disk Encryption criptografa apenas volumes montados.
O que é criptografia do lado do servidor do Armazenamento?

A criptografia do lado do servidor do Armazenamento criptografa discos gerenciados do Azure no
Armazenamento do Microsoft Azure. Discos gerenciados são criptografados por padrão com criptografia do
lado do servidor com chave gerenciada de plataforma (a partir de 10 de junho de 2017). Você pode gerenciar a
criptografia de discos gerenciados com suas próprias chaves especificando uma chave gerenciada pelo cliente.
Para obter mais informações, consulte: Criptografia do lado do servidor dos discos gerenciados do Azure.
Qual é a diferença entre o Azure Disk Encryption e a criptografia do

lado do servidor do Armazenamento com chave gerenciada pelo
cliente e quando eu devo usar cada solução?
O Azure Disk Encryption fornece criptografia de ponta a ponta para o disco do sistema operacional, discos de
dados e o disco temporário, usando uma chave gerenciada pelo cliente.
Se seus requisitos incluírem todas as criptografias acima e de ponta a ponta, use o Azure Disk Encryption.
Se seus requisitos incluírem a criptografia somente de dados em repouso com a chave gerenciada pelo
cliente, use a criptografia do lado do servidor com chaves gerenciadas pelo cliente. Você não pode
criptografar, ao mesmo tempo, um disco com o Azure Disk Encryption e a criptografia do lado do servidor do
Armazenamento com chaves gerenciadas do cliente.
Se sua distribuição do Linux não estiver listada em sistemas operacionais com suporte para Azure Disk
Encryption ou você estiver usando um cenário destacado em cenários sem suporte para o Windows,
considere a criptografia do lado do servidor com chaves gerenciadas pelo cliente.
Se a política da sua organização permitir criptografar conteúdo em repouso com uma chave gerenciada pelo
Azure, nenhuma ação será necessária. O conteúdo será criptografado por padrão. Para discos gerenciados, o
conteúdo no armazenamento é criptografado por padrão com a criptografia do lado do servidor com chave
gerenciada por plataforma. A chave é gerenciada pelo serviço de Armazenamento do Microsoft Azure.
Como fazer revezar segredos ou chaves de criptografia?

Para revezar segredos, basta chamar o mesmo comando usado originalmente para habilitar a criptografia de
disco, especificando um Key Vault diferente. Para revezar a chave de criptografia da chave, chame o mesmo
comando usado originalmente para habilitar a criptografia de disco, especificando a nova criptografia de chave.
WARNING
Se usou anteriormente o Azure Disk Encryption com aplicativo do Microsoft Azure Active Directory ao especificar
credenciais do Azure Active Directory para criptografar essa VM, você deverá continuar usando essa opção para
criptografar a VM. Não é possível usar o Azure Disk Encryption nessa VM criptografada pois esse cenário não tem
suporte, o que significa que ainda não é possível alternar o aplicativo AAD por essa VM criptografada.
Como fazer para adicionar ou remover uma chave de criptografia da
chave senão utilizei originalmente uma?
Para adicionar uma chave de criptografia da chave, chame o comando “enable” novamente passando o
parâmetro de chave de criptografia da chave. Para remover uma chave de criptografia da chave, chame o
comando “enable” sem passar o parâmetro de chave de criptografia da chave.
O Azure Disk Encryption permite o recurso BYOK (Bring Your Own

Key)?
Sim, você pode fornecer suas próprias chaves de criptografia de chave. Essas chaves ficam protegidas no Azure
Key Vault, que é o repositório de chaves do Azure Disk Encryption. Para obter mais informações sobre cenários
de suporte de chaves de criptografia, consulte Criar e configurar um cofre de chaves para Azure Disk
Encryption.
Posso usar uma chave de criptografia de chave criada pelo Azure?

Sim, você pode usar o Azure Key Vault para gerar uma chave de criptografia de chave para ser usada pela
criptografia de disco do Azure. Essas chaves ficam protegidas no Azure Key Vault, que é o repositório de chaves
do Azure Disk Encryption. Para obter mais informações sobre chave de criptografia, consulte Criar e configurar
um cofre de chaves para Azure Disk Encryption.
Posso usar um serviço de gerenciamento de chaves local ou HSM

para proteger as chaves de criptografia?
Você não pode usar o serviço de gerenciamento de chaves local ou HSM para proteger as chaves de criptografia
com o Azure Disk Encryption. Você só pode usar o serviço Azure Key Vault para proteger as chaves de
criptografia. Para obter mais informações sobre cenários de suporte de chave de criptografia, consulte Criar e
configurar um cofre de chaves para Azure Disk Encryption.
Quais são os pré-requisitos para configurar o Azure Disk Encryption?

Há pré-requisitos para o Azure Disk Encryption. Consulte o artigo Criar e configurar um cofre de chaves para o
Azure Disk Encryption para criar um novo cofre de chaves ou configurar um cofre de chaves existente para
acesso da criptografia de disco para habilitar a criptografia e proteger segredos e chaves. Para obter mais
informações sobre cenários de suporte de chave de criptografia, consulte Criar e configurar um cofre de chaves
para Azure Disk Encryption.
Quais são os pré-requisitos para configurar o Azure Disk Encryption

com um aplicativo do Azure AD (versão anterior)?
Há pré-requisitos para o Azure Disk Encryption. Consulte o conteúdo Azure Disk Encryption com o Azure Active
Directory para criar um aplicativo do Azure Active Directory, criar um novo cofre de chaves ou configurar um
cofre de chaves existente para criptografia de disco para ativar a criptografia e proteger segredos e chaves. Para
obter mais informações sobre cenários de suporte de chave de criptografia, consulte Criar e configurar um cofre
de chaves para Azure Disk Encryption com o Azure Active Directory.
Ainda há suporte para o Azure Disk Encryption usando um aplicativo

do Azure AD (versão anterior)?
Sim. Ainda há suporte para criptografia de disco usando um aplicativo do Azure AD. No entanto, ao criptografar
novas VMs, é recomendável que você use o novo método em vez de criptografar com um aplicativo do Azure
AD.
Posso migrar VMs que foram criptografadas com um aplicativo do

Azure AD para a criptografia sem um aplicativo do Azure AD?
Atualmente, não há um caminho de migração direto para computadores que foram criptografados com um
aplicativo do Azure AD para criptografia sem um aplicativo do Azure AD. Além disso, também não há um
caminho direto da criptografia sem um aplicativo do Azure AD para a criptografia com o aplicativo do AD.
À qual versão do Azure PowerShell o Azure Disk Encryption dá

suporte?
Use a versão mais recente do SDK do Azure PowerShell para configurar o Azure Disk Encryption. Baixe a última
versão do Azure PowerShell. O Azure Disk Encryption não é suportado pela versão 1.1.0 do SDK do Azure.
NOTE
A extensão de versão prévia de criptografia de disco do Azure para Linux
"Microsoft.OSTCExtension.AzureDiskEncryptionForLinux" foi preterida. Essa extensão foi publicada para a versão prévia de
criptografia de disco do Azure. Você não deve usar a versão de visualização da extensão na sua implantação de teste ou
de produção.
Para cenários de implantação, como o Azure Resource Manager (ARM), em que você precisa implantar a
extensão de criptografia de disco do Azure para VM do Linux para habilitar a criptografia em sua VM de IaaS
do Linux, é necessário usar a extensão com suporte para produção do Azure Disk Encryption
"Microsoft.Azure.Security.AzureDiskEncryptionForLinux".
Posso aplicar o Azure Disk Encryption à minha imagem personalizada

do Linux?
Você não pode aplicar a criptografia de disco do Azure à sua imagem personalizada do Linux. Somente as
imagens da galeria Linux para as distribuições suportadas chamadas anteriormente são suportadas. Imagens
personalizadas do Linux não são suportadas atualmente.
Posso aplicar atualizações a uma VM Red Hat Linux que usa a

atualização do yum?
Sim, você pode executar uma atualização do yum em uma VM Red Hat Linux. Para obter mais informações,
consulte Azure Disk Encryption em uma rede isolada.
O que é o fluxo de trabalho recomendado de criptografia de disco do

Azure recomendado para Linux?
O seguinte fluxo de trabalho é recomendado para ter os melhores resultados no Linux:
Inicie na imagem da galeria de estoque não modificada que corresponde à distribuição e à versão do sistema
operacional necessárias
Faça backup de todas as unidades montadas que serão criptografadas. Esse backup permitirá a recuperação
se houver uma falha, por exemplo, se a VM for reinicializada antes da conclusão da criptografia.
Criptografar (pode levar várias horas ou mesmo dias dependendo das características da VM e do tamanho
dos discos de dados anexados)
Personalizar e adicionar o software à imagem conforme necessário.
Se esse fluxo de trabalho não for possível, usar a SSE (Criptografia do Serviço de Armazenamento) na camada
da conta de armazenamento de plataforma poderá ser uma alternativa para a criptografia de disco completo
usando dm-crypt.
O que é o disco "Volume Bek" ou "/mnt/azure_bek_disk"?

O “volume Bek” é um volume de dados locais que armazena com segurança chaves de criptografia para VMs
Azure criptografadas.
NOTE
Não exclua ou edite nenhum conteúdo neste disco. Não desmonte o disco, uma vez que a presença da chave de
criptografia é necessária para operações de criptografia na VM IaaS.
Qual método de criptografia é usado pela criptografia de disco do

Azure?
O Azure Disk Encryption usa o padrão de descriptografia aes-xts-plain64 com uma chave mestra de volume de
256-bit.
Se eu usar EncryptFormatAll e especificar todos os tipos de volume,

ele apagará os dados em unidades de dados que já tivermos
criptografado?
Não, os dados não serão apagados de unidades de dados que já tiverem sido criptografadas usando o Azure
Disk Encryption. Semelhante ao modo como o EncryptFormatAll não criptografou novamente a unidade do
sistema operacional, ele não criptografará novamente a unidade de dados já criptografada. Para obter mais
informações, veja os critérios do EncryptFormatAll.
Há suporte para o sistema de arquivos XFS?

A criptografia de discos de sistema operacional XFS tem suporte.
A criptografia de discos de dados XFS é suportada somente quando o parâmetro EncryptFormatAll é usado. Isso
reformatará o volume, apagando todos os dados que já existiam. Para obter mais informações, veja os critérios
do EncryptFormatAll.
Posso fazer backup e restaurar uma VM criptografada?

O Backup do Azure fornece um mecanismo para fazer backup e restaurar VMs criptografadas na mesma
assinatura e região. Para obter instruções, consulte Backup e restauração de máquinas virtuais criptografadas
usando o Backup do Azure. Atualmente, não há suporte para a restauração de uma VM criptografada em uma
região diferente.
Onde posso fazer perguntas ou fornecer comentários?

Você pode fazer perguntas ou comentários na Página de P e R da Microsoft para Azure Disk Encryption.
Próximas etapas
Neste documento, você aprendeu mais sobre as perguntas mais frequentes relativas ao Azure Disk Encryption.
Para obter mais informações sobre esse serviço, veja os seguintes artigos:
Perguntas frequentes sobre Azure Disk Encryption
para máquinas virtuais do Windows
Este artigo fornece respostas a perguntas frequentes sobre o Azure Disk Encryption para VMs do Windows. Para
obter mais informações sobre esse serviço, consulte Visão geral do Azure Disk Encryption.
O que é o Azure Disk Encryption para VMs do Windows?

O Azure Disk Encryption para VMs do Windows usa o recurso BitLocker do Windows para fornecer criptografia
completa do disco do sistema operacional e dos discos de dados. Além disso, ele fornece criptografia do disco
temporário quando o parâmetro VolumeType é All. O conteúdo é transmitido criptografado da VM para ao back-
end do Armazenamento. Assim, é fornecida uma criptografia de ponta a ponta com uma chave gerenciada pelo
cliente.
Consulte Sistemas operacionais e VMs com suporte.
Onde o Azure Disk Encryption está na GA (disponibilidade geral)?

O Azure Disk Encryption está em disponibilidade geral em todas as regiões públicas do Azure.
Quais experiências de usuário estão disponíveis com o Azure Disk

Encryption?
A GA do Azure Disk Encryption dá suporte a modelos do Azure Resource Manager, ao Azure PowerShell e à CLI
do Azure. As diferentes experiências de usuário oferecem flexibilidade. Você tem três opções diferentes para
habilitar a criptografia de disco para suas VMs. Para saber mais sobre a experiência do usuário e as orientações
passo a passo disponíveis no Azure Disk Encryption, consulte Cenários do Azure Disk Encryption para Windows.
Quanto custa o Azure Disk Encryption?

Não há nenhum encargo para criptografar discos de VM com o Azure Disk Encryption, mas há encargos
associados ao uso do Azure Key Vault. Para obter mais informações sobre os custos do Cofre de Chaves do
Azure, consulte a página de preços Cofre de chaves.
Como posso começar a usar o Azure Disk Encryption?

Para começar, leia as visão geral do Azure Disk Encryption.
Quais tamanhos de VM e sistemas operacionais dão suporte ao Azure

Disk Encryption?
O artigo Visão geral do Azure Disk Encryption lista os tamanhos de VM e os sistemas operacionais de VM
compatíveis com o Azure Disk Encryption.
Posso criptografar volumes de dados e de inicialização com o Azure

Disk Encryption?
Você pode criptografar volumes de dados e de boot, mas não pode criptografar os dados sem primeiro
criptografar o volume do sistema operacional (SO).
Posso criptografar um volume não montado com o Azure Disk

Encryption?
Não, o Azure Disk Encryption criptografa apenas volumes montados.
O que é criptografia do lado do servidor do Armazenamento?

A criptografia do lado do servidor do Armazenamento criptografa discos gerenciados do Azure no
Armazenamento do Microsoft Azure. Discos gerenciados são criptografados por padrão com criptografia do
lado do servidor com chave gerenciada de plataforma (a partir de 10 de junho de 2017). Você pode gerenciar a
criptografia de discos gerenciados com suas próprias chaves especificando uma chave gerenciada pelo cliente.
Para saber mais, confira Criptografia do lado do servidor dos discos gerenciados do Azure.
Qual é a diferença entre o Azure Disk Encryption e a criptografia do

lado do servidor do Armazenamento com chave gerenciada pelo
cliente e quando eu devo usar cada solução?
O Azure Disk Encryption fornece criptografia de ponta a ponta para o disco do sistema operacional, discos de
dados e o disco temporário com uma chave gerenciada pelo cliente.
Se seus requisitos incluírem todas as criptografias acima e de ponta a ponta, use o Azure Disk Encryption.
Se seus requisitos incluírem a criptografia somente de dados em repouso com a chave gerenciada pelo
cliente, use a criptografia do lado do servidor com chaves gerenciadas pelo cliente. Você não pode
criptografar, ao mesmo tempo, um disco com o Azure Disk Encryption e a criptografia do lado do servidor do
Armazenamento com chaves gerenciadas do cliente.
Se você estiver usando um cenário chamado em cenários do Windows não compatíveis, considere
Criptografia do lado do servidor com chaves gerenciadas pelo cliente.
Se a política da sua organização permitir criptografar conteúdo em repouso com uma chave gerenciada pelo
Azure, nenhuma ação será necessária. O conteúdo será criptografado por padrão. Para discos gerenciados, o
conteúdo no armazenamento é criptografado por padrão com a criptografia do lado do servidor com chave
gerenciada por plataforma. A chave é gerenciada pelo serviço de Armazenamento do Microsoft Azure.
Como fazer revezar segredos ou chaves de criptografia?

Para revezar segredos, basta chamar o mesmo comando usado originalmente para habilitar a criptografia de
disco, especificando um Key Vault diferente. Para revezar a chave de criptografia da chave, chame o mesmo
comando usado originalmente para habilitar a criptografia de disco, especificando a nova criptografia de chave.
WARNING
Se usou anteriormente o Azure Disk Encryption com aplicativo do Microsoft Azure Active Directory ao especificar
credenciais do Azure Active Directory para criptografar essa VM, você deverá continuar usando essa opção para
criptografar a VM. Não é possível usar o Azure Disk Encryption nessa VM criptografada pois esse cenário não tem
suporte, o que significa que ainda não é possível alternar o aplicativo AAD por essa VM criptografada.
Como fazer para adicionar ou remover uma chave de criptografia da

chave senão utilizei originalmente uma?
Para adicionar uma chave de criptografia da chave, chame o comando “enable” novamente passando o
parâmetro de chave de criptografia da chave. Para remover uma chave de criptografia da chave, chame o
comando “enable” sem passar o parâmetro de chave de criptografia da chave.
O Azure Disk Encryption permite o recurso BYOK (Bring Your Own

Key)?
Sim, você pode fornecer suas próprias chaves de criptografia de chave. Essas chaves ficam protegidas no Azure
Key Vault, que é o repositório de chaves do Azure Disk Encryption. Para obter mais informações sobre cenários
de suporte de chaves de criptografia, consulte Criar e configurar um cofre de chaves para Azure Disk
Encryption.
Posso usar uma chave de criptografia de chave criada pelo Azure?

Sim, você pode usar o Azure Key Vault para gerar uma chave de criptografia de chave para ser usada pela
criptografia de disco do Azure. Essas chaves ficam protegidas no Azure Key Vault, que é o repositório de chaves
do Azure Disk Encryption. Para obter mais informações sobre chave de criptografia, consulte Criar e configurar
um cofre de chaves para Azure Disk Encryption.
Posso usar um serviço de gerenciamento de chaves local ou HSM

para proteger as chaves de criptografia?
Você não pode usar o serviço de gerenciamento de chaves local ou HSM para proteger as chaves de criptografia
com o Azure Disk Encryption. Você só pode usar o serviço Azure Key Vault para proteger as chaves de
criptografia. Para obter mais informações sobre cenários de suporte de chave de criptografia, consulte Criar e
configurar um cofre de chaves para Azure Disk Encryption.
Quais são os pré-requisitos para configurar o Azure Disk Encryption?

Há pré-requisitos para o Azure Disk Encryption. Consulte o artigo Criar e configurar um cofre de chaves para o
Azure Disk Encryption para criar um novo cofre de chaves ou configurar um cofre de chaves existente para
acesso da criptografia de disco para habilitar a criptografia e proteger segredos e chaves. Para obter mais
informações sobre cenários de suporte de chave de criptografia, consulte Criar e configurar um cofre de chaves
para Azure Disk Encryption.
Quais são os pré-requisitos para configurar o Azure Disk Encryption

com um aplicativo do Azure AD (versão anterior)?
Há pré-requisitos para o Azure Disk Encryption. Consulte o conteúdo Azure Disk Encryption com o Azure Active
Directory para criar um aplicativo do Azure Active Directory, criar um novo cofre de chaves ou configurar um
cofre de chaves existente para criptografia de disco para ativar a criptografia e proteger segredos e chaves. Para
obter mais informações sobre cenários de suporte de chave de criptografia, consulte Criar e configurar um cofre
de chaves para Azure Disk Encryption com o Azure Active Directory.
Ainda há suporte para o Azure Disk Encryption usando um aplicativo

do Azure AD (versão anterior)?
Sim. Ainda há suporte para criptografia de disco usando um aplicativo do Azure AD. No entanto, ao criptografar
novas VMs, é recomendável que você use o novo método em vez de criptografar com um aplicativo do Azure
AD.
Posso migrar VMs que foram criptografadas com um aplicativo do
Azure AD para a criptografia sem um aplicativo do Azure AD?
Atualmente, não há um caminho de migração direto para computadores que foram criptografados com um
aplicativo do Azure AD para criptografia sem um aplicativo do Azure AD. Além disso, também não há um
caminho direto da criptografia sem um aplicativo do Azure AD para a criptografia com o aplicativo do AD.
À qual versão do Azure PowerShell o Azure Disk Encryption dá

suporte?
Use a versão mais recente do SDK do Azure PowerShell para configurar o Azure Disk Encryption. Baixe a última
versão do Azure PowerShell. O Azure Disk Encryption não é suportado pela versão 1.1.0 do SDK do Azure.
O que é o disco "Volume Bek" ou "/mnt/azure_bek_disk"?

O “volume Bek” é um volume de dados locais que armazena com segurança chaves de criptografia para VMs
Azure criptografadas.
NOTE
Não exclua ou edite nenhum conteúdo neste disco. Não desmonte o disco, uma vez que a presença da chave de
criptografia é necessária para operações de criptografia na VM IaaS.
Qual método de criptografia é usado pela criptografia de disco do

Azure?
O Azure Disk Encryption seleciona o método de criptografia no BitLocker com base na versão do Windows, da
seguinte maneira:
VERSÕ ES DO W IN DO W S VERSÃ O M ÉTO DO DE C RIP TO GRA F IA
Windows Server 2012, Windows 10 ou >=1511 XTS-AES de 256 bits

superior
Windows Server 2012, Windows 8, < 1511 AES de 256 bits*

8.1, 10
Windows Server 2008R2 AES de 256 bits com Difusor
* O AES de 256 bits com Difusor não é compatível com o Windows 2012 e posterior.
Para determinar a versão do sistema operacional Windows, execute a ferramenta “winver”' em sua máquina
virtual.
Posso fazer backup e restaurar uma VM criptografada?

O Backup do Azure fornece um mecanismo para fazer backup e restaurar VMs criptografadas na mesma
assinatura e região. Para obter instruções, consulte Backup e restauração de máquinas virtuais criptografadas
usando o Backup do Azure. Atualmente, não há suporte para a restauração de uma VM criptografada em uma
região diferente.
Onde posso fazer perguntas ou fornecer comentários?

Você pode fazer perguntas ou comentários na Página de P e R da Microsoft para Azure Disk Encryption.
Próximas etapas
Neste documento, você aprendeu mais sobre as perguntas mais frequentes relativas ao Azure Disk Encryption.
Para obter mais informações sobre esse serviço, veja os seguintes artigos:
Azure Disk Encryption com Azure Active Directory
(AD) (versão anterior)
A nova versão do Azure Disk Encryption elimina a necessidade de fornecer um parâmetro de aplicativo Azure
Active Directory (AD do Azure) para habilitar a criptografia de disco de VM. Com a nova versão, não é mais
necessário fornecer credenciais do Azure AD durante a etapa para habilitar criptografia. Todas as novas VMs
devem ser criptografadas sem os parâmetros do aplicativo do Azure AD usando a nova versão. Para obter
instruções sobre como habilitar a criptografia de disco de VM usando a nova versão, consulte Azure Disk
Encryption para VMs do Linux. As VMs que já foram criptografadas com os parâmetros de aplicativo do Azure
AD ainda têm suporte e devem continuar a ser mantidas com a sintaxe do AAD.
Este artigo fornece suplementos para Azure Disk Encryption para VMs Linux com requisitos e pré-requisitos
adicionais para Azure Disk Encryption com o Azure AD (versão anterior).
As informações contidas nessas seções permanecem as mesmas:
Requisitos adicionais da VM
Sistema de rede e a diretiva de grupo

Para habilitar o recurso de Azure Disk Encryption usando a sintaxe de parâmetro AAD mais antiga, as VMs de
IaaS (infraestrutura como serviço) devem atender aos seguintes requisitos de configuração de ponto de
extremidade de rede:
Para obter um token para se conectar ao cofre de chaves, a VM IaaS deve ser capaz de se conectar a um
ponto de extremidade do Azure AD, [ login.microsoftonline.com ] .
Para gravar as chaves de criptografia no cofre de chaves, a VM IaaS deve ser capaz de se conectar ao ponto
de extremidade do cofre de chaves.
A VM IaaS deve ser capaz de se conectar a um ponto de extremidade do armazenamento do Azure que
hospeda o repositório de extensão do Azure e uma conta de armazenamento do Azure que hospeda os
arquivos VHD.
Se sua política de segurança limitar o acesso de VMs do Azure à Internet, você poderá resolver o URI anterior
e configurar uma regra específica para permitir a conectividade de saída com os IPs. Para obter mais
informações, consulte Azure Key Vault por trás de um firewall.
No Windows, se o TLS 1,0 estiver explicitamente desabilitado e a versão do .NET não for atualizada para 4,6
ou superior, a seguinte alteração de registro permitirá que Azure Disk Encryption selecione a versão mais
recente do TLS:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001`
Política de Grupo
A solução de Azure Disk Encryption usa o protetor de chave externa BitLocker para VMs IaaS do
Windows. Para VMs ingressadas no domínio, não envie nenhuma política de grupo que imponha
protetores de TPM. Para obter informações sobre o Política de Grupo para a opção permitir BitLocker
sem um TPM compatível , consulte referência de política de grupo do BitLocker.
A política do BitLocker em máquinas virtuais ingressadas no domínio com um Política de Grupo
personalizado deve incluir a seguinte configuração: Configurar o armazenamento do usuário das
informações de recuperação do BitLocker-> permitir a chave de recuperação de 256 bits. Azure Disk
Encryption falha quando as configurações de Política de Grupo personalizadas para o BitLocker são
incompatíveis. Em computadores que não têm a configuração de política correta, aplique a nova política,
force a nova política a ser atualizada (gpupdate.exe/Force) e, em seguida, reinicie se for necessário.

Azure Disk Encryption requer Azure Key Vault para controlar e gerenciar chaves de criptografia de disco e
segredos. Seu cofre de chaves e as VMs devem residir na mesma região e assinatura do Azure.
Para obter mais informações, consulte criando e configurando um cofre de chaves para Azure Disk Encryption
com o Azure AD (versão anterior).
Próximas etapas
Criando e configurando um cofre de chaves para Azure Disk Encryption com o Azure AD (versão anterior)
Habilitar Azure Disk Encryption com o Azure AD em VMs do Linux (versão anterior)
Azure Disk Encryption com o Azure AD (versão
anterior)
A nova versão do Azure Disk Encr yption elimina a necessidade de fornecer um parâmetro de
aplicativo do Azure AD para habilitar a criptografia de disco de VM. Com a nova versão, você não
precisa mais fornecer as credenciais do Azure AD durante a etapa habilitar criptografia. Todas as
novas VMs devem ser criptografadas sem os parâmetros de aplicativo do Azure AD usando a nova
versão. Para exibir instruções para habilitar a criptografia de disco de VM usando a nova versão,
consulte Azure Disk Encr yption para VMs do Windows . As VMs que já foram criptografadas com
parâmetros de aplicativo do Azure AD ainda têm supor te e devem continuar a ser mantidas com a
sintaxe do AAD.
Este artigo complementa Azure Disk Encryption para VMs do Windows com requisitos e pré-requisitos
adicionais para Azure Disk Encryption com o Azure AD (versão anterior). A seção VMs e sistemas operacionais
com suporte permanece a mesma.
Sistema de rede e a diretiva de grupo

Para habilitar o recurso de Azure Disk Encr yption usando a sintaxe do parâmetro AAD, as VMs
IaaS devem atender os requisitos de configuração do ponto de extremidade da rede a seguir :
Para obter um token para se conectar ao seu cofre de chaves, a VM IaaS deve ser capaz de se conectar a um
ponto de extremidade do Azure Active Directory, [login.microsoftonline.com].
Para gravar as chaves de criptografia no cofre de chaves, a VM IaaS deve ser capaz de se conectar ao ponto
de extremidade do cofre de chaves.
A VM IaaS deve ser capaz de se conectar a um ponto de extremidade do armazenamento do Azure que
hospeda o repositório de extensão do Azure e uma conta de armazenamento do Azure que hospeda os
arquivos VHD.
Se a política de segurança limita o acesso de VMs do Azure à Internet, você pode resolver o URI anterior e
configurar uma regra específica para permitir a conectividade de saída para os IPs. Para obter mais
informações, consulte Azure Key Vault por trás de um firewall.
A VM a ser criptografada deve ser configurada para usar o TLS 1,2 como o protocolo padrão. Se o TLS 1,0
tiver sido explicitamente desabilitado e a versão do .NET não tiver sido atualizada para 4,6 ou superior, a
seguinte alteração no registro permitirá que o ADE selecione a versão mais recente do TLS:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001`
Política de Grupo:
A solução de Azure Disk Encryption usa o protetor de chave externa BitLocker para VMs IaaS do
Windows. Para VMs ingressado no domínio, não envie por push todas as políticas de grupo que
imponham protetores TPM. Para obter informações sobre a política de grupo "Permitir BitLocker sem um
TPM compatível", confira Referência de política de grupo do BitLocker.
A política do BitLocker em máquinas virtuais ingressadas no domínio com a política de grupo
personalizada deve incluir a seguinte configuração: Configurar o armazenamento do usuário das
informações de recuperação do BitLocker-> permitir chave de recuperação de 256 bits. O Azure Disk
Encryption falha quando as configurações da política de grupo personalizada para o BitLocker são
incompatíveis. Em computadores que não tinham a configuração de política correta, aplique a nova
política, force a atualização da nova política (gpupdate.exe /force) e, em seguida, pode ser necessário
reiniciar.

O Azure Disk Encryption requer um Azure Key Vault para ajudar você a controlar e gerenciar os segredos e
chaves de criptografia de disco. Seu cofre de chaves e as VMs devem residir na mesma região e assinatura do
Azure.
Para obter detalhes, consulte criando e configurando um cofre de chaves para Azure Disk Encryption com o
Azure AD (versão anterior).
Próximas etapas
Habilitar Azure Disk Encryption com o Azure AD em VMs do Windows (versão anterior)
Criando e configurando um cofre de chaves para
anterior) para VMs do Linux
consulte Azure Disk Encr yption . As VMs que já foram criptografadas com parâmetros de aplicativo
do Azure AD ainda têm supor te e devem continuar a ser mantidas com a sintaxe do AAD.
Criar e configurar um cofre de chaves para uso com o Azure Disk Encryption com o Azure AD (versão anterior)
envolve três etapas:
1. Crie um cofre da chave.
2. Configure um aplicativo do Azure AD e entidade de serviço.
3. Defina a política de acesso do Cofre de chaves para o aplicativo do Azure AD.
4. Defina as políticas de acesso avançado da chave de segurança.
Consulte o artigo principal criando e configurando um cofre de chaves para Azure Disk Encryption para obter as
etapas de como instalar as ferramentas e conectar-se ao Azure.
NOTE

O Azure Disk Encryption se integra Azure Key Vault para ajudá-lo a controlar e gerenciar as chaves de
criptografia de disco e segredos em sua assinatura do Cofre de chaves. Você pode criar um cofre de chaves ou
usar um existente para o Azure Disk Encryption. Para obter mais informações sobre cofres-chave, consulte
Introdução ao Cofre de Chaves do Azure e Proteja seu cofre de chaves. Você pode usar um modelo do Resource
Manager, o Azure PowerShell ou a CLI do Azure para criar um cofre de chaves.
WARNING
Para garantir que os segredos de criptografia não ultrapassem os limites regionais, o Azure Disk Encryption precisa que o
Key Vault e as VMs sejam colocados na mesma região. Crie e use um cofre de chaves que esteja na mesma região da VM
a ser criptografada.
Criar um cofre de chaves com o PowerShell
Você pode criar um cofre de chaves com Azure PowerShell usando o cmdlet New-AzKeyVault . Para obter
cmdlets adicionais para Key Vault, consulte AZ. keyvault.
1. Crie um novo grupo de recursos, se necessário, com New-AzResourceGroup. Para listar locais de data
center, use Get-AzLocation.
# Get-AzLocation
New-AzResourceGroup –Name 'MyKeyVaultResourceGroup' –Location 'East US'
2. Criar um novo cofre de chaves usando New-AzKeyVault
New-AzKeyVault -VaultName 'MySecureVault' -ResourceGroupName 'MyKeyVaultResourceGroup' -Location

'East US'
3. Observe a nome do cofre , nome do grupo de recursos , ID do recurso , URI do cofre e o ID de

objeto que são retornados para uso posterior ao criptografar os discos.
Criar um cofre de chaves com CLI do Azure
Você pode gerenciar o Cofre de chaves com CLI do Azure usando os comandos keyvault az. Para criar um cofre
de chaves, use az creata.
1. Criar um novo grupo de recursos, se necessário, com criar grupo de az. Para listar os locais, use locais de
lista az conta
# To list locations: az account list-locations --output table

az group create -n "MyKeyVaultResourceGroup" -l "East US"
2. Crie um novo cofre de chave usando az keyvault create.
az keyvault create --name "MySecureVault" --resource-group "MyKeyVaultResourceGroup" --location "East

US"
3. Observação o nome do cofre (nome), nome do grupo de recursos , ID do recurso (ID), URI do
cofre e o deIDdeobjeto que são retornados para uso posterior.
Criar um cofre de chaves com um modelo do Resource Manager
Você pode criar um cofre de chaves usando o modelo Resource Manager.
2. Selecione a assinatura, o grupo de recursos, o local do grupo de recursos, o nome do Key Vault, a ID do
objeto, os termos legais e o contrato e clique em comprar .
Configurar um aplicativo do Azure AD e o serviço de entidade

Quando você precisa habilitar a criptografia em uma VM em execução no Azure, o Azure Disk Encryption gera e
grava as chaves de criptografia no cofre de chaves. O gerenciamento de chaves de criptografia no cofre de
chaves requer a autenticação do Azure AD. Crie um aplicativo do Azure AD para essa finalidade. Para fins de
autenticação, você pode usar a autenticação baseada em segredo do cliente ou a autenticação do Azure AD
baseada em certificado de cliente.
Configure um aplicativo e uma entidade de serviço do Azure AD com o Azure PowerShell
Para executar os seguintes comandos, obtenha e use o módulo do PowerShell do Azure AD.
1. Use o cmdlet do PowerShell New-AzADApplication para criar um aplicativo do Azure AD.
MyApplicationHomePage e MyApplicationUri podem ser quaisquer valores que você desejar.
$aadClientSecret = "My AAD client secret"

$aadClientSecretSec = ConvertTo-SecureString -String $aadClientSecret -AsPlainText -Force
$azureAdApplication = New-AzADApplication -DisplayName "My Application Display Name" -HomePage
"https://MyApplicationHomePage" -IdentifierUris "https://MyApplicationUri" -Password
$aadClientSecretSec
$servicePrincipal = New-AzADServicePrincipal –ApplicationId $azureAdApplication.ApplicationId
2. O $ azureAdApplication.ApplicationId é o ClientID do Azure AD e o $ aadClientSecret é o segredo do

cliente que você usará posteriormente para ativar a Criptografia de Disco do Azure. Proteja
adequadamente o segredo do cliente no Azure AD. A execução $azureAdApplication.ApplicationId
mostrará o ApplicationID.
Configure um aplicativo e uma entidade de serviço do Azure AD com a CLI do Azure
Você pode gerenciar seus principais de serviço com a CLI do Azure usando os comandos az ad sp. Para obter
mais informações, consulte criar uma entidade de serviço do Azure.
1. Crie uma nova entidade de serviço.
az ad sp create-for-rbac --name "ServicePrincipalName" --password "My-AAD-client-secret" --skip-

assignment
2. O appId retornado é o ClientID do Azure AD usado em outros comandos. Ele é também o SPN que você
usará para az keyvault set-policy. A senha é o segredo do cliente que você deve usar posteriormente para
ativar a criptografia de disco do Azure. Proteja adequadamente o segredo do cliente no Azure AD.
Configure um aplicativo e uma entidade de serviço do Azure AD através do portal do Azure
Use as etapas do artigo usar o portal para criar aplicativo e entidade de serviço que pode acessar recursos de
um Azure Active Directory para criar um aplicativo do Azure AD. Cada etapa listada abaixo levará você
diretamente para a seção de artigos para concluir.
1. Verifique se as permissões necessárias
2. Criar um aplicativo do Azure Active Directory
Você pode usar qualquer nome e URL de logon que desejar ao criar o aplicativo.
3. Obtenha o ID do aplicativo e a chave de autenticação.
A chave de autenticação é o segredo do cliente e é usada como AadClientSecret para Set-
AzVMDiskEncryptionExtension.
A chave de autenticação é usada pelo aplicativo como uma credencial para entrar no Azure AD.
No portal do Azure, esse segredo é chamado de chaves, mas não tem relação com os cofres da
chave. Proteja esse segredo adequadamente.
A ID do aplicativo será usada posteriormente como AadClientId para Set-
AzVMDiskEncryptionExtension e como o servicePrincipalName para Set-AzKeyVaultAccessPolicy.
Defina a política de acesso ao cofre de chaves para o aplicativo Azure

AD
Para gravar segredos de criptografia em um Cofre de Chaves especificado, o Azure Disk Encryption precisa do
ID do Cliente e do Segredo do Cliente do aplicativo Azure Active Directory que tenha permissões para gravar
segredos no Cofre de Chaves.
NOTE
o Azure Disk Encryption exige que você configure as seguintes políticas de acesso ao aplicativo de cliente do Azure AD:
permissões WrapKey e Set .
Defina a política de acesso ao cofre principal para o aplicativo Azure AD com o Azure PowerShell
Seu aplicativo Azure AD precisa de direitos para acessar as chaves ou os segredos no cofre. Use o cmdlet set-
AzKeyVaultAccessPolicy para conceder permissões ao aplicativo, usando a ID do cliente (que foi gerada quando
o aplicativo foi registrado) como o valor do parâmetro – servicePrincipalName . Para saber mais, confira a
postagem de blog Azure Key Vault - passo a passo.
1. Defina a política de acesso ao vault principal para o aplicativo AD com o PowerShell.
$keyVaultName = 'MySecureVault'
$aadClientID = 'MyAadAppClientID'
$KVRGname = 'MyKeyVaultResourceGroup'
Set-AzKeyVaultAccessPolicy -VaultName $keyVaultName -ServicePrincipalName $aadClientID -
PermissionsToKeys 'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname
Defina a política de acesso ao cofre de chaves do aplicativo Azure AD com a CLI do Azure
Use az keyvault set-policy para definir a política de acesso. Para obter mais informações, consulte Gerenciar
cofre de chaves usando o CLI 2.0.
Dê à entidade de serviço que você criou por meio do acesso da CLI do Azure para obter segredos e agrupar
chaves com o seguinte comando:
az keyvault set-policy --name "MySecureVault" --spn "<spn created with CLI/the Azure AD ClientID>" --key-
permissions wrapKey --secret-permissions set
Defina a política de acesso ao cofre de chaves do aplicativo Azure AD com o portal

1. Abra o grupo de recursos com o Cofre de chaves.
2. Selecione seu cofre de chaves, vá para Acessar Políticas e clique em Adicionar novo .
3. Em Selecionar principal , procure o aplicativo do Azure AD criado e selecione-o.
4. Para permissões de chave , verifique Wrap Key sob operações criptográficas .
5. Para permissões do segredo , verifique definir sob operações de gerenciamento de segredo .
6. Clique em Ok para salvar a política de acesso.
Definir políticas de acesso avançado do cofre de chaves
disponibilizá-los para a máquina virtual para inicialização e descriptografar os volumes. Habilite a criptografia
de disco no cofre da chave ou as implantações falharão.
Definir políticas de acesso avançado ao cofre de chaves com o Azure PowerShell
Set-AzKeyVaultAccessPolicy -VaultName 'MySecureVault' -ResourceGroupName 'MyKeyVaultResourceGroup' -


EnabledForDeployment

EnabledForTemplateDeployment
Definir Cofre de chaves avançadas de políticas de acesso usando a CLI do Azure

necessária.
az keyvault update --name "MySecureVault" --resource-group "MyKeyVaultResourceGroup" --enabled-for-

disk-encryption "true"
Habilite o cofre de chaves para a implantação, se necessário: máquinas de virtuais permitem

recuperar certificados armazenados como segredos do cofre.

deployment "true"


template-deployment "true"
Defina as políticas de acesso avançado ao cofre de chaves por meio do portal do Azure
1. Selecione sua keyvault, vá para Access Policies e Clique para mostrar as políticas de acesso
avançadas .
2. Selecione a caixa rotulada habilitar o acesso ao Azure Disk Encr yption para criptografia de volume
.
Configurar uma chave de criptografia de chave (opcional)

criptografia, adicione uma KEK ao seu cofre de chaves. Use o cmdlet Add-AzKeyVaultKey para criar uma chave
de criptografia de chave no cofre de chaves. Você também pode importar a KEK do HSM do gerenciamento de
chaves local. Para obter mais informações, consulte documentação do cofre de chaves. Quando uma chave de
criptografia de chave é especificada, o Azure Disk Encryption usa essa chave para agrupar os segredos de
criptografia antes de gravar no Key Vault.
Ao gerar chaves, use um tipo de chave RSA. Azure Disk Encryption ainda não dá suporte ao uso de
chaves de curva elíptica.
O segredo do cofre de chaves e as URLs KEK devem ter controle de versão. O Azure impõe essa restrição
Exemplo de uma URL KEK válida:
o Azure Disk Encryption não dá suporte à especificação de números de portas como parte de segredos
do cofre de chaves e URLs KEK. Para exemplos de URLs do cofre de chaves não suportados e suportados,
consulte os seguintes exemplos:
URL do cofre de chaves inaceitável
URL do cofre de chaves aceitável:
Configurar uma chave de criptografia chave com o Azure PowerShell
Antes de usar o script do PowerShell, você deve estar familiarizado com os pré-requisitos do Azure Disk
Encryption para entender as etapas no script. O script de amostra pode precisar de mudanças para seu
ambiente. Esse script cria todos os pré-requisitos da criptografia de disco do Azure e criptografa uma VM IaaS
existente, envolvendo a chave de criptografia de disco usando uma chave de criptografia de chave.
# Step 1: Create a new resource group and key vault in the same location.
# Fill in 'MyLocation', 'MyKeyVaultResourceGroup', and 'MySecureVault' with your values.
# Use Get-AzLocation to get available locations and use the DisplayName.
# To use an existing resource group, comment out the line for New-AzResourceGroup
$Loc = 'MyLocation';
New-AzResourceGroup –Name $KVRGname –Location $Loc;
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc;
$KeyVaultResourceId = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).ResourceId;
$diskEncryptionKeyVaultUrl = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).VaultUri;
# Step 2: Create the AD application and service principal.

# Fill in 'MyAADClientSecret', "<My Application Display Name>", "<https://MyApplicationHomePage>", and "
<https://MyApplicationUri>" with your values.
# MyApplicationHomePage and the MyApplicationUri can be any values you wish.
$aadClientSecret = 'MyAADClientSecret';
$aadClientSecretSec = ConvertTo-SecureString -String $aadClientSecret -AsPlainText -Force;
$azureAdApplication = New-AzADApplication -DisplayName "<My Application Display Name>" -HomePage "
<https://MyApplicationHomePage>" -IdentifierUris "<https://MyApplicationUri>" -Password $aadClientSecretSec
$servicePrincipal = New-AzADServicePrincipal –ApplicationId $azureAdApplication.ApplicationId;
$aadClientID = $azureAdApplication.ApplicationId;
#Step 3: Enable the vault for disk encryption and set the access policy for the Azure AD application.
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -

EnabledForDiskEncryption;
PermissionsToKeys 'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname;
#Step 4: Create a new key in the key vault with the Add-AzKeyVaultKey cmdlet.
# Fill in 'MyKeyEncryptionKey' with your value.
Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName -Destination 'Software';
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;
#Step 5: Encrypt the disks of an existing IaaS VM

# Fill in 'MySecureVM' and 'MyVirtualMachineResourceGroup' with your values.
$VMName = 'MySecureVM';
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $vmName -AadClientID $aadClientID -
AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -
DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl $keyEncryptionKeyUrl -
KeyEncryptionKeyVaultId $KeyVaultResourceId;
Autenticação baseada em certificado (opcional)

Se você quiser usar a autenticação de certificado, poderá fazer o upload de um para o seu cofre de chaves e
implantá-lo no cliente. Antes de usar o script do PowerShell, você deve estar familiarizado com os pré-requisitos
do Azure Disk Encryption para entender as etapas no script. O script de amostra pode precisar de mudanças
para seu ambiente.
# Fill in "MyKeyVaultResourceGroup", "MySecureVault", and 'MyLocation' ('My location' only if needed)
$KeyVaultName= 'MySecureVault'
# Create a key vault and set enabledForDiskEncryption property on it.

# Comment out the next three lines if you already have an existing key vault enabled for encryption. No
need to set 'My location' in this case.
$Loc = 'MyLocation'
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDiskEncryption
#Setting some variables with the key vault information

$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname
$DiskEncryptionKeyVaultUrl = $KeyVault.VaultUri
$KeyVaultResourceId = $KeyVault.ResourceId
# Create the Azure AD application and associate the certificate with it.
# Fill in "C:\certificates\mycert.pfx", "Password", "<My Application Display Name>", "
<https://MyApplicationHomePage>", and "<https://MyApplicationUri>" with your values.
# MyApplicationHomePage and the MyApplicationUri can be any values you wish
$CertPath = "C:\certificates\mycert.pfx"
$CertPassword = "Password"
$Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($CertPath,
$CertPassword)
$CertValue = [System.Convert]::ToBase64String($cert.GetRawCertData())
$AzureAdApplication = New-AzADApplication -DisplayName "<My Application Display Name>" -HomePage "

<https://MyApplicationHomePage>" -IdentifierUris "<https://MyApplicationUri>" -CertValue $CertValue
$ServicePrincipal = New-AzADServicePrincipal -ApplicationId $AzureAdApplication.ApplicationId
$AADClientID = $AzureAdApplication.ApplicationId
$aadClientCertThumbprint= $cert.Thumbprint
Set-AzKeyVaultAccessPolicy -VaultName $keyVaultName -ServicePrincipalName $aadClientID -PermissionsToKeys

'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname
# Upload the pfx file to the key vault.

# Fill in "MyAADCert".
$KeyVaultSecretName = "MyAADCert"
$FileContentBytes = get-content $CertPath -Encoding Byte
$FileContentEncoded = [System.Convert]::ToBase64String($fileContentBytes)
$JSONObject = @"
{
"data" : "$filecontentencoded",
"dataType" : "pfx",
"password" : "$CertPassword"
}
"@
$JSONObjectBytes = [System.Text.Encoding]::UTF8.GetBytes($jsonObject)
$JSONEncoded = [System.Convert]::ToBase64String($jsonObjectBytes)
#Set the secret and set the key vault policy for -EnabledForDeployment
$Secret = ConvertTo-SecureString -String $JSONEncoded -AsPlainText -Force

Set-AzKeyVaultSecret -VaultName $KeyVaultName -Name $KeyVaultSecretName -SecretValue $Secret
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDeployment
# Deploy the certificate to the VM

$VMName = 'MySecureVM'
$VMRGName = 'MyVirtualMachineResourceGroup'
$CertUrl = (Get-AzKeyVaultSecret -VaultName $KeyVaultName -Name $KeyVaultSecretName).Id
$SourceVaultId = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGName).ResourceId
$VM = Get-AzVM -ResourceGroupName $VMRGName -Name $VMName
$VM = Add-AzVMSecret -VM $VM -SourceVaultId $SourceVaultId -CertificateStore "My" -CertificateUrl $CertUrl
Update-AzVM -VM $VM -ResourceGroupName $VMRGName
#Enable encryption on the VM using Azure AD client ID and the client certificate thumbprint
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $VMName -AadClientID $AADClientID -

AadClientCertThumbprint $AADClientCertThumbprint -DiskEncryptionKeyVaultUrl $DiskEncryptionKeyVaultUrl -
DiskEncryptionKeyVaultId $KeyVaultResourceId
Autenticação baseada em certificado e uma KEK (opcional)

Se você quiser usar a autenticação de certificado e encapsular a chave de criptografia com uma KEK, use o script
abaixo como exemplo. Antes de usar o script do PowerShell, você deve estar familiarizado com todos os pré-
requisitos anteriores da Criptografia de Disco do Azure para entender as etapas do script. O script de amostra
pode precisar de mudanças para seu ambiente.
IMPORTANT
No momento, não há suporte para a autenticação baseada em certificado do Azure AD em VMs do Linux.
# Fill in 'MyKeyVaultResourceGroup', 'MySecureVault', and 'MyLocation' (if needed)

# Comment out the next three lines if you already have an existing key vault enabled for encryption.
$Loc = 'MyLocation'
$CertPassword)

## Give access for setting secrets and wraping keys


$JSONObject = @"
{
"dataType" : "pfx",
}
"@
#Set the secret and set the key vault policy for deployment

#Setting some variables with the key vault information and generating a KEK
# FIll in 'KEKName'
$KEKName ='KEKName'
$KEK = Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $KEKName -Destination "Software"
$KeyEncryptionKeyUrl = $KEK.Key.kid


KeyEncryptionKeyVaultId $KeyVaultResourceId
Próximas etapas
Habilitar Azure Disk Encryption com o Azure AD em VMs do Linux (versão anterior)
Criando e configurando um cofre de chaves para
anterior)
consulte Azure Disk Encr yption . As VMs que já foram criptografadas com parâmetros de aplicativo
do Azure AD ainda têm supor te e devem continuar a ser mantidas com a sintaxe do AAD.
Criar e configurar um cofre de chaves para uso com o Azure Disk Encryption com o Azure AD (versão anterior)
envolve três etapas:
1. Crie um cofre da chave.
2. Configure um aplicativo do Azure AD e entidade de serviço.
3. Defina a política de acesso do Cofre de chaves para o aplicativo do Azure AD.
4. Defina as políticas de acesso avançado da chave de segurança.
Consulte o artigo principal criando e configurando um cofre de chaves para Azure Disk Encryption para obter as
etapas de como instalar as ferramentas e conectar-se ao Azure.
NOTE

O Azure Disk Encryption se integra Azure Key Vault para ajudá-lo a controlar e gerenciar as chaves de
criptografia de disco e segredos em sua assinatura do Cofre de chaves. Você pode criar um cofre de chaves ou
usar um existente para o Azure Disk Encryption. Para obter mais informações sobre cofres-chave, consulte
Introdução ao Cofre de Chaves do Azure e Proteja seu cofre de chaves. Você pode usar um modelo do Resource
Manager, o Azure PowerShell ou a CLI do Azure para criar um cofre de chaves.
WARNING
Para garantir que os segredos de criptografia não ultrapassem os limites regionais, o Azure Disk Encryption precisa que o
Key Vault e as VMs sejam colocados na mesma região. Crie e use um cofre de chaves que esteja na mesma região da VM
a ser criptografada.
Criar um cofre de chaves com o PowerShell
Você pode criar um cofre de chaves com Azure PowerShell usando o cmdlet New-AzKeyVault . Para obter
cmdlets adicionais para Key Vault, consulte AZ. keyvault.
1. Crie um novo grupo de recursos, se necessário, com New-AzResourceGroup. Para listar locais de data
center, use Get-AzLocation.
# Get-AzLocation
New-AzResourceGroup –Name 'MyKeyVaultResourceGroup' –Location 'East US'
2. Criar um novo cofre de chaves usando New-AzKeyVault
New-AzKeyVault -VaultName 'MySecureVault' -ResourceGroupName 'MyKeyVaultResourceGroup' -Location

'East US'
3. Observe a nome do cofre , nome do grupo de recursos , ID do recurso , URI do cofre e o ID de

objeto que são retornados para uso posterior ao criptografar os discos.
Criar um cofre de chaves com CLI do Azure
Você pode gerenciar o Cofre de chaves com CLI do Azure usando os comandos keyvault az. Para criar um cofre
de chaves, use az creata.
1. Criar um novo grupo de recursos, se necessário, com criar grupo de az. Para listar os locais, use locais de
lista az conta
# To list locations: az account list-locations --output table

az group create -n "MyKeyVaultResourceGroup" -l "East US"
2. Crie um novo cofre de chave usando az keyvault create.
az keyvault create --name "MySecureVault" --resource-group "MyKeyVaultResourceGroup" --location "East

US"
3. Observação o nome do cofre (nome), nome do grupo de recursos , ID do recurso (ID), URI do
cofre e o deIDdeobjeto que são retornados para uso posterior.
Criar um cofre de chaves com um modelo do Resource Manager
Você pode criar um cofre de chaves usando o modelo Resource Manager.
2. Selecione a assinatura, o grupo de recursos, o local do grupo de recursos, o nome do Key Vault, a ID do
objeto, os termos legais e o contrato e clique em comprar .
Configurar um aplicativo do Azure AD e o serviço de entidade

Quando você precisa habilitar a criptografia em uma VM em execução no Azure, o Azure Disk Encryption gera e
grava as chaves de criptografia no cofre de chaves. O gerenciamento de chaves de criptografia no cofre de
chaves requer a autenticação do Azure AD. Crie um aplicativo do Azure AD para essa finalidade. Para fins de
autenticação, você pode usar a autenticação baseada em segredo do cliente ou a autenticação do Azure AD
baseada em certificado de cliente.
Configure um aplicativo e uma entidade de serviço do Azure AD com o Azure PowerShell
Para executar os seguintes comandos, obtenha e use o módulo do PowerShell do Azure AD.
1. Use o cmdlet do PowerShell New-AzADApplication para criar um aplicativo do Azure AD.
MyApplicationHomePage e MyApplicationUri podem ser quaisquer valores que você desejar.
$aadClientSecret = "My AAD client secret"

$aadClientSecretSec = ConvertTo-SecureString -String $aadClientSecret -AsPlainText -Force
$azureAdApplication = New-AzADApplication -DisplayName "My Application Display Name" -HomePage
"https://MyApplicationHomePage" -IdentifierUris "https://MyApplicationUri" -Password
$aadClientSecretSec
$servicePrincipal = New-AzADServicePrincipal –ApplicationId $azureAdApplication.ApplicationId
2. O $ azureAdApplication.ApplicationId é o ClientID do Azure AD e o $ aadClientSecret é o segredo do

cliente que você usará posteriormente para ativar a Criptografia de Disco do Azure. Proteja
adequadamente o segredo do cliente no Azure AD. A execução $azureAdApplication.ApplicationId
mostrará o ApplicationID.
Configure um aplicativo e uma entidade de serviço do Azure AD com a CLI do Azure
Você pode gerenciar seus principais de serviço com a CLI do Azure usando os comandos az ad sp. Para obter
mais informações, consulte criar uma entidade de serviço do Azure.
1. Crie uma nova entidade de serviço.
az ad sp create-for-rbac --name "ServicePrincipalName" --password "My-AAD-client-secret" --skip-

assignment
2. O appId retornado é o ClientID do Azure AD usado em outros comandos. Ele é também o SPN que você
usará para az keyvault set-policy. A senha é o segredo do cliente que você deve usar posteriormente para
ativar a criptografia de disco do Azure. Proteja adequadamente o segredo do cliente no Azure AD.
Configure um aplicativo e uma entidade de serviço do Azure AD através do portal do Azure
Use as etapas do artigo usar o portal para criar aplicativo e entidade de serviço que pode acessar recursos de
um Azure Active Directory para criar um aplicativo do Azure AD. Cada etapa listada abaixo levará você
diretamente para a seção de artigos para concluir.
1. Verifique se as permissões necessárias
2. Criar um aplicativo do Azure Active Directory
Você pode usar qualquer nome e URL de logon que desejar ao criar o aplicativo.
3. Obtenha o ID do aplicativo e a chave de autenticação.
A chave de autenticação é o segredo do cliente e é usada como AadClientSecret para Set-
AzVMDiskEncryptionExtension.
A chave de autenticação é usada pelo aplicativo como uma credencial para entrar no Azure AD.
No portal do Azure, esse segredo é chamado de chaves, mas não tem relação com os cofres da
chave. Proteja esse segredo adequadamente.
A ID do aplicativo será usada posteriormente como AadClientId para Set-
AzVMDiskEncryptionExtension e como o servicePrincipalName para Set-AzKeyVaultAccessPolicy.
Definir a política de acesso ao cofre de chaves para o aplicativo Azure

AD
Para gravar segredos de criptografia em um Cofre de Chaves especificado, o Azure Disk Encryption precisa do
ID do Cliente e do Segredo do Cliente do aplicativo Azure Active Directory que tenha permissões para gravar
segredos no Cofre de Chaves.
NOTE
o Azure Disk Encryption exige que você configure as seguintes políticas de acesso ao aplicativo de cliente do Azure AD:
permissões WrapKey e Set.
Defina a política de acesso ao cofre principal para o aplicativo Azure AD com o Azure PowerShell
Seu aplicativo Azure AD precisa de direitos para acessar as chaves ou os segredos no cofre. Use o cmdlet set-
AzKeyVaultAccessPolicy para conceder permissões ao aplicativo, usando a ID do cliente (que foi gerada quando
o aplicativo foi registrado) como o valor do parâmetro – servicePrincipalName . Para saber mais, confira a
postagem de blog Azure Key Vault - passo a passo.
1. Defina a política de acesso ao vault principal para o aplicativo AD com o PowerShell.
$keyVaultName = 'MySecureVault'
$aadClientID = 'MyAadAppClientID'
PermissionsToKeys 'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname
Defina a política de acesso ao cofre de chaves do aplicativo Azure AD com a CLI do Azure
Use az keyvault set-policy para definir a política de acesso. Para obter mais informações, consulte Gerenciar
cofre de chaves usando o CLI 2.0.
Dê à entidade de serviço que você criou por meio do acesso da CLI do Azure para obter segredos e agrupar
chaves com o seguinte comando:
az keyvault set-policy --name "MySecureVault" --spn "<spn created with CLI/the Azure AD ClientID>" --key-
permissions wrapKey --secret-permissions set
Defina a política de acesso ao cofre de chaves do aplicativo Azure AD com o portal

1. Abra o grupo de recursos com o Cofre de chaves.
2. Selecione seu cofre de chaves, vá para Acessar Políticas e clique em Adicionar novo .
3. Em Selecionar principal , procure o aplicativo do Azure AD criado e selecione-o.
4. Para permissões de chave , verifique Wrap Key sob operações criptográficas .
5. Para permissões do segredo , verifique definir sob operações de gerenciamento de segredo .
6. Clique em Ok para salvar a política de acesso.
disponibilizá-los para a máquina virtual para inicialização e descriptografar os volumes. Habilite a criptografia
de disco no cofre da chave ou as implantações falharão.
Definir políticas de acesso avançado ao cofre de chaves com o Azure PowerShell


EnabledForDeployment

EnabledForTemplateDeployment
Definir Cofre de chaves avançadas de políticas de acesso usando a CLI do Azure

necessária.

disk-encryption "true"
Habilite o cofre de chaves para a implantação, se necessário: máquinas de virtuais permitem

recuperar certificados armazenados como segredos do cofre.

deployment "true"


template-deployment "true"
Defina as políticas de acesso avançado ao cofre de chaves por meio do portal do Azure
1. Selecione sua keyvault, vá para Access Policies e Clique para mostrar as políticas de acesso
avançadas .
2. Selecione a caixa rotulada habilitar o acesso ao Azure Disk Encr yption para criptografia de volume .
Configurar uma chave de criptografia de chave (opcional)

criptografia, adicione uma KEK ao seu cofre de chaves. Use o cmdlet Add-AzKeyVaultKey para criar uma chave
de criptografia de chave no cofre de chaves. Você também pode importar a KEK do HSM do gerenciamento de
chaves local. Para obter mais informações, consulte documentação do cofre de chaves. Quando uma chave de
Ao gerar chaves, use um tipo de chave RSA. Azure Disk Encryption ainda não dá suporte ao uso de
chaves de curva elíptica.
O segredo do cofre de chaves e as URLs KEK devem ter controle de versão. O Azure impõe essa restrição
Exemplo de uma URL KEK válida:
o Azure Disk Encryption não dá suporte à especificação de números de portas como parte de segredos
do cofre de chaves e URLs KEK. Para exemplos de URLs do cofre de chaves não suportados e suportados,
consulte os seguintes exemplos:
URL do cofre de chaves inaceitável
URL do cofre de chaves aceitável:
Configurar uma chave de criptografia chave com o Azure PowerShell
Antes de usar o script do PowerShell, você deve estar familiarizado com os pré-requisitos do Azure Disk
Encryption para entender as etapas no script. O script de amostra pode precisar de mudanças para seu
ambiente. Esse script cria todos os pré-requisitos da criptografia de disco do Azure e criptografa uma VM IaaS
existente, envolvendo a chave de criptografia de disco usando uma chave de criptografia de chave.
# Step 1: Create a new resource group and key vault in the same location.
# Fill in 'MyLocation', 'MyKeyVaultResourceGroup', and 'MySecureVault' with your values.
# Use Get-AzLocation to get available locations and use the DisplayName.
# To use an existing resource group, comment out the line for New-AzResourceGroup
$Loc = 'MyLocation';
New-AzResourceGroup –Name $KVRGname –Location $Loc;
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc;
$KeyVaultResourceId = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).ResourceId;
$diskEncryptionKeyVaultUrl = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).VaultUri;
# Step 2: Create the AD application and service principal.

# Fill in 'MyAADClientSecret', "<My Application Display Name>", "<https://MyApplicationHomePage>", and "
<https://MyApplicationUri>" with your values.
# MyApplicationHomePage and the MyApplicationUri can be any values you wish.
$aadClientSecret = 'MyAADClientSecret';
$aadClientSecretSec = ConvertTo-SecureString -String $aadClientSecret -AsPlainText -Force;
$azureAdApplication = New-AzADApplication -DisplayName "<My Application Display Name>" -HomePage "
<https://MyApplicationHomePage>" -IdentifierUris "<https://MyApplicationUri>" -Password $aadClientSecretSec
$servicePrincipal = New-AzADServicePrincipal –ApplicationId $azureAdApplication.ApplicationId;
$aadClientID = $azureAdApplication.ApplicationId;
#Step 3: Enable the vault for disk encryption and set the access policy for the Azure AD application.
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -

EnabledForDiskEncryption;
PermissionsToKeys 'WrapKey' -PermissionsToSecrets 'Set' -ResourceGroupName $KVRGname;
#Step 4: Create a new key in the key vault with the Add-AzKeyVaultKey cmdlet.
# Fill in 'MyKeyEncryptionKey' with your value.
Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName -Destination 'Software';
#Step 5: Encrypt the disks of an existing IaaS VM

Autenticação baseada em certificado (opcional)

Se você quiser usar a autenticação de certificado, poderá fazer o upload de um para o seu cofre de chaves e
implantá-lo no cliente. Antes de usar o script do PowerShell, você deve estar familiarizado com os pré-requisitos
do Azure Disk Encryption para entender as etapas no script. O script de amostra pode precisar de mudanças
para seu ambiente.
# Fill in "MyKeyVaultResourceGroup", "MySecureVault", and 'MyLocation' ('My location' only if needed)

# Comment out the next three lines if you already have an existing key vault enabled for encryption. No
need to set 'My location' in this case.
$Loc = 'MyLocation'
#Setting some variables with the key vault information

$CertPassword)



$JSONObject = @"
{
"dataType" : "pfx",
}
"@
#Set the secret and set the key vault policy for -EnabledForDeployment


$VMName = 'MySecureVM'

Autenticação baseada em certificado e uma KEK (opcional)

Se você quiser usar a autenticação de certificado e encapsular a chave de criptografia com uma KEK, use o script
abaixo como exemplo. Antes de usar o script do PowerShell, você deve estar familiarizado com todos os pré-
requisitos anteriores da Criptografia de Disco do Azure para entender as etapas do script. O script de amostra
pode precisar de mudanças para seu ambiente.
# Fill in 'MyKeyVaultResourceGroup', 'MySecureVault', and 'MyLocation' (if needed)

# Comment out the next three lines if you already have an existing key vault enabled for encryption.
$Loc = 'MyLocation'
$CertPassword)

## Give access for setting secrets and wraping keys


$JSONObject = @"
{
"dataType" : "pfx",
}
"@
#Set the secret and set the key vault policy for deployment

#Setting some variables with the key vault information and generating a KEK
# FIll in 'KEKName'
$KEKName ='KEKName'
$KEK = Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $KEKName -Destination "Software"
$KeyEncryptionKeyUrl = $KEK.Key.kid


Próximas etapas
Habilitar Azure Disk Encryption com o Azure AD em VMs do Windows (versão anterior)
Habilitar Azure Disk Encryption com o Azure AD
em VMs do Linux (versão anterior)
A nova versão do Azure Disk Encryption elimina a necessidade de fornecer um parâmetro de aplicativo Azure
Active Directory (AD do Azure) para habilitar a criptografia de disco de VM. Com a nova versão, não é mais
necessário fornecer credenciais do Azure AD durante a etapa para habilitar criptografia. Todas as novas VMs
devem ser criptografadas sem os parâmetros do aplicativo do Azure AD usando a nova versão. Para obter
instruções sobre como habilitar a criptografia de disco de VM usando a nova versão, consulte Azure Disk
Encryption para VMs do Linux. As VMs que já foram criptografadas com os parâmetros de aplicativo do Azure
AD ainda têm suporte e devem continuar a ser mantidas com a sintaxe do AAD.
Você pode habilitar muitos cenários de criptografia de disco e as etapas podem variar de acordo com o cenário.
As seções a seguir abordam os cenários em mais detalhes para VMs de IaaS (infraestrutura como serviço) do
Linux. Você só pode aplicar a criptografia de disco a máquinas virtuais de tamanhos de VM e sistemas
operacionais com suporte. Você também deve atender aos seguintes pré-requisitos:
Rede e Política de Grupo
Faça um instantâneo, faça um backup ou ambos antes de criptografar os discos. Os backups garantem que uma
opção de recuperação seja possível, no caso de uma falha inesperada durante a criptografia. VMs com discos
gerenciados exigem um backup antes que a criptografia ocorra. Depois que um backup é feito, você pode usar o
cmdlet Set-AzVMDiskEncryptionExtension para criptografar discos gerenciados especificando o parâmetro-
skipVmBackup. Para obter mais informações sobre como fazer backup e restaurar VMs criptografadas, consulte
backup do Azure.
WARNING
Se você usou anteriormente Azure Disk Encryption com o aplicativo Azure ad para criptografar essa VM, você deve
continuar a usar essa opção para criptografar sua VM. Você não pode usar Azure Disk Encryption nesta VM
criptografada porque esse não é um cenário com suporte, o que significa mudar para fora do aplicativo Azure ad para
essa VM criptografada ainda não tem suporte.
Para garantir que os segredos de criptografia não entrem em limites regionais, Azure Disk Encryption precisa que o
cofre de chaves e as VMs sejam colocalizados na mesma região. Crie e use um cofre de chaves que esteja na mesma
região que a VM a ser criptografada.
Quando você criptografa volumes do sistema operacional Linux, o processo pode levar algumas horas. É normal que
OS volumes do SO Linux demorem mais do que os volumes de dados para criptografar.
Quando você criptografa volumes do sistema operacional Linux, a VM deve ser considerada indisponível. É altamente
recomendável que você evite logons SSH enquanto a criptografia estiver em andamento para evitar o bloqueio de
arquivos abertos que precisam ser acessados durante o processo de criptografia. Para verificar o progresso, use os
comandos Get-AzVMDiskEncryptionStatus ou criptografia de VM show . Você pode esperar que esse processo demore
algumas horas para um volume de so de 30 GB, além de mais tempo para criptografar volumes de dados. O tempo de
criptografia do volume de dados é proporcional ao tamanho e à quantidade dos volumes de dados, a menos que a
opção de formato criptografado tudo seja usada.
Desabilitar criptografia nas VMs do Linux tem suporte apenas para volumes de dados. Não haverá suporte para os
volumes de dados ou do sistema operacional se o volume do sistema operacional tiver sido criptografado.
Habilitar criptografia em uma VM da IaaS do Linux existente ou em
execução
Nesse cenário, você pode habilitar a criptografia usando o modelo de Azure Resource Manager, cmdlets do
PowerShell ou comandos CLI do Azure.
IMPORTANT
É obrigatório tirar um instantâneo ou fazer backup de uma instância de VM baseada em disco gerenciado fora do e antes
de habilitar o Azure Disk Encryption. Você pode tirar um instantâneo do disco gerenciado do portal do Azure ou pode
usar o backup do Azure. Backups asseguram que uma opção de recuperação é possível no caso de qualquer falha
inesperada durante a criptografia. Depois de fazer um backup, use o cmdlet Set-AzVMDiskEncryptionExtension para
criptografar discos gerenciados especificando o parâmetro-skipVmBackup. O comando Set-AzVMDiskEncryptionExtension
falha em VMs baseadas em disco gerenciadas até que um backup seja feito e esse parâmetro seja especificado.
Criptografar ou desabilitar a criptografia pode fazer com que a VM seja reinicializada.
Habilitar a criptografia em uma VM Linux existente ou em execução usando o CLI do Azure

Você pode habilitar a criptografia de disco em seu VHD criptografado Instalando e usando a ferramenta de linha
de comando CLI do Azure 2,0 . Você pode usá-lo em seu navegador com o Azure Cloud Shell, ou você pode
instalá-lo em seu computador local e usá-lo em qualquer sessão do PowerShell. Para habilitar a criptografia em
VMs da IaaS do Linux existentes ou em execução no Azure, use os comandos a seguir da CLI:
Criptografar uma VM em execução usando um segredo do cliente:
az vm encryption enable --resource-group "MyVirtualMachineResourceGroup" --name "MySecureVM" --

aad-client-id "<my spn created with CLI/my Azure AD ClientID>" --aad-client-secret "My-AAD-client-
secret" --disk-encryption-keyvault "MySecureVault" --volume-type [All|OS|Data]
Criptografe uma VM em execução usando KEK para encapsular o segredo do cliente:

aad-client-id "<my spn created with CLI which is the Azure AD ClientID>" --aad-client-secret "My-
AAD-client-secret" --disk-encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --
key-encryption-keyvault "MySecureVaultContainingTheKEK" --volume-type [All|OS|Data]
NOTE
A sintaxe para o valor do parâmetro Disk-Encryption-keyvault é a cadeia de caracteres do identificador
completo:/subscriptions/[Subscription-ID-GUID]/resourceGroups/[nome-do-grupo-de-
recursos]/providers/Microsoft.KeyVault/vaults/[keyvault-Name].
A sintaxe para o valor do parâmetro Key-Encryption-Key é o URI completo para o KEK como em:
https://[keyvault-Name]. Vault. Azure. net/Keys/[kekname]/[Kek-Unique-ID].


volume-type DATA
Habilitar a criptografia em uma VM Linux existente ou em execução usando o PowerShell

execução no Azure. Faça um instantâneo ou faça um backup da VM com o backup do Azure antes que os discos
sejam criptografados. O parâmetro -skipVmBackup já está especificado nos scripts do PowerShell para
criptografar uma VM Linux em execução.
Criptografar uma VM em execução usando um segredo do cliente: O script a seguir inicializa as
variáveis e executa o cmdlet Set-AzVMDiskEncryptionExtension. O grupo de recursos, a VM, o cofre de
chaves, o aplicativo do Azure AD e o segredo do cliente já devem ter sido criados como pré-requisitos.
Substitua MyVirtualMachineResourceGroup, MyKeyVaultResourceGroup, MySecureVM, MySecureVault,
meu-AAD-Client-ID e meu-AAD-Client-Secret pelos valores. Modifique o parâmetro -VolumeType para
especificar quais discos você está criptografando.
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $vmName -AadClientID

$aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl
-DiskEncryptionKeyVaultId $KeyVaultResourceId -VolumeType '[All|OS|Data]' -SequenceVersion
$sequenceVersion -skipVmBackup;
Criptografe uma VM em execução usando Kek para encapsular o segredo do cliente: Azure
Disk Encryption permite especificar uma chave existente no cofre de chaves para encapsular os segredos
de criptografia de disco que foram gerados ao habilitar a criptografia. Quando uma chave de criptografia
de chave é especificada, o Azure Disk Encryption usa essa chave para encapsular os segredos de
criptografia antes de gravar no cofre de chaves. Modifique o parâmetro -VolumeType para especificar
quais discos você está criptografando.

-DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl $keyEncryptionKeyUrl -
KeyEncryptionKeyVaultId $KeyVaultResourceId -VolumeType '[All|OS|Data]' -SequenceVersion
$sequenceVersion -skipVmBackup;
NOTE
completo:/subscriptions/[Subscription-ID-GUID]/resourceGroups/[KVresource-Group-
Name]/providers/Microsoft.KeyVault/vaults/[keyvault-Name].
A sintaxe para o valor do parâmetro Key-Encryption-Key é o URI completo para o KEK como em:
https://[keyvault-Name]. Vault. Azure. net/Keys/[kekname]/[Kek-Unique-ID].
Get-AzVmDiskEncryptionStatus -ResourceGroupName MyVirtualMachineResourceGroup -VMName MySecureVM

AzureRmVMDiskEncryption. Desabilitar criptografia somente é permitida em volumes de Dados para
VMs do Linux.
Disable-AzVMDiskEncryption -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName

'MySecureVM'
Habilitar criptografia em uma VM da IaaS do Linux existente ou em execução com um modelo

Você pode habilitar a criptografia de disco em uma VM Linux IaaS existente ou em execução no Azure usando o
modelo do Gerenciador de Recursos.
1. Selecione implantar no Azure no modelo de início rápido do Azure.
legais e o contrato. Selecione criar para habilitar a criptografia na VM IaaS existente ou em execução.
A tabela a seguir lista os parâmetros de modelo do Gerenciador de Recursos existente ou VMs em execução que
usam uma ID de cliente do Azure AD:
AADClientID ID do cliente do aplicativo Azure AD que tem permissões

para gravar segredos no cofre de chaves.
AADClientSecret Segredo do cliente do aplicativo AD do Azure que tem

permissões para gravar segredos para o cofre de chaves.
keyVaultName Nome do cofre de chaves em que a chave deve ser

carregada. É possível obtê-lo, usando o comando da CLI do
Azure
az keyvault show --name "MySecureVault" --query
KVresourceGroup
.
keyEncryptionKeyURL URL da chave de criptografia de chave usada para

criptografar a chave gerada. Esse parâmetro é opcional se
você selecionar nokek na lista suspensa UseExistingKek .
Se você selecionar Kek na lista suspensa UseExistingKek ,
deverá inserir o valor de keyEncryptionKeyURL .

executada. Os valores válidos com suporte são os ou todos .
(Consulte distribuições do Linux com suporte e suas versões
para OS discos do sistema operacional e de dados na seção
de pré-requisitos anterior.)
sequenceVersion Versão de sequência da operação de BitLocker. Aumente

esse número de versão sempre que uma operação de
criptografia de disco for executada na mesma VM.
vmName Nome da VM em que a operação de criptografia deve ser

executada.
senha Digite uma frase secreta forte como chave de criptografia de

dados.
Usar o recurso EncryptFormatAll para discos de dados em VMs IaaS

do Linux
O parâmetro EncryptFormatAll reduz o tempo de criptografia dos discos de dados do Linux. As partições que
atendem a determinados critérios são formatadas (com o sistema de arquivos atual). Em seguida, eles são
remontados de volta para onde estavam antes da execução do comando. Se desejar excluir um disco de dados
que atenda aos critérios, você poderá desmontá-lo antes de executar o comando.
Depois de executar esse comando, todas as unidades que foram montadas anteriormente são formatadas. Em
seguida, a camada de criptografia começa na parte superior da unidade agora vazia. Quando essa opção é
selecionada, o disco temporário anexado à VM também é criptografado. Se a unidade efêmera for redefinida, ela
será reformatada e criptografada novamente para a VM pela solução de Azure Disk Encryption na próxima
oportunidade.
WARNING
EncryptFormatAll não deve ser usado quando houver dados necessários nos volumes de dados de uma VM. Você pode
excluir discos da criptografia desmontando-os. Experimente o parâmetro EncryptFormatAll em uma VM de teste primeiro
para entender o parâmetro de recurso e sua implicação antes de experimentá-lo na VM de produção. A opção
EncryptFormatAll formata o disco de dados, de modo que todos os dados nele serão perdidos. Antes de prosseguir,
verifique se os discos que você deseja excluir estão desmontados corretamente.
Se você definir esse parâmetro enquanto atualiza as configurações de criptografia, isso poderá levar a uma reinicialização
antes da criptografia real. Nesse caso, você também deseja remover o disco que não deseja Formatar do arquivo fstab. Da
mesma forma, você deve adicionar a partição que deseja criptografar no arquivo fstab antes de iniciar a operação de
criptografia.
Critérios de EncryptFormatAll
O parâmetro passa por todas as partições e as criptografa, desde que atendam a todos os critérios a seguir:
Não é uma partição de inicialização/SO/raiz
Ainda não está criptografado
Não é um volume BEK
Não é um volume RAID
Não é um volume LVM
Está montado
Criptografe os discos que compõem o volume RAID ou LVM em vez do volume RAID ou LVM.
Usar o parâmetro EncryptFormatAll com um modelo
Para usar a opção EncryptFormatAll, use qualquer modelo de Azure Resource Manager preexistente que
criptografa uma VM do Linux e altere o campo Encr yptionOperation para o recurso AzureDiskEncryption.
1. Como exemplo, use o modelo do Resource Manager para criptografar uma VM da IaaS do Linux em
execução.
2. Selecione implantar no Azure no modelo de início rápido do Azure.
3. Altere o campo Encr yptionOperation de enableencr yption e para EnableEncr yptionFormatAl .
4. Selecione a assinatura, o grupo de recursos, o local do grupo de recursos, outros parâmetros, termos legais e
contrato. Selecione criar para habilitar a criptografia na VM IaaS existente ou em execução.
Usar o parâmetro EncryptFormatAll com um cmdlet do PowerShell
Use o cmdlet Set-AzVMDiskEncryptionExtension com o parâmetro EncryptFormatAll.
Criptografar uma VM em execução usando um segredo do cliente e Encr yptFormatAll: Por exemplo,
o script a seguir inicializa suas variáveis e executa o cmdlet Set-AzVMDiskEncryptionExtension com o parâmetro
EncryptFormatAll. O grupo de recursos, a VM, o cofre de chaves, o aplicativo do Azure AD e o segredo do cliente
já devem ter sido criados como pré-requisitos. Substitua MyKeyVaultResourceGroup,
MyVirtualMachineResourceGroup, MySecureVM, MySecureVault, meu-AAD-Client-ID e meu-AAD-Client-Secret
pelos valores.

DiskEncryptionKeyVaultId $KeyVaultResourceId -EncryptFormatAll
Usar o parâmetro EncryptFormatAll com o LVM (Gerenciador de volumes lógicos)

É recomendável uma configuração LVM-on-crypt. Para todos os exemplos a seguir, substitua o caminho-do-
dispositivo e o montagem pelo que for adequado ao seu caso de uso. Essa configuração pode ser feita da
seguinte maneira:
Adicione os discos de dados que irão compor a VM.
Formatar, montar e adicionar esses discos ao arquivo fstab.
1. Formate o disco adicionado recentemente. Usamos symlinks gerados pelo Azure aqui. O uso de
symlinks evita problemas relacionados à alteração de nomes de dispositivos. Para obter mais
informações, consulte solucionar problemas de nomes de dispositivo.
mkfs -t ext4 /dev/disk/azure/scsi1/lun0
2. Monte os discos.
mount /dev/disk/azure/scsi1/lun0 /mnt/mountpoint
3. Adicione ao fstab.
echo "/dev/disk/azure/scsi1/lun0 /mnt/mountpoint ext4 defaults,nofail 1 2" >> /etc/fstab
4. Execute o cmdlet Set-AzVMDiskEncryptionExtension PowerShell com-EncryptFormatAll para

criptografar esses discos.

DiskEncryptionKeyVaultUrl "https://mykeyvault.vault.azure.net/" -EncryptFormatAll
5. Configure a LVM sobre esses novos discos. Observe que as unidades criptografadas serão
desbloqueadas após a VM concluir a inicialização. Portanto, a montagem de LVM também deverá
ser subsequentemente atrasada.
Novas VMs da IaaS criadas a partir de chaves de criptografia e VHD

criptografado pelo cliente
Nesse cenário, você pode habilitar a criptografia usando o modelo do Resource Manager, cmdlets do PowerShell
ou comandos da CLI. As seções a seguir explicam detalhadamente o modelo do Gerenciador de Recursos e
comandos da CLI.
Use as instruções no apêndice para preparar imagens previamente criptografadas que podem ser usadas no
Azure. Depois que a imagem for criada, você poderá usar as etapas na próxima seção para criar uma VM do
Azure criptografada.
IMPORTANT
É obrigatório tirar um instantâneo ou fazer backup de uma instância de VM baseada em disco gerenciado fora do e antes
de habilitar o Azure Disk Encryption. Você pode tirar um instantâneo do disco gerenciado do portal ou pode usar o
backup do Azure. Backups asseguram que uma opção de recuperação é possível no caso de qualquer falha inesperada
durante a criptografia. Depois de fazer um backup, use o cmdlet Set-AzVMDiskEncryptionExtension para criptografar
discos gerenciados especificando o parâmetro-skipVmBackup. O comando Set-AzVMDiskEncryptionExtension falha em
VMs baseadas em disco gerenciadas até que um backup seja feito e esse parâmetro seja especificado.
Criptografar ou desabilitar a criptografia pode fazer com que a VM seja reinicializada.
Usar o Azure PowerShell para criptografar VMs da IaaS com VHDs previamente criptografados
AzVMOSDisk. O exemplo a seguir fornece alguns parâmetros comuns.

000000000000/resourceGroups/myresourcegroup/providers/Microsoft.KeyVault/vaults/mytestvault"

Você pode adicionar um novo disco de dados usando AZ VM Disk Attach ou por meio do portal do Azure. Antes
de poder criptografar, primeiro será necessário montar o disco de dados anexado recentemente. Você deve
solicitar a criptografia da unidade de dados porque a unidade será inutilizável enquanto a criptografia estiver
em andamento.
Habilitar a criptografia em um disco recém-adicionado com o CLI do Azure
Se a VM tiver sido criptografada anteriormente com "All", o parâmetro--volume-Type deverá permanecer todos.
Todos inclui o sistema operacional e os discos de dados. Se a VM tiver sido criptografada anteriormente com um
tipo de volume de "OS", o parâmetro--volume-Type deverá ser alterado para All, de modo que o so e o novo
disco de dados serão incluídos. Se a VM tiver sido criptografada apenas com o tipo de volume de "dados", ela
poderá permanecer com os dados, conforme demonstrado aqui. Adicionar e anexar um novo disco de dados a
uma VM não é uma preparação suficiente para a criptografia. O disco recentemente anexado também deve ser
formatado e montado corretamente na VM antes de habilitar a criptografia. No Linux, o disco deve ser montado
em/etc/fstab com um nome de dispositivo de bloqueio persistente.
Ao contrário da sintaxe do PowerShell, a CLI não exige que você forneça uma versão de sequência exclusiva ao
habilitar a criptografia. A CLI gera e usa automaticamente o próprio valor de versão de sequência exclusivo.

aad-client-id "<my spn created with CLI/my Azure AD ClientID>" --aad-client-secret "My-AAD-client-
secret" --disk-encryption-keyvault "MySecureVault" --volume-type "Data"
Criptografe uma VM em execução usando KEK para encapsular o segredo do cliente:

aad-client-id "<my spn created with CLI which is the Azure AD ClientID>" --aad-client-secret "My-
AAD-client-secret" --disk-encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --
key-encryption-keyvault "MySecureVaultContainingTheKEK" --volume-type "Data"

Quando você usa o PowerShell para criptografar um novo disco para Linux, uma nova versão de sequência
precisa ser especificada. A versão da sequência deverá ser exclusiva. O script a seguir gera um GUID para a
versão de sequência.
Criptografar uma VM em execução usando um segredo do cliente: O script a seguir inicializa as
variáveis e executa o cmdlet Set-AzVMDiskEncryptionExtension. O grupo de recursos, a VM, o cofre de
chaves, o aplicativo do Azure AD e o segredo do cliente já devem ter sido criados como pré-requisitos.
Substitua MyVirtualMachineResourceGroup, MyKeyVaultResourceGroup, MySecureVM, MySecureVault,
meu-AAD-Client-ID e meu-AAD-Client-Secret pelos valores. O parâmetro -VolumeType é configurado
para discos de dados e não para o disco de SO. Se a VM tiver sido criptografada anteriormente com um
tipo de volume de "os" ou "All", o parâmetro-Volumetype deverá ser alterado para All, de modo que o
sistema operacional e o novo disco de dados serão incluídos.

-DiskEncryptionKeyVaultId $KeyVaultResourceId -VolumeType 'data' –SequenceVersion $sequenceVersion;
Criptografe uma VM em execução usando Kek para encapsular o segredo do cliente: Azure
Disk Encryption permite especificar uma chave existente no cofre de chaves para encapsular os segredos
de criptografia de disco que foram gerados ao habilitar a criptografia. Quando uma chave de criptografia
de chave é especificada, o Azure Disk Encryption usa essa chave para encapsular os segredos de
criptografia antes de gravar no cofre de chaves. O parâmetro -VolumeType é configurado para discos de
dados e não para o disco de SO. Se a VM tiver sido criptografada anteriormente com um tipo de volume
de "os" ou "All", o parâmetro-Volumetype deverá ser alterado para All, de modo que o sistema
operacional e o novo disco de dados serão incluídos.

KeyEncryptionKeyVaultId $KeyVaultResourceId -VolumeType 'data' –SequenceVersion $sequenceVersion;
NOTE
completo:/subscriptions/[Subscription-ID-GUID]/resourceGroups/[nome-do-grupo-de-
recursos]/providers/Microsoft.KeyVault/vaults/[keyvault-Name].
A sintaxe para o valor do parâmetro Key-Encryption-Key é o URI completo para o KEK como em: https://[keyvault-Name].
Vault. Azure. net/Keys/[kekname]/[Kek-Unique-ID].
Desabilitar criptografia para VMs do Linux

Você pode desabilitar a criptografia usando Azure PowerShell, o CLI do Azure ou um modelo do Resource
Manager.
IMPORTANT
Desabilitar criptografia com Azure Disk Encryption em VMs do Linux tem suporte apenas para volumes de dados. Não
haverá suporte para os volumes de dados ou do sistema operacional se o volume do sistema operacional tiver sido
criptografado.
Desabilitar a criptografia de disco com o Azure PowerShell: Para desabilitar a criptografia, use o
cmdlet Disable-AzureRmVMDiskEncryption .
Disable-AzVMDiskEncryption -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName

'MySecureVM' [--volume-type {ALL, DATA, OS}]
encryption disable.

Desabilitar a criptografia com um modelo do Resource Manager : Para desabilitar a criptografia,

use a desabilitação de criptografia em um modelo de VM Linux em execução .
1. Selecione implantar no Azure .
3. Selecione comprar para desabilitar a criptografia de disco em uma VM do Windows em execução.
Próximas etapas
Visão geral do Azure Disk Encryption para Linux
Azure Disk Encryption com o Azure AD para VMs
do Windows (versão anterior)
consulte Azure Disk Encr yption para VMs do Windows . As VMs que já foram criptografadas com
parâmetros de aplicativo do Azure AD ainda têm supor te e devem continuar a ser mantidas com a
sintaxe do AAD.
Você pode habilitar muitos cenários de criptografia de disco, e as etapas podem variar de acordo com o cenário.
As seções a seguir abordam os cenários com mais detalhes para VMs da IaaS do Windows. Antes de poder usar
a criptografia de disco, os pré-requisitos do Azure Disk Encryption devem ser cumpridos.
IMPORTANT
Você deve fazer um instantâneo e/ou criar um backup antes que os discos sejam criptografados. Os backups
garantem que uma opção de recuperação seja possível, no caso de uma falha inesperada durante a criptografia.
VMs com discos gerenciados exigem um backup antes que a criptografia ocorra. Depois que um backup é feito,
você poderá usar o cmdlet Set-AzVMDiskEncryptionExtension para criptografar discos gerenciados, especificando
o parâmetro -skipVmBackup. Para obter mais informações sobre como fazer backup e restaurar VMs
criptografadas, consulte fazer backup e restaurar a VM do Azure criptografada.
Criptografar ou desabilitar a criptografia pode fazer com que uma VM seja reinicializada.
Habilitar criptografia em novas VMs da IaaS criadas a partir do

Marketplace
É possível habilitar criptografia de disco na nova VM do Windows da IaaS a partir do Marketplace no Azure
usando um modelo do Resource Manager. O modelo cria uma nova VM criptografada do Windows usando a
imagem da galeria do Windows Server 2012.
1. No modelo do Resource Manager, cliquem em Implantar no Azure .
legais e o contrato. Clique em Comprar para implantar uma nova VM da IaaS onde a criptografia está
habilitada.
3. Depois de implantar o modelo, verifique o status de criptografia da VM usando o método preferido:
Verifique com a CLI do Azure, usando o comando az vm encryption show.
Verifique com Azure PowerShell usando o cmdlet Get-AzVmDiskEncryptionStatus .

Get-AzVmDiskEncryptionStatus -ResourceGroupName 'MyVirtualMachineResourceGroup' -VMName
'MySecureVM'
Selecione a VM e, em seguida, clique em Discos sob o cabeçalho Configurações para verificar o

status da criptografia no portal. No gráfico em Criptografia , você verá se ela está habilitada.
A tabela a seguir lista os parâmetros de modelo do Gerenciador de Recursos para novas VMs do cenário do
Marketplace usando a ID de cliente do Azure AD:
adminUserName Especifique um nome de usuário para a máquina virtual.
adminPassword Senha de usuário administrador para a máquina virtual.
newStorageAccountName Nome da conta de armazenamento para armazenar VHDs

do sistema operacional e de dados.
vmSize O tamanho da VM. Atualmente, há suporte somente para

séries Standard A, D e G.
virtualNetworkName Nome da VNet à qual a NIC da VM deve pertencer.
subnetName Nome da sub-rede na VNet à qual a NIC da VM deve

pertencer.
AADClientID A ID do cliente do aplicativo Azure AD que tem permissões

AADClientSecret Segredo do cliente do aplicativo AD do Azure que tem

permissões para gravar segredos para o cofre de chaves.
keyVaultURL URL do cofre de chaves no qual a chave do BitLocker deve

(Get-AzKeyVault -VaultName "MyKeyVault" -
ResourceGroupName
"MyKeyVaultResourceGroupName").VaultURI
ou a CLI do Azure
az keyvault show --name "MySecureVault" --query
properties.vaultUri
keyEncryptionKeyURL URL da chave de criptografia de chave que é usada para

criptografar a chave gerada do BitLocker (opcional).
KeyEncryptionKeyURL é um parâmetro opcional. Você pode

usar seu próprio KEK para proteger ainda mais a chave de
criptografia de dados (frase secreta) no cofre de chaves.
keyVaultResourceGroup Grupo de recursos do cofre de chaves.

executada.
Habilitar criptografia em VMs do Windows da IaaS existentes ou em

execução
Nesse cenário, é possível habilitar a criptografia usando um modelo, cmdlets do PowerShell ou comandos da
CLI. As seções a seguir explicam com mais detalhes como habilitar o Azure Disk Encryption.
Habilitar criptografia em VMs existentes ou em execução com Azure PowerShell
execução no Azure. Para obter informações sobre como habilitar a criptografia com o Azure Disk Encryption
usando cmdlets do PowerShell, confira as postagens de blog Explorar Azure Disk Encryption com o Azure
PowerShell - parte 1 e Explorar Azure Disk Encryption com o Azure PowerShell - parte 2.
Criptografar uma VM em execução usando um segredo do cliente: O script a seguir inicializa
suas variáveis e executa o cmdlet Set-AzVMDiskEncryptionExtension. O grupo de recursos, VM, cofre de
chaves, aplicativo AAD e segredo do cliente já devem ter sido criados como pré-requisitos. Substitua
MyKeyVaultResourceGroup, MyVirtualMachineResourceGroup, MySecureVM, MySecureVault, meu-AAD-
Client-ID e meu-AAD-Client-Secret pelos valores.

-DiskEncryptionKeyVaultId $KeyVaultResourceId;
Criptografar uma VM em execução usando KEK para encapsular o segredo do cliente: o Azure
Disk Encryption permite que você especifique uma chave existente no cofre de chaves para encapsular
segredos de criptografia de disco que foram gerados ao habilitar a criptografia. Quando uma chave de
$vmName = ‘MyExtraSecureVM’;
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGname -VMName $vmName -AadClientID

NOTE

AzureRmVMDiskEncryption.
Habilitar criptografia em VMs existentes ou em execução com CLI do Azure

az vm encryption enable --resource-group "MyVirtualMachineResourceGroup" --name "MySecureVM" --aad-

client-id "<my spn created with CLI/my Azure AD ClientID>" --aad-client-secret "My-AAD-client-
secret" --disk-encryption-keyvault "MySecureVault" --volume-type [All|OS|Data]
Criptografar uma VM em execução usando KEK para encapsular o segredo do cliente:

client-id "<my spn created with CLI which is the Azure AD ClientID>" --aad-client-secret "My-AAD-
client-secret" --disk-encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --key-
encryption-keyvault "MySecureVaultContainingTheKEK" --volume-type [All|OS|Data]
NOTE

Usando o modelo do Gerenciador de Recursos

É possível habilitar a criptografia de disco em VMs do Windows da IaaS em execução ou existentes no Azure
usando o modelo do Resource Manager para criptografar uma VM do Windows em execução.
legais e o contrato. Clique em Comprar para habilitar a criptografia na VM da IaaS em execução ou
existente.
A tabela a seguir lista os parâmetros de modelo do Gerenciador de Recursos existente ou VMs em execução que
usam uma ID de cliente do Azure AD:
AADClientID ID do cliente do aplicativo Azure AD que tem permissões

AADClientSecret Segredo do cliente do aplicativo Azure AD que tem

permissões para gravar segredos no cofre de chaves.
keyVaultName Nome do cofre de chaves no qual a chave do BitLocker deve

ou o comando
az keyvault list --resource-group "MySecureGroup"
da CLI do Azure
keyEncryptionKeyURL URL da chave de criptografia de chaves que é usada para

criptografar a chave gerada do BitLocker. Esse parâmetro
será opcional se você selecionar nokek na lista suspensa
UseExistingKek. Se selecionar kek na lista suspensa
UseExistingKek, você deverá inserir o valor
keyEncryptionKeyURL .

executada. Os valores válidos são OS , Data e All .
sequenceVersion Versão de sequência da operação de BitLocker. Aumente

esse número de versão sempre que uma operação de
criptografia de disco for executada na mesma VM.

executada.
Novas VMs IaaS criadas do VHD criptografado pelo cliente e chaves

de criptografia
Nesse cenário, você pode habilitar a criptografia usando o modelo do Resource Manager, cmdlets do PowerShell
ou comandos da CLI. As seções a seguir explicam detalhadamente o modelo do Gerenciador de Recursos e
comandos da CLI.
Use as instruções no apêndice para preparar imagens previamente criptografadas que podem ser usadas no
Azure. Depois que a imagem for criada, você poderá usar as etapas na próxima seção para criar uma VM do
Azure criptografada.
Preparar um VHD do Windows previamente criptografado
Criptografar VMs com VHDs previamente criptografados com Azure PowerShell

000000000000/resourceGroups/myKVresourcegroup/providers/Microsoft.KeyVault/vaults/mytestvault"

É possível adicionar um novo disco a uma VM do Windows usando o PowerShell ou por meio do portal do
Azure.
Ao usar o Powershell para criptografar um novo disco para VMs do Windows, uma nova versão da sequência
deverá ser especificada. A versão da sequência deverá ser exclusiva. O script abaixo gera um GUID para a versão
da sequência. Em alguns casos, um disco de dados adicionado recentemente pode ser criptografado
automaticamente pela extensão do Azure Disk Encryption. A criptografia automática geralmente ocorre quando
a VM é reinicializada depois que o novo disco fica online. Isso geralmente é causado porque "All" foi
especificado para o tipo de volume quando a criptografia de disco foi executada anteriormente na VM. Se a
criptografia automática ocorrer em um disco de dados recém-adicionado, recomendamos executar o cmdlet
Set-AzVmDiskEncryptionExtension novamente com a nova versão de sequência. Se o seu novo disco de dados
for criptografado automaticamente e você não quiser ser criptografado, primeiro descriptografe todas as
unidades e criptografe novamente com uma nova versão de sequência, especificando o SO para o tipo de
volume.
Criptografar uma VM em execução usando um segredo do cliente: O script a seguir inicializa
suas variáveis e executa o cmdlet Set-AzVMDiskEncryptionExtension. O grupo de recursos, VM, cofre de
chaves, aplicativo AAD e segredo do cliente já devem ter sido criados como pré-requisitos. Substitua
MyKeyVaultResourceGroup, MyVirtualMachineResourceGroup, MySecureVM, MySecureVault, meu-AAD-
Client-ID e meu-AAD-Client-Secret pelos valores. Este exemplo usa "All" para o parâmetro -VolumeType,
que inclui ambos os volumes de Dados e SO. Se você quiser apenas criptografar o volume do SO, use
"OS" para o parâmetro -VolumeType.

-DiskEncryptionKeyVaultId $KeyVaultResourceId -VolumeType 'all' –SequenceVersion $sequenceVersion;
Criptografar uma VM em execução usando KEK para encapsular o segredo do cliente: o Azure
Disk Encryption permite que você especifique uma chave existente no cofre de chaves para encapsular
segredos de criptografia de disco que foram gerados ao habilitar a criptografia. Quando uma chave de
criptografia antes de gravar no Key Vault. Este exemplo usa "All" para o parâmetro -VolumeType, que
inclui ambos os volumes de Dados e SO. Se você quiser apenas criptografar o volume do SO, use "OS"
para o parâmetro -VolumeType.

KeyEncryptionKeyVaultId $KeyVaultResourceId -VolumeType 'all' –SequenceVersion $sequenceVersion;
NOTE
O comando da CLI do Azure fornecerá automaticamente uma nova versão da sequência quando você executar o
comando para habilitar a criptografia. Valores aceitáveis para o parâmetro do tipo de volume são Todos, SO e
Dados. Talvez seja necessário alterar o parâmetro do tipo de volume para OS ou Dados, se você estiver
criptografando apenas um tipo de disco para a VM. Os exemplos usam "All" para o parâmetro do tipo de
volume.

client-id "<my spn created with CLI/my Azure AD ClientID>" --aad-client-secret "My-AAD-client-
secret" --disk-encryption-keyvault "MySecureVault" --volume-type "All"
Criptografar uma VM em execução usando KEK para encapsular o segredo do cliente:

client-id "<my spn created with CLI which is the Azure AD ClientID>" --aad-client-secret "My-AAD-
client-secret" --disk-encryption-keyvault "MySecureVault" --key-encryption-key "MyKEK_URI" --key-
encryption-keyvault "MySecureVaultContainingTheKEK" --volume-type "all"
Habilitar criptografia usando a autenticação baseada no certificado de

cliente do Azure AD.
É possível usar a autenticação de certificado de cliente com ou sem KEK. Antes de usar os scripts do PowerShell,
você já deve ter o certificado carregado no cofre de chaves e implantado na VM. Se você também estiver
usando KEK, o KEK já deverá existir. Para obter mais informações, consulte a seção Autenticação baseada em
certificado do Azure AD do artigo de pré-requisitos.
Habilitar a criptografia usando a autenticação baseada em certificado com Azure PowerShell
## Fill in 'MyVirtualMachineResourceGroup', 'MyKeyVaultResourceGroup', 'My-AAD-client-ID', 'MySecureVault,

and ‘MySecureVM’.
$AADClientID ='My-AAD-client-ID';
# Fill in the certificate path and the password so the thumbprint can be set as a variable.
$certPath = '$CertPath = "C:\certificates\mycert.pfx';

$CertPassword ='Password'
$Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($CertPath, $CertPassword)
$aadClientCertThumbprint = $cert.Thumbprint;
# Enable disk encryption using the client certificate thumbprint

Habilitar criptografia usando autenticação baseada em certificado e um KEK com o Azure PowerShell
# Fill in 'MyVirtualMachineResourceGroup', 'MyKeyVaultResourceGroup', 'My-AAD-client-ID', 'MySecureVault,,
'MySecureVM’, and "KEKName.
$AADClientID ='My-AAD-client-ID';
$keyEncryptionKeyName ='KEKName';
## Fill in the certificate path and the password so the thumbprint can be read and set as a variable.
$certPath = '$CertPath = "C:\certificates\mycert.pfx';

$CertPassword ='Password'
$Cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($CertPath, $CertPassword)
$aadClientCertThumbprint = $cert.Thumbprint;
# Enable disk encryption using the client certificate thumbprint and a KEK

Desabilitar criptografia
Manager.
Desabilitar criptografia de disco com Azure PowerShell: para desabilitar a criptografia, use o
cmdlet Disable-AzureRmVMDiskEncryption.
encryption disable.

Desabilitar a criptografia com um modelo do Resource Manager :

1. Clique em implantar no Azure no modelo desabilitar a criptografia de disco no Windows VM em
execução .
3. Clique em Comprar para desabilitar a criptografia de disco em uma VM do Windows em execução.
Próximas etapas
Usando os ultra discos do Azure
Este artigo explica como implantar e usar um ultra Disk, para obter informações conceituais sobre ultra disks,
consulte quais tipos de disco estão disponíveis no Azure?.
Os ultra discos do Azure oferecem alta taxa de transferência, IOPS alta e armazenamento de disco consistente
de baixa latência para VMs (máquinas virtuais) IaaS do Azure. Essa nova oferta fornece o melhor em
desempenho de linha, nos mesmos níveis de disponibilidade que nossas ofertas de discos atuais. Um grande
benefício dos ultra discos é a capacidade de alterar dinamicamente o desempenho do SSD junto com suas
cargas de trabalho sem a necessidade de reiniciar suas VMs. Os discos Ultra são adequados para cargas de
trabalho de grande volume de dados, como SAP HANA, bancos de dados de camada superior e cargas de
trabalho de transações pesadas.
Limitações e escopo de GA
Por enquanto, ultra discos têm limitações adicionais, como a seguir:
As únicas opções de redundância de infraestrutura disponíveis atualmente para ultra discos são zonas de
disponibilidade. As VMs que usam qualquer outra opção de redundância não podem anexar um ultra Disk.
A tabela a seguir descreve as regiões em que os ultra discos estão disponíveis, bem como suas opções de
disponibilidade correspondentes:
NOTE
Se uma região na lista a seguir não tiver nenhuma zona de disponibilidade com capacidade de disco ultra, as VMs nessa
região deverão ser implantadas sem nenhuma opção de redundância de infraestrutura para anexar um ultra Disk.
Brazil South Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Índia Central Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Leste da Ásia Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Centro-Oeste da Alemanha Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Coreia Central Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Centro-Sul dos Estados Unidos Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Governo dos EUA do Arizona Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Gov. dos EUA – Virgínia Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Governo dos EUA do Texas Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Oeste dos EUA Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Austrália Central Somente VMs únicas (conjuntos de disponibilidade e

têm suporte)
Leste da Austrália Três zonas de disponibilidade
Sudeste Asiático Três zonas de disponibilidade
Centro-Canadá * Três zonas de disponibilidade
Centro dos EUA Três zonas de disponibilidade
Leste dos EUA Três zonas de disponibilidade
Leste dos EUA 2 Três zonas de disponibilidade
França Central Duas zonas de disponibilidade
Japan East Três zonas de disponibilidade
Norte da Europa Três zonas de disponibilidade
Sul do Reino Unido Três zonas de disponibilidade
Europa Ocidental Três zonas de disponibilidade
Oeste dos EUA 2 Três zonas de disponibilidade
* Contate o suporte do Azure para obter acesso a Zonas de Disponibilidade para esta região.
Há suporte apenas na seguinte série de VMs:
ESv3
Easv4
Edsv4
Esv4
DSv3
Dasv4
Ddsv4
Dsv4
FSv2
LSv2
M
Mv2
Nem todo tamanho de VM está disponível em todas as regiões com suporte com ultra discos.
Estão disponíveis somente como discos de dados.
Suporte ao tamanho de setor físico de 4K por padrão. o tamanho do setor 512E está disponível como uma
oferta geralmente disponível (nenhuma inscrição é necessária), mas só está disponível no momento usando
a CLI ou o PowerShell. A maioria dos aplicativos é compatível com tamanhos de setor de 4K, mas alguns
exigem tamanhos de setor de 512 bytes. Um exemplo seria Oracle Database, que requer a versão 12,2 ou
posterior para dar suporte aos discos nativos de 4K. Para versões mais antigas do Oracle DB, é necessário o
tamanho do setor de 512 bytes.
Só pode ser criado como discos vazios.
Atualmente, o não oferece suporte a instantâneos de disco, imagens de VM, conjuntos de disponibilidade,
hosts dedicados do Azure ou Azure Disk Encryption.
Atualmente, o não oferece suporte à integração com o backup do Azure ou Azure Site Recovery.
Dá suporte apenas a leituras não armazenadas em cache e gravações não armazenadas em cache.
O limite máximo atual para IOPS em VMs GA é 80.000.
Os ultra discos do Azure oferecem até 16 TiB por região por assinatura por padrão, mas os ultra discos
oferecem suporte à maior capacidade por solicitação. Para solicitar um aumento na capacidade, entre em
contato com o suporte do Azure.
Determinar a disponibilidade da região e do tamanho da VM

VMs que usam zonas de disponibilidade
Para aproveitar os ultra discos, você precisa determinar em qual zona de disponibilidade você está. Nem toda
região dá suporte a todos os tamanhos de VM com ultra discos. Para determinar se a região, a zona e o
tamanho da VM dão suporte a ultra discos, execute um dos seguintes comandos, certifique-se de substituir os
valores de região , vmSize e assinatura primeiro:
CLI
subscription="<yourSubID>"
# example value is southeastasia
region="<yourLocation>"
# example value is Standard_E64s_v3
vmSize="<yourVMSize>"
az vm list-skus --resource-type virtualMachines --location $region --query "[?

name=='$vmSize'].locationInfo[0].zoneDetails[0].Name" --subscription $subscription
PowerShell
$region = "southeastasia"
$vmSize = "Standard_E64s_v3"
$sku = (Get-AzComputeResourceSku | where {$_.Locations.Contains($region) -and ($_.Name -eq $vmSize) -and
$_.LocationInfo[0].ZoneDetails.Count -gt 0})
if($sku){$sku[0].LocationInfo[0].ZoneDetails} Else {Write-host "$vmSize is not supported with Ultra Disk in
$region region"}
A resposta será semelhante ao formulário abaixo, em que X é a zona a ser usada para implantação na sua região
escolhida. X pode ser 1, 2 ou 3.
Preservar o valor de zonas , representa sua zona de disponibilidade e você precisará dela para implantar um
ultra Disk.
RESO URC ET Y LO C A L IZ A Ç Ã F UN C IO N A L I
PE NOME O ZONAS REST RIÇ Ã O DA DE VA LO R
disks UltraSSD_LRS eastus2 X
NOTE
Se não houver resposta do comando, o tamanho da VM selecionado não terá suporte com ultra discos na região
selecionada.
Agora que você sabe em qual zona implantar, siga as etapas de implantação neste artigo para implantar uma
VM com um ultra Disk anexado ou anexar um ultra Disk a uma VM existente.
VMs sem opções de redundância
Ultra discos implantados em regiões selecionadas devem ser implantados sem nenhuma opção de redundância,
por enquanto. No entanto, nem todo tamanho de disco que dá suporte a ultra discos pode estar nessa região.
Para determinar quais tamanhos de disco dão suporte a ultra discos, você pode usar qualquer um dos trechos
de código a seguir. Certifique-se de substituir vmSize os subscription valores e primeiro:
subscription="<yourSubID>"
region="westus"
# example value is Standard_E64s_v3
vmSize="<yourVMSize>"
az vm list-skus --resource-type virtualMachines --location $region --query "[?

name=='$vmSize'].capabilities" --subscription $subscription
$region = "westus"
$vmSize = "Standard_E64s_v3"
(Get-AzComputeResourceSku | where {$_.Locations.Contains($region) -and ($_.Name -eq $vmSize) })
[0].Capabilities
A resposta será semelhante ao seguinte formulário, UltraSSDAvailable True indica se o tamanho da VM dá

suporte a ultra discos nessa região.
Name Value
---- -----
MaxResourceVolumeMB 884736
OSVhdSizeMB 1047552
vCPUs 64
HyperVGenerations V1,V2
MemoryGB 432
MaxDataDiskCount 32
LowPriorityCapable True
PremiumIO True
VMDeploymentTypes IaaS
vCPUsAvailable 64
ACUs 160
vCPUsPerCore 2
CombinedTempDiskAndCachedIOPS 128000
CombinedTempDiskAndCachedReadBytesPerSecond 1073741824
CombinedTempDiskAndCachedWriteBytesPerSecond 1073741824
CachedDiskBytes 1717986918400
UncachedDiskIOPS 80000
UncachedDiskBytesPerSecond 1258291200
EphemeralOSDiskSupported True
AcceleratedNetworkingEnabled True
RdmaEnabled False
MaxNetworkInterfaces 8
UltraSSDAvailable True
Implantar um ultra Disk usando o Azure Resource Manager

Primeiro, determine o tamanho da VM a ser implantado. Para obter uma lista de tamanhos de VM com suporte,
consulte a seção escopo e limitações do GA .
Se você quiser criar uma VM com vários ultra discos, consulte o exemplo criar uma VM com vários ultra discos.
Se você pretende usar seu próprio modelo, certifique-se de que apiVersion para
Microsoft.Compute/virtualMachines e Microsoft.Compute/Disks esteja definido como 2018-06-01 (ou posterior).
Defina a SKU do disco como UltraSSD_LRS , em seguida, defina a capacidade do disco, o IOPS, a zona de
disponibilidade e a taxa de transferência em Mbps para criar um ultra Disk.
Depois que a VM for provisionada, será possível particionar e formatar os discos de dados e configurá-los para
suas cargas de trabalho.
Implantar um ultra Disk

Portal
CLI do Azure
PowerShell
Esta seção aborda a implantação de uma máquina virtual equipada com um ultra Disk como um disco de dados.
Ele pressupõe que você tenha familiaridade com a implantação de uma máquina virtual, se não tiver, consulte
nosso início rápido: criar uma máquina virtual do Windows no portal do Azure.
Entre no portal do Azure e navegue até implantar uma máquina virtual (VM).
Certifique-se de escolher um tamanho de VM e uma região com suporte.
Selecione zona de disponibilidade em Opções de disponibilidade .
Preencha as entradas restantes com seleções de sua escolha.
Escolha Discos .
Na folha discos, selecione Sim para habilitar a compatibilidade de ultra Disk .
Selecione criar e anexar um novo disco para anexar um ultra Disk agora.
Na folha criar um novo disco , insira um nome e, em seguida, selecione alterar tamanho .
Altere o tipo de armazenamento para ultra Disk .
Altere os valores de tamanho de disco personalizado (GIB) , IOPS de disco e taxa de
transferência de disco para aqueles de sua escolha.
Selecione OK em ambas as folhas.
Continue com a implantação da VM, ela será a mesma que você implantaria qualquer outra VM.
Implantar um tamanho de setor de byte de 512 bytes

Portal
CLI do Azure
PowerShell
Atualmente, o portal do Azure não dá suporte à criação de um ultra Disk com um tamanho de setor de 512
bytes. Você pode criar um ultra Disk com um tamanho de setor de 512 bytes usando o módulo Azure
PowerShell ou a CLI do Azure, em vez disso.
Anexar um ultra Disk

Portal
CLI do Azure
PowerShell
Como alternativa, se sua VM existente estiver em uma zona de região/disponibilidade que seja capaz de usar
ultra disks, você poderá usar ultra discos sem precisar criar uma nova VM. Habilitando ultra discos em sua VM
existente e, em seguida, anexando-os como discos de dados. Para habilitar a compatibilidade de ultra Disk, você
deve parar a VM. Depois de parar a VM, você pode habilitar a compatibilidade e reiniciar a VM. Quando a
compatibilidade estiver habilitada, você poderá anexar um disco ultra:
Navegue até sua VM e interrompa-a, aguarde até que ela seja desalocada.
Depois que a VM tiver sido desalocada, selecione discos .
Selecione Edit (Editar).
Selecione Sim para habilitar a compatibilidade de ultra Disk .
Clique em Salvar .
Selecione adicionar disco de dados e, em seguida, no menu suspenso para nome , selecione criar disco .
Preencha um nome para o novo disco e selecione alterar tamanho .

Altere o tipo de conta para ultra Disk .
Altere os valores de tamanho de disco personalizado (GIB) , IOPS de disco e taxa de
transferência de disco para aqueles de sua escolha.
Selecione OK e, em seguida, selecione criar .
Depois de retornar à folha do disco, selecione salvar .
Inicie sua VM novamente.
Ajustar o desempenho de um ultra Disk

Portal
CLI do Azure
PowerShell
Ultra disks oferece um recurso exclusivo que permite que você ajuste seu desempenho. Você pode fazer esses
ajustes da portal do Azure, nos próprios discos.
Navegue até sua VM e selecione discos .
Selecione o ultra Disk do qual você gostaria de modificar o desempenho.
Selecione configuração e faça suas modificações.
Clique em Salvar .
Próximas etapas
Use os ultra discos do Azure no serviço kubernetes do Azure (versão prévia).
Migre o disco de log para um ultra Disk.
Desempenho de máquina virtual e disco
Este artigo ajuda a esclarecer o desempenho do disco e como ele funciona quando você combina máquinas
virtuais do Azure e discos do Azure. Ele também descreve como você pode diagnosticar afunilamentos para a
e/s de disco e as alterações que você pode fazer para otimizar o desempenho.
Como funciona o desempenho do disco?

As máquinas virtuais do Azure têm o IOPS (operações de entrada/saída por segundo) e os limites de
desempenho de taxa de transferência com base no tipo e no tamanho da máquina virtual. Discos do sistema
operacional e discos de dados podem ser anexados a máquinas virtuais. Os discos têm seus próprios limites de
IOPS e taxa de transferência.
O desempenho do aplicativo é limitado quando solicita mais IOPS ou taxa de transferência do que o que é
alocado para as máquinas virtuais ou discos anexados. Quando estiver limitado, o aplicativo apresentará um
desempenho de qualidade inferior. Isso pode levar a consequências negativas, como maior latência. Vamos
executar alguns exemplos para esclarecer esse conceito. Para facilitar o acompanhamento desses exemplos,
veremos apenas IOPS. Porém, a mesma lógica se aplica à taxa de transferência.
Limitação de e/s de disco

Instalação
Standard_D8s_v3
IOPS não armazenado em cache: 12.800
Disco do sistema operacional E30
IOPS: 500
Dois discos de dados E30 × 2
IOPS: 500
O aplicativo em execução na máquina virtual faz uma solicitação que exige 10.000 IOPS para a máquina virtual.
Todos os quais são permitidos pela VM porque a máquina virtual Standard_D8s_v3 pode executar até 12.800
IOPS.
As solicitações de IOPS de 10.000 são divididas em três solicitações diferentes para os diferentes discos:
1.000 IOPS são solicitados para o disco do sistema operacional.
4.500 IOPS são solicitadas para cada disco de dados.
Todos os discos anexados são discos E30 e só podem manipular 500 IOPS. Portanto, eles respondem com 500
IOPS cada. O desempenho do aplicativo é limitado pelos discos anexados e só pode processar 1.500 IOPS. O
aplicativo pode funcionar em desempenho máximo em 10.000 IOPS se discos de melhor desempenho forem
usados, como SSD Premium discos p30.
E/s de máquina virtual com limitação

Instalação
Standard_D8s_v3
Disco do sistema operacional p30
IOPS: 5.000
Dois discos de dados p30 × 2
IOPS: 5.000
O aplicativo em execução na máquina virtual faz uma solicitação que exige 15.000 IOPS. Infelizmente, a
máquina virtual Standard_D8s_v3 é provisionada apenas para lidar com 12.800 IOPS. O aplicativo é limitado
pelos limites da máquina virtual e deve alocar o IOPS alocado de 12.800.
Esses 12.800 IOPS solicitados são divididos em três solicitações diferentes para os diferentes discos:
4.267 IOPS são solicitados para o disco do sistema operacional.
4.266 IOPS são solicitadas para cada disco de dados.
Todos os discos anexados são discos p30 que podem lidar com 5.000 IOPS. Portanto, eles respondem de volta
com seus valores solicitados.
Limites em cache de máquina virtual desarmazenado versus

As máquinas virtuais habilitadas para armazenamento Premium e cache de armazenamento Premium têm dois
limites de largura de banda de armazenamento diferentes. Vamos examinar a máquina virtual Standard_D8s_v3
como um exemplo. Aqui está a documentação sobre a série Dsv3 e o Standard_D8s_v3:
A taxa de transferência máxima do disco não armazenado em cache é o limite máximo de armazenamento
padrão que a máquina virtual pode manipular.
O limite máximo de taxa de transferência de armazenamento em cache é um limite separado quando você
habilita o cache de host.
O cache de host funciona colocando o armazenamento mais próximo da VM que pode ser gravada ou lida com
rapidez. A quantidade de armazenamento disponível para a VM para o cache de host está na documentação. Por
exemplo, você pode ver que a Standard_D8s_v3 vem com 200 GiB de armazenamento em cache.
Você pode habilitar o cache de host ao criar sua máquina virtual e anexar discos. Você também pode ativar e
desativar o cache de host em seus discos em uma VM existente.
Você pode ajustar o cache do host para corresponder aos seus requisitos de carga de trabalho para cada disco.
Você pode definir o cache do host como:
Somente leitura : para cargas de trabalho que só fazem operações de leitura
Leitura/gravação : para cargas de trabalho que fazem um saldo de operações de leitura e gravação
Se sua carga de trabalho não seguir nenhum desses padrões, não recomendamos que você use o cache de host.
Vamos executar alguns exemplos de diferentes configurações de cache de host para ver como ele afeta o fluxo
de dados e o desempenho. Neste primeiro exemplo, veremos o que acontece com as solicitações de e/s quando
a configuração de cache do host é definida como somente leitura .
Instalação
Standard_D8s_v3
IOPS em cache: 16.000
Disco de dados p30
IOPS: 5.000
Cache de host: somente leitura
Quando uma leitura é executada e os dados desejados estão disponíveis no cache, o cache retorna os dados
solicitados. Não é necessário ler a partir do disco. Essa leitura é contada em relação aos limites em cache da VM.
Quando uma leitura é executada e os dados desejados não estão disponíveis no cache, a solicitação de leitura é
retransmitida para o disco. Em seguida, o disco a superfícies tanto para o cache quanto para a VM. Essa leitura é
contada em relação ao limite não armazenado em cache da VM e ao limite em cache da VM.
Quando uma gravação é executada, a gravação precisa ser gravada no cache e no disco antes que ele seja
considerado concluído. Essa gravação é contada em relação ao limite não armazenado em cache da VM e ao
limite em cache da VM.
Em seguida, vamos examinar o que acontece com as solicitações de e/s quando a configuração de cache do host
é definida como leitura/gravação .
Instalação
Standard_D8s_v3
Disco de dados p30
IOPS: 5.000
Cache de host: leitura/gravação
Uma leitura é tratada da mesma maneira que uma somente leitura. As gravações são a única coisa que é
diferente com o cache de leitura/gravação. Quando a gravação com cache de host é definida como
leitura/gravação , a gravação só precisa ser gravada no cache do host para ser considerada concluída. Em
seguida, a gravação é gravada lentamente no disco como um processo em segundo plano. Isso significa que
uma gravação é contada em relação a e/s em cache quando gravada no cache. Quando ele é gravado
lentamente no disco, ele conta para a e/s não armazenada em cache.
Vamos continuar com nossa máquina virtual de Standard_D8s_v3. Exceto desta vez, Habilitaremos o cache de
host nos discos. Além disso, agora o limite de IOPS da VM é de 16.000 IOPS. Anexados à VM estão três discos
p30 subjacentes que podem lidar com 5.000 IOPS.
Instalação
Standard_D8s_v3
IOPS: 5.000
IOPS: 5.000
O aplicativo usa uma máquina virtual Standard_D8s_v3 com Caching habilitado. Ele faz uma solicitação de
15.000 IOPS. As solicitações são divididas como 5.000 IOPS para cada disco subjacente anexado. Nenhum
capping de desempenho ocorre.
Limites combinados não armazenados em cache e armazenados em

cache
Os limites em cache de uma máquina virtual são separados dos limites não armazenados em cache. Isso
significa que você pode habilitar o cache de host em discos anexados a uma VM e não habilitar o cache de host
em outros discos. Essa configuração permite que suas máquinas virtuais obtenham uma e/s de armazenamento
total do limite em cache mais o limite não armazenado em cache.
Vamos executar um exemplo para ajudá-lo a entender como esses limites funcionam juntos. Continuaremos
com a máquina virtual Standard_D8s_v3 e a configuração anexada de discos Premium.
Instalação
Standard_D8s_v3
IOPS: 5.000
IOPS: 5.000
IOPS: 5.000
Cache de host: desabilitado
Nesse caso, o aplicativo em execução em um Standard_D8s_v3 máquina virtual faz uma solicitação de 25.000
IOPS. A solicitação é dividida como 5.000 IOPS para cada um dos discos anexados. Três discos usam o cache de
host e dois discos não usam o cache de host.
Como os três discos que usam o cache de host estão dentro dos limites em cache de 16.000, essas
solicitações são concluídas com êxito. Nenhum capping de desempenho de armazenamento ocorre.
Como os dois discos que não usam o cache de host estão dentro dos limites não armazenados em cache de
12.800, essas solicitações também são concluídas com êxito. Não ocorre nenhum capping.
Entenda como o desconto de reserva é aplicado ao
Armazenamento em Disco do Azure
Depois de comprar a capacidade reservada de disco do Azure, um desconto de reserva será aplicado
automaticamente aos recursos do disco que correspondem aos termos da reserva. O desconto de reserva se
aplica apenas aos SKUs do disco. Instantâneos de disco são cobrados em taxas pagas conforme o uso.
Para obter mais informações sobre a reserva de discos do Azure, confira Economizar custos com a reserva de
discos do Azure. Para obter informações sobre preços de reserva de discos do Azure, confira Preços do Azure
Managed Disks.
Como o desconto de reserva é aplicado

O desconto de reserva de discos do Azure é um desconto do tipo pegar ou largar. Aplica-se a recursos de disco
gerenciado por hora. Para uma determinada hora, se não tiver nenhum recurso de disco gerenciado que atenda
aos termos de reserva, você perderá uma quantidade de reserva para essa hora. Horas não utilizadas não são
postergadas.
Quando você exclui um recurso, o desconto de reserva se aplica automaticamente a outro recurso
correspondente no escopo especificado. Se não for encontrado nenhum recurso correspondente, as horas
reservadas serão perdidas.
Exemplos de desconto
Os exemplos a seguir mostram como o desconto de reserva de discos do Azure se aplica dependendo de sua
implantação.
Suponha que você compre e reserve 100 discos P30 na região Oeste dos EUA 2 durante o prazo de um ano.
Cada disco tem aproximadamente 1 TiB de armazenamento. Suponha que o custo desta reserva de exemplo
seja de US$ 140.100. Você pode optar por pagar antecipadamente o valor total ou parcelas mensais fixas de
US$ 11.675 nos próximos 12 meses.
Os cenários a seguir descrevem o que acontecerá se você subutilizar, usar excessivamente ou dividir em níveis
sua capacidade reservada. Para esses exemplos, vamos supor que você tenha se inscrito em um plano de
pagamento mensal de reservas.
Subutilização da sua capacidade
Vamos supor que você implante apenas 99 de seus 100 discos P30 SSD (unidade de estado sólido) premium do
Azure reservados por uma hora dentro do período de reserva. O disco P30 restante não é aplicado durante essa
hora. Ele também não é transferido.
Superutilização da sua capacidade
Suponha que, para uma hora dentro do período de reserva, você use 101 discos P30 SSD Premium. O desconto
de reserva se aplica apenas a 100 discos P30. O disco P30 restante é cobrado em taxas pagas conforme o uso
para essa hora. Na próxima hora, se o uso diminuir para 100 discos P30, todo o uso será coberto pela reserva.
Divisão em camadas de sua capacidade
Suponha que, em uma determinada hora em seu período de reserva, você queira usar o total de 200 SSDs P30
Premium. Suponha também que você use apenas 100 nos primeiros 30 minutos. Durante esse período, seu uso
é totalmente coberto, porque você fez uma reserva de 100 discos P30. Se, em seguida, você descontinuar o uso
dos primeiros 100 (ou seja, está usando zero) e começar a usar os outros 100 pelos 30 minutos restantes, esse
uso também estará coberto por sua reserva.
Precisa de ajuda? Fale conosco

Próximas etapas
Reduzir os custos com a reserva de discos do Azure
Reduzir os custos com a reserva de discos do Azure
Economize em seu uso de Armazenamento em Disco do Azure com capacidade reservada. Armazenamento em
Disco do Azure reservas combinadas com as instâncias de máquinas virtuais reservadas do Azure permitem
reduzir os custos totais da VM (máquina virtual). O desconto de reserva é aplicado automaticamente aos discos
correspondentes no escopo de reserva selecionado. Devido a esse aplicativo automático, você não precisa
atribuir uma reserva a um disco gerenciado para obter os descontos.
Os descontos são aplicados por hora, dependendo do uso do disco. A capacidade reservada não utilizada não é
transferida. Os descontos de reserva de Armazenamento em Disco do Azure não se aplicam a discos não
gerenciados, ultra discos ou consumo de blob de páginas.
Determinar suas necessidades de armazenamento

Antes de comprar uma reserva, determine suas necessidades de armazenamento. Atualmente, Armazenamento
em Disco do Azure reservas estão disponíveis apenas para os SKUs selecionados do SSD do Azure Premium. A
SKU de um SSD Premium determina o tamanho e o desempenho do disco.
Ao determinar suas necessidades de armazenamento, não considere os discos com base apenas na capacidade.
Por exemplo, você não pode ter uma reserva para um disco P40 e usá-lo para pagar por dois discos p30
menores. Ao comprar uma reserva, você está apenas comprando uma reserva para o número total de discos
por SKU.
Uma reserva de disco é feita por SKU de disco. Como resultado, o consumo de reserva é baseado na unidade
das SKUs de disco, em vez do tamanho fornecido.
Por exemplo, suponha que você reserve um disco P40 que tenha 2 TiB de capacidade de armazenamento
provisionado. Suponha também que você aloque apenas dois discos p30. A reserva de P40 nesse caso não
conta com o consumo de p30 e você paga a tarifa paga conforme o uso nos discos p30.
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Tam 4 8 16 32 64 128 256 512 1.0 2.0 4.0 8.1 16. 32.
anh 24 48 96 92 384 767
o
do
disc
o
em
GiB
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
IOP 120 120 120 120 240 500 1.1 2.3 5.0 7.5 7.5 16. 18. 20,
S 00 00 00 00 00 000 000 000
pro
visi
ona
da
por
disc
o
Taxa 25 25 25 25 50 100 125 150 200 250 250 500 750 900
sfer
ênci
a
pro
visi
ona
da
por
disc
o
Má 3.5 3.5 3.5 3.5 3.5 3.5 3.5 3.5

xim 00 00 00 00 00 00 00 00
o
de
IOP
S
de
inte
rmit
ênci
a
por
disc
o
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Taxa 170 170 170 170 170 170 170 170

sfer
ênci
a
de
inte
rmit
ênci
a
máx
ima
por
disc
o
Dur 30 30 30 30 30 30 30 30
o
máx
ima
da
inte
rmit
ênci
a
par
a
rese
rva
Considerações sobre a compra

Recomendamos as seguintes práticas ao considerar a compra de reserva de disco:
Analise suas informações de uso para ajudar a determinar quais reservas devem ser compradas.
Certifique-se de controlar o uso em SKUs de disco em vez de capacidade de disco provisionada ou usada.
Examine sua reserva de disco juntamente com sua reserva de VM. É altamente recomendável fazer
reservas para uso da VM e uso do disco para economia máxima. Você pode começar a determinar a
reserva de VM correta e, em seguida, avaliar a reserva de disco. Em geral, você terá uma configuração
padrão para cada uma de suas cargas de trabalho. Por exemplo, um servidor de SQL Server pode ter dois
discos de dados P40 e um disco de sistema operacional p30.
Esse tipo de padrão pode ajudá-lo a determinar o valor reservado que você pode comprar. Essa
abordagem pode simplificar o processo de avaliação e garantir que você tenha um plano alinhado para a
VM e os discos. O plano contém considerações como assinaturas ou regiões.
Restrições de compra
Os descontos de reserva não estão disponíveis no momento para o seguinte:
Discos não gerenciados ou BLOBs de página.
SSDs padrão ou unidades de disco rígido padrão (HDDs).
SSD Premium SKUs menores que p30: P1, P2, P3, P4, P6, P10, P15 e SKUs de SSD P20.
Discos nas regiões Azure governamental, Azure Alemanha ou Azure China.
Em raras circunstâncias, o Azure limita a compra de novas reservas para um subconjunto de SKUs de disco
devido à baixa capacidade em uma região.
Comprar uma reserva de disco

Você pode comprar Armazenamento em Disco do Azure reservas por meio do portal do Azure. Você pode pagar
pela reserva até a frente ou com pagamentos mensais. Para obter mais informações sobre como comprar com
pagamentos mensais, consulte reservas de compra com pagamentos mensais.
Siga estas etapas para comprar a capacidade reservada:
1. Vá para o painel reservas de compra na portal do Azure.
2. Selecione Managed disks do Azure para comprar uma reserva.
3. Especifique os valores necessários descritos na tabela a seguir:
EL EM EN TO DESC RIÇ Ã O
EL EM EN TO DESC RIÇ Ã O
Escopo Quantas assinaturas podem usar o benefício de cobrança

associado à reserva. Esse valor também especifica como
a reserva é aplicada a assinaturas específicas.
Se você selecionar compar tilhado , o desconto de

reserva será aplicado à capacidade de armazenamento
do Azure em cada assinatura no contexto de cobrança. O
contexto de cobrança é baseado em como você se
inscreveu no Azure. Para clientes empresariais, o escopo
compartilhado é o registro e inclui todas as assinaturas
no registro. Para clientes pagos conforme o uso, o
escopo compartilhado inclui todas as assinaturas
individuais com tarifas pagas conforme o uso criadas
pelo administrador da conta.
Se você selecionar assinatura única , o desconto de

reserva será aplicado à capacidade de armazenamento
do Azure na assinatura selecionada.
Se você selecionar um único grupo de recursos , o

desconto de reserva será aplicado à capacidade de
armazenamento do Azure na assinatura selecionada e no
grupo de recursos selecionado da assinatura.
Você pode alterar o escopo de reserva depois de

comprar a reserva.
Assinatura A assinatura que você usa para pagar pela reserva de

armazenamento do Azure. O método de pagamento na
assinatura selecionada é usado para cobrar os custos. A
assinatura deve ser um dos seguintes tipos:
Enterprise Agreement (números de oferta MS-
AZR-0017P e MS-AZR-0148P). Para uma
assinatura empresarial, os encargos são
deduzidos do saldo antecipado do Azure do
registro (anteriormente chamado de
compromisso monetário) ou cobrados como
excedentes.
Assinatura individual com tarifas pagas conforme

o uso (números de oferta MS-AZR-0003P e MS-
AZR-0023P). Para uma assinatura individual com
tarifas pagas conforme o uso, os encargos são
cobrados no cartão de crédito ou no método de
pagamento de fatura na assinatura.
Discos A SKU que você deseja criar.
Região A região em que a reserva está em vigor.
Frequência de cobrança Com que frequência a conta é cobrada pela reserva. As

opções incluem mensalmente e antecipadamente .
4. Depois de especificar os valores para sua reserva, o portal do Azure exibirá o custo. O portal também
mostra a porcentagem de desconto sobre a cobrança paga conforme o uso. Selecione Avançar para
continuar no painel reser vas de compra .
5. No painel reser vas de compra , você pode nomear sua reserva e selecionar a quantidade total de
reservas que deseja fazer. O número de reservas é mapeado para o número de discos. Por exemplo, se
você quiser reservar uma centena de discos, insira o valor de quantidade 100 .
6. Examine o custo total da reserva.
Depois de comprar uma reserva, ela é aplicada automaticamente a todos os recursos existentes do
Armazenamento em Disco que correspondam aos termos de reserva. Se você ainda não tiver criado nenhum
recurso Armazenamento em Disco, a reserva será aplicada sempre que você criar um recurso que corresponda
aos termos de reserva. Em ambos os casos, o termo de reserva começa imediatamente após uma compra bem-
sucedida.
Cancelar, trocar ou reembolsar reservas

Você pode cancelar, trocar ou reembolsar reservas dentro de determinadas limitações. Para saber mais, confira
Trocas e reembolsos via autoatendimento para Reservas do Azure.
Expiração de uma reserva

Quando uma reserva expira, qualquer capacidade de Armazenamento em Disco do Azure que você use sob essa
reserva será cobrada com a taxa paga conforme o uso. As reservas não são renovadas automaticamente.
Você receberá uma notificação por email 30 dias antes da expiração da reserva e novamente na data de
expiração. Para continuar aproveitando a economia de custos que uma reserva fornece, renove-a não depois da
data de expiração.
Precisa de ajuda? Fale conosco

Próximas etapas
Entenda como seu desconto de reserva é aplicado a Armazenamento em Disco do Azure
Armazenamento Premium do Azure: projeto para
alto desempenho
Este artigo fornece diretrizes para a criação de aplicativos de alto desempenho usando o Armazenamento
Premium do Azure. Você pode usar as instruções fornecidas neste documento combinadas com as práticas
recomendadas de desempenho aplicáveis às tecnologias usadas pelo aplicativo. Para ilustrar as diretrizes,
usamos o SQL Server em execução no Armazenamento Premium como exemplo em todo este documento.
Embora, neste artigo, tenhamos abordado cenários da camada de Armazenamento, você precisará otimizar a
camada de aplicativo. Por exemplo, se estiver hospedando um Farm do SharePoint no Armazenamento
Premium do Azure, você poderá usar os exemplos do SQL Server deste artigo para otimizar o servidor de
banco de dados. Adicionalmente, otimize o servidor Web e o servidor de Aplicativos do Farm do SharePoint
para obter o melhor desempenho possível.
Este artigo ajudará a responder às perguntas comuns a seguir sobre como otimizar o desempenho de
aplicativos no Armazenamento Premium do Azure.
Como avaliar o desempenho do aplicativo?
Por que você não está vendo o alto desempenho esperado?
Quais fatores influenciam o desempenho do aplicativo no Armazenamento Premium?
Como esses fatores influenciam o desempenho do aplicativo no Armazenamento Premium?
Como você pode otimizar para IOPS, Largura de Banda e Latência?
Fornecemos estas diretrizes especificamente para Armazenamento Premium porque as cargas de trabalho em
execução no Armazenamento Premium são altamente sensíveis ao desempenho. Fornecemos exemplos onde
apropriado. Também é possível aplicar algumas destas diretrizes a aplicativos em execução nas VMs da IaaS
com discos de Armazenamento Padrão.
NOTE
Às vezes, o que parece ser um problema de desempenho de disco é, na verdade, um gargalo de rede. Nessas situações,
você deve otimizar seu desempenho de rede.
Se você pretende avaliar o benchmark de seu disco, consulte nossos artigos sobre benchmarking de um disco:
Para o Linux: avaliar o aplicativo no armazenamento em disco do Azure
Para Windows: benchmarking de um disco.
Se sua VM oferecer suporte a rede acelerada, verifique se ela está ativada. Se não estiver ativado, você poderá ativá-lo em
VMs já implementadas nos Windows e Linux.
Antes de começar, se você não estiver familiarizado com o Armazenamento Premium, leia primeiro os artigos
Selecionar um tipo de disco do Azure para VMs IaaS e Metas de escalabilidade para contas de Armazenamento
de Blobs de Páginas Premium.
Indicadores de desempenho de aplicativo

Avaliamos o desempenho de um aplicativo como bom ou ruim usando indicadores de desempenho como estes:
rapidez com que um aplicativo está processando uma solicitação de usuário, volume de dados que um
aplicativo está processando por solicitação, quantidade de solicitações que um aplicativo está processando em
um intervalo específico, quanto tempo um usuário precisa aguardar para obter uma resposta depois de enviar
uma solicitação. Os termos técnicos para esses indicadores de desempenho são IOPS, Taxa de Transferência ou
Largura de Banda e Latência.
Nesta seção, discutiremos os indicadores comuns de desempenho no contexto do Armazenamento Premium.
Na seção a seguir, Coletando os requisitos de aplicativo, você aprenderá como avaliar esses indicadores de
desempenho para seu aplicativo. Mais adiante, em Otimizando o desempenho do aplicativo, você saberá mais
sobre os fatores que afetam esses indicadores de desempenho e as recomendações para otimizá-los.
IOPS
O IOPS ou Operações de Entrada/Saída por Segundo é o número de solicitações que seu aplicativo está
enviando para os discos de armazenamento em um segundo. Uma operação de entrada/saída pode ser de
leitura ou gravação, sequencial ou aleatória. Os aplicativos OLTP (Processamento de Transações Online), como
um site varejista online, precisam processar muitas solicitações simultâneas de usuários instantaneamente. As
solicitações do usuário são transações de banco de dados com inserções e atualizações intensas, que o
aplicativo deve processar rapidamente. Desse modo, os aplicativos OLTP exigem IOPS bastante alta. Tais
aplicativos tratam milhões de solicitações de E/S aleatórias e pequenas. Se você tiver um aplicativo desse tipo,
será preciso projetar a infraestrutura do aplicativo para otimização de IOPS. Na seção posterior, Otimizando o
desempenho do aplicativo, vamos abordar em detalhes os fatores que devem ser considerados para obter IOPS
alta.
Quando você anexa um disco do armazenamento premium à sua VM de alta escala, o Azure provisiona um
número garantido de IOPS de acordo com a especificação do disco. Por exemplo, um disco P50 provisiona 7500
IOPS. Cada tamanho de VM de alta escala também tem um limite específico de IOPS que ela pode manter. Por
exemplo, uma VM GS5 Padrão tem um limite de 80.000 IOPS.
Produtividade
A taxa de transferência ou largura de banda é o volume de dados que o aplicativo está enviando aos discos de
armazenamento em um intervalo especificado. Se o aplicativo estiver executando operações de entrada/saída
com tamanhos grandes de unidade de E/S, ele exigirá uma taxa de transferência alta. Os aplicativos de data
warehouse tendem a emitir operações de alta verificação que acessam grandes partes de dados por vez e
geralmente executam operações em massa. Em outras palavras, esses aplicativos exigem uma taxa de
transferência mais alta. Caso você tenha um aplicativo desse tipo, será preciso projetar sua infraestrutura para
otimização da taxa de transferência. Na próxima seção, abordaremos em detalhes os fatores que você deve
ajustar para conseguir isso.
Quando você anexa um disco do armazenamento Premium a uma VM de alta escala, o Azure provisiona a taxa
de transferência de acordo com a especificação do disco. Por exemplo, um disco P50 provisiona taxas de
transferência de disco de 250 MB por segundo. Cada tamanho de VM de alta escala também tem um limite
específico de taxa de transferência que ela pode manter. Por exemplo, a VM GS5 padrão tem uma Taxa de
Transferência máxima de 2.000 MB por segundo.
Há uma relação entre a taxa de transferência e a IOPS, como mostrado na fórmula abaixo.
Portanto, é importante determinar os valores ideais de taxa de transferência e de IOPS que o aplicativo exige. Ao
tentar otimizar um deles, o outro também é afetado. Em uma seção mais adiante, Otimizando o desempenho do
aplicativo, abordaremos em mais detalhes como otimizar a IOPS e Taxa de Transferência.
Latency
A Latência é o tempo que leva para um aplicativo receber uma única solicitação, enviá-la aos discos de
armazenamento e enviar a resposta ao cliente. Essa é uma medida essencial do desempenho de um aplicativo,
além de IOPS e da Taxa de Transferência. A Latência de um disco do Armazenamento Premium é o tempo que se
leva para recuperar informações de uma solicitação e comunicá-la de volta ao aplicativo. O Armazenamento
Premium fornece baixas latências consistentes. Discos Premium são projetados para fornecer latências de dígito
único em milissegundos para a maioria das operações de E/S. Ao habilitar o cache do host ReadOnly nos discos
do Armazenamento Premium, você obtém latência de leitura mais baixa. Abordaremos o Cache de Disco em
mais detalhes na seção Otimizando o desempenho do aplicativo.
Quando você otimizar o aplicativo para obter IOPS e taxa de transferência mais altas, a latência do aplicativo
também será afetada. Após ajustar o desempenho do aplicativo, sempre avalie a latência dele pare evitar
comportamento inesperado de alta latência.
Estas operações de plano de controle em discos gerenciados podem envolver a movimentação do disco de um
local de armazenamento para outro. Isso é orquestrado por meio de cópia em segundo plano de dados que
pode levar várias horas para ser concluída, geralmente menor que 24 horas, dependendo da quantidade de
dados nos discos. Durante esse tempo seu aplicativo pode apresentar latência de leitura maior do que o normal
uma vez que as leituras podem ser redirecionadas para o local original e podem demorar para serem
concluídas. Não há nenhum impacto na latência de gravação durante esse período.
Atualize o tipo de armazenamento.
Desanexe e anexe um disco de uma VM para outra.
Crie um disco gerenciado com base em um VHD.
Crie um disco gerenciado com base em um instantâneo.
Converta uma VM de discos não gerenciados em discos gerenciados.
Lista de verificação de aplicativo de desempenho para discos

A primeira etapa na criação de aplicativos de alto desempenho executados no Armazenamento Premium do
Azure é entender os requisitos de desempenho do aplicativo. Depois de entender os requisitos de desempenho,
será possível otimizar o aplicativo para obter o desempenho ideal.
Na seção anterior, explicamos os indicadores comuns de desempenho: IOPS, taxa de transferência e latência.
Você deve identificar quais desses indicadores de desempenho são essenciais para o aplicativo proporcionar a
experiência desejada ao usuário. Por exemplo, a IOPS alta é mais importante para aplicativos OLTP que
processam milhões de transações em um segundo. Já a Taxa de Transferência alta é essencial para aplicativos de
data warehouse que processam grandes volumes de dados em um segundo. A Latência extremamente baixa é
essencial para aplicativos em tempo real, como sites de streaming de vídeo ao vivo.
Em seguida, avalie os requisitos de desempenho máximo do aplicativo durante todo o seu ciclo de vida. Use a
lista de verificação de exemplo como ponto de partida. Registre os requisitos de desempenho máximo durante
os períodos de carga de trabalho normais, de pico e fora do horário de expediente. Ao identificar os requisitos
para todos os níveis de cargas de trabalho, você poderá determinar o requisito de desempenho geral do
aplicativo. Por exemplo, a carga de trabalho normal de um site de comércio eletrônico serão as transações feitas
durante a maioria dos dias em um ano. A carga de trabalho de pico do site será composta das transações
atendidas no fim do ano ou em datas especiais. A carga de trabalho de pico geralmente ocorre por um tempo
limitado, mas pode exigir que o aplicativo seja dimensionado para duas ou três vezes de sua operação normal.
Descubra os requisitos de percentil 50, percentil 90 e percentil 99. Isso ajuda a filtrar as exceções nos requisitos
de desempenho e você pode concentrar seus esforços na otimização dos valores certos.
Lista de verificação dos requisitos de desempenho do aplicativo

REQ UISITO S DE
DESEM P EN H O P ERC EN T IL 50 P ERC EN T IL 90 P ERC EN T IL 99
Máx. Transações por

segundo
% de operações de Leitura
% de operações de
Gravação
% de operações Aleatórias
% de operações Sequenciais
Tamanho da solicitação de
E/S
Taxa de transferência média
Máx. Produtividade
Mín. Latency
Latência Média
Máx. CPU
CPU Média
Máx. Memória
Memória Média
Profundidade da Fila
NOTE
você deve considerar o dimensionamento desses números com base no futuro crescimento esperado do aplicativo. É uma
boa ideia planejar o crescimento antecipadamente, pois pode ser mais difícil alterar a infraestrutura para melhorar o
desempenho posteriormente.
Se você já tiver um aplicativo e deseja passar para o Armazenamento Premium, antes de qualquer coisa, crie a
lista de verificação acima para o aplicativo. Em seguida, crie um protótipo do aplicativo no Armazenamento
Premium e projete o aplicativo com base nas diretrizes descritas em Otimizando o desempenho do aplicativo
em uma seção posterior deste documento. O próximo artigo descreve as ferramentas podem ser usadas para
entender as medições de desempenho.
Contadores para avaliar requisitos de desempenho do aplicativo
A melhor maneira de avaliar os requisitos de desempenho do aplicativo é usando as ferramentas de
monitoramento de desempenho fornecidas pelo sistema operacional do servidor. Você pode usar o PerfMon
para Windows e iostat para Linux. Essas ferramentas capturam contadores correspondentes para cada medida
explicada na seção acima. Você deve capturar os valores desses contadores quando o aplicativo está executando
suas cargas de trabalho normais, de pico ou fora do expediente.
Os contadores do PerfMon estão disponíveis para processador, memória e cada disco lógico e físico do seu
servidor. Quando você usa discos do Armazenamento Premium com uma VM, os contadores de disco físico são
para cada disco do Armazenamento Premium e os contadores de disco lógico são para cada volume criado nos
discos do Armazenamento Premium. É preciso capturar os valores dos discos que hospedam a carga de
trabalho do aplicativo. Se houver um mapeamento de um para um entre os discos lógicos e físicos, você poderá
consultar os contadores de disco físico, caso contrário, consulte os contadores de disco lógico. No Linux, o
comando iostat gera um relatório de utilização de CPU e disco. O relatório de utilização de disco fornece
estatísticas por dispositivo físico ou partição. Se você tiver um servidor de banco de dados com seus dados e
registrados em discos separados, colete esses dados de ambos os discos. A tabela abaixo descreve contadores
de discos, processadores e memória:
C O N TA DO R DESC RIÇ Ã O P ERF M O N IO STAT
IOPS ou Transações por Número de solicitações de Leituras de Disco/s tps

segundo E/S emitidas para o disco de Gravações de Disco/s r/s
armazenamento por w/s
segundo.
Leituras e gravações de % de operações de Leitura e % de Tempo de Leitura de r/s

discos Gravação executadas no Disco w/s
disco. % de Tempo de Gravação
de Disco
Taxa de transferência Volume de dados lidos ou Bytes Lidos no Disco/s kB_read/s

gravados no disco por Bytes Gravados no Disco/s kB_wrtn/s
segundo.
Latência Tempo total para concluir Média por Segundo do await

uma solicitação de E/S no Disco/Leitura svctm
disco. Média por segundo do
disco/Gravação
Tamanho de E/S O tamanho das solicitações Média de Bytes do avgrq-sz

de E/S emitidas para os Disco/Leitura
discos de armazenamento. Média de Bytes do
Disco/Gravação
Profundidade da Fila Número de solicitações de Comprimento da fila atual avgqu-sz

E/S pendentes aguardando de disco
serem lidas ou gravadas no
disco de armazenamento.
IOPS Máxima Quantidade de memória % de Bytes Confirmados em Usar o vmstat

exigida para execução Uso
perfeita do aplicativo
IOPS Máxima Quantidade de CPU exigida % do Tempo do %util

para a execução perfeita do Processador
aplicativo
Saiba mais sobre o iostat e PerfMon.
Otimizar o desempenho do aplicativo

Os principais fatores que influenciam o desempenho de um aplicativo em execução no Armazenamento
Premium são nativos das solicitações de E/S, do tamanho da VM, do tamanho do disco, do número de discos, do
cache do disco, do multithreading e da profundidade da fila. Você pode controlar alguns desses fatores com
botões fornecidos pelo sistema. A maioria dos aplicativos talvez não apresente uma opção para alterar o
tamanho de E/S e a profundidade da fila diretamente. Por exemplo, se você estiver usando o SQL Server, não
será possível escolher a profundidade de fila e o tamanho de E/S. O SQL Server escolhe os valores ideais do
tamanho de E/S e da profundidade da fila para obter o melhor desempenho. É importante compreender os
efeitos de ambos os tipos de fator no desempenho do aplicativo para que você possa provisionar recursos
apropriados que atendam às necessidades de desempenho.
Ao longo desta seção, consulte a lista de verificação de requisitos de aplicativo que você criou para identificar
quanto você precisa para otimizar o desempenho do aplicativo. Com base nisso, você poderá determinar quais
fatores dessa seção será preciso ajustar. Para ver os efeitos de cada fator no desempenho do aplicativo, execute
os parâmetros de comparação na configuração do aplicativo. Consulte o artigo Parâmetros, vinculado ao final,
para ver as etapas para executar ferramentas comuns de comparação em VMs do Windows e do Linux.
Otimizar a IOPS, a taxa de transferência e a latência em segundos
A tabela abaixo resume os fatores de desempenho e as etapas necessárias para otimizar a IOPS, taxa de
transferência e latência. As seções a seguir deste resumo descreverão cada fator mais detalhadamente.
Para obter mais informações sobre tamanhos de VM e sobre IOPS, taxa de transferência e latência disponíveis
para cada tipo de VM, consulte tamanhos de máquinas virtuais no Azure.
IO P S TA XA DE T RA N SF ERÊN C IA L AT ÊN C IA
Cenário de exemplo Aplicativo OLTP corporativo Aplicativo de data Aplicativos quase em tempo
que exige taxa muito alta de warehouse corporativo que real que exigem respostas
transações por segundo. processa grandes volumes instantâneas às solicitações
de dados. de usuário, como jogos
online.
Fatores de desempenho
Tamanho de E/S E/S menores geram IOPS E/S maiores geram Taxa de
mais altas. Transferência mais altas.
Tamanho da VM Use um tamanho de VM Use um tamanho de VM Use um tamanho de VM

que ofereça IOPS maior que com limite de Taxa de que ofereça limites de
o requisito do seu Transferência maior que o escala maiores que o
aplicativo. requisito do seu aplicativo. requisito do seu aplicativo.
Tamanho do disco Use um tamanho de disco Use um tamanho de disco Use um tamanho de disco
que ofereça IOPS maior que com limite de Taxa de que ofereça limites de
o requisito de seu Transferência maior que o escala maiores que o
aplicativo. requisito do seu aplicativo. requisito do seu aplicativo.
Limites de escala de VM O limite de IOPS do O limite de Taxa de Os limites de escala do

e disco tamanho da VM escolhido Transferência do tamanho tamanho da VM escolhido
deve ser maior que o total da VM escolhido deve ser devem ser maiores que o
de IOPS impulsionado pelos maior que o total de Taxa total de limites de escala de
discos do armazenamento de Transferência discos do Armazenamento
anexados a ela. impulsionado pelos discos Premium anexados.
do Armazenamento
Premium anexados a ela.
Cache de disco Habilite o Cache ReadOnly Habilite o Cache ReadOnly

nos discos do nos discos do
Armazenamento Premium Armazenamento Premium
com operações pesadas de com operações pesadas de
leitura para obter IOPS mais leitura para obter latências
alta de leitura. de leitura bem baixas.
Distribuição de disco Use vários discos e

distribua-os em conjunto
para obter um limite
combinado mais alto de
IOPS e Taxa de
Transferência. O limite
combinado por VM deve
ser maior do que os limites
combinados de discos
premium anexados.
Tamanho da distribuição Tamanho menor de Tamanho maior de

distribuição para padrão distribuição para padrão
pequeno de E/S aleatório grande de E/S sequencial
visto em aplicativos OLTP. visto em aplicativos de data
Por exemplo, use o warehouse. Por exemplo,
tamanho de distribuição de use o tamanho de
64 KB para aplicativo OLTP distribuição de 256 KB para
do SQL Server. aplicativo de data
warehouse do SQL Server.
Multithread Use multithreading para

enviar por push números
maiores de solicitações ao
Armazenamento Premium
que levarão à IOPS e Taxa
de Transferência mais altas.
Por exemplo, no SQL Server,
defina um valor MAXDOP
alto para alocar mais CPUs
para o SQL Server.
Profundidade da Fila Profundidade da fila maior Uma Profundidade da Fila Profundidade da fila menor
gera IOPS mais alta. maior gera uma Taxa de gera latências mais baixas.
Transferência mais alta.
Natureza das solicitações de E/S

Uma solicitação de E/S é uma unidade da operação de entrada/saída que seu aplicativo executará. Identificar a
natureza das solicitações de E/S, aleatória ou sequencial, leitura ou gravação, grande ou pequena, ajudará você a
determinar os requisitos de desempenho do aplicativo. É importante entender a natureza das solicitações de E/S
para tomar das decisões certas ao projetar a infraestrutura do aplicativo. O IOs deve ser distribuído
uniformemente para obter o melhor desempenho possível.
O tamanho de E/S é um dos fatores mais importantes. O tamanho de E/S é o tamanho da solicitação de
operação de entrada/saída gerada pelo aplicativo. O tamanho de E/S tem um impacto significativo no
desempenho, especificamente na IOPS e na largura de banda que o aplicativo é capaz de atingir. A fórmula a
seguir mostra a relação entre IOPS, tamanho de E/S e Largura de Banda/Taxa de Transferência.
Alguns aplicativos permitem a você alterar o tamanho de E/S, enquanto outros aplicativos, não. Por exemplo, o
SQL Server determina por si só o tamanho ideal de E/S e não fornece aos usuários nenhum botão para alterá-
lo. Por outro lado, o Oracle oferece um parâmetro chamado DB_BLOCK_SIZE com o qual você pode configurar o
tamanho da solicitação de E/S do banco de dados.
Se estiver usando um aplicativo que não permite alterar o tamanho de E/S, use as diretrizes neste artigo para
otimizar o KPI de desempenho que é mais relevante para o aplicativo. Por exemplo,
Um aplicativo OLTP gera milhões de solicitações de E/S pequenas e aleatórias. Para lidar com esses tipos de
solicitação de E/S, você deve projetar a infraestrutura do aplicativo para obter IOPS mais alta.
Um aplicativo de data warehouse gera solicitações de E/S grandes e sequenciais. Para lidar com esses tipos
de solicitação de E/S, você deve projetar a infraestrutura do aplicativo para obter Largura de Banda ou Taxa
de Transferência mais alta.
Se estiver usando um aplicativo que permita alterar o tamanho de E/S, use esta regra prática para o tamanho de
E/S além de outras diretrizes de desempenho:
Tamanho menor de E/S para obter IOPS mais alta. Por exemplo, 8 KB para um aplicativo OLTP.
Tamanho maior de E/S para obter largura de banda/Taxa de Transferência mais alta. Por exemplo, 1024 KB
para um aplicativo de data warehouse.
Veja um exemplo de como é possível calcular a IOPS e a Taxa de Transferência/largura de banda do seu
aplicativo. Considere um aplicativo usando um disco P30. A IOPS e a Taxa de Transferência/largura de banda
máximas que um disco P30 pode atingir é de 5.000 IOPS e 200 MB por segundo, respectivamente. Agora, se seu
aplicativo exigir a IOPS máxima do disco P30 e você usar um tamanho de E/S menor, como 8 KB, a largura de
banda resultante que você poderá obter será de 40 MB por segundo. No entanto, se seu aplicativo exigir a Taxa
de Transferência/largura de banda máxima do disco P30 e você usar um tamanho de E/S maior, como 1024 KB,
a IOPS resultante será menor, 200 IOPS. Sendo assim, ajuste o tamanho de E/S, de tal modo que ele atenda aos
requisitos de IOPS e Taxa de Transferência/Largura de Banda do aplicativo. A tabela abaixo resume os diferentes
tamanhos de E/S e a IOPS e a Taxa de Transferência correspondentes para um disco P30.
TA XA DE
T RA N SF ERÊN C IA / L A RGURA
REQ UISITO DE A P L IC AT IVO TA M A N H O DE E/ S IO P S DE B A N DA
IOPS Máxima 8 KB 5.000 40 MB por segundo
Taxa de Transferência 1024 KB 200 200 MB por segundo

Máxima
Taxa de Transferência 64 KB 3.200 200 MB por segundo

Máxima + IOPS alta
IOPS máxima + Taxa de 32 KB 5.000 160 MB por segundo

Transferência alta
Para obter IOPS e Largura de Banda mais altas do que o valor máximo de um único disco do Armazenamento
Premium, use vários discos premium distribuídos em conjunto. Por exemplo, distribua dois discos P30 para
obter uma IOPS de 10.000 IOPS ou um combinado de Taxa de Transferência de 400 MB por segundo. Como
explicado na próxima seção, você deve usar um tamanho de VM que ofereça suporte à IOPS e à Taxa de
Transferência de disco combinado.
NOTE
À medida que você aumenta a IOPS ou a Taxa de Transferência, a outra também aumenta. Fique dentro dos limites de
Taxa de Transferência ou de IOPS do disco ou da VM ao aumentar uma das duas.
Para ver os efeitos do tamanho de E/S no desempenho do aplicativo, você pode executar ferramentas de
parâmetros comparação na VM e nos discos. Crie várias execuções de teste e use diferentes tamanhos de E/S
para cada execução a fim de ver o impacto. Consulte o artigo Parâmetros de comparação, vinculado ao final,
para obter mais detalhes.
Tamanhos de VM de alta escala

Quando você começa a criar um aplicativo, uma das primeiras tarefas é escolher uma VM para hospedar o
aplicativo. O Armazenamento Premium surge com os tamanhos de VM de alta escala que podem executar
aplicativos que exigem potência mais alta de computação e um alto desempenho de E/S do disco local. Essas
VMs fornecem processadores mais rápidos, uma taxa mais alta de memória para núcleo e uma SSD (unidade de
estado sólido) para o disco local. Exemplos de VMs de alta escala que dão suporte ao Armazenamento Premium
são as VMs das séries DS e GS.
As VMs de alta escala estão disponíveis em diferentes tamanhos com diferentes números de núcleos de CPU,
memória, sistema operacional e tamanho de disco temporário. Cada tamanho de VM também tem um número
máximo de discos de dados que você pode anexar à VM. Sendo assim, o tamanho de VM escolhido afetará a
quantidade de capacidade de armazenamento, processamento e memória disponível para o aplicativo. Ele
também afeta o custo da computação e do armazenamento. Por exemplo, abaixo estão as especificações do
maior tamanho de VM em uma série DS e uma GS:
L IM IT ES DE
E/ S DO
TA M A N H O M Á X. DE C A C H E DA
TA M A N H O N ÚC L EO S S DE DISC O DISC O S DE TA M A N H O L A RGURA
DA VM DE C P U M EM Ó RIA DA VM DA DO S DO C A C H E IO P S DE B A N DA
Standard_D 16 112 GB SO = 1023 32 576 GB 50.000 4.000 IOPS

S14 GB IOPS e 33 MB
SSD local = 512 MB por
224 GB por segundo
segundo
Standard_G 32 448 GB SO = 1023 64 4224 GB 80.000 5.000 IOPS

S5 GB IOPS e 50 MB
SSD local = 2.000 MB por
896 GB por segundo
segundo
Para exibir uma lista completa de todos os tamanhos de VM do Azure disponíveis, consulte tamanhos de
máquinas virtuais no Azure ou. Escolha um tamanho de VM que possa atender aos requisitos de desempenho
de aplicativo desejados. Além disso, leve em consideração as seguintes considerações importantes ao escolher
tamanhos de VM.
Limites de Escala
Os limites máximos de IOPS por VM e por disco são diferentes e independentes um do outro. Verifique se o
aplicativo está impulsionando a IOPS dentro dos limites da VM, bem como os discos premium anexados a ela.
Caso contrário, o desempenho do aplicativo será limitado.
Por exemplo, suponha que o requisito de um aplicativo seja de 4.000 IOPS. Para chegar a isso, você provisiona
um disco P30 em uma VM DS1. O disco P30 pode oferecer até 5.000 IOPS. No entanto, a VM DS1 é limitada a
3.200 IOPS. Consequentemente, o desempenho do aplicativo será restrito pelo limite da VM de 3.200 IOPS e
haverá degradação do desempenho. Para evitar essa situação, escolha um tamanho de disco e VM que atenda
aos requisitos do aplicativo.
Custo da operação
Em muitos casos, é possível que o custo geral de operação usando o Armazenamento Premium seja menor do
que usando o Armazenamento Padrão.
Por exemplo, considere um aplicativo que exija 16.000 IOPS. Para atingir esse desempenho, você precisará de
uma VM de IaaS Standard_D14 do Azure que possa fornecer um máximo de 16.000 IOPS usando 32 discos de
armazenamento padrão de 1 TB. Cada disco de armazenamento padrão de 1 TB pode atingir um máximo de
500 IOPS. O custo estimado dessa VM por mês será de US$ 1.570. O custo mensal de 32 discos de
armazenamento padrão será de US$ 1.638. O custo mensal total estimado será de US$ 3.208.
No entanto, se você tiver hospedado o mesmo aplicativo no Armazenamento Premium, será preciso uma VM
menor e menos discos de Armazenamento Premium, reduzindo, assim, o custo geral. Uma VM Standard_DS13
pode atender ao requisito de 16.000 IOPS usando quatro discos P30. A VM DS13 tem um máximo de 25.600
IOPS e cada disco P30 tem um máximo de 5.000 IOPS. Em geral, essa configuração pode alcançar 5.000 x 4 =
20.000 IOPS. O custo estimado dessa VM por mês será de US$ 1.003. O custo mensal de quatro discos P30 de
armazenamento premium será de US$ 544,34. O custo total mensal estimado será de US$ 1.544.
A tabela abaixo resume o detalhamento do custo desse cenário para Armazenamento Premium e Standard.
STA N DA RD P REM IUM
Custo de VM por mês US$ 1.570,58 (Standard_D14) US$ 1.003,66 (Standard_DS13)

STA N DA RD P REM IUM
Custo de discos por mês US$ 1.638,40 (32 discos x 1 TB) US$ 544,34 (4 discos x P30)
Custo geral por mês US$ 3.208,98 US$ 1.544,34
Distribuições do Linux
Com o Armazenamento Premium do Azure, você obtém o mesmo nível de Desempenho para VMs que
executam Windows e Linux. Há suporte para vários tipos de distribuição Linux, e você pode ver a lista completa
aqui. É importante observar que as diferentes distribuições são mais adequadas para tipos diferentes de carga
de trabalho. Você verá diferentes níveis de desempenho dependendo da distribuição em que a carga de trabalho
está sendo executada. Teste as distribuições Linux com seu aplicativo e escolha a mais adequada.
Ao executar Linux com Armazenamento Premium, verifique as últimas atualizações dos drivers necessários para
garantir alto desempenho.
Tamanhos de disco do armazenamento Premium

O Armazenamento Premium do Azure oferece uma variedade de tamanhos para que você possa escolher um
que melhor atenda às suas necessidades. Cada tamanho de disco tem um limite de escala diferente para IOPS,
largura de banda e armazenamento. Escolha o tamanho certo do disco do Armazenamento Premium de acordo
com os requisitos do aplicativo e o tamanho da VM de alta escala. A tabela abaixo mostra os três tamanhos de
disco e seus recursos. Atualmente, os tamanhos de disco 4, P6, P15, P60, P70, e P80 têm suporte apenas para o
Managed Disks.
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Tam 4 8 16 32 64 128 256 512 1.0 2.0 4.0 8.1 16. 32.
anh 24 48 96 92 384 767
o
do
disc
o
em
GiB
IOP 120 120 120 120 240 500 1.1 2.3 5.0 7.5 7.5 16. 18. 20,
S 00 00 00 00 00 000 000 000
pro
visi
ona
da
por
disc
o
Taxa 25 25 25 25 50 100 125 150 200 250 250 500 750 900
sfer
ênci
a
pro
visi
ona
da
por
disc
o
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Má 3.5 3.5 3.5 3.5 3.5 3.5 3.5 3.5

xim 00 00 00 00 00 00 00 00
o
de
IOP
S
de
inte
rmit
ênci
a
por
disc
o
Taxa 170 170 170 170 170 170 170 170

sfer
ênci
a
de
inte
rmit
ênci
a
máx
ima
por
disc
o
Dur 30 30 30 30 30 30 30 30
o
máx
ima
da
inte
rmit
ênci
a
par
a
rese
rva
Quantos discos você escolhe depende do tamanho do disco escolhido. Você pode usar um único disco P50 ou
vários discos P10 para atender aos requisitos do aplicativo. Leve em conta as considerações listadas abaixo ao
fazer sua escolha.
Limites de Escala (IOPS e Taxa de Transferência)
Os limites de IOPS e Taxa de Transferência de cada tamanho de disco Premium são diferentes e independentes
dos limites de escala da VM. Verifique se o total de IOPS e Taxa de Transferência dos discos estão dentro dos
limites de escala do tamanho escolhido de VM.
Por exemplo, se o requisito de um aplicativo for de, no máximo, 250 MB/s de Taxa de Transferência e você
estiver usando uma VM DS4 com um único disco P30. A VM DS4 pode fornecer uma Taxa de Transferência de
256 MB/s. No entanto, um único disco P30 tem o Limite de taxa de transferência de 200 MB/s.
Consequentemente, o aplicativo será limitado a 200 MB/s, devido ao limite do disco. Para superar esse limite,
provisione mais de um disco de dados à VM ou redimensione seus discos para P40 ou P50.
NOTE
as leituras atendidas pelo cache não estão incluídas na IOPS e Taxa de Transferência do disco, portanto, não estão sujeitas
aos limites de disco. O cache tem seu limite de IOPS e Taxa de Transferência separado por VM.
Por exemplo, inicialmente as leituras e gravações são de 60 MB/s e 40 MB/s, respectivamente. Ao longo do tempo, o
cache aquece e atende cada vez mais leituras no cache. Assim, você pode obter Taxa de Transferência de gravação mais
alta do disco.
Número de discos
Determine o número de discos que você precisará ao avaliar os requisitos de aplicativo. Cada tamanho de VM
também tem um limite de número de discos que você pode anexar à VM. Normalmente, é duas vezes o número
de núcleos. Verifique se o tamanho de VM que você escolheu pode oferecer suporte ao número de discos
necessário.
Lembre-se de que os discos do Armazenamento Premium têm recursos de desempenho mais alto comparados
aos discos do Armazenamento Padrão. Portanto, se estiver migrando seu aplicativo da VM de IaaS do Azure
usando Armazenamento Padrão para Armazenamento Premium, provavelmente você precisará de poucos
discos premium para atingir o mesmo desempenho ou mais alto para seu aplicativo.
Cache de disco
As VMs de alta escala que aproveitam o Armazenamento Premium do Azure têm uma tecnologia de cache de
várias camadas chamada BlobCache. O BlobCache usa uma combinação de RAM do host e SSD local para cache.
Esse cache está disponível para os discos persistentes do Armazenamento Premium e os discos locais da VM.
Por padrão, essa configuração de cache é definida como Leitura/Gravação para discos do SO e ReadOnly para
discos de dados hospedados no Armazenamento Premium. Com o cache de disco habilitado nos discos do
Armazenamento Premium, as VMs de alta escala podem atingir níveis extremamente altos de desempenho que
excedem o desempenho do disco subjacente.
WARNING
O cache de disco não tem suporte para discos 4 TiB e maiores. Se vários discos estiverem anexados à sua VM, cada disco
com menos de 4 TiB dará suporte ao cache.
Alterar a configuração de cache de um disco do Azure desanexa e anexa novamente o disco de destino. Se for o disco do
sistema operacional, a VM será reiniciada. Pare todos os aplicativos/serviços que podem ser afetados por essa interrupção
antes de alterar a configuração de cache do disco. Não seguir essas recomendações pode gerar dados corrompidos.
Para saber mais sobre como o BlobCache funciona, consulte a postagem do blog interno Armazenamento
Premium do Azure .
É importante habilitar o cache no conjunto certo de discos. Se você deve habilitar o cache de disco em um disco
premium ou não dependerá do padrão da carga de trabalho que o disco manipulará. A tabela abaixo mostra as
configurações padrão de cache para sistema operacional e discos de dados.
T IP O DE DISC O C O N F IGURA Ç Ã O PA DRÃ O DE C A C H E
Disco do sistema operacional ReadWrite
Disco de dados ReadOnly
Veja a seguir as configurações recomendadas de cache de disco para discos de dados:
REC O M EN DA Ç Ã O SO B RE Q UA N DO USA R ESSA

C O N F IGURA Ç Ã O DO C A C H E DE DISC O C O N F IGURA Ç Ã O
Nenhum Configure o cache do host como None para discos de

gravação pesada e somente gravação.
ReadOnly Configure o cache do host como ReadOnly para discos de

leitura/gravação e somente leitura.
ReadWrite Configure o cache do host como ReadWrite somente se o

aplicativo tratar adequadamente a gravação de dados em
cache em discos persistentes quando necessário.
ReadOnly (somente-leitura)
Ao configurar o cache ReadOnly em discos de dados do Armazenamento Premium, você pode obter baixa
latência de leitura e IOPS de leitura e Taxa de Transferência muito altas para seu aplicativo. Isso se deve a dois
motivos:
1. As leituras executadas no cache, que está na memória da VM e na SSD local, são muito mais rápidas do que
as leituras no disco de dados, que está no armazenamento blob do Azure.
2. O Armazenamento Premium não conta as leituras atendidas no cache para IOPS e Taxa de Transferência do
disco. Portanto, o aplicativo é capaz de atingir um total mais alto de IOPS e Taxa de Transferência.
ReadWrite
Por padrão, os discos do sistema operacional têm o cache ReadWrite habilitado. Recentemente, adicionamos
suporte ao cache ReadWrite também nos discos de dados. Se estiver usando o cache ReadWrite, você deverá ter
uma maneira adequada de gravar os dados do cache nos discos persistentes. Por exemplo, o SQL Server
manipula a gravação de dados em cache nos discos de armazenamento persistentes por sua própria conta. Usar
o cache ReadWrite com um aplicativo que não manipule a persistência dos dados necessários pode levar à
perda de dados no caso de falha da VM.
Nenhuma
Atualmente, Nenhum só tem suporte em discos de dados. Ela não tem suporte nos discos do sistema
operacional. Se você definir Nenhum em um disco do sistema operacional, ele substituirá isso internamente e o
definirá como ReadOnly .
Por exemplo, você pode aplicar essas diretrizes ao SQL Server em execução no Armazenamento Premium
seguindo estes passos.
1. Configure o cache "ReadOnly" em discos do Armazenamento Premium que hospedam arquivos de dados.
a. A leitura rápida no cache reduz o tempo de consulta do SQL Server, uma vez que as páginas de dados são
recuperadas muito mais rapidamente do cache do que diretamente dos discos de dados.
b. Atender às leituras no cache, significa que há Taxa de Transferência adicional disponível nos discos de
dados premium. O SQL Server pode usar essa Taxa de Transferência adicional para recuperar mais páginas
de dados e outras operações, como backup/restauração, cargas em lote e recriações de índice.
2. Configure o cache "None" nos discos do Armazenamento Premium que hospedam os arquivos de log.
a. Os arquivos de log têm basicamente operações pesadas de gravação. Sendo assim, eles não se beneficiam
do cache ReadOnly.
Otimizar o desempenho em VMs Linux

Para todos os SSDs ou ultra discos Premium, você poderá desabilitar "barreiras" para sistemas de arquivos no
disco, a fim de melhorar o desempenho quando for conhecido que não haja caches que possam perder dados.
Se o cache de disco do Azure estiver definido como ReadOnly ou None, você poderá desabilitar as barreiras. Mas
se o Caching estiver definido como ReadWrite, as barreiras deverão permanecer habilitadas para garantir a
durabilidade da gravação. As barreiras são geralmente habilitadas por padrão, mas você pode desabilitar as
barreiras usando um dos seguintes métodos, dependendo do tipo de sistema de arquivos:
Para reiserFS , use a opção de montagem barreira = nenhum para desabilitar as barreiras. Para habilitar as
barreiras explicitamente, use barreira = liberação.
Para ext3/ext4 , use a opção de montagem barreira = 0 para desabilitar as barreiras. Para habilitar as
barreiras explicitamente, use a barreira = 1.
Para xfs , use a opção de montagem nobarreira para desabilitar as barreiras. Para habilitar as barreiras
explicitamente, use a barreira. Observe que nas versões posteriores do kernel do Linux, o design do sistema
de arquivos XFS sempre garante a durabilidade, e desabilitar as barreiras não tem nenhum efeito.
Distribuição de discos
Quando uma VM de alta escala é anexada aos vários discos persistentes do Armazenamento Premium, os discos
podem ser divididos em conjunto para agregar a respectiva capacidade de armazenamento, IOPS e largura de
banda.
No Windows, você pode usar Espaços de Armazenamento para dividir discos em conjunto. É preciso configurar
uma coluna para cada disco em um pool. Caso contrário, o desempenho geral do volume distribuído poderá ser
menor que o esperado devido a uma distribuição irregular do tráfego entre os discos.
Importante: Usando a interface de usuário do Gerenciador do Servidor UI, você pode definir o número total de
colunas até 8 para um volume distribuído. Ao anexar mais de oito discos, use o PowerShell para criar o volume.
Usando o PowerShell, é possível definir o número de colunas como igual ao número de discos. Por exemplo, se
houver 16 discos em um único conjunto de distribuição; especifique 16 colunas no parâmetro
NumberOfColumns do cmdlet New-VirtualDisk do PowerShell.
No Linux, use o utilitário MDADM para distribuir os discos em conjunto. Para ver etapas detalhadas sobre como
distribuir discos no Linux, consulte Configurar o Software RAID no Linux.
Tamanho da distribuição
Uma configuração importante na distribuição de disco é o tamanho dela. O tamanho da distribuição ou
tamanho do bloco é a menor parte de dados que o aplicativo pode incluir em um volume distribuído. O
tamanho da distribuição que você configura depende do tipo de aplicativo e de seu padrão de solicitação. Se
você escolher o tamanho de distribuição errado, isso pode levar ao alinhamento incorreto de E/S, o que leva à
degradação de desempenho do aplicativo.
Por exemplo, se uma solicitação de E/S gerada pelo seu aplicativo for maior que o tamanho da distribuição do
disco, o sistema de armazenamento a gravará entre limites de unidade de distribuição em mais de um disco.
Quando for a hora de acessar esses dados, ele terá que procurar em mais de uma unidade de distribuição para
concluir a solicitação. O efeito cumulativo de tal comportamento pode levar à degradação substancial de
desempenho. Por outro lado, se o tamanho da solicitação de E/S for menor que o tamanho da distribuição e se
ela for de natureza aleatória, as solicitações de E/S poderão ser adicionadas no mesmo disco, causando um
gargalo e, por fim, a degradação do desempenho de E/S.
De acordo com o tipo de carga de trabalho que o aplicativo está executando, escolha um tamanho de
distribuição apropriado. Para solicitações pequenas e aleatórias de E/S, use um tamanho de distribuição menor.
Já para solicitações de E/S grandes e sequenciais, use um tamanho de distribuição maior. Descubra as
recomendações de tamanho de distribuição para o aplicativo que será executado no Armazenamento Premium.
Para SQL Server, configure o tamanho da distribuição de 64 KB para cargas de trabalho OLTP e 256 KB para
cargas de trabalho de data warehouse. Confira Melhores práticas de desempenho para o SQL Server em VMs
do Azure para saber mais.
NOTE
você pode usar a distribuição com um máximo de 32 discos do armazenamento premium em uma VM série DS e 64
discos do armazenamento premium em uma VM série GS.
Multithreading
O Azure projetou a plataforma Armazenamento Premium para ser extremamente paralela. Portanto, um
aplicativo com multithread atinge desempenho muito mais alto que um aplicativo de único thread. Um
aplicativo com multithread divide as tarefas entre vários threads e aumenta a eficiência de sua execução ao
utilizar ao máximo os recursos de VM e disco.
Por exemplo, se o aplicativo estiver em execução em uma VM de único núcleo usando dois threads, a CPU
poderá alternar entre os dois threads para obter eficiência. Enquanto um thread está aguardando em um disco
que a E/S seja concluída, a CPU pode alternar para o outro thread. Dessa forma, dois threads podem fazer mais
do que um único thread. Se a VM tiver mais de um núcleo, ela diminui ainda mais o tempo de execução, uma
vez que cada núcleo pode executar tarefas paralelamente.
Você não poderá alterar a forma como um aplicativo pronto para uso implementa único thread ou
multithreading. Por exemplo, o SQL Server é capaz de lidar com várias CPUs e vários núcleos. No entanto, o SQL
Server decide sob quais condições ele utilizará um ou mais threads para processar uma consulta. Ele pode
executar consultas e criar índices usando multithreading. Para uma consulta que envolva união de tabelas
grandes e classificação de dados antes do retorno ao usuário, o SQL Server provavelmente usará vários threads.
No entanto, um usuário não pode controlar se o SQL Server executará uma consulta usando um único thread
ou vários threads.
Há definições de configuração que você pode alterar para influenciar esse multithreading ou processamento
paralelo de um aplicativo. Por exemplo, no caso do SQL Server, ele é a configuração máxima do grau de
paralelismo. Essa configuração chamada MAXDOP, permite que você configure o número máximo de
processadores que o SQL Server pode usar no processamento paralelo. É possível configurar MAXDOP para
consultas individuais ou operações de índice. Isso é benéfico quando você deseja equilibrar recursos do sistema
para um aplicativo crítico de desempenho.
Por exemplo, digamos que seu aplicativo que usa SQL Server está executando uma consulta grande e uma
operação de índice ao mesmo tempo. Vamos supor que você gostaria que a operação de índice tivesse um
desempenho melhor do que a consulta grande. Nesse caso, você pode definir o valor MAXDOP da operação de
índice para que seja maior que o valor MAXDOP da consulta. Dessa forma, o SQL Server tem maior número de
processadores que pode aproveitar para a operação de índice em comparação ao número de processadores que
pode dedicar à consulta grande. Lembre-se de que você não controla o número de threads que o SQL Server
usará para cada operação. É possível controlar o número máximo de processadores que está sendo dedicado ao
multithreading.
Saiba mais sobre Graus de Paralelismo no SQL Server. Descubra as configurações que influenciam o
multithreading em seu aplicativo e as respectivas configurações para otimizar o desempenho.
Profundidade da fila
A profundidade da fila, comprimento da fila ou tamanho da fila é o número de solicitações de E/S pendentes no
sistema. O valor da profundidade da fila determina quantas operações de E/S o aplicativo pode alinhar, as quais
os discos de armazenamento processarão. Isso afeta os três indicadores de desempenho de aplicativo que
abordamos neste artigo: IOPS, taxa de transferência e latência.
A profundidade da fila e o multithreading estão intimamente relacionados. O valor de profundidade da fila
indica quanto multithreading pode ser obtido pelo aplicativo. Se a profundidade da fila for grande, o aplicativo
poderá executar mais operações simultaneamente. Em outras palavras, mais multithreading. Se a profundidade
da fila for pequena, mesmo que o aplicativo esteja com multithread, ele não terá solicitações suficientes
alinhadas para execução simultânea.
Normalmente, aplicativos prontos para uso não permitem que você altere a profundidade da fila, pois se
definida incorretamente, fará mais mal do que bem. Os aplicativos definirão o valor correto da profundidade da
fila para obter o desempenho ideal. No entanto, é importante compreender esse conceito para que você possa
solucionar problemas de desempenho com seu aplicativo. Também é possível observar os efeitos da
profundidade da fila executando ferramentas de parâmetros de comparação no sistema.
Alguns aplicativos fornecem configurações para influenciar a profundidade da fila. Por exemplo, a configuração
MAXDOP (grau máximo de paralelismo) do SQL Server explicada na seção anterior. MAXDOP é uma forma de
influenciar a profundidade da fila e o multithreading, embora isso não altere diretamente o valor da
profundidade da fila do SQL Server.
Profundidade alta de fila
Uma profundidade alta de fila alinha mais operações no disco. O disco sabe da próxima solicitação na fila
antecipadamente. Consequentemente, o disco pode agendar operações com antecedência e processá-las em
uma sequência ideal. Uma vez que o aplicativo está enviando mais solicitações ao disco, este pode processar
mais E/S paralelamente. No fim, o aplicativo poderá atingir IOPS mais alta. Uma vez que o aplicativo está
processando mais solicitações, a Taxa de Transferência total do aplicativo também aumenta.
Normalmente, um aplicativo pode atingir a taxa máxima de transferência com 8 a pouco mais de 16 E/S
pendentes por disco anexado. Se a profundidade de fila for um, o aplicativo não está enviando E/S suficiente ao
sistema, e ele processará menos quantidade em um determinado período. Em outras palavras, Taxa de
Transferência menor.
Por exemplo, no SQL Server, configurar o valor MAXDOP de uma consulta para "4" informa ao SQL Server que
ele pode usar até quatro núcleos para executar a consulta. O SQL Server determinará qual é o melhor valor de
profundidade de fila e o número de núcleos para a execução da consulta.
Profundidade ideal de fila
Um valor muito alto de profundidade de fila também tem suas desvantagens. Se o valor de profundidade da fila
for muito alto, o aplicativo tentará impulsionar uma IOPS muito alta. A menos que o aplicativo tenha discos
persistentes com provisão suficiente de IOPS, isso pode afetar negativamente as latências do aplicativo. A
fórmula a seguir mostra a relação entre a IOPS, a latência e a profundidade da fila.
Você não deve configurar a profundidade da fila para algum valor alto, mas para um valor ideal, o que pode
fornecer IOPS suficiente ao aplicativo sem afetar as latências. Por exemplo, se a latência do aplicativo precisa ser
de 1 milissegundo, a profundidade da fila necessária para alcançar 5.000 IOPS será, QD = 5000 x 0,001 = 5.
Profundidade da fila para volume distribuído
Para um volume distribuído, mantenha uma profundidade de fila alta o suficiente, de tal forma que cada disco
tenha uma profundidade de fila de pico individualmente. Por exemplo, considere um aplicativo que envia uma
profundidade de fila de dois e tenha quatro discos na distribuição. As duas solicitações de E/S vão para os dois
discos e os dois discos restantes ficarão ociosos. Sendo assim, configure a profundidade da fila para que todos
os discos possam estar ocupados. A fórmula abaixo mostra como determinar a profundidade da fila de volumes
distribuídos.
Limitação
O Armazenamento Premium do Azure provisiona um número especificado de IOPS e Taxa de Transferência,
dependendo dos tamanhos da VM e do disco que você escolhe. Sempre que o aplicativo tentar impulsionar
IOPS ou Taxa de Transferência acima desses limites com os quais a VM ou o disco podem lidar, o
Armazenamento Premium será restrito. Isso se manifesta na forma de degradação de desempenho do
aplicativo. Isso pode significar latência mais alta, Taxa de Transferência mais baixa ou IOPS mais baixa. Se o
Armazenamento Premium não for restrito, o aplicativo poderá falhar completamente, excedendo o que seus
recursos são capazes de alcançar. Portanto, para evitar problemas de desempenho devido à limitação, sempre
provisione recursos suficientes ao aplicativo. Leve em consideração o que abordamos nas seções acima sobre
tamanhos de disco e VM Os parâmetros de comparação são a melhor maneira de entender de quais recursos
você precisará para hospedar o aplicativo.
Próximas etapas
Se você pretende avaliar o benchmark de seu disco, consulte nossos artigos sobre benchmarking de um disco:
Para o Linux: avaliar o aplicativo no armazenamento em disco do Azure
Para Windows: benchmarking de um disco.
Saiba mais sobre os tipos de disco disponíveis:
Para Linux: Selecione um tipo de disco
Para Windows: Selecione um tipo de disco
Para usuários do SQL Server, leia os artigos sobre Práticas recomendadas de desempenho para o SQL Server:
Práticas recomendadas para o SQL Server em Máquinas Virtuais do Azure
Armazenamento Premium do Azure fornece desempenho mais alto para SQL Server na VM do Azure
Métricas de desempenho de disco
O Azure oferece métricas no portal do Azure que fornecem informações sobre como as máquinas virtuais (VM)
e os discos são executados. As métricas também podem ser recuperadas por meio de uma chamada à API. Este
artigo é dividido em três subseções:
Métricas de e/s de disco, produtividade e profundidade de fila -essas métricas permitem que você
veja o desempenho do armazenamento da perspectiva de um disco e de uma máquina virtual.
Métricas de intermitência de disco -essas são as métricas fornecem a observação sobre nosso recurso
de disparo em nossos discos Premium.
Métricas de utilização de e/s de armazenamento -essas métricas ajudam a diagnosticar afunilamentos
em seu desempenho de armazenamento com discos.
Todas as métricas são emitidas a cada minuto, exceto pela métrica de porcentagem de crédito de intermitência,
emitida a cada 5 minutos.
Métricas de e/s de disco, produtividade e profundidade de fila

As métricas a seguir estão disponíveis para obter informações sobre a VM e a e/s de disco, taxa de transferência
e desempenho de profundidade de fila:
Profundidade da fila de disco do so : o número de solicitações de e/s pendentes atuais que estão
aguardando para serem lidas ou gravadas no disco do sistema operacional.
Bytes de leitura do disco do so/s : o número de bytes lidos em um segundo do disco do sistema
operacional.
Operações de leitura de disco do so/s : o número de operações de entrada que são lidas em um
segundo do disco do sistema operacional.
Bytes de gravação de disco do sistema operacional/s : o número de bytes gravados em um segundo
do disco do sistema operacional.
Operações de gravação de disco do so/s : o número de operações de saída que são gravadas em um
segundo do disco do sistema operacional.
Profundidade da fila do disco de dados : o número de solicitações de e/s pendentes atuais que estão
aguardando para serem lidas ou gravadas nos discos de dados.
Bytes de leitura do disco de dados/s : o número de bytes lidos em um segundo dos discos de dados.
Operações de leitura de disco de dados/s : o número de operações de entrada que são lidas em um
segundo de discos de dados.
Bytes de gravação do disco de dados/s : o número de bytes gravados em um segundo dos discos de
dados.
Operações de gravação do disco de dados/s : o número de operações de saída que são gravadas em
um segundo a partir de disco (s) de dados.
Bytes de leitura de disco/s : o número total de bytes lidos em um segundo de todos os discos anexados a
uma VM.
Operações de leitura de disco/s : o número de operações de entrada que são lidas em um segundo de
todos os discos anexados a uma VM.
Bytes de gravação de disco/s : o número de bytes gravados em um segundo de todos os discos anexados
a uma VM.
Operações de gravação de disco/s : o número de operações de saída que são gravadas em um segundo
de todos os discos anexados a uma VM.
Métricas de intermitência
As métricas a seguir ajudam a observar a observação em nosso recurso de disparo em nossos discos Premium:
Largura de banda máxima de intermitência do disco de dados : o limite de taxa de transferência para
o qual os discos de dados podem se estourar.
Largura de banda máxima de intermitência do disco do so : o limite de taxa de transferência que o
disco do sistema operacional pode aumentar até.
IOPS de intermitência máxima do disco de dados : o limite de IOPS para o qual os discos de dados
podem se estourar.
IOPS de intermitência máxima do disco do so : o limite de IOPS para o qual o disco do sistema
operacional pode ser intermitente.
Largura de banda de destino do disco de dados : o limite de taxa de transferência que o disco de dados
pode atingir sem intermitência.
Largura de banda de destino do disco do so : o limite de taxa de transferência que o disco do sistema
operacional pode atingir sem intermitência.
IOPS de destino do disco de dados : o limite de IOPS que os discos de dados podem alcançar sem
intermitência.
IOPS de destino de disco do so : o limite de IOPS que os discos de dados podem alcançar sem
intermitência.
Percentual de créditos de intermitência de bps usados no disco de dados : a porcentagem
acumulada da intermitência de taxa de transferência usada para os discos de dados. Emitido em um intervalo
de 5 minutos.
Percentual de créditos de disparo de bps do disco do sistema operacional : a porcentagem
acumulada da intermitência de taxa de transferência usada para o disco do sistema operacional. Emitido em
um intervalo de 5 minutos.
Porcentagem de créditos de e/s intermitentes do disco de dados usada : a porcentagem acumulada
da intermitência de IOPS usada para os discos de dados. Emitido em um intervalo de 5 minutos.
Percentual de créditos de e/s de disco do so usados : a porcentagem acumulada da intermitência de
IOPS usada para o disco do sistema operacional. Emitido em um intervalo de 5 minutos.
Métricas de utilização de e/s de armazenamento

As métricas a seguir ajudam a diagnosticar afunilamento na sua combinação de disco e máquina virtual. Essas
métricas só estão disponíveis ao usar a VM habilitada Premium. Essas métricas estão disponíveis para todos os
tipos de disco, exceto para ultra.
Métricas que ajudam a diagnosticar a e/s de disco com limitação:
Percentual de IOPS consumido de disco de dados : a porcentagem calculada pelo IOPS de disco de
dados foi concluída sobre o IOPS de disco de dados provisionado. Se esse valor for em 100%, seu aplicativo
em execução será e/s limitada do limite de IOPS do disco de dados.
Porcentagem consumida da largura de banda do disco de dados : a porcentagem calculada pela taxa
de transferência do disco de dados foi concluída na taxa de transferência do disco de dados provisionado Se
esse valor for em 100%, seu aplicativo em execução será e/s limitada do limite de largura de banda do disco
de dados.
Porcentagem consumida de IOPS de disco do so : a porcentagem calculada pelo IOPS de disco do
sistema operacional concluída em relação à IOPS de disco do sistema operacional provisionado. Se esse
valor for em 100%, seu aplicativo em execução será e/s limitada do limite de IOPS do disco do sistema
operacional.
Porcentagem consumida da largura de banda do disco do so : a porcentagem calculada pela taxa de
transferência do disco do so concluída sobre a taxa de transferência do disco do so provisionado Se esse
valor for em 100%, seu aplicativo em execução será e/s limitada do limite de largura de banda do disco do
Métricas que ajudam a diagnosticar a e/s de VM com limitação:
Porcentagem consumida de IOPS em cache da VM : a porcentagem calculada pelo total de IOPS
concluída em relação ao limite de IOPS máximo em cache da máquina virtual. Se esse valor for em 100%,
seu aplicativo em execução será e/s limitada do limite de IOPS em cache da VM.
Porcentagem consumida da largura de banda em cache da VM : a porcentagem calculada pela taxa de
transferência total do disco concluída na taxa de transferência máxima de máquina virtual em cache. Se esse
valor for em 100%, seu aplicativo em execução será e/s limitada do limite de largura de banda em cache da
VM.
Percentual de IOPS consumido de VM não armazenado em cache : a porcentagem calculada pelo
IOPS total em uma máquina virtual foi concluída com o limite máximo de IOPS de máquina virtual sem
cache. Se esse valor for em 100%, seu aplicativo em execução será e/s limitada do limite de IOPS sem cache
da sua VM.
Porcentagem consumida da largura de banda não armazenada em cache da VM : a porcentagem
calculada pela taxa de transferência total do disco em uma máquina virtual foi concluída com a taxa de
transferência máxima da máquina virtual provisionada. Se esse valor for em 100%, seu aplicativo em
execução será e/s limitada do limite de largura de banda sem cache da sua VM.
Exemplo de métrica de e/s de armazenamento

Vamos executar um exemplo de como usar essas novas métricas de utilização de e/s de armazenamento para
nos ajudar a depurar onde há um afunilamento em nosso sistema. A configuração do sistema é igual ao
exemplo anterior, exceto que, desta vez, o disco do sistema operacional anexado não é armazenado em cache.
Instalação
Standard_D8s_v3
IOPS: 5.000
IOPS: 5.000
IOPS: 5.000
Vamos executar um teste de benchmark nessa máquina virtual e na combinação de disco que cria a atividade de
e/s. Para saber como avaliar o parâmetro de e/s de armazenamento no Azure, confira avaliar seu aplicativo no
armazenamento em disco do Azure. Na ferramenta de benchmarking, você pode ver que a combinação de VM e
disco pode atingir 22.800 IOPS:
O Standard_D8s_v3 pode alcançar um total de 28.600 IOPS. Usando as métricas, vamos investigar o que está
acontecendo e identificar nosso afunilamento de e/s de armazenamento. No painel esquerdo, selecione
métricas :
Primeiro, vamos dar uma olhada em nossa métrica percentual consumida de IOPS em cache de VM :
Essa métrica nos informa que 61% dos 16.000 IOPS alocados para o IOPS armazenado em cache na VM estão
sendo usados. Essa porcentagem significa que o afunilamento de e/s de armazenamento não está com os discos
armazenados em cache porque não está em 100%. Agora, vamos examinar nossa métrica de percentual
consumida de IOPS sem cache de VM :
Esta métrica está em 100%. Ele nos informa que todos os 12.800 IOPS alocados para o IOPS não armazenado
em cache na VM estão sendo usados. Uma maneira de corrigir esse problema é alterar o tamanho de nossa VM
para um tamanho maior que possa lidar com a e/s adicional. Mas antes de fazermos isso, vamos examinar o
disco anexado para descobrir quantos IOPS eles estão vendo. Verifique o disco do sistema operacional
examinando a porcentagem consumida de IOPS de disco do so :
Essa métrica nos informa que cerca de 90% dos 5.000 IOPS provisionados para esse disco de so p30 está sendo
usado. Essa porcentagem significa que não há nenhum afunilamento no disco do sistema operacional. Agora,
vamos verificar os discos de dados que estão anexados à VM examinando a porcentagem consumida IOPS
do disco de dados :
Essa métrica nos informa que a porcentagem média de IOPS consumidas em todos os discos anexados está em
cerca de 42%. Esse percentual é calculado com base no IOPS usado pelos discos e não está sendo servido pelo
cache do host. Vamos aprofundar essa métrica aplicando a divisão nessas métricas e dividindo pelo valor de
LUN:
Essa métrica nos informa que os discos de dados anexados no LUN 3 e 2 estão usando cerca de 85% de seus
IOPS provisionados. Aqui está um diagrama de como a e/s se parece da arquitetura de VM e de discos:
Próximas etapas
Visão geral das métricas de Azure Monitor
Agregação de métricas explicada
Criar, exibir e gerenciar alertas de métrica usando o Azure Monitor
Intermitência de disco gerenciado
No Azure, oferecemos a capacidade de aumentar o desempenho de IOPS de armazenamento em disco e MB/s,

chamados de intermitência em discos e máquinas virtuais. A intermitência é útil em muitos cenários, como o
tratamento de tráfego de disco inesperado ou processamento de trabalhos em lotes. Você pode efetivamente
aproveitar a intermitência de nível de disco e de VM para obter uma excelente linha de base e desempenho de
intermitência na VM e no disco. Dessa forma, você pode obter um excelente desempenho de linha de base e
desempenho de intermitência na VM e no disco.
Observe que a intermitência em discos e VMs é independente uma da outra. Se você tiver um disco de
intermitência, não precisará de uma VM de intermitência para permitir que o disco seja estourado. Se você tiver
uma VM de intermitência, não será necessário um disco de intermitência para permitir que a VM seja rompida.
O SSDs Premium do Azure oferece dois modelos de intermitência:
Um modelo de intermitência sob demanda (versão prévia), em que o disco é estourado sempre que suas
necessidades excedem sua capacidade atual. Esse modelo incorre em encargos adicionais sempre que o
disco for rompido. A intermitência de não crédito só está disponível em discos com mais de 512 GiB de
tamanho.
Um modelo baseado em crédito, onde o disco será estourado somente se tiver créditos de intermitência
acumulados em seu Bucket de crédito. Esse modelo não incorrerá em encargos adicionais quando o disco for
estourado. A intermitência baseada em crédito só está disponível em discos 512 GiB e menores.
Além disso, o nível de desempenho dos discos gerenciados pode ser alterado, o que pode ser ideal se sua carga
de trabalho fosse executada em intermitência.
IN T ERM IT ÊN C IA C O M B A SE IN T ERM IT ÊN C IA SO B A LT ERA N DO O N ÍVEL DE

EM C RÉDITO DEM A N DA DESEM P EN H O
Cenários Ideal para Ideal para Ideal se sua carga de

dimensionamento de curto dimensionamento de curto trabalho seria
prazo (30 minutos ou prazo (sem restrições de continuamente executada
menos). tempo). em intermitência.
Custo Gratuita Custo é variável, consulte a O custo de cada nível de

seção de cobrança para desempenho é fixo,
obter detalhes. consulte preços de
Managed disks para obter
detalhes.
Disponibilidade Disponível somente para o Disponível somente para o Disponível para todos os
SSDs Premium 512 GiB e SSDs Premium maior que tamanhos de SSD Premium.
menor. 512 GiB.
Habilitação Habilitado por padrão em Deve ser habilitado pelo O usuário deve alterar
discos qualificados. usuário. manualmente sua camada.
Cenários comuns
Os cenários a seguir podem se beneficiar muito da intermitência:
Melhorar os tempos de inicialização – com a intermitência, sua instância será inicializada a uma taxa
significativamente mais rápida. Por exemplo, o disco do sistema operacional padrão para VMs com
habilitação Premium é o disco P4, que é um desempenho provisionado de até 120 IOPS e 25 MB/s. Com a
intermitência, o P4 pode ir até 3500 IOPS e 170 MB/s, permitindo que a inicialização Acelere até 6 vezes.
Manipular trabalhos em lotes – algumas cargas de trabalho de aplicativo são cíclicas por natureza. Eles
exigem um desempenho de linha de base na maior parte do tempo e melhor desempenho por curtos
períodos de tempo. Um exemplo disso é um programa de contabilidade que processa transações diárias que
exigem uma pequena quantidade de tráfego de disco. No final do mês, esse programa concluiria a
reconciliação de relatórios que precisam de uma quantidade muito maior de tráfego de disco.
Picos de tráfego – os servidores Web e seus aplicativos podem enfrentar sobretensões de tráfego a
qualquer momento. Se o seu servidor Web for apoiado por VMs ou discos que usam intermitência, os
servidores seriam mais bem equipados para lidar com picos de tráfego.
Cenários comuns
Os cenários a seguir podem se beneficiar muito da intermitência:
Melhorando os tempos de inicialização – com a intermitência, sua instância será inicializada a uma taxa
significativamente mais rápida. Por exemplo, o disco do sistema operacional padrão para VMs com
habilitação Premium é o disco P4, que é um desempenho provisionado de até 120 IOPS e 25 MB/s. Com a
intermitência, o P4 pode ir até 3500 IOPS e 170 MB/s, permitindo um tempo de inicialização para acelerar
por 6 vezes.
Manipulação de trabalhos em lotes – algumas cargas de trabalho do aplicativo são cíclicas por natureza
e exigem um desempenho de linha de base para a maioria do tempo e exigem um desempenho maior por
um curto período de tempo. Um exemplo disso é um programa de contabilidade que processa transações
diárias que exigem uma pequena quantidade de tráfego de disco. No final do mês, o reconcilia os relatórios
que precisam de uma quantidade muito maior de tráfego de disco.
Preparação para picos de tráfego – os servidores Web e seus aplicativos podem enfrentar sobretensões
de tráfego a qualquer momento. Se o seu servidor Web for apoiado por VMs ou discos que usam
intermitência, os servidores serão mais bem equipados para lidar com picos de tráfego.
Fluxo de intermitência
O sistema de crédito de intermitências aplica-se da mesma maneira no nível de disco e no nível de máquina
virtual. Seu recurso, uma VM ou um disco, será iniciado com créditos totalmente em estoque. Esses créditos
permitirão que você se intermitência por 30 minutos na taxa máxima de intermitência. Os créditos de
intermitência acumulam quando o recurso está em execução em seus limites de armazenamento em disco de
desempenho. Para todos os IOPS e MB/s que seu recurso está usando abaixo do limite de desempenho, você
começa a acumular créditos. Se o recurso tiver Créditos acumulados a serem usados para intermitência e sua
carga de trabalho precisar de desempenho extra, seu recurso poderá usar esses créditos para ir acima do seu
limite de desempenho para dar a ele o desempenho de e/s de disco necessário para atender à demanda.
Cabe a você saber como você deseja usar os 30 minutos de intermitência. Você pode usá-lo por 30 minutos
consecutivamente ou esporadicamente ao longo do dia. Quando o produto é implantado, ele vem pronto com
créditos completos e quando esgota os créditos que leva menos de um dia para ser totalmente estocado em
todos os créditos. Você pode acumular e gastar seus créditos de intermitência a seu critério e o Bucket de 30
minutos não precisa estar cheio novamente para intermitência. Uma coisa a ser observada sobre a acumulação
de intermitência é que ele é diferente para cada recurso, pois ele se baseia em IOPS não utilizados e MB/s abaixo
de seus valores de desempenho. Isso significa que produtos de desempenho de linha de base mais altos podem
acumular seus valores de intermitência mais rápido que os produtos de execução de linha de base menores. Por
exemplo, um deixar de disco P1 sem atividade acumulará 120 IOPS por segundo, enquanto um disco P20
acumula 2.300 IOPS por segundo, enquanto deixar sem atividade.
Estados de intermitência
Há três Estados em que o recurso pode estar com a intermitência ativada:
Acumulando – o tráfego de e/s do recurso está usando menos do que o destino de desempenho. Acumular
créditos de intermitência para IOPS e MB/s é feito separadamente um do outro. Seu recurso pode estar
acumulando créditos de IOPS e créditos de MB/s ou vice-versa.
Intermitência – o tráfego do recurso está usando mais do que o destino de desempenho. O tráfego de
intermitência consumirá de forma independente os créditos de IOPS ou largura de banda.
Constante – o tráfego do recurso está exatamente no destino de desempenho.
Exemplos de intermitência
Os exemplos a seguir mostram como a intermitência funciona com várias combinações de VM e disco. Para
facilitar o acompanhamento dos exemplos, vamos nos concentrar em MB/s, mas a mesma lógica é aplicada de
forma independente ao IOPS.
Máquina virtual não expansível com discos com intermitência
Combinação de VM e disco:
Standard_D8as_v4
MB/s não armazenados em cache: 192
Disco do sistema operacional P4
MB/s provisionados: 25
Máximo de MB/s de intermitência: 170
2 discos de dados P10
Quando a VM é inicializada, ela recupera dados do disco do sistema operacional. Como o disco do sistema
operacional faz parte de uma VM que está sendo inicializada, o disco do sistema operacional estará cheio de
créditos de intermitência. Esses créditos permitirão que o disco do so estoure sua inicialização em 170 MB/s
segundo.
Após a conclusão da inicialização, um aplicativo é executado na VM e tem uma carga de trabalho não crítica.
Essa carga de trabalho requer 15 MB/S que se espalham uniformemente em todos os discos.
Em seguida, o aplicativo precisa processar um trabalho em lote que requer 192 MB/s. 2 MB/s são usados pelo
disco do sistema operacional e o restante são divididos uniformemente entre os discos de dados.
Máquina virtual expansível com discos não intermitentes

Standard_L8s_v2
Máximo de MB/s de intermitência: 1.280
Após a inicialização inicial, um aplicativo é executado na VM e tem uma carga de trabalho não crítica. Essa carga
de trabalho requer 30 MB/s que se espalham uniformemente em todos os discos.
Em seguida, o aplicativo precisa processar um trabalho em lote que requer 600 MB/s. O Standard_L8s_v2
intermitência para atender a essa demanda e, em seguida, as solicitações para os discos são distribuídas
uniformemente para os discos P50.
Máquina virtual expansível com discos expansível
Standard_L8s_v2
Máximo de MB/s de intermitência: 1.280
Quando a VM for iniciada, ela será intermitente para solicitar seu limite de intermitência de 1.280 MB/s do disco
do sistema operacional e o disco do sistema operacional responderá com seu desempenho de intermitência de
170 MB/s.
Após a inicialização, você inicia um aplicativo que tem uma carga de trabalho não crítica. Esse aplicativo requer
15 MB/s que é distribuído uniformemente em todos os discos.
Em seguida, o aplicativo precisa processar um trabalho em lote que requer 360 MB/s. O Standard_L8s_v2 é
intermitente para atender a essa demanda e, em seguida, solicitações. Apenas 20 MB/s são necessários para o
disco do sistema operacional. Os 340 MB/s restantes são tratados pelos discos de dados de intermitência P4.
Próximas etapas
Para habilitar a intermitência sob demanda, consulte habilitar intermitência sob demanda. Para saber como
obter informações sobre os recursos de intermitência, confira métricas de intermitência de disco.
Níveis de desempenho para discos gerenciados
O desempenho do seu disco gerenciado do Azure é definido quando você cria o disco, na forma de seu nível de
desempenho. O nível de desempenho determina a IOPS e a taxa de transferência que o disco gerenciado tem.
Quando você define o tamanho provisionado do disco, um nível de desempenho é selecionado
automaticamente. O nível de desempenho pode ser alterado na implantação ou posteriormente, sem alterar o
tamanho do disco.
Alterar o nível de desempenho permite que você se prepare e atenda a uma demanda maior sem usar o recurso
de intermitência do disco. Pode ser mais econômico alterar o nível de desempenho em vez de se basear na
intermitência, dependendo de quanto tempo o desempenho adicional é necessário. Isso é ideal para eventos
que exigem temporariamente um nível de desempenho consistentemente mais alto, como compras de feriados,
testes de desempenho ou execução de um ambiente de treinamento. Para lidar com esses eventos, você pode
usar um nível de desempenho mais alto pelo tempo necessário. Em seguida, você pode retornar à camada
original quando não precisar mais do desempenho adicional.
Como ele funciona

Quando você implanta ou provisiona um disco pela primeira vez, o nível de desempenho de linha de base desse
disco é definido com base no tamanho do disco provisionado. Você pode usar um nível de desempenho maior
do que a linha de base original para atender à demanda mais alta. Quando você não precisar mais desse nível
de desempenho, poderá retornar para o nível de desempenho de linha de base inicial.
Sua cobrança muda à medida que sua camada de desempenho muda. Por exemplo, se você provisionar um
disco P10 (128 GiB), o nível de desempenho de linha de base será definido como P10 (500 IOPS e 100 MBps).
Você será cobrado na taxa de P10. Você pode atualizar a camada para corresponder ao desempenho de p50
(7.500 IOPS e 250 MBps) sem aumentar o tamanho do disco. Durante o tempo da atualização, você será
cobrado na taxa de P50. Quando você não precisar mais do melhor desempenho, poderá retornar para a
camada P10. O disco será novamente cobrado na taxa de P10.
C A M A DA DE DESEM P EN H O DE L IN H A
TA M A N H O DO DISC O DE B A SE P O DE SER AT UA L IZ A DO PA RA
4 GiB P1 P2, P3, P4, P6, P10, P15, P20, P30,

P40, P50
8 GiB P2 P3, P4, P6, P10, P15, P20, P30, P40,

P50
16 GiB P3 P4, P6, P10, P15, P20, P30, P40, P50
32 GiB P4 P6, P10, P15, P20, P30, P40, P50
64 GiB P6 P10, P15, P20, P30, P40, P50
128 GiB P10 P15, P20, P30, P40, P50
256 GiB P15 P20, P30, P40, P50

C A M A DA DE DESEM P EN H O DE L IN H A
TA M A N H O DO DISC O DE B A SE P O DE SER AT UA L IZ A DO PA RA
512 GiB P20 P30, P40, P50
1 TiB P30 P40, P50
2 TiB P40 P50
4 TiB P50 Nenhum
8 TiB P60 P70, P80
16 TiB P70 P80
32 TiB P80 Nenhum
Para obter informações de cobrança, consulte preços de disco gerenciado.
Restrições
Atualmente, esse recurso tem suporte apenas para SSDs Premium.
Você deve desalocar sua VM ou desanexar o disco de uma VM em execução antes de poder alterar a camada
do disco.
Os níveis de desempenho P60, P70 e P80 só podem ser usados por discos maiores que 4.096 GiB.
O nível de desempenho de um disco pode ser rebaixado apenas uma vez a cada 12 horas.
Próximas etapas
Para saber como alterar o nível de desempenho, consulte os artigos sobre o portal ou PowerShell/CLI .
Altere o nível de desempenho usando o módulo
Azure PowerShell ou o CLI do Azure
tamanho do disco. Para saber mais sobre as camadas de desempenho, consulte camadas de desempenho para
discos gerenciados.
Restrições
do disco.
Criar um disco de dados vazio com uma camada superior à camada de

linha de base
CLI do Azure
PowerShell
subscriptionId=<yourSubscriptionIDHere>
resourceGroupName=<yourResourceGroupNameHere>
diskName=<yourDiskNameHere>
diskSize=<yourDiskSizeHere>
performanceTier=<yourDesiredPerformanceTier>
region=westcentralus
az login
az disk create -n $diskName -g $resourceGroupName -l $region --sku Premium_LRS --size-gb $diskSize --tier
$performanceTier
Criar um disco do sistema operacional com uma camada superior à

camada de linha de base de uma imagem do Azure Marketplace
region=westcentralus
image=Canonical:UbuntuServer:18.04-LTS:18.04.202002180
az disk create -n $diskName -g $resourceGroupName -l $region --image-reference $image --sku Premium_LRS --

tier $performanceTier
Atualizar a camada de um disco

CLI do Azure
PowerShell
az disk update -n $diskName -g $resourceGroupName --set tier=$performanceTier
Mostrar a camada de um disco

CLI do Azure
PowerShell
az disk show -n $diskName -g $resourceGroupName --query [tier] -o tsv
Alterar o nível de desempenho de um disco sem tempo de

inatividade (versão prévia)
Você também pode alterar seu nível de desempenho sem tempo de inatividade, portanto, não é necessário
desalocar sua VM ou desanexar o disco para alterar a camada. Para obter mais informações e o link de inscrição
para a versão prévia, consulte a seção alterando o tipo de desempenho sem tempo de inatividade (versão
prévia) .
O script a seguir atualizará a camada de um disco maior do que a camada de linha de base usando o modelo de
exemplo CreateUpdateDataDiskWithTier.jsem. Substitua <yourSubScriptionID> , <yourResourceGroupName> ,
<yourDiskName> , <yourDiskSize> e <yourDesiredPerformanceTier> Execute o script:
subscriptionId=<yourSubscriptionID>
resourceGroupName=<yourResourceGroupName>
diskName=<yourDiskName>
diskSize=<yourDiskSize>
region=EastUS2EUAP
az login
az group deployment create -g $resourceGroupName \

--template-uri "https://raw.githubusercontent.com/Azure/azure-managed-disks-performance-
tiers/main/CreateUpdateDataDiskWithTier.json" \
--parameters "region=$region" "diskName=$diskName" "performanceTier=$performanceTier"
"dataDiskSizeInGb=$diskSize"
Uma alteração no nível de desempenho pode levar até 15 minutos para ser concluída. Para confirmar se o disco
alterou as camadas, use o seguinte comando:
az resource show -n $diskName -g $resourceGroupName --namespace Microsoft.Compute --resource-type disks --

api-version 2020-12-01 --query [properties.tier] -o tsv
Próximas etapas
Se você precisar redimensionar um disco para tirar proveito dos níveis de desempenho mais alto, consulte estes
artigos:
Expandir discos rígidos virtuais em uma VM do Linux com a CLI do Azure
Expandir um disco gerenciado conectado a uma máquina virtual do Windows
Alterar o nível de desempenho usando o portal do
Azure
tamanho do disco. Para saber mais sobre as camadas de desempenho, consulte camadas de desempenho para
discos gerenciados.
Restrições
do disco.
Introdução
Novos discos
As etapas a seguir mostram como alterar a camada de desempenho do disco quando você cria o disco pela
primeira vez:
2. Navegue até a VM para a qual você gostaria de criar um novo disco.
3. Ao selecionar o novo disco, primeiro escolha o tamanho do disco que você precisa.
4. Depois de selecionar um tamanho, selecione um nível de desempenho diferente para alterar seu
desempenho.
5. Selecione OK para criar o disco.
Discos existentes
As etapas a seguir descrevem como alterar o nível de desempenho de um disco existente:
2. Navegue até a VM que contém o disco que você gostaria de alterar.
3. Desaloque a VM ou desanexe o disco.
4. Selecione seu disco
5. Selecione tamanho + desempenho .
6. Na lista suspensa nível de desempenho , selecione uma camada diferente da camada de desempenho
atual do disco.
7. Selecione Redimensionar .
Próximas etapas
Se você precisar redimensionar um disco para tirar proveito dos níveis de desempenho mais alto, consulte estes
artigos:
Expandir discos rígidos virtuais em uma VM do Linux com a CLI do Azure
Expandir um disco gerenciado conectado a uma máquina virtual do Windows
Habilitar acelerador de gravação
O Acelerador de Gravação é uma capacidade de disco máquinas virtuais (VMs) da Série M no Armazenamento
Premium com Azure Managed Disks exclusivamente. Como o nome indica, o objetivo da funcionalidade é
melhorar a latência de E/S das gravações no Armazenamento Premium do Azure. O Acelerador de Gravação é
ideal para quando as atualizações do arquivo de log são necessárias para manter em disco em um modo de alto
desempenho para bancos de dados modernos.
O Acelerador de Gravação está disponível para as VMs da Série M na nuvem pública.
Planejar a utilização do Acelerador de Gravação

O Acelerador de Gravação deve ser utilizado para os volumes, os quais contêm o log de transações ou logs de
recuperação de um DBMS. Não é recomendável usar Aceleradores de Gravação para os volumes de dados de
um DBMS porque o recurso foi otimizado para ser usado em discos de log.
O Acelerador de Gravação funciona somente em conjunto com o Azure Managed Disks.
IMPORTANT
Habilitar o Acelerador de Gravação para disco do sistema operacional da VM reiniciará a VM.
Para habilitar o Acelerador de Gravação para um disco do Azure existente que NÃO faça parte de um volume compilado
de vários discos com gerenciadores de volume ou discos do Windows, SOFS (Servidor de Arquivos de Escalabilidade
Horizontal do Windows), LVM do Linux ou MDADM, a carga de trabalho que acessa o disco do Azure precisa ser
desligada. Os aplicativos de banco de dados utilizando o disco do Azure devem ser desligados.
Se você quiser habilitar ou desabilitar o Acelerador de Gravação para um volume existente que é compilado de vários
discos do Armazenamento Premium do Azure e distribuído utilizando gerenciadores de volume ou discos do Windows,
SOFS (Servidor de Arquivos de Escalabilidade Horizontal do Windows), LVM do Linux ou MDADM, todos os discos
compilando o volume devem ser habilitados ou desabilitados para o Acelerador de Gravação em etapas separadas. Antes
de habilitar ou desabilitar o Acelerador de Gravação nessa configuração, desligue a VM do Azure .
Habilitar o Acelerador e Gravação para discos do sistema operacional não deve ser necessária para
configurações de VM relacionadas ao SAP.
Restrições ao utilizar o Acelerador de Gravação
Ao utilizar o Acelerador de Gravação para um VHD/disco do Azure, estas restrições são aplicáveis:
O armazenamento em cache do disco Premium deve ser definido como 'Nenhum' ou ‘Somente leitura’.
Todos os outros modos de armazenamento em cache não têm suporte.
Instantâneo não têm suporte atualmente para discos do Acelerador de Gravação habilitados. Durante o
backup, o serviço de Backup do Microsoft Azure exclui automaticamente os discos habilitados do Acelerador
de Gravação anexados à VM.
Somente E/S menores (<=512 KiB) estão tomando o caminho mais rápido. Em situações de carga de
trabalho em que os dados estão sendo carregados em massa ou quando buffers de log de transação dos
diferentes DBMS são preenchidos a um maior grau antes de serem retidos no armazenamento, é provável
que a E/S gravada em disco não esteja fazendo o caminho mais rápido.
Há limites de VHDs de Armazenamento Premium do Azure por VM que podem ter suporte pelo Acelerador de
Gravação. Os limites atuais são:
N ÚM ERO DE DISC O S DO A C EL ERA DO R IO P S DO DISC O A C EL ERA DO R DE
SK U DA VM DE GRAVA Ç Ã O GRAVA Ç Ã O P O R VM
M416ms_v2, M416s_v2 16 20000
M208ms_v2, M208s_v2 8 10000
M128ms, M128s 16 20000
M64ms, M64ls, M64s 8 10000
M32ms, M32ls, M32ts, M32s 4 5.000
M16ms, M16s 2 2500
M8ms, M8s 1 1250
São os limites de IOPS por VM e não por disco. Todos os discos do Acelerador de Gravação compartilham o
mesmo limite IOPS por VM. Os discos anexados não podem exceder o limite de IOPS do acelerador de gravação
para uma VM. Por exemplo, embora os discos anexados possam fazer 30.000 IOPS, o sistema não permite que
os discos passem acima de 20.000 IOPS para M416ms_v2.
Habilitar o Acelerador de Gravação em um disco específico

As próximas seções descreverão como o Acelerador de Gravação pode ser habilitado nos VHDs do
Armazenamento Premium do Azure.
Pré -requisitos
Os pré-requisitos a seguir são aplicáveis ao uso do Acelerador de Gravação neste momento:
Os discos aos quais você deseja aplicar o Acelerador de Gravação do Azure precisam ser discos gerenciados
do Azure no Armazenamento Premium.
Você deve estar usando uma VM de Série M
Habilitar o Acelerador de Gravação do Azure usando o Microsoft

Azure PowerShell
O módulo do PowerShell do Azure da versão 5.5.0 inclui as alterações nos cmdlets relevantes para habilitar ou
desabilitar o Acelerador de Gravação para discos específicos do Armazenamento Premium do Azure. Para
habilitar ou implantar discos com suporte pelo Acelerador de Gravação, os seguintes comandos do PowerShell
foram alterados e estendidos para aceitar um parâmetro para o Acelerador de Gravação.
Um novo parâmetro de opção, -WriteAccelerator foi adicionado aos cmdlets a seguir:
Set-AzVMOsDisk
Add-AzVMDataDisk
Set-AzVMDataDisk
Add-AzVmssDataDisk
Não fornecer o parâmetro define a propriedade como falso e implantará discos que não tenham suporte pelo
Acelerador de Gravação.
Um novo parâmetro de opção, -OsDiskWriteAccelerator foi adicionado aos cmdlets a seguir:
Set-AzVmssStorageProfile
Não especificar o parâmetro define a propriedade como falso, retornando os discos que não alavancam o
Um novo parâmetro booliano (não anulável) parâmetro, OsDiskWriteAccelerator - foi adicionado aos
cmdlets a seguir:
Update-AzVM
Update-AzVmss
Especifique se $true ou $false para controlar o suporte do Aelerador de Gravação do Azure com os discos.
Exemplos de comandos podem ser semelhantes a:
New-AzVMConfig | Set-AzVMOsDisk | Add-AzVMDataDisk -Name "datadisk1" | Add-AzVMDataDisk -Name "logdisk1" -

WriteAccelerator | New-AzVM
Get-AzVM | Update-AzVM -OsDiskWriteAccelerator $true
New-AzVmssConfig | Set-AzVmssStorageProfile -OsDiskWriteAccelerator | Add-AzVmssDataDisk -Name "datadisk1" -

WriteAccelerator:$false | Add-AzVmssDataDisk -Name "logdisk1" -WriteAccelerator | New-AzVmss
Get-AzVmss | Update-AzVmss -OsDiskWriteAccelerator:$false
Dois principais cenários podem ser em script, conforme mostrado nas seções a seguir.
Adicionar novo disco com suporte pelo Acelerador de Gravação usando o PowerShell
É possível utilizar esse script para adicionar um novo disco à sua VM. O disco criado com esse script usará o
Substitua myVM , myWAVMs , log001 , tamanho do disco e LunID do disco com valores apropriados para sua
implantação específica.
# Specify your VM Name

$vmName="myVM"
#Specify your Resource Group
$rgName = "myWAVMs"
#data disk name
$datadiskname = "log001"
#LUN Id
$lunid=8
#size
$size=1023
#Pulls the VM info for later
$vm=Get-AzVM -ResourceGroupName $rgname -Name $vmname
#add a new VM data disk
Add-AzVMDataDisk -CreateOption empty -DiskSizeInGB $size -Name $vmname-$datadiskname -VM $vm -Caching None -
WriteAccelerator:$true -lun $lunid
#Updates the VM with the disk config - does not require a reboot
Update-AzVM -ResourceGroupName $rgname -VM $vm
Habilitar o Acelerador de Gravação do Azure em um disco do Azure existente usando o PowerShell

Você pode usar este script para habilitar o Acelerador de Gravação em um disco existente. Substitua myVM ,
myWAVMs , e test-log001 com valores apropriados para sua implantação específica. O script acima adiciona o
Acelerador de Gravação a um disco existente, onde o valor $newstatus é definido como '$true'. Usar o valor
'$false' desabilitará o Acelerador de Gravação em um determinado disco.
#Specify your VM Name
$vmName="myVM"
#Specify your Resource Group
$rgName = "myWAVMs"
#data disk name
$datadiskname = "test-log001"
#new Write Accelerator status ($true for enabled, $false for disabled)
$newstatus = $true
#Pulls the VM info for later
$vm=Get-AzVM -ResourceGroupName $rgname -Name $vmname
#add a new VM data disk
Set-AzVMDataDisk -VM $vm -Name $datadiskname -Caching None -WriteAccelerator:$newstatus
#Updates the VM with the disk config - does not require a reboot
Update-AzVM -ResourceGroupName $rgname -VM $vm
NOTE
Executar o script acima desanexará o disco especificado, habilitará o Acelerador de Gravação no disco e, em seguida,
anexará o disco novamente
Habilitar o Acelerador de Gravação usando o Portal do Azure

Você pode habilitar o Acelerador de Gravação por meio do portal onde pode especificar suas configurações de
cache de disco:
Habilitar o Acelerador de Gravação usando a CLI do Azure

Você pode usar a CLI do Azure para habilitar o Acelerador de Gravação.
Para habilitar o Acelerador de Gravação em um disco existente, use atualização az vm, você pode usar os
seguintes exemplos, se você substituir o diskName, VMName e ResourceGroup para seus próprios valores:
az vm update -g group1 -n vm1 -write-accelerator 1=true
Para anexar um disco com o Acelerador de Gravação habilitado, use anexar disco de vm az, você pode usar o
exemplo a seguir, se você substituir em seus próprios valores:
az vm disk attach -g group1 -vm-name vm1 -disk d1 --enable-write-accelerator
Para desativar a Aceleração de Gravação, use atualização de vm az, definindo as propriedades como falsas:
az vm update -g group1 -n vm1 -write-accelerator 0=false 1=false
Habilitar o Acelerador de Gravação usando as APIS Rest

Para implantar por meio da API REST do Azure, é necessário instalar o armclient do Azure.
Instalar o armclient
Para executar o armclient, é necessário instalá-lo por meio do Chocolatey. Você pode instalá-lo por meio do
cmd.exe ou do PowerShell. Utilize direitos elevados para esses comandos (“Executar como Administrador”).
Utilizando cmd.exe, execute o comando a seguir:
@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy
Bypass -Command "iex ((New-Object
System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET
"PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"
Utilizando o Power Shell execute o comando a seguir:

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object
System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
Agora você pode instalar o armclient usando o seguinte comando em cmd.exe ou o PowerShell
choco install armclient
Obter a configuração atual da VM

Para alterar os atributos da configuração do disco, primeiro é necessário obter a configuração atual em um
arquivo JSON. Você pode obter a configuração atual executando o comando a seguir:
armclient GET /subscriptions/<<subscription-
ID<</resourceGroups/<<ResourceGroup>>/providers/Microsoft.Compute/virtualMachines/<<virtualmachinename>>?api-
version=2017-12-01 > <<filename.json>>
Substitua os termos dentro de '<< >>' pelos seus dados, incluindo o nome do arquivo que o arquivo JSON
deve ter.
A saída pode ser semelhante a:
{
"properties": {
"vmId": "2444c93e-f8bb-4a20-af2d-1658d9dbbbcb",
"vmSize": "Standard_M64s"
},
"storageProfile": {
"imageReference": {
"publisher": "SUSE",
"offer": "SLES-SAP",
"sku": "12-SP3",
"version": "latest"
},
"osDisk": {
"osType": "Linux",
"name": "mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a",
"managedDisk": {
"storageAccountType": "Premium_LRS",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
disks/mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a"
},
"diskSizeGB": 30
},
"dataDisks": [
{
"lun": 0,
"name": "data1",
"name": "data1",
"createOption": "Attach",
"caching": "None",
"managedDisk": {
"id":
disks/data1"
},
"diskSizeGB": 1023
},
{
"lun": 1,
"name": "log1",
"caching": "None",
"managedDisk": {
"id":
disks/data2"
},
"diskSizeGB": 1023
}
]
},
"osProfile": {
"computerName": "mylittlesapVM",
"adminUsername": "pl",
"disablePasswordAuthentication": false
},
"secrets": []
},
"networkProfile": {
{
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Network/
networkInterfaces/mylittlesap518"
}
]
},
"enabled": true,
"storageUri": "https://mylittlesapdiag895.blob.core.windows.net/"
}
},
},
"location": "westeurope",
"id":
virtualMachines/mylittlesapVM",
"name": "mylittlesapVM"
Em seguida, atualize o arquivo JSON e habilitar o Acelerador de Gravação no disco chamado 'log1'. Essa etapa
pode ser realizada adicionando esse atributo no arquivo JSON após a entrada do cache do disco.
{
"lun": 1,
"name": "log1",
"caching": "None",
"writeAcceleratorEnabled": true,
"managedDisk": {
"id":
disks/data2"
},
"diskSizeGB": 1023
}
Em seguida, atualize a implantação existente com este comando:

armclient PUT /subscriptions/<<subscription-
ID<</resourceGroups/<<ResourceGroup>>/providers/Microsoft.Compute/virtualMachines/<<virtualmachinename>>?api-
version=2017-12-01 @<<filename.json>>
A saída deve ser semelhante à seguinte. É possível ver esse Acelerador de Gravação habilitado para um disco.
{
"properties": {
"vmId": "2444c93e-f8bb-4a20-af2d-1658d9dbbbcb",
"vmSize": "Standard_M64s"
},
"storageProfile": {
"imageReference": {
"publisher": "SUSE",
"offer": "SLES-SAP",
"sku": "12-SP3",
"version": "latest"
},
"osDisk": {
"osType": "Linux",
"name": "mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a",
"managedDisk": {
"id":
disks/mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a"
},
"diskSizeGB": 30
},
"dataDisks": [
{
"lun": 0,
"name": "data1",
"caching": "None",
"managedDisk": {
"id":
disks/data1"
},
"diskSizeGB": 1023
},
{
"lun": 1,
"name": "log1",
"caching": "None",
"writeAcceleratorEnabled": true,
"managedDisk": {
"id":
disks/data2"
},
"diskSizeGB": 1023
}
]
},
"osProfile": {
"computerName": "mylittlesapVM",
"adminUsername": "pl",
"disablePasswordAuthentication": false
},
"secrets": []
},
"networkProfile": {
{
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Network/
networkInterfaces/mylittlesap518"
}
]
},
"enabled": true,
"storageUri": "https://mylittlesapdiag895.blob.core.windows.net/"
}
},
},
"location": "westeurope",
"id":
virtualMachines/mylittlesapVM",
"name": "mylittlesapVM"
Ao realizar essa alteração, a unidade deve ser compatível com o Acelerador de Gravação.
Submeter um disco a benchmark
Os parâmetros de comparação são o processo de simular diferentes cargas de trabalho no aplicativo e avaliar o
desempenho do aplicativo para cada carga de trabalho. Usando as etapas descritas no artigo Projeto para alto
desempenho, você reuniu os requisitos de desempenho do aplicativo. Ao executar ferramentas de benchmark
nas VMs que hospedam o aplicativo, você pode determinar os níveis de desempenho que seu aplicativo pode
atingir com o SSDs Premium. Neste artigo, fornecemos exemplos de benchmarking de uma VM
Standard_D8ds_v4 provisionada com o SSDs Premium do Azure.
Usamos ferramentas comuns de benchmark DiskSpd e FIO, para Windows e Linux, respectivamente. Essas
ferramentas geram vários threads que simulam uma carga de trabalho parecida com uma produção e avaliam o
desempenho do sistema. Usando as ferramentas, você pode configurar parâmetros como tamanho do bloco e
profundidade da fila, que normalmente você não pode mudar para um aplicativo. Isso proporciona mais
flexibilidade para impulsionar o desempenho máximo em uma VM de alta escala provisionada com o SSDs
Premium para diferentes tipos de cargas de trabalho de aplicativo. Para saber mais sobre cada ferramenta de
benchmark, visite DiskSpd e fio.
Para seguir os exemplos abaixo, crie um Standard_D8ds_v4 e anexe quatro SSDs Premium à VM. Dos quatro
discos, configure três com o cache de host como "None" e distribua-os para um volume chamado
NoCacheWrites. Configure o cache de host como "ReadOnly" no disco restante e crie um volume chamado
CacheReads com esse disco. Usando essa configuração, você pode ver o desempenho máximo de leitura e
gravação de uma VM Standard_D8ds_v4. Para obter etapas detalhadas sobre como criar um Standard_D8ds_v4
com o SSDs Premium, consulte projetando para alto desempenho.
Aquecimento do cache
O disco com cache de host ReadOnly é capaz de fornecer IOPS maior do que o limite de disco. Para atingir esse
desempenho máximo de leitura do cache de host, primeiramente você deve aquecer o cache desse disco. Isso
faz com que as E/S de leitura que a ferramenta de parâmetros de comparação impulsionará no volume
CacheReads realmente alcancem o cache, não o disco diretamente. Os acertos de cache resultam em mais IOPS
do disco habilitado para cache único.
IMPORTANT
Você deve iniciar o cache antes de executar os parâmetros de comparação toda vez que a VM for reinicializada.
DISKSPD
Baixe a ferramenta DISKSP na VM. DISKSPD é uma ferramenta que você pode personalizar para criar suas
próprias cargas de trabalho sintéticas. Usaremos a mesma configuração descrita acima para executar testes de
benchmark. Você pode alterar as especificações para testar cargas de trabalho diferentes.
Neste exemplo, usamos o seguinte conjunto de parâmetros de linha de base:
-c200G: cria (ou recria) o arquivo de exemplo usado no teste. Ele pode ser definido em bytes, KiB, MiB, GiB ou
blocos. Nesse caso, um arquivo grande do arquivo de destino 200-GiB é usado para minimizar o cache de
memória.
-W100: especifica a porcentagem de operações que são solicitações de gravação (-W0 é equivalente a 100%
Read).
-b4K: indica o tamanho do bloco em bytes, KiB, MiB ou GiB. Nesse caso, o tamanho do bloco de 4K é usado
para simular um teste de e/s aleatório.
-F4: define um total de quatro threads.
-r: indica o teste de e/s aleatório (Substitui o parâmetro-s).
-o128: indica o número de solicitações de e/s pendentes por destino por thread. Isso também é conhecido
como a profundidade da fila. Nesse caso, 128 é usado para enfatizar a CPU.
-W7200: especifica a duração do tempo de aquecimento antes do início das medições.
-D30: especifica a duração do teste, sem incluir o aquecimento.
-Sh: desabilitar o cache de gravação de software e hardware (equivalente a-Suw).
Para obter uma lista completa de parâmetros, consulte o repositório GitHub.
IOPS máxima de gravação
Usamos uma profundidade de fila alta de 128, um tamanho de bloco pequeno de 8 KB e quatro threads de
trabalho para conduzir operações de gravação. Os trabalhos de gravação estão orientando o tráfego no volume
"NoCacheWrites", que tem três discos com o cache definido como "None".
Execute o seguinte comando para 30 segundos de aquecimento e 30 segundos de medida:
diskspd -c200G -w100 -b8K -F4 -r -o128 -W30 -d30 -Sh testfile.dat
Os resultados mostram que a VM Standard_D8ds_v4 está fornecendo seu limite máximo de IOPS de gravação
de 12.800.
IOPS máxima de leitura

Usamos uma profundidade de fila alta de 128, um tamanho de bloco pequeno de quatro KB e quatro threads de
trabalho para conduzir operações de leitura. Os trabalhos de leitura estão orientando o tráfego no volume
"CacheReads", que tem um disco com cache definido como "ReadOnly".
Execute o seguinte comando por duas horas de aquecimento e 30 segundos de medida:
diskspd -c200G -b4K -F4 -r -o128 -W7200 -d30 -Sh testfile.dat
Os resultados mostram que o Standard_D8ds_v4 VM está fornecendo seu limite máximo de IOPS de leitura de
77.000.
Taxa de transferência máxima

Para obter a taxa de transferência máxima de leitura e gravação, você pode mudar para um tamanho de bloco
maior de 64 KB.
FIO
FIO é uma ferramenta popular para o armazenamento de parâmetros de comparação em VMs Linux. Ela tem a
flexibilidade para selecionar diferentes tamanhos de E/S, leituras e gravações sequenciais ou aleatórias. Ela gera
threads ou processos de trabalho para executar as operações de E/S especificadas. Você pode especificar o tipo
de operação de E/S que cada thread de trabalho deve executar usando arquivos de trabalho. Criamos um
arquivo de trabalho por cenário ilustrado nos exemplos abaixo. É possível alterar as especificações nesses
arquivos de trabalho para comparar diferentes cargas de trabalho em execução no Armazenamento Premium.
Nos exemplos, estamos usando um Standard_D8ds_v4 executando o Ubuntu . Use a mesma configuração
descrita no início da seção de benchmark e execute o cache antes de executar os testes de parâmetro de
comparação.
Antes de começar, baixe o FIO e instale-o em sua máquina virtual.
Execute o comando a seguir para o Ubuntu,
apt-get install fio
Usamos quatro threads de trabalho para impulsionar operações de gravação e quatro threads de trabalho para
impulsionar operações de leitura nos discos. Os trabalhos de gravação estão orientando o tráfego no volume
"NoCache", que tem três discos com o cache definido como "None". Os trabalhos de leitura estão orientando o
tráfego no volume "readcache", que tem um disco com cache definido como "ReadOnly".
IOPS máxima de gravação
Crie o arquivo de trabalho com as especificações a seguir para obter IOPS máxima de gravação. Dê o nome de
"fiowrite.ini".
[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=4k
numjobs=4
[writer1]
rw=randwrite
directory=/mnt/nocache
Observe os itens importantes a seguir que estão de acordo com as diretrizes de projeto abordadas nas seções
anteriores. Estas especificações são essenciais para impulsionar a IOPS máxima:
Uma profundidade de fila alta de 256.
Um tamanho de bloco pequeno de 4 KB.
Vários threads que executam gravações aleatórias.
Execute o seguinte comando para iniciar o teste FIO por 30 segundos:
sudo fio --runtime 30 fiowrite.ini
Enquanto o teste é executado, você pode ver o número de IOPS de gravação fornecido pela VM e pelos discos
Premium. Conforme mostrado no exemplo abaixo, a VM Standard_D8ds_v4 está fornecendo seu limite máximo
de IOPS de gravação de 12.800 IOPS.
IOPS máxima de leitura

Crie o arquivo de trabalho com as especificações a seguir para obter IOPS máxima de leitura. Dê o nome de
"fioread.ini".
[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=4k
numjobs=4
[reader1]
rw=randread
directory=/mnt/readcache
Uma profundidade de fila alta de 256.
Vários threads que executam gravações aleatórias.
sudo fio --runtime 30 fioread.ini
Enquanto o teste é executado, você pode ver o número de IOPS de leitura fornecido pela VM e pelos discos
Premium. Conforme mostrado no exemplo abaixo, a VM Standard_D8ds_v4 está fornecendo mais de 77.000
IOPS de leitura. Essa é uma combinação do desempenho do cache e do disco.
IOPS máxima de leitura e gravação

Crie o arquivo de trabalho com as especificações a seguir para obter a IOPS Máxima de Leitura e Gravação. Dê o
nome de "fioreadwrite.ini".
[global]
size=30g
direct=1
iodepth=128
ioengine=libaio
bs=4k
numjobs=4
[reader1]
rw=randread
directory=/mnt/readcache
[writer1]
rw=randwrite
directory=/mnt/nocache
rate_iops=3200
Uma profundidade alta de fila de 128.
Vários threads que executam leituras e gravações aleatórias.
sudo fio --runtime 30 fioreadwrite.ini
Enquanto o teste é executado, você pode ver o número de IOPS de leitura e gravação combinadas fornecido
pela VM e pelos discos Premium. Conforme mostrado no exemplo abaixo, a VM Standard_D8ds_v4 está
fornecendo mais de 90.000 IOPS de leitura e gravação combinados. Essa é uma combinação do desempenho do
cache e do disco.
Taxa de transferência máxima combinada

Para atingir a Taxa de Transferência máxima de Leitura e Gravação combinadas, use um tamanho de bloco maior
e uma profundidade de fila grande com vários threads executando leituras e gravações. É possível usar um
tamanho de bloco de 64 KB e uma profundidade de fila de 128.
Próximas etapas
Vá para nosso artigo sobre como projetar para alto desempenho.
Neste artigo, você cria uma lista de verificação semelhante ao aplicativo existente para o protótipo. Usando
ferramentas de Benchmark, você pode simular as cargas de trabalho e avaliar o desempenho no aplicativo do
protótipo. Com isso, será possível determinar qual oferta de disco pode corresponder ou superar os requisitos
de desempenho do aplicativo. Em seguida, você pode implementar as mesmas diretrizes para o aplicativo de
produção.
Escalabilidade e metas de desempenho para discos
de VM
Você pode anexar um número de discos de dados a uma máquina virtual do Azure. Com base nas metas de
escalabilidade e de desempenho dos discos de dados de uma VM, você pode determinar o número e o tipo de
disco necessários para atender aos seus requisitos de desempenho e capacidade.
IMPORTANT
Para obter o desempenho ideal, limite a quantidade de discos altamente utilizados anexados à máquina virtual para evitar
possíveis limitações. Se todos os discos anexados não forem altamente utilizados ao mesmo tempo, a máquina virtual
poderá dar suporte a um número maior de discos.
Para discos gerenciados Azure:

A tabela a seguir ilustra os limites padrão e máximo do número de recursos por região e assinatura. Os limites
continuam os mesmos, independentemente dos discos criptografados com chaves de criptografia gerenciadas
pela plataforma ou chaves gerenciadas pelo cliente. Não há nenhum limite para o número de discos
gerenciados, instantâneos e imagens por grupo de recursos.
REC URSO L IM IT E
Standard Managed Disks 50.000
Discos gerenciados SSD Standard 50.000
Discos gerenciados Premium 50.000
Instantâneos de Standard_LRS 50.000
Instantâneos de Standard_ZRS 50.000
Imagem gerenciada 50.000
Para contas de armazenamento Standard: uma conta de armazenamento Standard tem uma taxa de
solicitação total máxima de 20.000 IOPS. A IOPS total de todos os discos da máquina virtual de uma conta de
armazenamento Standard não deve exceder esse limite.
Basicamente, você calcula o número de discos altamente utilizados compatíveis com uma conta de
armazenamento Standard com base no limite da taxa de solicitação. Por exemplo, para uma VM do nível Básico,
o número máximo de discos altamente utilizados é de cerca de 66, sendo 20.000/300 IOPS por disco. O número
máximo de discos altamente utilizados para uma VM de nível Standard é de cerca de 40, sendo 20.000/500
IOPS por disco.
Para contas de armazenamento Premium: uma conta de armazenamento Premium tem uma taxa de
transferência total máxima de 50 Gbps. A taxa de transferência total de todos os discos da VM não deve exceder
esse limite.
Consulte tamanhos de VM para obter detalhes adicionais.
Discos de máquina virtual gerenciados

Tamanhos demarcados com um asterisco estão atualmente em visualização. Consulte nosso perguntas
frequentes sobre para saber em quais regiões eles estão disponíveis no.
Discos gerenciados HDD Standard
T IP O
DE
DISC
O
STA N
DA RD S4 S6 S10 S15 S20 S30 S40 S50 S60 S70 S80
Tama 32 64 128 256 512 1.024 2.048 4.096 8.192 16.38 32.76
nho 4 7
do
Disk
em
GiB
IOPS Até Até Até Até Até Até Até Até Até Até Até
por 500 500 500 500 500 500 500 500 1.300 2.000 2.000
disco
Taxa Até Até Até Até Até Até Até Até Até Até Até
de 60 60 60 60 60 60 60 60 300 500 500
transf MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s MB/s
erênci
a por
disco
Discos gerenciados SSD Standard

TA
MA
NH
OS
DE
SSD
STA
ND
AR
Tam 4 8 16 32 64 128 256 512 1.0 2.0 4.0 8.1 16. 32.
anh 24 48 96 92 384 767
o
do
disc
o
em
GiB
IOP Até Até Até Até Até Até Até Até Até Até Até Até Até Até
S 500 500 500 500 500 500 500 500 500 500 500 2.0 4 6
por 00 mil mil
disc
o
TA
MA
NH
OS
DE
SSD
STA
ND
AR
Taxa Até Até Até Até Até Até Até Até Até Até Até Até Até Até
de 60 60 60 60 60 60 60 60 60 60 60 400 600 750
tran MB MB MB MB MB MB MB MB MB MB/ MB/ MB/ MB/ MB/
sfer /s /s /s /s /s /s /s /s /s s s s s s
ênci
a
por
disc
o
Discos gerenciados SSD Premium: limites por disco

TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Tam 4 8 16 32 64 128 256 512 1.0 2.0 4.0 8.1 16. 32.
anh 24 48 96 92 384 767
o
do
disc
o
em
GiB
IOP 120 120 120 120 240 500 1.1 2.3 5.0 7.5 7.5 16. 18. 20,
S 00 00 00 00 00 000 000 000
pro
visi
ona
da
por
disc
o
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Taxa 25 25 25 25 50 100 125 150 200 250 250 500 750 900
sfer
ênci
a
pro
visi
ona
da
por
disc
o
Má 3.5 3.5 3.5 3.5 3.5 3.5 3.5 3.5

xim 00 00 00 00 00 00 00 00
o
de
IOP
S
de
inte
rmit
ênci
a
por
disc
o
Taxa 170 170 170 170 170 170 170 170

sfer
ênci
a
de
inte
rmit
ênci
a
máx
ima
por
disc
o
TA
MA
NH
OS
DE
UN I
DA
DES
SSD
P RE
M IU
Dur 30 30 30 30 30 30 30 30
o
máx
ima
da
inte
rmit
ênci
a
par
a
rese
rva
Discos gerenciados SSD Premium: limites por VM

REC URSO L IM IT E
IOPS máxima por VM 80.000 IOPS com VM GS5
Taxa de transferência máxima por VM 2.000 MB/s com VM GS5
Discos de máquina virtual não gerenciados

Discos padrão de máquinas vir tuais não gerenciados: limites por disco
C A M A DA DE VM VM DE C A M A DA B Á SIC A VM DE C A M A DA STA N DA RD
Tamanho do disco 4.095 GB 4.095 GB
IOPS máxima de 8 KB por disco 300 500

persistente
Número máximo de discos que 66 40

executam a IOPS máxima
Discos de máquina vir tual não gerenciados Premium: limites por conta
REC URSO L IM IT E
Capacidade total do disco por conta 35 TB
Capacidade total de instantâneos por conta 10 TB
Largura de banda máxima por conta (entrada + saída)1 <=50 Gbps
1Entrada refere-se a todos os dados de solicitações que são enviados a uma conta de armazenamento. Saída
refere-se a todos os dados de respostas recebidos de uma conta de armazenamento.

Discos de máquina vir tual não gerenciados Premium: limites por disco
T IP O DE DISC O
DE
A RM A Z EN A M EN
TO P REM IUM P 10 P 20 P 30 P 40 P 50
Tamanho do 128 GiB 512 GiB 1.024 GiB (1 TB) 2.048 GiB (2 TB) 4.095 GiB (4 TB)
disco
IOPS máxima 500 2.300 5.000 7.500 7.500

por disco
Taxa de 100 MB/s 150 MB/s 200 MB/s 250 MB/s 250 MB/s
transferência
máxima por
disco
Número máximo 280 70 35 17 8

de discos por
conta de
armazenamento
Discos de máquina vir tual não gerenciados Premium: limites por VM
REC URSO L IM IT E
IOPS máxima por VM 80.000 IOPS com VM GS5
Taxa de transferência máxima por VM 2 mil MB/s com VM GS5
Confira também
Assinatura do Azure e limite de serviços, cotas e restrições
Criar um instantâneo incremental para discos
gerenciados
Os instantâneos incrementais são backups pontuais para os discos gerenciados que, quando tirados, consistem
apenas nas alterações desde o último instantâneo. Quando você restaura um disco de um instantâneo
incremental, o sistema reconstrói o disco completo que representa o backup pontual do disco quando o
instantâneo incremental foi tirado. Essa nova funcionalidade para instantâneos de disco gerenciado pode
permitir que eles sejam mais econômicos, já que, a menos que você escolha, você não precisa armazenar todo o
disco com cada instantâneo individual. Assim como instantâneos completos, instantâneos incrementais podem
ser usados para criar um disco gerenciado completo ou um instantâneo completo.
Há algumas diferenças entre um instantâneo incremental e um instantâneo completo. Os instantâneos
incrementais sempre usarão o armazenamento de HDDs padrão, independentemente do tipo de
armazenamento do disco, enquanto os instantâneos completos podem usar o SSDs Premium. Se você estiver
usando instantâneos completos no armazenamento Premium para escalar verticalmente as implantações de
VM, recomendamos o uso de imagens personalizadas no armazenamento Standard na Galeria de imagens
compartilhadas. Ele o ajudará a alcançar uma escala mais maciça com menor custo. Além disso, os instantâneos
incrementais podem oferecer melhor confiabilidade com ZRS ( armazenamento com redundância de zona ). Se
ZRS estiver disponível na região selecionada, um instantâneo incremental usará o ZRS automaticamente. Se
ZRS não estiver disponível na região, o instantâneo usará como padrão o armazenamento com redundância
local (LRS). Você pode substituir esse comportamento e selecionar um manualmente, mas não é recomendável.
Os instantâneos incrementais também oferecem um recurso diferencial, disponível apenas para discos
gerenciados. Eles permitem que você obtenha as alterações entre dois instantâneos incrementais dos mesmos
discos gerenciados, até o nível de bloco. Você pode usar essa capacidade para reduzir o volume de dados ao
copiar instantâneos entre regiões. Por exemplo, você pode baixar o primeiro instantâneo incremental como um
blob de base em outra região. Para os instantâneos incrementais subsequentes, você pode copiar somente as
alterações desde o último instantâneo para o blob de base. Depois de copiar as alterações, você pode tirar
instantâneos no blob de base que representam o backup pontual do disco em outra região. Você pode restaurar
seu disco a partir do blob de base ou de um instantâneo no blob de base em outra região.
Os instantâneos incrementais são cobrados apenas pelo tamanho usado. Você pode encontrar o tamanho usado
de seus instantâneos examinando o relatório de uso do Azure. Por exemplo, se o tamanho dos dados de um
snapshot usado for 10 GiB, o relatório de uso diário mostrará 10 GiB/(31 dias) = 0,3226 como a quantidade
consumida.
Restrições
Os instantâneos incrementais atualmente não podem ser movidos entre assinaturas.
No momento, você pode gerar apenas URIs SAS de até cinco instantâneos de uma família de instantâneos
específica em um determinado momento.
Você não pode criar um instantâneo incremental para um disco específico fora da assinatura desse disco.
Até sete instantâneos incrementais por disco podem ser criados a cada cinco minutos.
Um total de 200 instantâneos incrementais podem ser criados para um único disco.
Você não pode obter as alterações entre os instantâneos feitos antes e depois de alterar o tamanho do disco
pai entre 4 TB de limite. Por exemplo, você tirou um instantâneo de instantâneo incremental-a quando o
tamanho de um disco era 2 TB. Agora você aumentou o tamanho do disco para 6 TB e, em seguida, tirou
outro instantâneo de instantâneo incremental-b. Você não pode obter as alterações entre o instantâneo-a e o
instantâneo-b. Você precisa baixar novamente a cópia completa do instantâneo-b criado após o
redimensionamento. Subsequentemente, você pode obter as alterações entre instantâneos-b e instantâneos
criados após o instantâneo-b.
PowerShell
Portal
Você pode usar Azure PowerShell para criar um instantâneo incremental. Você precisará da versão mais recente
do Azure PowerShell, o seguinte comando o instalará ou atualizará a instalação existente para o mais recente:
Install-Module -Name Az -AllowClobber -Scope CurrentUser
Depois de instalado, faça logon na sua sessão do PowerShell com Connect-AzAccount .

Para criar um instantâneo incremental com Azure PowerShell, defina a configuração com New-
AzSnapShotConfig com o -Incremental parâmetro e, em seguida, passe-o como uma variável para New-
AzSnapshot por meio do -Snapshot parâmetro.
$diskName = "yourDiskNameHere>"
$resourceGroupName = "yourResourceGroupNameHere"
$snapshotName = "yourDesiredSnapshotNameHere"
# Get the disk that you need to backup by creating an incremental snapshot
$yourDisk = Get-AzDisk -DiskName $diskName -ResourceGroupName $resourceGroupName
# Create an incremental snapshot by setting the SourceUri property with the value of the Id property of the
disk
$snapshotConfig=New-AzSnapshotConfig -SourceUri $yourDisk.Id -Location $yourDisk.Location -CreateOption Copy
-Incremental
New-AzSnapshot -ResourceGroupName $resourceGroupName -SnapshotName $snapshotName -Snapshot $snapshotConfig
Você pode identificar instantâneos incrementais do mesmo disco com o SourceResourceId e as SourceUniqueId
Propriedades de instantâneos. SourceResourceId é a ID de recurso Azure Resource Manager do disco pai.
SourceUniqueId é o valor herdado da UniqueId Propriedade do disco. Se você for excluir um disco e, em
seguida, criar um novo disco com o mesmo nome, o valor da UniqueId propriedade será alterado.
Você pode usar SourceResourceId e SourceUniqueId para criar uma lista de todos os instantâneos associados a
um disco específico. Substitua <yourResourceGroupNameHere> pelo seu valor e, em seguida, você pode usar o
exemplo a seguir para listar seus instantâneos incrementais existentes:
$snapshots = Get-AzSnapshot -ResourceGroupName $resourceGroupName
$incrementalSnapshots = New-Object System.Collections.ArrayList

foreach ($snapshot in $snapshots)
{
if($snapshot.Incremental -and $snapshot.CreationData.SourceResourceId -eq $yourDisk.Id -and

$snapshot.CreationData.SourceUniqueId -eq $yourDisk.UniqueId){
$incrementalSnapshots.Add($snapshot)
}
}
$incrementalSnapshots
Próximas etapas
Se você quiser ver um exemplo de código que demonstra a capacidade diferencial de instantâneos incrementais,
usando o .NET, consulte copiar backups de Managed disks do Azure para outra região com capacidade
diferencial de instantâneos incrementais.
Visão geral do backup em disco do Azure (em
versão prévia)
IMPORTANT
O backup em disco do Azure está em versão prévia sem um contrato de nível de serviço e não é recomendado para
cargas de trabalho de produção. Para obter mais informações, consulte Termos de Uso Complementares de Versões
Prévias do Microsoft Azure. Para disponibilidade de região, consulte a matriz de suporte.
Preencha este formulário para se inscrever na versão prévia.
O backup em disco do Azure é uma solução de backup nativa baseada em nuvem que protege seus dados em
discos gerenciados. É uma solução simples, segura e econômica que permite configurar a proteção de discos
gerenciados em algumas etapas. Garante que você possa recuperar seus dados em um cenário de desastre.
O backup em disco do Azure oferece uma solução completa que fornece gerenciamento de ciclo de vida de
instantâneos para discos gerenciados automatizando a criação periódica de instantâneos e retendo-o para
duração configurada usando a política de backup. Você pode gerenciar os instantâneos de disco sem custo de
infraestrutura zero e sem a necessidade de script personalizado ou qualquer sobrecarga de gerenciamento. Esta
é uma solução de backup consistente com falhas que faz backup pontual de um disco gerenciado usando
instantâneos incrementais com suporte para vários backups por dia. Ela também é uma solução sem agente e
não afeta o desempenho do aplicativo de produção. Ele dá suporte a backup e restauração de sistemas
operacionais e de discos de dados (incluindo discos compartilhados), independentemente de estarem ou não
conectados a uma máquina virtual do Azure em execução.
Se você precisar de backup consistente com o aplicativo de máquina virtual, incluindo os discos de dados, ou
uma opção para restaurar uma máquina virtual inteira do backup, restaurar um arquivo ou uma pasta ou
restaurar para uma região secundária, use a solução de backup da VM do Azure . O backup do Azure oferece
suporte lado a lado para backup de discos gerenciados usando o backup em disco além das soluções de backup
de VM do Azure . Isso é útil quando você precisa de backups consistentes do aplicativo uma vez por dia de
máquinas virtuais e também de backups mais frequentes de discos do sistema operacional ou de um disco de
dados específico que são consistentes com falha e não afetam o desempenho do aplicativo de produção.
O backup em disco do Azure é integrado ao centro de backup, que fornece uma única experiência de
gerenciamento unificada no Azure para empresas para controlar, monitorar, operar e analisar backups em
escala.
Principais benefícios do backup em disco

O backup em disco do Azure é uma solução consistente sem agente e com falha que usa instantâneos
incrementais e oferece as seguintes vantagens:
Backups mais frequentes e rápidos sem interromper a máquina virtual.
Não afeta o desempenho do aplicativo de produção.
Nenhuma preocupação de segurança, pois não requer a execução de scripts personalizados nem a instalação
de agentes.
Uma solução econômica para fazer backup de discos específicos em comparação com o backup de uma
máquina virtual inteira.
A solução de backup em disco do Azure é útil nos seguintes cenários:
Necessidade de backups frequentes por dia sem que o aplicativo esteja sendo inativo
Aplicativos em execução em um cenário de cluster: o cluster de failover do Windows Server e os clusters do
Linux estão gravando em discos compartilhados
Necessidade específica de backup sem agente devido a questões de segurança ou desempenho no aplicativo
O backup consistente com o aplicativo da VM não é viável, pois os aplicativos de linha de negócios não dão
suporte a Serviço de Cópias de Sombra de Volume (VSS).
Considere o backup em disco do Azure em cenários em que:
um aplicativo de missão crítica está em execução em uma máquina virtual do Azure que exige vários
backups por dia para atender ao objetivo do ponto de recuperação, mas sem afetar o desempenho do
ambiente de produção ou do aplicativo
sua organização ou regulamento do setor restringe a instalação de agentes devido a questões de segurança
executar scripts anteriores ou posteriores personalizados e invocar congelar e descongelar em máquinas
virtuais Linux para obter o backup consistente com o aplicativo coloca uma sobrecarga indevida na
disponibilidade da carga de trabalho de produção
os aplicativos em contêineres executados no serviço kubernetes do Azure (cluster AKS) estão usando discos
gerenciados como armazenamento persistente. Hoje, você precisa fazer backup do disco gerenciado por
meio de scripts de automação que são difíceis de gerenciar.
um disco gerenciado está mantendo dados críticos para os negócios, usados como um compartilhamento de
arquivos ou contém arquivos de backup de banco e você deseja otimizar o custo de backup não investindo
no backup de VM do Azure
Você tem muitas máquinas virtuais de disco único do Linux e do Windows (ou seja, uma máquina virtual
com apenas um disco do sistema operacional e sem discos de dados anexados) que hospedam o servidor
Webou computadores sem estado ou serve como um ambiente de preparo com definições de configuração
de aplicativo e você precisa de uma solução de backup econômica para proteger o disco do sistema
operacional. Por exemplo, para disparar um backup rápido sob demanda antes de atualizar ou aplicar patch
na máquina virtual
uma máquina virtual está executando uma configuração de sistema operacional que não é suportada pela
solução de backup de VM do Azure (por exemplo, servidor do Windows 2008 32 bits)
Como funciona o processo de backup e restauração

A primeira etapa na configuração do backup para o Azure Managed disks é a criação de um cofre de
backup. O cofre fornece uma exibição consolidada dos backups configurados em diferentes cargas de
trabalho.
Em seguida, crie uma política de backup que permita configurar a frequência de backup e a duração da
retenção.
Para configurar o backup, vá para o cofre de backup, atribua uma política de backup, selecione o disco
gerenciado que precisa ser armazenado em backup e forneça um grupo de recursos no qual os
instantâneos devem ser armazenados e gerenciados. O backup do Azure dispara automaticamente os
trabalhos de backup agendados que criam um instantâneo incremental do disco de acordo com a
frequência de backup. Os instantâneos mais antigos são excluídos de acordo com a duração da retenção
especificada pela política de backup.
O backup do Azure usa instantâneos incrementais do disco gerenciado. Instantâneos incrementais são
um backup pontual e econômico de discos gerenciados que são cobrados pelas alterações delta no disco
desde o último instantâneo. Eles são sempre armazenados no armazenamento mais econômico,
armazenamento de HDD padrão, independentemente do tipo de armazenamento dos discos pai. O
primeiro instantâneo do disco ocupará o tamanho usado do disco e os instantâneos incrementais
consecutivos armazenarão as alterações delta no disco desde o último instantâneo.
Depois de configurar o backup de um disco gerenciado, uma instância de backup será criada no cofre de
backup. Usando a instância de backup, você pode encontrar a integridade das operações de backup,
disparar backups sob demanda e executar operações de restauração. Você também pode exibir a
integridade de backups em vários cofres e instâncias de backup usando o centro de backup, que fornece
um único painel de exibição de vidro.
Para restaurar, basta selecionar o ponto de recuperação do qual você deseja restaurar o disco. Forneça o
grupo de recursos em que o disco restaurado deve ser criado a partir do instantâneo. O backup do Azure
fornece uma experiência de restauração instantânea, já que os instantâneos são armazenados localmente
em sua assinatura.
O cofre de backup usa identidade gerenciada para acessar outros recursos do Azure. Para configurar o
backup de um disco gerenciado e restaurar do backup anterior, a identidade gerenciada do cofre de
backup requer um conjunto de permissões no disco de origem, o grupo de recursos de instantâneo em
que os instantâneos são criados e gerenciados e o grupo de recursos de destino no qual você deseja
restaurar o backup. Você pode conceder permissões para a identidade gerenciada usando o controle de
acesso baseado em função do Azure (RBAC do Azure). A identidade gerenciada é uma entidade de
serviço de um tipo especial que pode ser usada apenas com recursos do Azure. Saiba mais sobre
identidades gerenciadas.
Atualmente, o backup em disco do Azure dá suporte ao backup operacional de discos gerenciados e não
copia os backups para o armazenamento do cofre de backup. Consulte a matriz de suportepara obter
uma lista detalhada de cenários com e sem suporte e disponibilidade de região.
Preços
O backup do Azure oferece uma solução de gerenciamento de ciclo de vida de instantâneo para proteger discos
do Azure. Os instantâneos de disco criados pelo backup do Azure são armazenados no grupo de recursos em
sua assinatura do Azure e incorrem em encargos de armazenamento de instantâneos . Você pode visitar
preços do disco gerenciado para obter mais detalhes sobre os preços do instantâneo. Como os instantâneos não
são copiados para o cofre de backup, o backup do Azure não cobra uma taxa de instância protegida e o custo
de armazenamento de backup não se aplica. Além disso, os instantâneos incrementais ocupam alterações
delta desde o último instantâneo e sempre são armazenados no armazenamento Standard, independentemente
do tipo de armazenamento dos discos gerenciados pelo pai e são cobrados de acordo com o preço do
armazenamento padrão. Isso torna o backup em disco do Azure uma solução econômica.
Próximas etapas
Matriz de suporte de Backup de Disco do Azure
Fazer backup do Azure Managed Disks (em versão
prévia)
IMPORTANT
Este artigo explica como fazer backup do disco gerenciado do Azure no portal do Azure.
Neste artigo, você aprenderá a:
Criar um cofre de backup
Criar uma política de backup
Configurar um backup de um disco do Azure
Executar um trabalho de backup sob demanda
Para obter informações sobre a disponibilidade da região de backup em disco do Azure, cenários e limitações
com suporte, consulte a matriz de suporte.
Criar um cofre de backup

Um cofre de backup é uma entidade de armazenamento no Azure que mantém dados de backup para várias
cargas de trabalho mais recentes com suporte no backup do Azure, como o banco de dados do Azure para
servidores PostgreSQL e discos do Azure. Os cofres de backup facilitam a organização dos dados de backup,
minimizando a sobrecarga de gerenciamento. Os cofres de backup são baseados no modelo de Azure Resource
Manager do Azure, que fornece recursos avançados para ajudar a proteger os dados de backup.
2. Digite centro de backup na caixa de pesquisa.
3. Em Ser viços , selecione centro de backup .
4. Na página centro de backup , selecione cofre .
5. Na tela Iniciar : criar cofre , selecione cofre de backup e continue .
6. Na guia noções básicas , forneça assinatura, grupo de recursos, nome do cofre de backup, região e
redundância de armazenamento de backup. Continue selecionando revisar + criar . Saiba mais sobre
como criar um cofre de backup.
Criar política de backup
1. No cofre de backup do DemoVault criado na etapa anterior, vá para políticas de backup e selecione
Adicionar .
2. Na guia noções básicas , forneça o nome da política, selecione o tipo DataSource como disco do
Azure . O cofre já foi preenchido previamente e as propriedades do cofre selecionado são apresentadas.
NOTE
Embora o cofre selecionado possa ter a configuração de redundância global, atualmente o backup em disco do
Azure dá suporte apenas ao armazenamento de instantâneos de snapshot. Todos os backups são armazenados
em um grupo de recursos em sua assinatura e não são copiados para o armazenamento do cofre de backup.
3. Na guia política de backup , selecione a frequência de agendamento de backup.
O backup em disco do Azure oferece vários backups por dia. Se você precisar de backups mais
frequentes, escolha a frequência de backup por hora com a capacidade de fazer backups com intervalos
de cada 4, 6, 8 ou 12 horas. Os backups são agendados com base no intervalo de tempo selecionado.
Por exemplo, se você selecionar a cada 4 horas , os backups serão feitos em aproximadamente no
intervalo de cada 4 horas para que os backups sejam distribuídos igualmente ao longo do dia. Se um
backup de um dia for suficiente, escolha a frequência de backup diária . Na frequência de backup diário,
você pode especificar a hora do dia em que os backups são feitos. É importante observar que a hora do
dia indica a hora de início do backup e não a hora em que o backup foi concluído. O tempo necessário
para concluir a operação de backup depende de vários fatores, incluindo o tamanho do disco e a taxa de
rotatividade entre backups consecutivos. No entanto, o backup em disco do Azure é um backup sem
agente que usa instantâneos incrementais, o que não afeta o desempenho do aplicativo de produção.
4. Na guia política de backup , selecione as configurações de retenção que atendem ao requisito de
objetivo de ponto de recuperação (RPO).
A regra de retenção padrão se aplicará se nenhuma outra regra de retenção for especificada. A regra de
retenção padrão pode ser modificada para alterar a duração da retenção, mas não pode ser excluída.
Você pode adicionar uma nova regra de retenção selecionando Adicionar regra de retenção .
Você pode escolher o primeiro backup bem-sucedido feito diariamente ou semanalmente e fornecer
a duração da retenção de que os backups específicos devem ser retidos antes de serem excluídos. Essa
opção é útil para reter backups específicos do dia ou da semana para uma duração mais longa do tempo.
Todos os outros backups frequentes podem ser retidos por uma duração menor.
NOTE
O backup do Azure para Managed Disks usa instantâneos incrementais limitados a 200 instantâneos por disco.
Para permitir que você faça backups sob demanda além dos backups agendados, a política de backup limita o
total de backups a 180. Saiba mais sobre instantâneos incrementais do disco gerenciado.
5. Conclua a criação da política de backup selecionando examinar + criar .
Configurar backup
O cofre de backup usa identidade gerenciada para acessar outros recursos do Azure. Para configurar o backup
de discos gerenciados, a identidade gerenciada do cofre de backup requer um conjunto de permissões nos
discos de origem e nos grupos de recursos em que os instantâneos são criados e gerenciados.
Uma identidade gerenciada atribuída pelo sistema é restrita a uma por recurso e está vinculada ao ciclo de vida
deste recurso. Você pode conceder permissões para a identidade gerenciada usando o controle de acesso
baseado em função do Azure (RBAC do Azure). A identidade gerenciada é uma entidade de serviço de um tipo
especial que pode ser usada apenas com recursos do Azure. Saiba mais sobre identidades gerenciadas.
Os seguintes pré-requisitos são necessários para configurar o backup de discos gerenciados:
1. Atribua a função leitor de backup de disco à identidade gerenciada do cofre de backup no disco de
origem cujo backup deve ser feito.
a. Vá para o disco que precisa ser submetido a backup.
b. Vá para controle de acesso (iam) e selecione Adicionar atribuições de função
c. No painel de contexto à direita, selecione leitor de backup em disco na lista suspensa função .
Selecione a identidade gerenciada do cofre de backup e salve .
TIP
Digite o nome do cofre de backup para selecionar a identidade gerenciada do cofre.
2. Atribua a função de colaborador de instantâneo de disco à identidade gerenciada do cofre de

backup no grupo de recursos em que os backups são criados e gerenciados pelo serviço de backup do
Azure. Os instantâneos de disco são armazenados em um grupo de recursos em sua assinatura. Para
permitir que o serviço de backup do Azure crie, armazene e gerencie instantâneos, você precisa fornecer
permissões para o cofre de backup.
Escolhendo o grupo de recursos para armazenar e gerenciar instantâneos:
Não selecione o mesmo grupo de recursos do disco de origem.
Como uma diretriz, é recomendável criar um grupo de recursos dedicado como um repositório de
armazenamento de instantâneo a ser usado pelo serviço de backup do Azure. Ter um grupo de
recursos dedicado permite restringir as permissões de acesso no grupo de recursos, fornecendo
segurança e facilidade de gerenciamento dos dados de backup.
Você pode usar esse grupo de recursos para armazenar instantâneos em vários discos que estão
sendo incluídos no backup (ou planejado).
Você não pode criar um instantâneo incremental para um disco específico fora da assinatura desse
disco. Portanto, escolha o grupo de recursos na mesma assinatura do disco do qual será feito o
backup. Saiba mais sobre o instantâneo incremental para discos gerenciados.
Para atribuir a função, siga estas etapas:
a. Vá para o grupo de recursos. Por exemplo, o grupo de recursos é SnapshotRG, que está na mesma
assinatura do disco do qual será feito o backup.
b. Vá para controle de acesso (iam) e selecione Adicionar atribuições de função .
c. No painel de contexto à direita, selecione colaborador de instantâneo de disco na lista
suspensa função . Selecione a identidade gerenciada do cofre de backup e salve .
TIP
3. Verifique se a identidade gerenciada do cofre de backup tem o conjunto correto de atribuições de função
no disco de origem e no grupo de recursos que serve como o repositório de armazenamento de
instantâneo.
a. Vá para cofre de backup-> identidade e selecione atribuições de função do Azure .
b. Verifique se a função, o nome do recurso e o tipo de recurso estão refletidos corretamente.

NOTE
Embora as atribuições de função sejam refletidas corretamente no portal, pode levar aproximadamente 15
minutos para que a permissão seja aplicada na identidade gerenciada do cofre de backup.
4. Depois que os pré-requisitos forem atendidos, vá para cofre de backup-> visão geral e selecione
backup para começar a configurar o backup dos discos.
5. Na guia noções básicas , selecione Azure Disk como o tipo DataSource.

NOTE
O backup do Azure usa instantâneos incrementais de discos gerenciados, que armazenam apenas as alterações
delta no disco desde o último instantâneo no armazenamento de HDD Standard, independentemente do tipo de
armazenamento do disco pai. Para obter confiabilidade adicional, os instantâneos incrementais são armazenados
no armazenamento com redundância de zona (ZRS) por padrão em regiões que dão suporte a ZRS. Atualmente, o
backup em disco do Azure dá suporte ao backup operacional de discos gerenciados que não copia os backups
para o armazenamento do cofre de backup. Portanto, a configuração de redundância de armazenamento de
backup do cofre de backup não se aplica aos pontos de recuperação.
6. Na guia política de backup , escolha uma política de backup.
7. Na guia recursos , selecione selecionar disco do Azure . No painel de contexto à direita, selecione os
discos cujo backup será feito.
NOTE
Embora o portal permita que você selecione vários discos e configure o backup, cada disco é uma instância de
backup individual. Atualmente, o backup em disco do Azure só dá suporte ao backup de discos individuais. Não
há suporte para o backup pontual de vários discos anexados a um disco virtual.
Ao usar o portal, você está limitado a selecionar os discos na mesma assinatura. Se você tiver vários discos para
fazer backup ou se os discos estiverem espalhados por uma assinatura diferente, você poderá usar scripts para
automatizar.
Para obter mais informações sobre a disponibilidade da região de backup em disco do Azure, cenários e limitações
com suporte, consulte a matriz de suporte.
8. Selecione um grupo de recursos de instantâneo e selecione validar . Esse é o grupo de recursos em

que o serviço de backup do Azure criou e gerencia os instantâneos incrementais para o cofre de backup.
A identidade gerenciada é atribuída com as permissões de função necessárias como parte dos pré-
requisitos.
NOTE
A validação pode levar alguns minutos para ser concluída antes que você possa concluir a configuração do fluxo
de trabalho de backup. A validação poderá falhar se:
Não há suporte para um disco. Consulte a matriz de suporte para cenários sem suporte.
a identidade gerenciada do cofre de backup não tem atribuições de função válidas no disco para fazer backup
ou no grupo de recursos de instantâneo em que os instantâneos incrementais são armazenados.
9. Após uma validação bem-sucedida, selecione revisar e configurar para configurar o backup dos discos
selecionados.
Executar um backup sob demanda

1. No cofre de backup do DemoVault criado na etapa anterior, vá para instâncias de backup e selecione
uma instância de backup.
2. Na tela instâncias de backup , você encontrará:

informações essenciais , incluindo o nome do disco de origem, o grupo de recursos de instantâneo
em que os instantâneos incrementais são armazenados, cofre de backup e política de backup.
Status do trabalho mostrando o resumo das operações de backup e restauração e seu status nos
últimos sete dias.
Uma lista de pontos de restauração para o período de tempo selecionado.
3. Selecione backup para iniciar um backup sob demanda.
4. Selecione uma das regras de retenção associadas à política de backup. Essa regra de retenção
determinará a duração da retenção deste backup sob demanda. Selecione fazer backup agora para
iniciar o backup.
Rastrear uma operação de backup

O serviço de backup do Azure cria um trabalho para backups agendados ou se você disparar a operação de
backup sob demanda para acompanhamento. Para exibir o status do trabalho de backup:
1. Vá para a tela de instância de backup . Ele mostra o painel trabalhos com a operação e o status dos
últimos sete dias.
2. Para exibir o status da operação de backup, selecione Exibir tudo para mostrar os trabalhos em
andamento e passados desta instância de backup.
3. Examine a lista de trabalhos de backup e restauração e seu status. Selecione um trabalho na lista de
trabalhos para exibir detalhes do trabalho.
Próximas etapas
Restaurar Managed Disks do Azure
Restaurar Managed Disks do Azure (em versão
prévia)
IMPORTANT
Este artigo explica como restaurar Managed disks do Azure de um ponto de restauração criado pelo backup do
Azure.
Atualmente, a opção de recuperação de Original-Location (OLR) de restauração substituindo o disco de origem
existente do qual os backups foram feitos não tem suporte. Você pode restaurar de um ponto de recuperação
para criar um novo disco no mesmo grupo de recursos do disco de origem do qual os backups foram feitos ou
em qualquer outro grupo de recursos. Isso é conhecido como ALR (recuperação de Alternate-Location) e isso
ajuda a manter o disco de origem e o disco restaurado (novo).
Neste artigo, você aprenderá a:
Restaurar para criar um novo disco
Acompanhar o status da operação de restauração
Restaurar para criar um novo disco

O cofre de backup usa identidade gerenciada para acessar outros recursos do Azure. Para restaurar do backup, a
identidade gerenciada do cofre de backup requer um conjunto de permissões no grupo de recursos em que o
disco deve ser restaurado.
O cofre de backup usa uma identidade gerenciada atribuída pelo sistema, que é restrita a um por recurso e está
vinculada ao ciclo de vida deste recurso. Você pode conceder permissões para a identidade gerenciada usando o
controle de acesso baseado em função do Azure (RBAC do Azure). A identidade gerenciada é uma entidade de
serviço de um tipo especial que pode ser usada apenas com recursos do Azure. Saiba mais sobre identidades
gerenciadas.
Os pré-requisitos a seguir são necessários para executar uma operação de restauração:
1. Atribua a função de operador de restauração de disco à identidade gerenciada do cofre de backup
no grupo de recursos em que o disco será restaurado pelo serviço de backup do Azure.
NOTE
Você pode escolher o mesmo grupo de recursos do disco de origem de onde os backups são feitos ou para
qualquer outro grupo de recursos na mesma ou em uma assinatura diferente.
a. Vá para o grupo de recursos no qual o disco deve ser restaurado. Por exemplo, o grupo de
recursos é TargetRG.
b. Vá para controle de acesso (iam) e selecione Adicionar atribuições de função
c. No painel de contexto à direita, selecione operador de restauração de disco na lista suspensa
função . Selecione a identidade gerenciada do cofre de backup e salve .
TIP
2. Verifique se a identidade gerenciada do cofre de backup tem o conjunto correto de atribuições de função
no grupo de recursos em que o disco será restaurado.
a. Vá para cofre de backup-> identidade e selecione atribuições de função do Azure
b. Verifique se a função, o nome do recurso e o tipo de recurso aparecem corretamente.

NOTE
Embora as atribuições de função sejam refletidas corretamente no portal, pode levar aproximadamente 15
minutos para que a permissão seja aplicada na identidade gerenciada do cofre de backup.
Durante os backups agendados ou uma operação de backup sob demanda, o backup do Azure armazena os
instantâneos incrementais de disco no grupo de recursos de instantâneo fornecido durante a configuração do
backup do disco. O backup do Azure usa esses instantâneos incrementais durante a operação de restauração. Se
os instantâneos forem excluídos ou movidos do grupo de recursos de instantâneo ou se as atribuições de função
do cofre de backup forem revogadas no grupo de recursos de instantâneo, a operação de restauração falhará.
3. Se o disco a ser restaurado for criptografado com chaves gerenciadas pelo cliente (CMK) ou usando a
criptografia dupla usando chaves gerenciadas por plataforma e chaves gerenciadas pelo cliente, atribua a
permissão de função de leitor à identidade gerenciada do cofre de backup no recurso de conjunto de
criptografia de disco .
Depois que os pré-requisitos forem atendidos, siga estas etapas para executar a operação de restauração.
1. Na portal do Azure, vá para o centro de backup . Selecione instâncias de backup na seção gerenciar
. Na lista de instâncias de backup, selecione a instância de backup em disco para a qual você deseja
executar a operação de restauração.
Como alternativa, você pode executar essa operação no cofre de backup usado para configurar o backup
do disco.
2. Na tela instância de backup , selecione o ponto de restauração que você deseja usar para executar a
operação de restauração e selecione restaurar .
3. No fluxo de trabalho de restauração , examine os conceitos básicos e selecione informações da guia
ponto de recuperação e selecione Avançar : restaurar parâmetros .
4. Na guia restaurar parâmetros , selecione a assinatura de destino e o grupo de recursos de

destino para onde você deseja restaurar o backup. Forneça o nome do disco a ser restaurado. Selecione
Avançar : revisar + restaurar .
TIP
Os discos cujo backup foi feito pelo backup do Azure usando a solução de backup em disco também podem ser
submetidos a backup pelo backup do Azure usando a solução de backup de VM do Azure com o cofre dos
serviços de recuperação. Se você tiver configurado a proteção da VM do Azure à qual esse disco está anexado,
também poderá usar a operação de restauração de VM do Azure. Você pode optar por restaurar a VM, ou discos
e arquivos ou pastas do ponto de recuperação da instância de backup de VM do Azure correspondente. Para
obter mais informações, consulte backup de VM do Azure.
5. Depois que a validação for bem-sucedida, selecione restaurar para iniciar a operação de restauração.
NOTE
A validação pode levar alguns minutos para ser concluída antes que você possa disparar a operação de
restauração. A validação poderá falhar se:
um disco com o mesmo nome fornecido no nome do disco restaurado já existe no grupo de recursos
de destino
a identidade gerenciada do cofre de backup não tem atribuições de função válidas no grupo de recursos de
destino
as atribuições da função de identidade gerenciada do cofre de backup são revogadas no grupo de recursos
de instantâneo em que os instantâneos incrementais são armazenados
Se instantâneos incrementais forem excluídos ou movidos do grupo de recursos de instantâneo
A restauração criará um novo disco do ponto de recuperação selecionado no grupo de recursos de destino que
foi fornecido durante a operação de restauração. Para usar o disco restaurado em uma máquina virtual
existente, você precisará executar mais etapas:
Se o disco restaurado for um disco de dados, você poderá anexar um disco existente a uma máquina
virtual. Se o disco restaurado for um disco do sistema operacional, você poderá trocar o disco do sistema
operacional de uma máquina virtual da portal do Azure no menu painel da máquina vir tual – > discos
na seção configurações .
Para máquinas virtuais do Windows, se o disco restaurado for um disco de dados, siga as instruções para
desanexar o disco de dados original da máquina virtual. Em seguida, anexe o disco restaurado à máquina
virtual. Siga as instruções para trocar o disco do sistema operacional da máquina virtual pelo disco
restaurado.
Para máquinas virtuais do Linux, se o disco restaurado for um disco de dados, siga as instruções para
desanexar o disco de dados original da máquina virtual. Em seguida, anexe o disco restaurado à máquina
virtual. Siga as instruções para trocar o disco do sistema operacional da máquina virtual pelo disco
restaurado.
É recomendável revogar a atribuição de função do operador de restauração de disco da identidade
gerenciada do cofre de backup no grupo de recursos de destino após a conclusão bem-sucedida da operação
de restauração.
Rastrear uma operação de restauração

Após disparar a operação de restauração, o serviço de backup cria um trabalho para acompanhamento. O
Backup do Azure exibe notificações sobre o trabalho no portal. Para exibir o progresso do trabalho de
restauração:
1. Vá para a tela de instância de backup . Ele mostra o painel trabalhos com a operação e o status dos
últimos sete dias.
2. Para exibir o status da operação de restauração, selecione Exibir tudo para mostrar os trabalhos em
andamento e passados desta instância de backup.
3. Examine a lista de trabalhos de backup e restauração e seu status. Selecione um trabalho na lista de
trabalhos para exibir detalhes do trabalho.
Próximas etapas
FAQ do backup em disco do Azure
Backup e recuperação de desastre de discos de IaaS
do Azure
Este artigo explica como planejar o backup e a DR (recuperação de desastre) de VMs (máquinas virtuais) e
discos de IaaS no Azure. Este documento aborda discos gerenciados e discos não gerenciados.
Primeiro, abordamos as funcionalidades internas de tolerância a falhas da plataforma Azure que ajudam a
proteger contra falhas locais. Em seguida, abordamos os cenários de desastre que não são totalmente cobertos
pelas funcionalidades internas. Também mostramos vários exemplos de cenários de carga de trabalho nos quais
diferentes considerações sobre backup e DR se aplicam. Depois, examinamos possíveis soluções para DR de
discos de IaaS.
Introdução
A plataforma Azure usa vários métodos de redundância e tolerância a falhas para ajudar a proteger os clientes
contra falhas de hardware localizadas. Falhas locais podem incluir problemas com um computador de servidor
do Armazenamento do Azure que armazena parte dos dados de um disco virtual ou falhas de um SSD ou HD
nesse servidor. Falhas de componente de hardware isoladas como essas podem ocorrer durante operações
normais.
A plataforma Azure foi projetada para ser resiliente a essas falhas. Desastres graves podem resultar em falhas
ou na incapacidade de acesso de muitos servidores de armazenamento ou até mesmo de um datacenter inteiro.
Embora as VMs e os discos normalmente sejam protegidos contra falhas localizadas, etapas adicionais são
necessárias para proteger a carga de trabalho contra falhas catastróficas de toda a região, como um desastre
grave, que podem afetar a VM e os discos.
Além da possibilidade de falhas na plataforma, podem ocorrer problemas com os dados ou o aplicativo de um
cliente. Por exemplo, uma nova versão do aplicativo pode inadvertidamente fazer uma alteração nos dados que
provoca sua interrupção. Nesse caso, talvez você deseje reverter o aplicativo e os dados para uma versão
anterior que contém o último estado válido conhecido. Isso exige a manutenção de backups regulares.
Para a recuperação de desastre regional, você deve fazer backup dos discos da VM de IaaS em outra região.
Antes de examinarmos as opções de backup e DR, vamos recapitular alguns métodos disponíveis para o
tratamento de falhas localizadas.
Resiliência de IaaS do Azure
Resiliência refere-se à tolerância a falhas normais que ocorrem em componentes de hardware. A resiliência é a
capacidade de se recuperar de falhas e continuar funcionando. Não se trata de evitar falhas, mas responder a
elas de uma maneira que evite o tempo de inatividade ou a perda de dados. A meta de resiliência é retornar o
aplicativo a um estado totalmente funcional após uma falha. As máquinas virtuais e os discos do Azure foram
projetados para serem resilientes a falhas comuns de hardware. Vamos dar uma olhada em como a plataforma
de IaaS do Azure fornece essa resiliência.
Uma máquina virtual consiste principalmente em duas partes: um servidor de computação e os discos
persistentes. Ambos afetam a tolerância a falhas de uma máquina virtual.
Se o servidor host de computação do Azure que hospeda a VM tiver uma falha de hardware, o que é raro, o
Azure restaurará automaticamente a VM em outro servidor, pois foi projetado para isso. Se esse cenário ocorrer,
o computador será reinicializado e a VM volta a funcionar após algum tempo. O Azure detecta essas falhas de
hardware automaticamente e executa recuperações para ajudar a garantir que a VM do cliente estará disponível
assim que possível.
Em relação aos discos de IaaS, a durabilidade dos dados é crítica para uma plataforma de armazenamento
persistente. Os clientes do Azure têm aplicativos de negócios importantes em execução na IaaS e dependem da
persistência dos dados. O Azure projeta a proteção para esses discos de IaaS, com três cópias redundantes dos
dados armazenados localmente. Essas cópias fornecem alta durabilidade contra falhas locais. Se um dos
componentes de hardware que contém o disco falhar, a VM não será afetada porque há duas cópias adicionais
para dar suporte às solicitações do disco. Isso funcionará bem, mesmo se dois componentes de hardware
diferentes que dão suporte a um disco falharem ao mesmo tempo (o que é raro).
Para ajudar a garantir que você sempre mantém três réplicas, o Armazenamento do Azure gera
automaticamente uma nova cópia dos dados em segundo plano se uma das três cópias não fica disponível.
Portanto, não deve ser necessário usar o RAID com discos do Azure para a tolerância a falhas. Uma simples
configuração RAID 0 deve ser suficiente para a distribuição dos discos, se necessário, para criar volumes
maiores.
Devido a essa arquitetura, o Azure proporcionou durabilidade de nível empresarial de modo consistente para
discos de IaaS, com uma taxa de falha anualizada líder do setor de 0%.
Falhas de hardware localizadas no host de computação ou na plataforma de Armazenamento podem, às vezes,
resultar na indisponibilidade temporária para a VM que é coberta pelo SLA do Azure em relação à
disponibilidade da VM. O Azure também fornece um SLA líder do setor para instâncias de VM individuais que
usam SSDs premium do Azure.
Para proteger cargas de trabalho do aplicativo contra o tempo de inatividade devido à indisponibilidade
temporária de um disco ou de uma VM, os clientes podem usar conjuntos de disponibilidade. Duas ou mais
máquinas virtuais em um conjunto de disponibilidade fornecem redundância para o aplicativo. Em seguida, o
Azure cria essas VMs e esses discos em domínios de falha separados com diferentes componentes de energia,
rede e servidor.
Devido a esses domínios de falha separados, as falhas de hardware localizadas geralmente não afetam várias
VMs no conjunto ao mesmo tempo. Ter domínios de falha separados fornece alta disponibilidade para o
aplicativo. É considerada uma melhor prática usar conjuntos de disponibilidade quando a alta disponibilidade é
necessária. A próxima seção aborda o aspecto de recuperação de desastre.
Backup e recuperação de desastres
A recuperação de desastre é a capacidade de recuperação de incidentes raros, mas importantes. Esses incidentes
incluem falhas não transitórias de larga escala, como interrupções de serviço que afetam toda uma região. A
recuperação de desastre inclui backup e arquivamento de dados e pode incluir a intervenção manual, como a
restauração um banco de dados com base em um backup.
A proteção interna da plataforma Azure contra falhas localizadas poderá não proteger totalmente as VMs e os
discos se desastres graves causarem interrupções em grande escala. Isso inclui interrupções em larga escala,
como se um data center for atingido por um furacão, terremoto, incêndio ou se houver falhas de unidade de
hardware em grande escala. Além disso, você pode encontrar falhas devido a problemas dos dados ou do
aplicativo.
Para ajudar a proteger as cargas de trabalho de IaaS contra interrupções, você deve planejar a redundância e ter
backups para permitir a recuperação. Para a recuperação de desastre, você deve fazer backup em uma
localização geográfica diferente fora do site primário. Essa abordagem ajuda a garantir que o backup não é
afetado pelo mesmo evento que originalmente afetou a VM ou os discos. Para obter mais informações, consulte
Recuperação de desastre para aplicativos do Azure.
Suas considerações sobre DR podem incluir os seguintes aspectos:
Alta disponibilidade: A capacidade do aplicativo de continuar em execução em um estado íntegro, sem
tempo de inatividade significativo. Por estado íntegro, esse estado significa que o aplicativo está
respondendo e que os usuários podem se conectar ao aplicativo e interagir com ele. Alguns aplicativos e
bancos de dados críticos podem precisar estar sempre disponíveis, mesmo quando há falhas na
plataforma. Para essas cargas de trabalho, talvez você precise planejar a redundância para o aplicativo,
bem como para os dados.
Durabilidade dos dados: Em alguns casos, a principal consideração é garantir que os dados são
preservados no caso de um desastre. Portanto, talvez seja necessário fazer um backup dos dados em
outro site. Para essas cargas de trabalho, talvez não seja necessário ter a redundância total para o
aplicativo, mas apenas um backup regular dos discos.
Cenários de backup e DR
Vamos examinar alguns exemplos típicos de cenários de carga de trabalho do aplicativo e as considerações
sobre o planejamento da recuperação de desastre.
Cenário 1: Principais soluções de banco de dados
Considere um servidor de banco de dados de produção, como o SQL Server ou o Oracle, que pode dar suporte
à alta disponibilidade. Usuários e aplicativos de produção críticos dependem desse banco de dados. O plano de
recuperação de desastre para esse sistema pode precisar dar suporte aos seguintes requisitos:
Os dados devem ser protegidos e recuperáveis.
O servidor deve estar disponível para uso.
O plano de recuperação de desastre pode exigir a manutenção de uma réplica do banco de dados em outra
região como um backup. Dependendo dos requisitos de disponibilidade do servidor e de recuperação de dados,
a solução pode variar de um site de réplica ativo-ativo ou ativo-passivo para backups offline periódicos dos
dados. Bancos de dados relacionais, como o SQL Server e o Oracle, fornecem várias opções de replicação. Para o
SQL Server, use Grupos de Disponibilidade AlwaysOn do SQL Server para alta disponibilidade.
Bancos de dados NoSQL, como o MongoDB, também dão suporte a réplicas para redundância. As réplicas para
alta disponibilidade são usadas.
Cenário 2: Um cluster de VMs redundantes
Considere uma carga de trabalho manipulada por um cluster de VMs que fornece redundância e balanceamento
de carga. Um exemplo é um cluster do Cassandra implantado em uma região. Esse tipo de arquitetura já fornece
um alto nível de redundância nessa região. No entanto, para proteger a carga de trabalho contra uma falha de
nível regional, você deve considerar a distribuição do cluster em duas regiões ou a realização de backups
periódicos em outra região.
Cenário 3: Carga de trabalho de aplicativos IaaS
Vamos examinar a carga de trabalho de aplicativos IaaS. Por exemplo, isso pode ser uma carga de trabalho de
produção típica em execução em uma VM do Azure. Isso pode ser um servidor Web ou servidor de arquivos
que mantém o conteúdo e outros recursos de um site. Também pode ser um aplicativo de negócios
personalizado em execução em uma VM que armazenou seus dados, recursos e o estado do aplicativo nos
discos da VM. Nesse caso, é importante fazer backups regularmente. A frequência de backup deve se basear na
natureza da carga de trabalho da VM. Por exemplo, se o aplicativo é executado diariamente e modifica dados, o
backup deve ser feito a cada hora.
Outro exemplo é um servidor de relatórios que efetua pull de dados de outras fontes e gera relatórios
agregados. A perda dessa VM ou desses discos poderá levar à perda dos relatórios. No entanto, talvez seja
possível executar o processo de relatórios novamente e regenerar o resultado. Nesse caso, você realmente não
tem uma perda de dados, mesmo se o servidor de relatório é atingido por um desastre. Como resultado, talvez
você tenha um nível mais alto de tolerância da perda de parte dos dados no servidor de relatório. Nesse caso,
backups menos frequentes são uma opção para reduzir os custos.
Cenário 4: Problemas de dados de aplicativos IaaS
Problemas de dados de aplicativos IaaS são outra possibilidade. Considere um aplicativo que calcula, mantém e
fornece dados comerciais críticos, como informações sobre preços. Uma nova versão do aplicativo tinha um bug
de software que calculava os preços incorretamente e corrompeu os dados comerciais existentes fornecidos
pela plataforma. Aqui, a melhor decisão é reverter para a versão anterior do aplicativo e dos dados. Para
possibilitar isso, faça backups periódicos do sistema.
Solução de recuperação de desastre: Serviço de Backup do Azure

O Backup do Azure é usado para backups e DR e funciona com discos gerenciados, bem como com discos não
gerenciados. Crie um trabalho de backup com backups baseados em tempo, fácil restauração de VM e políticas
de retenção de backup.
Se você usar SSDs premium, discos gerenciados ou outros tipos de disco com a opção armazenamento com
redundância local, é especialmente importante fazer backups periódicos de DR. O Backup do Azure armazena os
dados no cofre dos serviços de recuperação para retenção de longo prazo. Escolha a opção armazenamento
com redundância geográfica para o cofre dos serviços de recuperação de backup. Essa opção garante que os
backups são replicados em outra região do Azure para proteger contra desastres regionais.
Para discos não gerenciados, use o tipo de armazenamento com redundância local para discos de IaaS, mas
verifique se o Backup do Azure está habilitado com a opção de armazenamento com redundância geográfica no
cofre dos serviços de recuperação.
NOTE
Se você usar a opção armazenamento com redundância geográfica ou armazenamento com redundância geográfica com
acesso de leitura para seus discos não gerenciados, ainda precisará de instantâneos consistentes para backup e
recuperação de desastre. Use o Backup do Azure ou instantâneos consistentes.
A tabela a seguir é um resumo das soluções disponíveis para DR.
C EN Á RIO REP L IC A Ç Ã O A UTO M ÁT IC A SO L UÇ Ã O DE DR
Discos SSD Premium Local (armazenamento com Serviço de Backup do Azure

redundância local)
Discos gerenciados Local (armazenamento com Serviço de Backup do Azure

redundância local)
Discos não gerenciados com Local (armazenamento com Serviço de Backup do Azure
armazenamento com redundância redundância local)
local
Discos não gerenciados com Várias regiões (armazenamento com Serviço de Backup do Azure
armazenamento com redundância redundância geográfica) Instantâneos consistentes
geográfica
Discos não gerenciados de Entre regiões (armazenamento com Serviço de Backup do Azure
armazenamento com redundância redundância geográfica com acesso de Instantâneos consistentes
geográfica com acesso de leitura leitura)
A alta disponibilidade é melhor alcançada com discos gerenciados em um conjunto de disponibilidade junto
com o Backup do Azure. Se você usar discos não gerenciados, ainda poderá usar o Backup do Azure para DR. Se
não for possível usar o Backup do Azure, tirar instantâneos consistentes, conforme descrito em uma seção
posterior, é uma solução alternativa para backup e DR.
Suas escolhas de alta disponibilidade, backup e DR nos níveis do aplicativo ou da infraestrutura podem ser
representadas da seguinte maneira:
N ÍVEL A LTA DISP O N IB IL IDA DE B A C K UP O U DR
Aplicativo SQL Server AlwaysOn Serviço de Backup do Azure
Infraestrutura Conjunto de disponibilidade Armazenamento com redundância

geográfica com instantâneos
consistentes
Usando o Backup do Azure

O Backup do Azure pode fazer backup das VMs que executam Windows ou Linux no cofre dos serviços de
recuperação do Azure. Fazer backup e restaurar dados críticos para os negócios é complicado, pois os dados
críticos para os negócios precisam ser copiados em backup enquanto os aplicativos que produzem os dados
estão em execução.
Para resolver esse problema, o Backup do Azure fornece backups consistentes com o aplicativo para cargas de
trabalho da Microsoft. Ele usa o serviço de sombra de volume para garantir que os dados são gravados
corretamente no armazenamento. Para VMs do Linux, o modo de consistência do backup padrão são backups
consistentes com o arquivo, pois o Linux não tem uma funcionalidade equivalente ao serviço de sombra de
volume, como no caso do Windows. Para computadores Linux, confira Backup consistente com o aplicativo de
VMs do Linux no Azure.
Quando o Backup do Azure inicia um trabalho de backup no horário agendado, ele dispara a extensão de
backup instalada na VM para tirar um instantâneo pontual. Um instantâneo é tirado em conjunto com o serviço
de sombra de volume para obter um instantâneo consistente dos discos na máquina virtual sem precisar
desligá-la. A extensão de backup na VM libera todas as gravações antes de tirar um instantâneo consistente de
todos os discos. Depois de tirar o instantâneo, os dados são transferidos pelo Backup do Azure para o cofre de
backup. Para tornar o processo de backup mais eficiente, o serviço identifica e transfere apenas os blocos de
dados que foram alterados após o último backup.
Para restaurar, exiba os backups disponíveis por meio do Backup do Azure e, em seguida, inicie uma restauração.
Crie e restaure backups do Azure por meio do portal do Azure, usando o PowerShell ou usando a CLI do Azure.
Etapas para habilitar um backup
Use as etapas a seguir para habilitar backups das VMs usando o portal do Azure. Há algumas variações
dependendo do cenário exato. Consulte a documentação do Backup do Azure para obter detalhes completos. O
Backup do Azure também dá suporte a VMs com discos gerenciados.
1. Crie um cofre dos serviços de recuperação para uma VM:
a. No portal do Azure, procure Todos os recursos e localize Cofres dos Ser viços de Recuperação .
b. No menu Cofres dos Ser viços de Recuperação , clique em Adicionar e siga as etapas para criar
um novo cofre na mesma região da VM. Por exemplo, se a VM estiver na região Oeste dos EUA, escolha
Oeste dos EUA para o cofre.
2. Verifique a replicação de armazenamento do cofre recém-criado. Acesse o cofre em Cofres dos
Ser viços de Recuperação e acesse Propriedades > Configuração de Backup > Atualizar .
Verifique se a opção Armazenamento com redundância geográfica está selecionada por padrão.
Essa opção garante que o cofre é replicado automaticamente em um data center secundário. Por
exemplo, o cofre do Oeste dos EUA é replicado automaticamente no Leste dos EUA.
3. Configure a política de backup e selecione a VM na mesma interface do usuário.
4. Verifique se o Agente de Backup está instalado na VM. Se a VM for criada usando uma imagem da galeria
do Azure, o Agente de Backup já estará instalado. Caso contrário (ou seja, se você estiver usando uma
imagem personalizada), use as instruções para instalar o agente de VM em uma máquina virtual.
5. Depois que as etapas anteriores forem concluídas, o backup será executado em intervalos regulares,
conforme especificado na política de backup. Se necessário, dispare o primeiro backup manualmente no
painel do cofre do portal do Azure.
Para automatizar o Backup do Azure usando scripts, consulte Cmdlets do PowerShell para backup de VM.
Etapas de recuperação
Se você precisar reparar ou recriar uma VM, restaure a VM por meio de um dos pontos de recuperação de
backup no cofre. Há duas opções diferentes para realizar a recuperação:
Você pode criar uma nova VM como uma representação pontual da VM copiada em backup.
Você pode restaurar os discos e, em seguida, usar o modelo da VM para personalizar e recriar a VM
restaurada.
Para obter mais informações, consulte as instruções sobre como usar o portal do Azure para restaurar
máquinas virtuais. Este documento também explica as etapas específicas para a restauração de VMs copiadas
em backup para um datacenter emparelhado usando o cofre de backup com redundância geográfica, se houver
um desastre no datacenter primário. Nesse caso, o Backup do Azure usa o serviço de Computação da região
secundária para criar a máquina virtual restaurada.
Use também o PowerShell para criar uma nova VM com base em discos restaurados.
Solução alternativa: Instantâneos consistentes

Se não for possível usar o Backup do Azure, implemente seu próprio mecanismo de backup usando
instantâneos. É complicado criar instantâneos consistentes para todos os discos usados por uma VM e, em
seguida, replicar esses instantâneos em outra região. Por esse motivo, o Azure considera o uso do serviço de
Backup uma opção melhor do que a criação de uma solução personalizada.
Se você usar o armazenamento com redundância geográfica/armazenamento com redundância geográfica com
acesso de leitura para discos, os instantâneos serão replicados automaticamente em um datacenter secundário.
Se você usar o armazenamento com redundância local para discos, precisará replicar os dados por conta
própria. Para obter mais informações, consulte Fazer backup de discos não gerenciados de VM do Azure com
instantâneos incrementais.
Um instantâneo é uma representação de um objeto em um ponto específico no tempo. Um instantâneo incorre
em cobrança pelo tamanho incremental dos dados que ele mantém. Para obter mais informações, consulte Criar
um instantâneo de blob.
Criar instantâneos enquanto a VM está em execução
Embora você possa tirar um instantâneo a qualquer momento, se a VM estiver em execução, ainda haverá
dados sendo transmitidos para os discos. Os instantâneos podem conter operações parciais que estavam em
trânsito. Além disso, se houver vários discos envolvidos, os instantâneos de discos diferentes poderão ter
ocorrido em horários diferentes. Esses cenários podem fazer com que os instantâneos não sejam coordenados.
Essa falta de coordenação é especialmente problemática para volumes distribuídos cujos arquivos podem ser
corrompidos se alterações estavam sendo feitas durante o backup.
Para evitar essa situação, o processo de backup deve implementar as seguintes etapas:
1. Congele todos os discos.
2. Libere todas as gravações pendentes.
3. Crie um instantâneo de blob para todos os discos.
Alguns aplicativos do Windows, como o SQL Server, fornecem um mecanismo de backup coordenado por meio
do serviço de sombra de volume para criar backups consistentes com o aplicativo. No Linux, use uma
ferramenta como o fsfreeze para coordenar os discos. Essa ferramenta fornece backups consistentes com os
arquivos, mas não instantâneos consistentes com o aplicativo. Esse processo é complexo. Portanto, considere o
uso de Backup do Azure ou de uma solução de backup de terceiros que já implementa esse procedimento.
O processo anterior resulta em uma coleção de instantâneos coordenados para todos os discos de VM,
representando uma exibição pontual específica da VM. Esse é um ponto de restauração de backup para a VM.
Repita o processo em intervalos agendados para criar backups periódicos. Consulte Copiar os backups para
outra região para obter as etapas para copiar os instantâneos para outra região para DR.
Criar instantâneos enquanto a VM está offline
Outra opção para criar backups consistentes é desligar a VM e tirar instantâneos de blob de cada disco. Tirar
instantâneos de blob é mais fácil do que coordenar instantâneos de uma VM em execução, mas exige alguns
minutos de inatividade.
1. Desligue a VM.
2. Crie um instantâneo de cada blob de disco rígido virtual, o que leva apenas alguns segundos.
Para criar um instantâneo, use o PowerShell, a API REST do Armazenamento do Azure, a CLI do Azure ou
uma das bibliotecas de clientes do Armazenamento do Azure, como a biblioteca de clientes do
Armazenamento para .NET.
3. Inicie a VM, o que encerra o tempo de inatividade. Normalmente, todo o processo é concluído em alguns
minutos.
Esse processo gera uma coleção de instantâneos consistentes para todos os discos, fornecendo um ponto de
restauração de backup para a VM.
Copiar os instantâneos para outra região
A criação de instantâneos por si só pode não ser suficiente para DR. Também é necessário replicar os backups
de instantâneo em outra região.
Se você usar o armazenamento com redundância geográfica ou o armazenamento com redundância geográfica
com acesso de leitura para os discos, os instantâneos serão replicados automaticamente para a região
secundária. Pode haver alguns minutos de retardo antes da replicação. Se o datacenter primário ficar inativo
antes que os instantâneos concluam a replicação, você não poderá acessar os instantâneos no datacenter
secundário. A probabilidade de que isso ocorra é pequena.
NOTE
Somente ter os discos em uma conta de armazenamento com redundância geográfica ou de armazenamento com
redundância geográfica com acesso de leitura não protege a VM contra desastres. Também é necessário criar instantâneos
coordenados ou usar o Backup do Azure. Isso é necessário para recuperar uma VM para um estado consistente.
Se estiver usando o armazenamento com redundância local, copie os instantâneos para outra conta de
armazenamento imediatamente após a criação do instantâneo. O destino de cópia pode ser uma conta de
armazenamento com redundância local em outra região, resultando na localização da cópia em uma região
remota. Também copie o instantâneo para uma conta de armazenamento com redundância geográfica com
acesso de leitura na mesma região. Nesse caso, o instantâneo é replicado lentamente na região secundária
remota. O backup é protegido contra desastres no site primário após a conclusão da cópia e da replicação.
Para copiar os instantâneos incrementais para DR com eficiência, examine as instruções em Fazer backup de
discos não gerenciados de VM do Azure com instantâneos incrementais.
Recuperação com base em instantâneos

Para recuperar um instantâneo, copie-o para criar um novo blob. Se estiver copiando o instantâneo da conta
primária, copie o instantâneo sobre o blob base do instantâneo. Esse processo reverte o disco para o
instantâneo. Esse processo é conhecido como promoção do instantâneo. Se estiver copiando o backup de
instantâneo de uma conta secundária, no caso de uma conta de armazenamento com redundância geográfica
com acesso de leitura, você deverá copiá-lo para uma conta primária. Copie um instantâneo usando o
PowerShell ou o utilitário AzCopy. Para obter mais informações, consulte Transferir dados com o utilitário de
linha de comando AzCopy.
Para VMs com vários discos, é necessário copiar todos os instantâneos que fazem parte do mesmo ponto de
restauração coordenado. Depois de copiar os instantâneos para blobs de VHD graváveis, use os blobs para
recriar a VM usando o modelo da VM.
Outras opções
SQL Server
O SQL Server em execução em uma VM tem suas próprias funcionalidades internas para fazer backup do banco
de dados do SQL Server para o armazenamento de Blobs do Azure ou um compartilhamento de arquivos. Se a
conta de armazenamento for de armazenamento com redundância geográfica ou de armazenamento com
redundância geográfica com acesso de leitura, você poderá acessar esses backups no datacenter secundário da
conta de armazenamento em caso de desastre, com as mesmas restrições, conforme abordado anteriormente.
Para obter mais informações, consulte Backup e restauração para o SQL Server em máquinas virtuais do Azure.
Além de fazer backup e restaurar, os grupos de disponibilidade AlwaysOn do SQL Server podem manter
réplicas secundárias de bancos de dados. Essa capacidade reduz consideravelmente o tempo de recuperação de
desastre.
Outras considerações
Este artigo abordou como fazer backup ou tirar instantâneos das VMs e de seus discos para dar suporte à
recuperação de desastre e como realizes esses backups ou instantâneos para recuperar seus dados. Com o
modelo do Azure Resource Manager, muitas pessoas usam modelos para criar suas VMs e outras infraestruturas
no Azure. Use um modelo para criar uma VM que tem sempre a mesma configuração. Se você usar imagens
personalizadas para criar as VMs, também deverá verificar se as imagens são protegidas usando uma conta de
armazenamento com redundância geográfica com acesso de leitura para armazená-las.
Consequentemente, o processo de backup pode ser uma combinação de duas coisas:
Fazer backup dos dados (discos).
Fazer backup da configuração (modelos e imagens personalizadas).
Dependendo da opção de backup escolhida, talvez você precise administrar o backup dos dados e da
configuração ou o serviço de backup pode administrar tudo isso para você.
Apêndice: Noções básicas sobre o impacto da redundância de dados

Para contas de armazenamento no Azure, há três tipos de redundância de dados que devem ser considerados
em relação à recuperação de desastre: redundância local, redundância geográfica ou redundância geográfica
com acesso de leitura.
O armazenamento com redundância local retém três cópias dos dados no mesmo datacenter. Quando a VM
grava os dados, todas as três cópias são atualizadas antes que uma operação bem-sucedida seja retornada ao
chamador, de modo que você saiba que elas são idênticas. O disco está protegido contra falhas locais, pois é
improvável que todas as três cópias sejam afetadas ao mesmo tempo. No caso do armazenamento com
redundância local, não há nenhuma redundância geográfica e, portanto, o disco não está protegido contra
falhas catastróficas que podem afetar todo um datacenter ou uma unidade de armazenamento.
Com o armazenamento com redundância geográfica e o armazenamento com redundância geográfica com
acesso de leitura, três cópias dos dados são retidas na região primária escolhida por você. Mais três cópias dos
dados são retidas em uma região secundária correspondente que é definida pelo Azure. Por exemplo, se você
armazenar dados no Oeste dos EUA, os dados serão replicados no Leste dos EUA. A retenção de cópia é feita de
forma assíncrona e há um pequeno atraso entre as atualizações nos sites primário e secundário. As réplicas dos
discos no site secundário são consistentes por disco (com o atraso), mas as réplicas de vários discos ativos
podem não estar sincronizadas entre si. Para ter réplicas consistentes em vários discos, são necessários
instantâneos consistentes.
A principal diferença entre o armazenamento com redundância geográfica e o armazenamento com
redundância geográfica com acesso de leitura é que, com o armazenamento com redundância geográfica com
acesso de leitura, você pode ler a cópia secundária a qualquer momento. Se houver um problema que torna os
dados na região primária inacessíveis, a equipe do Azure envidará todos os esforços para restaurar o acesso.
Embora o primário esteja inativo, se você tiver o armazenamento com redundância geográfica com acesso de
leitura habilitado, poderá acessar os dados no datacenter secundário. Portanto, se você pretende ler na réplica
enquanto o primário estiver inacessível, o armazenamento com redundância geográfica com acesso de leitura
deve ser considerado.
Se isso acabar se tornando uma interrupção significativa, a equipe do Azure poderá disparar um failover
geográfico e alterar as entradas DNS primárias para que apontem para o armazenamento secundário. Neste
ponto, se você tiver o armazenamento com redundância geográfica ou o armazenamento com redundância
geográfica com acesso de leitura habilitado, poderá acessar os dados na região que costumava ser a secundária.
Em outras palavras, se sua conta de armazenamento for um armazenamento com redundância geográfica e
houver um problema, você poderá acessar o armazenamento secundário somente se houver um failover
geográfico.
Para obter mais informações, consulte O que fazer se ocorrer uma interrupção do Armazenamento do Azure.
Próximas etapas
Consulte fazer backup de discos de máquina virtual não gerenciados do Azure com instantâneos incrementais.
Criar um instantâneo usando o portal ou CLI do
Azure
Capture um instantâneo de um SO ou disco de dados para backup ou para solucionar problemas de VM. Um
instantâneo é uma cópia completa somente leitura de um VHD.
Usar a CLI do Azure

O exemplo a seguir exige que você use o Cloud Shell ou tenha a CLI do Azure instalada.
As etapas a seguir mostram como capturar um instantâneo usando o comando az snapshot create com o
parâmetro --source-disk . O exemplo a seguir assume que há uma VM chamada myVM no grupo de recursos
myResourceGroup.
Obtenha a ID do disco usando az vm show.
osDiskId=$(az vm show \
-n myVM \
--query "storageProfile.osDisk.managedDisk.id" \
-o tsv)
Tire um instantâneo chamado osDisk-backup usando az snapshot create.
az snapshot create \
--source "$osDiskId" \
--name osDisk-backup
NOTE
Se você quiser armazenar o instantâneo no armazenamento com resiliência de zona, será necessário criá-lo em uma
região compatível com zonas de disponibilidade e inclua o parâmetro --sku Standard_ZRS.
Você pode ver uma lista de instantâneos usando az snapshot list.
az snapshot list \
- table

2. Iniciando no canto superior esquerdo, clique em Criar um recurso e procure instantâneo . Selecione
Instantâneo nos resultados da pesquisa.
3. Na folha Instantâneo , clique em Criar .
5. Selecione um grupo de recursos existente ou digite o nome de um novo.
6. Para Disco de origem , selecione o disco gerenciado para instantâneo.
7. Escolha o Tipo de conta a ser usado para armazenar o instantâneo. Use HD Standard , a menos que você
precise dele armazenado em um SSD de alto desempenho.
8. Clique em Criar .
Próximas etapas
Cria uma máquina virtual de um instantâneo criando um disco gerenciado do instantâneo e, em seguida,
anexando o novo disco gerenciado como disco do SO. Para obter mais informações, consulte o script Criar uma
VM com base em um instantâneo.
Criar um instantâneo usando o portal ou o
PowerShell
Um instantâneo é uma cópia completa, somente leitura de um disco rígido virtual (VHD). Você pode tirar um
instantâneo de um VHD para usar como backup, ou para solucionar problemas VM (máquina virtual) do disco
do sistema operacional ou dados.
Se você pretende usar o instantâneo para criar uma nova VM, recomendamos desligar a VM antes de capturar
um instantâneo para limpar todos os processos em andamento.

Para criar um instantâneo, conclua as seguintes etapas:
1. Na portal do Azure, selecione criar um recurso .
2. Pesquise e selecione instantâneo .
3. Na janela Instantâneo , selecione Criar . A janela Criar novo instantâneo é exibida.
5. Selecione um Grupo de Recursos existente ou insira o nome de um novo.
6. Selecione um local do datacenter do Azure.
7. Para Disco de origem , selecione o disco gerenciado para instantâneo.
8. Escolha o Tipo de conta a ser usado para armazenar o instantâneo. Selecione Standard_HDD , a menos
que você precise que o instantâneo seja armazenado em um disco de alto desempenho.
Usar o PowerShell
As etapas a seguir mostram como copiar o disco VHD e criar a configuração de instantâneo. Em seguida, você
pode tirar um instantâneo do disco usando o cmdlet New-AzSnapshot .
1. Defina alguns parâmetros:
$location = 'eastus'
$vmName = 'myVM'
$snapshotName = 'mySnapshot'
2. Obtenha a VM:
$vm = Get-AzVM `
-Name $vmName
3. Crie a configuração do instantâneo. Neste exemplo, o instantâneo é do disco do sistema operacional:

$snapshot = New-AzSnapshotConfig `
-SourceUri $vm.StorageProfile.OsDisk.ManagedDisk.Id `
-CreateOption copy
NOTE
Se você quiser armazenar o instantâneo no armazenamento com resiliência de zona, crie-o em uma região que dá
suporte a zonas de disponibilidade e inclua o -SkuName Standard_ZRS parâmetro.
4. Crie o instantâneo:
New-AzSnapshot `
-Snapshot $snapshot `
-SnapshotName $snapshotName `
Próximas etapas
Cria uma máquina virtual usando um instantâneo criando um disco gerenciado do instantâneo e anexando o
novo disco gerenciado como disco do SO. Para obter mais informações, consulte o exemplo em Criar uma VM
de um instantâneo com o PowerShell.
Fazer backup de discos de máquina virtual não
gerenciados do Azure com instantâneos
incrementais
Visão geral
O Armazenamento do Azure oferece a capacidade de fazer instantâneos dos blobs. Os instantâneos capturam o
estado do blob no momento em questão. Neste artigo, descrevemos um cenário no qual você pode manter
backups dos discos de máquinas virtuais usando instantâneos. Você pode usar essa metodologia quando optar
por não usar o Serviço de Backup e Recuperação do Azure e desejar criar uma estratégia de backup
personalizada para seus discos da máquina virtual. Para máquinas virtuais que executam cargas de trabalho de
negócios ou de missão crítica, é recomendável usar o backup do Azure como parte da estratégia de backup.
Os discos de máquinas virtuais do Azure são armazenados como blobs de página no Armazenamento do Azure.
Como estamos descrevendo uma estratégia de backup para discos de máquina virtual neste artigo, faremos
referência aos instantâneos no contexto dos blobs de página. Para saber mais sobre instantâneos, consulte
Criando um instantâneo de um Blob.
O que é um instantâneo?
Um instantâneo de blob é uma versão somente leitura de um blob capturada em um dado momento. Quando
um instantâneo tiver sido criado, ele pode ser lido, copiado ou excluído, mas não modificado. Os instantâneos
fornecem uma maneira de fazer backup de um blob da maneira como ele aparece em um momento específico.
Até a versão 2015-04-05 do REST você podia copiar instantâneos completos. Com a versão 2015-07-08 do
REST e as versões superiores, você pode copiar instantâneos incrementais.
Cópia de instantâneo completo

Instantâneos podem ser copiados para outra conta de armazenamento como um blob para manter backups do
blob de base. Você também pode copiar um instantâneo sobre seu blob de base, que é semelhante a restaurar o
blob para uma versão anterior. Quando um instantâneo é copiado de uma conta de armazenamento para outra,
ele ocupa o mesmo espaço que o blob de páginas de base. Portanto, copiar instantâneos inteiros de uma conta
de armazenamento para outra é um processo lento que consume muito espaço na conta de armazenamento de
destino.
NOTE
Se você copiar o blob de base para outro destino, os instantâneos do blob não serão copiados com ele. Da mesma forma,
se você substituir um blob de base por uma cópia, os instantâneos associados ao blob de base não serão afetados e
permanecerão intactos com o nome do blob de base.
Fazer backup de discos usando instantâneos

Como estratégia de backup para seus discos de máquina virtual, você pode fazer instantâneos periódicos do
blob de páginas ou de disco e copiá-los para outra conta de armazenamento usando ferramentas como a
operação Copiar Blob ou AzCopy. Você pode copiar um instantâneo para um blob de páginas de destino com
um nome diferente. O blob de páginas de destino resultante é um blob de páginas gravável, e não um
instantâneo. Mais adiante neste artigo, descreveremos as etapas para fazer backups dos discos de máquinas
virtuais usando instantâneos.
Restaurar discos usando instantâneos
Quando for o momento de restaurar o disco para uma versão estável que foi anteriormente capturada em um
dos instantâneos de backup, você pode copiar um instantâneo sobre o blob de páginas de base. Após ser
promovido a blob de páginas de base, o instantâneo permanece, mas sua origem é substituída por uma cópia
que pode ser lida e gravada. Mais adiante neste artigo, descreveremos as etapas para restaurar uma versão
anterior do disco por meio do instantâneo.
Implementando uma cópia completa do instantâneo
Você pode implementar uma cópia completa do instantâneo fazendo o seguinte
Primeiro, faça um instantâneo do blob de base usando a operação de Snapshot Blob .
Em seguida, copie o instantâneo para uma conta de armazenamento de destino usando Copy Blob.
Repita esse processo para manter cópias de backup de seu blob de base.
Cópia de instantâneo incremental

O novo recurso na API GetPageRanges é uma maneira muito melhor para fazer backup de instantâneos de seus
blobs de página ou discos. A API retorna a lista de alterações entre o blob de base e os instantâneos, o que reduz
a quantidade de espaço de armazenamento usada na conta de backup. A API dá suporte a blobs de página no
Armazenamento Premium e no Armazenamento Standard. Com essa API, você pode criar soluções de backup
mais rápidas e eficientes para VMs do Azure. Essa API será disponibilizada com o REST versão 2015-07-08 ou
superior.
A Cópia de instantâneo incremental permite copiar de uma conta de armazenamento para outra a diferença
entre:
o blob de base e seu instantâneo OU
quaisquer dois instantâneos do blob de base
Se as condições a seguir forem atendidas,
O blob foi criado em 1º de janeiro de 2016 ou posteriormente.
O blob não foi substituído por PutPage ou Copiar Blob entre dois instantâneos.
NOTE
Esse recurso está disponível para os BLOBs Premium e Standard de páginas do Azure.
Quando você tem uma estratégia de backup personalizada usando instantâneos, copiar os instantâneos de uma
conta de armazenamento para outra pode ser um processo lento que consome muito espaço de
armazenamento. Em vez de copiar todo o instantâneo para uma conta de armazenamento de backup, você pode
gravar a diferença em um blob de páginas de backup. Dessa forma, o tempo para copiar e o espaço para
armazenar backups são reduzidos substancialmente.
Implementando a Cópia de instantâneo incremental
Você pode implementar a cópia de instantâneo incremental fazendo o seguinte
Faça um instantâneo do blob de base usando Snapshot Blob.
Copie o instantâneo para a conta de armazenamento de backup de destino na mesma ou em qualquer outra
região do Azure usando Copiar Blob. Esse é o blob de páginas de backup. Tire um instantâneo do blob de
páginas de backup e armazene-o na conta de backup.
Faça outro instantâneo do blob de base usando Blob de Instantâneo.
Obtenha a diferença entre o primeiro e o segundo instantâneo do blob de base usando GetPageRanges. Use
o novo parâmetro prevsnapshot para especificar o valor de DateTime do instantâneo do qual você deseja
obter a diferença. Quando esse parâmetro estiver presente, a resposta REST inclui apenas as páginas que
foram alteradas entre o instantâneo de destino e o instantâneo anterior, incluindo páginas em branco.
Use PutPage para aplicar essas alterações ao blob de páginas de backup.
Por fim, tire um instantâneo do blob de páginas de backup e armazene-o na conta de armazenamento de
backup.
Na próxima seção, descreveremos com mais detalhes como você pode manter backups de discos usando a
Cópia de instantâneo incremental
Cenário
Nesta seção, descrevemos um cenário que envolve uma estratégia de backup personalizada para discos de
máquina virtual usando instantâneos.
Considere uma VM do Azure da série DS com um disco P30 de armazenamento premium anexado. O disco P30
chamado mypremiumdisk é armazenado em uma conta de armazenamento premium chamada
mypremiumaccount. Uma conta de armazenamento standard chamada mybackupstdaccount é usada para
armazenar o backup do mypremiumdisk. Gostaríamos de manter um instantâneo de mypremiumdisk a cada 12
horas.
Para saber mais sobre como criar uma conta de armazenamento, consulte Criar uma conta de armazenamento.
Para saber mais sobre como fazer backup de VMs do Azure, consulte Planejar backups de VMs do Azure.
Etapas para manter backups de um disco usando instantâneos

incrementais
As etapas descritas a seguir descrevem como tirar instantâneos do mypremiumdisk e manter os backups em
mybackupstdaccount. O backup será um blob de páginas padrão chamado mybackupstdpageblob. O blob de
páginas de backup sempre reflete o mesmo estado que o último instantâneo de mypremiumdisk.
1. Crie o blob de páginas de backup para o disco de armazenamento premium, tirando um instantâneo de
mypremiumdisk chamado mypremiumdisk_ss1.
2. Copie esse instantâneo para mybackupstdaccount como um blob de páginas chamado
mybackupstdpageblob.
3. Faça um instantâneo de mybackupstdpageblob chamado mybackupstdpageblob_ss1 usando Blob de
Instantâneo e armazene-o em mybackupstdaccount.
4. Durante a janela de backup, crie outro instantâneo de mypremiumdisk, digamos que mypremiumdisk_ss2 e
armazene-o em mypremiumaccount.
5. Obtenha as alterações incrementais entre os dois instantâneos, mypremiumdisk_ss2 e mypremiumdisk_ss1,
usando GetPageRanges na mypremiumdisk_ss2 com o parâmetro prevsnapshot definido como o carimbo
de data/hora de mypremiumdisk_ss1. Grave essas alterações incrementais do blob de páginas de backup
mybackupstdpageblob em mybackupstdaccount. Se houver intervalos excluídos nas alterações incrementais,
eles deverão ser excluídos do blob de páginas de backup. Use PutPage para gravar as alterações
incrementais no blob de páginas de backup.
6. Faça um instantâneo do blob de páginas de backup mybackupstdpageblob, denominado
mybackupstdpageblob_ss2. Exclua o instantâneo anterior mypremiumdisk_ss1 da conta de armazenamento
premium.
7. Repita as etapas 4 a 6 em cada janela de backup. Dessa forma, você pode manter backups de
mypremiumdisk em uma conta de armazenamento padrão.
Etapas para restaurar um disco por meio de instantâneos
As etapas a seguir descrevem como restaurar o disco premium mypremiumdisk para um instantâneo anterior
da conta de armazenamento de backup mybackupstdaccount.
1. Identifique o ponto para o qual você deseja restaurar o disco premium. Digamos que seja o instantâneo
mybackupstdpageblob_ss2, que está armazenado na conta de armazenamento de backup
mybackupstdaccount.
2. Em mybackupstdaccount, promova o instantâneo mybackupstdpageblob_ss2 como o novo blob de páginas
de base de backup mybackupstdpageblobrestored.
3. Faça um instantâneo do blob de páginas de backup denominado mybackupstdpageblobrestored_ss1.
4. Copie o blob de páginas restauradas mybackupstdpageblobrestored de mybackupstdaccount para
mypremiumaccount como o novo disco premium mypremiumdiskrestored.
5. Tirar um instantâneo do mypremiumdiskrestored, chamado mypremiumdiskrestored_ss1 para fazer backups
incrementais futuros.
6. Aponte a VM da série DS para o disco restaurado mypremiumdiskrestored e desanexe o antigo
mypremiumdisk da VM.
7. Inicie o processo de backup descrito na seção anterior para o disco restaurado mypremiumdiskrestored
usando mybackupstdpageblobrestored como o blob de páginas de backup.
Próximas etapas
Use os links a seguir para saber mais sobre como criar instantâneos de um blob e planejar a infraestrutura de
backup da VM.
Criando um instantâneo de um Blob
Planejar sua infraestrutura de backup de VM
Discos do sistema operacional efêmero para VMs
do Azure
Os discos do sistema operacional efêmero são criados no armazenamento da VM (máquina virtual) local e não
são salvos no armazenamento remoto do Azure. Os discos do sistema operacional efêmero funcionam bem
para cargas de trabalho sem estado, em que os aplicativos são tolerantes a falhas de VM individuais, mas são
mais afetados pelo tempo de implantação da VM ou refazendo a imagem das instâncias de VM individuais. Com
o disco do sistema operacional efêmero, você obtém latência de leitura/gravação mais baixa no disco do
sistema operacional e uma reimagem de VM mais rápida.
Os principais recursos dos discos efêmeras são:
Ideal para aplicativos sem estado.
Eles podem ser usados com imagens do Marketplace e personalizadas.
Capacidade de redefinir rapidamente ou refazer a imagem de VMs e instâncias do conjunto de
dimensionamento para o estado de inicialização original.
Menor latência, semelhante a um disco temporário.
Discos do sistema operacional efêmero são gratuitos, você não incorre em nenhum custo de
armazenamento para o disco do sistema operacional.
Eles estão disponíveis em todas as regiões do Azure.
O disco do so efêmero tem suporte pela Galeria de imagens compartilhadas.
Principais diferenças entre discos do sistema operacional persistentes e efêmeras:
DISC O DO SO P ERSIST EN T E DISC O DO SO EF ÊM ERO
Limite de tamanho para o disco 2 TiB Tamanho do cache para o tamanho da

do sistema operacional VM ou 2TiB, o que for menor. Para o
tamanho do cache em GIB ,
consulte DS, es, M, FSe GS
Tamanhos de VM com supor te Tudo Tamanhos de VM que dão suporte ao

armazenamento Premium, como DSv1,
DSv2, DSv3, Esv3, FS, FsV2, GS, M
Supor te a tipo de disco Disco do sistema operacional Somente disco do sistema operacional
gerenciado e não gerenciado gerenciado
Supor te de regiões Todas as regiões Todas as regiões
Persistência de dados Os dados do disco do sistema Os dados gravados no disco do

operacional gravados no disco do sistema operacional são armazenados
sistema operacional são armazenados no armazenamento da VM local e não
no armazenamento do Azure são persistidos no armazenamento do
Azure.
Estado de parada desalocada As VMs e as instâncias do conjunto de VMs e instâncias do conjunto de

dimensionamento podem ser dimensionamento não podem ser
interrompidas e reiniciadas a partir do interrompidas-desalocadas
estado de parada/desalocada
Supor te a disco do so Sim Não

especializado
DISC O DO SO P ERSIST EN T E DISC O DO SO EF ÊM ERO
Redimensionamento de disco do Com suporte durante a criação da VM Com suporte somente durante a
so e depois que a VM é parada- criação da VM
desalocada
Redimensionando para um novo OS dados do disco do sistema Os dados no disco do sistema

tamanho de VM operacional são preservados operacional são excluídos, o sistema
operacional é reprovisionado
Posicionamento do arquivo de Para o Windows, o arquivo de Para o Windows, o arquivo de

paginação paginação é armazenado no disco de paginação é armazenado no disco do
recursos sistema operacional
Requisitos de tamanho
Você pode implantar as imagens da VM e da instância até o tamanho do cache da VM. Por exemplo, as imagens
padrão do Windows Server do Marketplace são cerca de 127 GiB, o que significa que você precisa de um
tamanho de VM que tenha um cache maior do que 127 GiB. Nesse caso, o Standard_DS2_v2 tem um tamanho
de cache de 86 Gib, o que não é grande o suficiente. O Standard_DS3_v2 tem um tamanho de cache de 172 GiB,
que é grande o suficiente. Nesse caso, o Standard_DS3_v2 é o menor tamanho na série DSv2 que você pode
usar com essa imagem. As imagens básicas do Linux no Marketplace e as imagens do Windows Server que são
indicadas [smallsize] tendem a ser cerca de 30 GiB e podem usar a maioria dos tamanhos de VM disponíveis.
Os discos efêmeros também exigem que o tamanho da VM dê suporte ao armazenamento Premium. Os
tamanhos geralmente (mas nem sempre) têm um s no nome, como DSv2 e EsV3. Para obter mais
informações, consulte tamanhos de VM do Azure para obter detalhes sobre quais tamanhos dão suporte ao
armazenamento Premium.
Visualização-OS discos do sistema operacional efêmero agora podem

ser armazenados em discos temporários
Os discos do sistema operacional efêmero agora podem ser armazenados no disco temporário/de recurso da
VM, além do cache da VM. Então, agora você pode usar discos do sistema operacional efêmero com a VM que
não tem um cache ou tem cache insuficiente, mas tem um disco temporário/de recursos para armazenar o disco
do sistema operacional efêmero, como Dav3, Dav4, Eav4 e Eav3. Se uma VM tiver um espaço temporário e
cache suficiente, você também poderá especificar onde deseja armazenar o disco do sistema operacional
efêmero usando uma nova propriedade chamada DiffDiskPlacement. Com esse recurso, quando uma VM do
Windows é provisionada, configuramos o arquivo de paginação para estar localizado no disco do sistema
operacional. Esse recurso está atualmente na visualização. Essa versão prévia é fornecida sem um contrato de
nível de serviço e não é recomendada para cargas de trabalho de produção. Para começar, solicite o acesso.
PowerShell
Para usar um disco efêmero para uma implantação de VM do PowerShell, use set-AzVMOSDisk em sua
configuração de VM. Defina -DiffDiskSetting como Local e -Caching como ReadOnly .
Set-AzVMOSDisk -DiffDiskSetting Local -Caching ReadOnly
Para implantações de conjunto de dimensionamento, use o cmdlet set-AzVmssStorageProfile em sua

configuração. Defina -DiffDiskSetting como Local e -Caching como ReadOnly .
Set-AzVmssStorageProfile -DiffDiskSetting Local -OsDiskCaching ReadOnly
CLI
Para usar um disco efêmero para uma implantação de VM da CLI, defina o --ephemeral-os-disk parâmetro em
AZ VM Create como true e o --os-disk-caching parâmetro para ReadOnly .
az vm create \
--name myVM \
--image UbuntuLTS \
--ephemeral-os-disk true \
--os-disk-caching ReadOnly \
--generate-ssh-keys
Para conjuntos de dimensionamento, use o mesmo --ephemeral-os-disk true parâmetro para AZ-vmss-Create
e defina o --os-disk-caching parâmetro como ReadOnly .
Portal
No portal do Azure, você pode optar por usar discos efêmeros ao implantar uma VM abrindo a seção avançada
da guia discos . Para usar disco do sistema operacional efêmero , selecione Sim .
Se a opção para usar um disco efêmero estiver esmaecida, você poderá ter selecionado um tamanho de VM que
não tenha um tamanho de cache maior do que a imagem do sistema operacional ou que não dê suporte ao
armazenamento Premium. Volte para a página noções básicas e tente escolher outro tamanho de VM.
Você também pode criar conjuntos de dimensionamento com discos do sistema operacional efêmero usando o
Portal. Apenas certifique-se de selecionar um tamanho de VM com tamanho de cache grande o suficiente e, em
seguida, em usar disco do so efêmero , selecione Sim .
Implantação do modelo do conjunto de dimensionamento
O processo para criar um conjunto de dimensionamento que usa um disco do sistema operacional efêmero é
adicionar a diffDiskSettings propriedade ao Microsoft.Compute/virtualMachineScaleSets/virtualMachineProfile
tipo de recurso no modelo. Além disso, a política de cache deve ser definida como ReadOnly para o disco do
sistema operacional efêmero.
{
"type": "Microsoft.Compute/virtualMachineScaleSets",
"name": "myScaleSet",
"location": "East US 2",
"apiVersion": "2018-06-01",
"sku": {
"capacity": "2"
},
"properties": {
"upgradePolicy": {
"mode": "Automatic"
},
"virtualMachineProfile": {
"storageProfile": {
"osDisk": {
"diffDiskSettings": {
"option": "Local"
},
"caching": "ReadOnly",
},
"imageReference": {
"sku": "16.04-LTS",
"version": "latest"
}
},
"osProfile": {
"computerNamePrefix": "myvmss",
"adminPassword": "P@ssw0rd!"
}
}
}
}
Implantação de modelo de VM
Você pode implantar uma VM com um disco do sistema operacional efêmero usando um modelo. O processo
para criar uma VM que usa discos do sistema operacional efêmero é adicionar a diffDiskSettings propriedade
ao tipo de recurso Microsoft. Compute/virtualMachines no modelo. Além disso, a política de cache deve ser
definida como ReadOnly para o disco do sistema operacional efêmero.
{
"name": "myVirtualMachine",
"location": "East US 2",
"apiVersion": "2018-06-01",
"properties": {
"storageProfile": {
"osDisk": {
"diffDiskSettings": {
"option": "Local"
},
"caching": "ReadOnly",
},
"imageReference": {
"sku": "2016-Datacenter-smalldisk",
"version": "latest"
},
"vmSize": "Standard_DS2_v2"
}
},
"osProfile": {
"computerNamePrefix": "myvirtualmachine",
"adminPassword": "P@ssw0rd!"
}
}
}
Refazer a imagem de uma VM usando REST

Você pode refazer a imagem de uma instância de máquina virtual com o disco do sistema operacional efêmero
usando a API REST, conforme descrito abaixo e por meio do portal do Azure, acessando o painel Visão geral da
VM. Para conjuntos de dimensionamento, a recriação de imagens já está disponível por meio do PowerShell, da
CLI e do Portal.
POST https://management.azure.com/subscriptions/{sub-
id}/resourceGroups/{rgName}/providers/Microsoft.Compute/VirtualMachines/{vmName}/reimage?a pi-version=2018-
06-01"
P: Qual é o tamanho dos discos do sistema operacional local?
R: damos suporte a plataformas e imagens personalizadas, até o tamanho do cache da VM, onde todas as
leituras/gravações no disco do sistema operacional serão locais no mesmo nó que a máquina virtual.
P: o disco do sistema operacional efêmero pode ser redimensionado?
R: não, depois que o disco do sistema operacional efêmero é provisionado, o disco do sistema operacional não
pode ser redimensionado.
P: posso anexar um Managed Disks a uma VM efêmera?
R: Sim, você pode anexar um disco de dados gerenciado a uma VM que usa um disco do sistema operacional
efêmero.
P: todos os tamanhos de VM terão supor te para discos do sistema operacional efêmero?
R: não, há suporte para os tamanhos de VM de armazenamento mais Premium (DS, ES, FS, GS, M, etc.). Para
saber se um determinado tamanho de VM dá suporte a discos do sistema operacional efêmero, você pode:
Chamar o Get-AzComputeResourceSku cmdlet do PowerShell

{
{
if($capability.Name -eq 'EphemeralOSDiskSupported' -and $capability.Value -eq 'true')
{
$vmSize
}
}
}
P: o disco do sistema operacional efêmero pode ser aplicado a VMs e conjuntos de

dimensionamento existentes?
R: não, o disco do sistema operacional efêmero só pode ser usado durante a criação da VM e do conjunto de
dimensionamento.
P: você pode misturar discos do sistema operacional efêmero e normal em um conjunto de
dimensionamento?
R: não, você não pode ter uma mistura de instâncias de disco do sistema operacional efêmeras e persistentes
dentro do mesmo conjunto de dimensionamento.
P: o disco do sistema operacional efêmero pode ser criado usando o PowerShell ou a CLI?
R: Sim, você pode criar VMs com o disco do sistema operacional efêmero usando REST, modelos, PowerShell e
CLI.
P: quais recursos não têm supor te com o disco do sistema operacional efêmero?
R: discos efêmeros não dão suporte A:
Capturando imagens de VM
Serviço de Backup do Azure
Azure Site Recovery
Permuta de disco do so
Próximas etapas
Você pode criar uma VM com um disco do sistema operacional efêmero usando o CLI do Azure.
Converter o armazenamento do Azure Managed
disks de Standard para Premium ou Premium para
Standard
Há quatro tipos de disco de discos gerenciados do Azure: ultra discos do Azure, SSD Premium, SSD padrão e
HDD padrão. Você pode alternar entre SSD Premium, SSD padrão e HDD padrão com base em suas
necessidades de desempenho. Você ainda não é capaz de mudar de ou para um ultra Disk, você deve implantar
um novo.
Não há suporte para essa funcionalidade em discos não gerenciados. Mas você pode converter facilmente um
disco não gerenciado em um disco gerenciado para poder alternar entre tipos de disco.
Este artigo mostra como converter discos gerenciados de um tipo de disco para outro usando o CLI do Azure.
Para instalar ou atualizar a ferramenta, consulte instalar CLI do Azure.
Antes de começar
A conversão de disco requer uma reinicialização da VM (máquina virtual), portanto, Agende a migração do
armazenamento em disco durante uma janela de manutenção pré-existente.
Para discos não gerenciados, primeiro converta em discos gerenciados para que você possa alternar entre as
opções de armazenamento.
Mudar todos os discos gerenciados de uma VM entre de uma conta

para outra
Este exemplo mostra como converter todos os discos de uma VM para o armazenamento Premium. No entanto,
alterando a variável de SKU neste exemplo, você pode converter o tipo de discos da VM em SSD padrão ou HDD
padrão. Observe que, para usar o Premium Managed disks, sua VM deve usar um tamanho de VM que ofereça
suporte ao armazenamento Premium. Este exemplo também muda para um tamanho que dá suporte ao
#resource group that contains the virtual machine
rgName='yourResourceGroup'
#Name of the virtual machine

vmName='yourVM'
#Premium capable size

#Required only if converting from Standard to Premium
size='Standard_DS2_v2'
#Choose between Standard_LRS, StandardSSD_LRS and Premium_LRS based on your scenario

sku='Premium_LRS'
#Deallocate the VM before changing the size of the VM

az vm deallocate --name $vmName --resource-group $rgName
#Change the VM size to a size that supports Premium storage

#Skip this step if converting storage from Premium to Standard
az vm resize --resource-group $rgName --name $vmName --size $size
#Update the SKU of all the data disks

az vm show -n $vmName -g $rgName --query storageProfile.dataDisks[*].managedDisk -o tsv \
| awk -v sku=$sku '{system("az disk update --sku "sku" --ids "$1)}'
#Update the SKU of the OS disk

az vm show -n $vmName -g $rgName --query storageProfile.osDisk.managedDisk -o tsv \
| awk -v sku=$sku '{system("az disk update --sku "sku" --ids "$1)}'
az vm start --name $vmName --resource-group $rgName
Alternar discos gerenciados individuais de um tipo de disco para

outro
Para sua carga de trabalho de desenvolvimento/teste, talvez você queira ter uma combinação de discos
Standard e Premium para reduzir os custos. Você pode optar por atualizar somente os discos que precisam de
melhor desempenho. Este exemplo mostra como converter um único disco de VM do armazenamento Standard
para Premium. No entanto, alterando a variável de SKU neste exemplo, você pode converter o tipo de discos da
VM em SSD padrão ou HDD padrão. Para usar o Premium Managed disks, sua VM deve usar um tamanho de
VM que dá suporte ao armazenamento Premium. Este exemplo também muda para um tamanho que dá
suporte ao armazenamento Premium.
#resource group that contains the managed disk
rgName='yourResourceGroup'
#Name of your managed disk

diskName='yourManagedDiskName'
#Premium capable size

#Required only if converting from Standard to Premium
size='Standard_DS2_v2'
#Choose between Standard_LRS, StandardSSD_LRS and Premium_LRS based on your scenario

sku='Premium_LRS'
#Get the parent VM Id

vmId=$(az disk show --name $diskName --resource-group $rgName --query managedBy --output tsv)
#Deallocate the VM before changing the size of the VM

az vm deallocate --ids $vmId
#Change the VM size to a size that supports Premium storage

#Skip this step if converting storage from Premium to Standard
az vm resize --ids $vmId --size $size
# Update the SKU

az disk update --sku $sku --name $diskName --resource-group $rgName
az vm start --ids $vmId
Mudar os discos gerenciados de um tipo de disco para outro

Siga estas etapas:
2. Selecione a VM na lista de máquinas vir tuais .
3. Se a VM não estiver parada, selecione parar na parte superior do painel visão geral da VM e aguarde a
interrupção da VM.
4. No painel da VM, selecione discos no menu.
5. Selecione o disco que você deseja converter.
6. Selecione configuração no menu.
7. Altere o tipo de conta do tipo de disco original para o tipo de disco desejado.
8. Selecione salvar e feche o painel de disco.
A atualização do tipo de disco é instantânea. Você pode reiniciar a VM após a conversão.
Próximas etapas
Faça uma cópia somente leitura de uma VM usando instantâneos.
Atualizar o tipo de armazenamento de um disco
gerenciado
Há quatro tipos de disco de discos gerenciados do Azure: ultra discos do Azure, SSD Premium, SSD padrão e
HDD padrão. Você pode alternar entre SSD Premium, SSD padrão e HDD padrão com base em suas
necessidades de desempenho. Você ainda não é capaz de mudar de ou para um ultra Disk, você deve implantar
um novo.
Não há suporte para essa funcionalidade em discos não gerenciados. Mas você pode converter facilmente um
disco não gerenciado em um disco gerenciado para poder alternar entre tipos de disco.
Antes de começar
Como a conversão requer uma reinicialização da VM (máquina virtual), você deve agendar a migração do
armazenamento em disco durante uma janela de manutenção pré-existente.
Se o disco não for gerenciado, primeiro converta-o em um disco gerenciado para que você possa alternar
entre as opções de armazenamento.
Mudar todos os discos gerenciados de uma VM entre de uma conta

para outra
Este exemplo mostra como converter todos os discos de uma VM para o armazenamento Premium. No entanto,
alterando a variável $storageType neste exemplo, você pode converter o tipo de discos da VM em SSD padrão
ou HDD padrão. Para usar o Premium Managed disks, sua VM deve usar um tamanho de VM que dá suporte ao
armazenamento Premium. Este exemplo também muda para um tamanho que suporte armazenamento
premium:
# Name of the resource group that contains the VM
$rgName = 'yourResourceGroup'
# Name of the your virtual machine

$vmName = 'yourVM'
# Choose between Standard_LRS, StandardSDD_LRS and Premium_LRS based on your scenario

$storageType = 'Premium_LRS'
# Premium capable size

# Required only if converting storage from Standard to Premium
$size = 'Standard_DS2_v2'
# Stop and deallocate the VM before changing the size

$vm = Get-AzVM -Name $vmName -resourceGroupName $rgName
# Change the VM size to a size that supports Premium storage

# Skip this step if converting storage from Premium to Standard
$vm.HardwareProfile.VmSize = $size
Update-AzVM -VM $vm -ResourceGroupName $rgName
# Get all disks in the resource group of the VM

$vmDisks = Get-AzDisk -ResourceGroupName $rgName
# For disks that belong to the selected VM, convert to Premium storage
foreach ($disk in $vmDisks)
{
if ($disk.ManagedBy -eq $vm.Id)
{
$disk.Sku = [Microsoft.Azure.Management.Compute.Models.DiskSku]::new($storageType)
$disk | Update-AzDisk
}
}
Start-AzVM -ResourceGroupName $rgName -Name $vmName
Alternar discos gerenciados individuais entre Standard e Premium

Para sua carga de trabalho de desenvolvimento/teste, talvez você queira uma combinação de discos Standard e
Premium para reduzir os custos. Você pode optar por atualizar somente os discos que precisam de melhor
desempenho. Este exemplo mostra como converter um único disco de VM do armazenamento Standard para
Premium. No entanto, alterando a variável $storageType neste exemplo, você pode converter o tipo de discos da
VM em SSD padrão ou HDD padrão. Para usar o Premium Managed disks, sua VM deve usar um tamanho de
VM que dá suporte ao armazenamento Premium. Este exemplo também mostra como mudar para um tamanho
que dá suporte ao armazenamento Premium:
$diskName = 'yourDiskName'
# resource group that contains the managed disk
$rgName = 'yourResourceGroupName'
# Choose between Standard_LRS, StandardSSD_LRS and Premium_LRS based on your scenario
# Premium capable size
$size = 'Standard_DS2_v2'
$disk = Get-AzDisk -DiskName $diskName -ResourceGroupName $rgName
# Get parent VM resource

$vmResource = Get-AzResource -ResourceId $disk.ManagedBy
# Stop and deallocate the VM before changing the storage type

Stop-AzVM -ResourceGroupName $vmResource.ResourceGroupName -Name $vmResource.Name -Force
$vm = Get-AzVM -ResourceGroupName $vmResource.ResourceGroupName -Name $vmResource.Name
# Change the VM size to a size that supports Premium storage

# Skip this step if converting storage from Premium to Standard
$vm.HardwareProfile.VmSize = $size
# Update the storage type

$disk.Sku = [Microsoft.Azure.Management.Compute.Models.DiskSku]::new($storageType)
$disk | Update-AzDisk
Start-AzVM -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name
Mudar os discos gerenciados de um tipo de disco para outro

Siga estas etapas:
2. Selecione a VM na lista de máquinas vir tuais .
3. Se a VM não estiver parada, selecione parar na parte superior do painel visão geral da VM e aguarde a
interrupção da VM.
4. No painel da VM, selecione discos no menu.
5. Selecione o disco que você deseja converter.
6. Selecione configuração no menu.
7. Altere o tipo de conta do tipo de disco original para o tipo de disco desejado.
8. Selecione salvar e feche o painel de disco.
A conversão de tipo de disco é instantânea. Você pode iniciar a VM após a conversão.
Próximas etapas
Faça uma cópia somente leitura de uma VM usando um snapshot.
Usar Site Recovery para migrar para o
armazenamento Premium
Os SSDs Premium do Azure oferecem suporte de disco de alto desempenho e baixa latência para máquinas
virtuais (VMs) que estão executando cargas de trabalho intensivas para entradas e saídas. Este guia ajuda você a
migrar os discos de VM de uma conta de armazenamento Standard para uma conta de armazenamento
Premium usando o Azure Site Recovery.
O Site Recovery é um serviço do Azure que colabora com sua estratégia de continuidade dos negócios e de
recuperação de desastre por meio da coordenação da replicação de servidores físicos locais e VMs na nuvem
(Azure) ou em um datacenter secundário. Quando ocorrem paralisações em seu local primário, você realiza o
failover em um local secundário a fim de manter aplicativos e cargas de trabalho disponíveis. Quando o local
primário retoma as operações normais, você realiza o failback.
O Site Recovery fornece failovers de teste para dar suporte à simulações de recuperação de desastre sem afetar
os ambientes de produção. É possível executar failovers com perda mínima de dados (dependendo da
frequência de replicação) para desastres inesperados. No cenário de migração para o Armazenamento
Premium, é possível usar um failover no Site Recovery para migrar os discos de destino para uma conta de
É recomendável migrar para o armazenamento Premium usando o Site Recovery, porque essa opção fornece
tempo de inatividade mínimo. Essa opção também evita a execução manual de copiar discos e criar novas VMs.
O Site Recovery vai copiar os discos sistematicamente e criar novas VMs durante o failover.
O Site Recovery oferece suporte a vários tipos de failover com pouco ou nenhum tempo de inatividade. Para
planejar o tempo de inatividade e estimar a perda de dados, consulte os tipos de failover no Site Recovery. Se
você se preparar para se conectar a VMs do Azure após o failover, você conseguirá se conectar à VM do Azure
usando RDP após o failover.
Componentes do Azure Site Recovery

Esses componentes do Site Recovery são relevantes para este cenário de migração:
O ser vidor de configuração é uma VM do Azure que coordena a comunicação e gerencia os processos
de recuperação e replicação de dados. Nesta VM, você executa um arquivo único de instalação para
instalar o servidor de configuração e um componente adicional, chamado de servidor de processo, como
um gateway de replicação. Leia sobre os pré-requisitos do servidor de configuração. Você define o
servidor de configuração apenas uma vez e pode usá-lo em todas as migrações para a mesma região.
O ser vidor de processo é um gateway de replicação que:
1. Recebe dados de replicação de VMs de origem.
2. Otimiza os dados com armazenamento em cache, compactação e criptografia.
3. Envia os dados para uma conta de armazenamento.
Ele também manipula a instalação por push do serviço de mobilidade nas VMs de origem e executa a
descoberta automática destas. O servidor de processo padrão é instalado no servidor de configuração.
Você pode implantar servidores de processo autônomo adicionais para dimensionar sua implantação.
Leia sobre práticas recomendadas para implantação de servidor de processo e implantação de servidores
de processo adicionais. Você define o servidor de processo apenas uma vez e pode usá-lo em todas as
migrações para a mesma região.
O ser viço de mobilidade é um componente que é implantado em todas as VMs padrão que você
deseja replicar. Ele captura gravações de dados na VM padrão e as encaminha ao servidor de processo.
Leia sobre pré-requisitos de máquinas replicadas.
Este gráfico mostra como esses componentes interagem:
NOTE
O Site Recovery não dá suporte à migração de discos dos espaços de armazenamento.
Para componentes adicionais para outros cenários, consulte Arquitetura de cenário.

Conceitos básicos do Azure
Estes são os requisitos do Azure para esse cenário de migração:
Uma assinatura do Azure.
Uma conta de armazenamento Premium do Azure para armazenar os dados replicados.
Uma rede virtual do Azure à qual as VMs serão conectadas quando forem criadas no failover. A rede virtual
do Azure tem que estar na mesma região em que o Site Recovery é executado.
Uma conta de armazenamento Standard do Azure para armazenar logs de replicação. Ela pode ser a mesma
conta de armazenamento dos discos de VM que estão sendo migrados.
Pré-requisitos
Compreenda os componentes relevantes do cenário de migração na seção anterior.
Planeje o tempo de inatividade sabendo mais sobre o Failover no Site Recovery.
Etapas de configuração e migração

Você pode usar o Site Recovery para migrar VMs IaaS do Azure entre regiões ou na mesma região. As
instruções a seguir foram adaptadas para este cenário de migração com base no artigo Replicar VMs VMware
ou servidores físicos para o Azure. Siga os links para obter as etapas detalhadas que complementam as
instruções deste artigo.
Etapa 1: Criar um cofre dos Serviços de Recuperação
2. Selecione Criar um recurso > Gerenciamento > Backup e Site Recover y (OMS) . Como alternativa,
você pode selecionar Procurar > Cofre dos Ser viços de Recuperação > Adicionar .
3. Especifique uma região para a qual as VMs serão replicadas. Para fins de migração na mesma região,
selecione a região em que estão as VMs e as contas de armazenamento de origem.
Etapa 2: Escolher as metas de proteção
1. Na VM em que você deseja instalar o servidor de configuração, abra o portal do Azure.
2. Vá para Cofres dos Ser viços de Recuperação > Configurações > Site Recover y > Etapa 1:
Preparar a Infraestrutura > Meta de proteção .
3. Em Objetivo de proteção , na primeira lista suspensa, selecione Para o Azure . Na segunda lista
suspensa, selecione Não vir tualizados / outros e selecione OK .
Etapa 3: Configure o ambiente de origem (servidor de configuração )

1. Baixe a Configuração unificada do Azure Site Recover y e a chave de registro do cofre indo para os
painéis Preparar infraestrutura > Preparar origem > Adicionar ser vidor .
Você vai precisar da chave de registro do cofre para executar a instalação unificada. A chave é válida por
cinco dias após ser gerada.
2. No painel Adicionar Ser vidor , adicione um servidor de configuração.

3. Na VM que você está usando como servidor de configuração, execute a Instalação Unificada para instalar
o servidor de configuração e o servidor de processo. Você pode percorrer as capturas de tela para
concluir a instalação. Você pode consultar as capturas de tela a seguir para ver as etapas especificadas
para este cenário de migração.
a. Em Antes de começar , selecione Instalar o ser vidor de configuração e o ser vidor em
processo .
b. Em Registro , procure e selecione a chave de registro que você baixou do cofre.
c. Em Detalhes do Ambiente , selecione se você replicará as VMs VMware. Para esse cenário de
migração, escolha Não .
4. Quando a instalação estiver concluída, faça o seguinte na janela Ser vidor de Configuração do
Microsoft Azure Site Recover y :
a. Use a guia Gerenciar contas para criar a conta que o Site Recovery pode usar para descoberta
automática. (No cenário sobre proteção de computadores físicos, configurar a conta não é
relevante, mas você precisa de pelo menos uma conta para habilitar uma das etapas a seguir.
Nesse caso, você pode nomear a conta e a senha como qualquer.)
b. Use a guia Registro do cofre para carregar o arquivo de credencial de cofre.
Etapa 4: Configurar o ambiente de origem

Selecione Preparar infraestrutura > Destino e especifique o modelo de implantação que você deseja usar
para as VMs após o failover. Você pode escolher Clássico ou Gerenciador de recursos , dependendo do
cenário.
A Recuperação de Site verifica se você tem uma ou mais contas de armazenamento e redes do Azure
compatíveis.
NOTE
Se estiver usando uma conta de armazenamento Premium para os dados replicados, você precisará configurar uma conta
de armazenamento Standard adicional para armazenar os logs de replicação.
Etapa 5: Definir as configurações de replicação

Para verificar se o seu servidor de configuração está corretamente associado à política de replicação que você
criou, siga Definir configurações de replicação.
Etapa 6: Planejar a capacidade
1. Use o planejador de capacidade para estimar com precisão a largura de banda de rede, o
armazenamento e outros requisitos para atender às suas necessidades de replicação.
2. Quando terminar, selecione Sim, eu fiz isso na caixa Você concluiu o planejamento da
capacidade? .
Etapa 7: Instalar o serviço de mobilidade e habilitar a replicação
1. Você pode optar pela instalação por push para suas VMs de origem ou instalação manual do serviço de
mobilidade nas suas VMs de origem. Você pode encontrar a solicitação de instalação por push e o
caminho do instalador do manual no link fornecido. Se você estiver fazendo uma instalação manual, será
preciso usar um endereço IP interno para localizar o servidor de configuração.
A VM que sofreu o failover terá dois discos temporários: um da VM primária e outro criado durante o
provisionamento da VM na região de recuperação. Para excluir o disco temporário antes da replicação,
instale o serviço de mobilidade antes de habilitar a replicação. Para saber mais sobre como excluir o disco
temporário, veja Excluir discos da replicação.
2. Habilite a replicação da seguinte maneira:
a. Selecione Replicar Aplicativo > Origem . Depois de habilitar a replicação pela primeira vez,
selecione +Replicar no cofre para habilitar a replicação para máquinas virtuais adicionais.
b. Na etapa 1, configure Origem como o servidor de processo.
c. Na etapa 2, especifique o modelo de implantação pós-failover, uma conta de armazenamento
Premium para a migração, uma conta de armazenamento padrão para salvar os logs e uma rede
virtual para falhas.
d. Na etapa 3, adicione VMs protegidas por endereço IP. (Talvez seja necessário um endereço IP interno
para localizá-las.)
e. Na etapa 4, configure as propriedades, selecionando as contas que você configurou anteriormente no
servidor de processo.
f. Na etapa 5, escolha a política de replicação que você criou anteriormente em "Etapa 5: Defina as
configurações de replicação."
g. Selecione OK .
NOTE
Quando uma VM do Azure é desalocada e reiniciada, não há nenhuma garantia de que ela receberá o mesmo
endereço IP. Se houver alteração no endereço IP do servidor de processo/configuração ou nas VMs do Azure
protegidas, a replicação pode não funcionar corretamente neste cenário.
Ao criar seu ambiente de Armazenamento do Azure, é recomendável usar contas de armazenamento separadas
para cada VM em um conjunto de disponibilidade. É recomendável que você siga a melhor prática na camada
de armazenamento para usar várias contas de armazenamento para cada conjunto de disponibilidade. A
distribuição de discos VM para várias contas de armazenamento ajuda a melhorar a disponibilidade de
armazenamento e distribui a E/S em toda a infraestrutura de armazenamento do Azure.
Se suas VMs estiverem em um conjunto de disponibilidade, em vez de replicar os discos de todas elas em uma
conta de armazenamento, é altamente recomendável migrar várias VMs várias vezes. Desse modo, as VMs em
um mesmo conjunto de disponibilidade não compartilham uma única conta de armazenamento. Use o painel
Habilitar Replicação para configurar uma conta de armazenamento de destino para cada VM, uma de cada
vez.
Você pode escolher um modelo de implantação pós-failover de acordo com suas necessidades. Se você escolher
o Azure Resource Manager como seu modelo de implantação pós-failover, você poderá fazer failover de uma
VM (Resource Manager) para uma VM (Resource Manager) ou você poderá fazer failover de uma VM (clássica)
para uma VM (Resource Manager).
Etapa 8: Execute um teste de failover
Para verificar se a replicação foi concluída, selecione sua instância do Site Recovery e, em seguida, selecione
Configurações > Itens Replicados . Você verá o status e a porcentagem do processo de replicação.
Após a conclusão da replicação inicial, execute o failover de teste para validar a estratégia de replicação. Para
obter as etapas detalhadas de um failover de teste, consulte Executar um failover de teste no Site Recovery.
NOTE
Antes de você executar qualquer failover, verifique se as VMs e a estratégia de replicação atendem aos requisitos. Para
obter mais informações e instruções sobre a execução de um failover de teste, consulte Failover de teste para o Azure no
Site Recovery.
Você pode ver o status do failover de teste em Configurações > Trabalhos >
NOME_DO_SEU_PLANO_DE_FAILOVER. No painel, você pode ver uma divisão das etapas e os resultados de
êxito/falha. Se o failover de teste falhar em alguma etapa, selecione-a para verificar a mensagem de erro.
Etapa 9: Executar um failover
Após a conclusão do failover de teste, execute um failover para migrar os discos para o Armazenamento
Premium e replicar as instâncias de VM. Siga as etapas detalhadas em Executar um failover.
Verifique se você selecionou Desligar VMs e sincronizar os dados mais recentes . Essa opção especifica
que o Site Recovery deve tentar desligar as VMs protegidas e sincronizar os dados para que ocorra o failover da
versão mais recente dos dados. Se você não selecionar essa opção ou se tentar e não tiver êxito, o failover será
do último ponto de recuperação da VM disponível.
O Site Recovery vai criar uma instância VM cujo tipo é igual ou semelhante ou de uma VM compatível com
armazenamento Premium. Para verificar o desempenho e o preço de várias instâncias de VM, vá para Preços de
Máquinas Virtuais Windows ou Preços de Máquinas Virtuais Linux.
Etapas pós-migração
1. Configurar as VMs replicadas para o conjunto de disponibilidade, se aplicável . O Site Recovery
não dá suporte à migração de VMs junto com o conjunto de disponibilidade. Dependendo da
implantação da VM replicada, siga um dos seguintes procedimentos:
Para uma VM criada por meio do modelo de implantação clássico: Adicione a VM ao conjunto de
disponibilidade no portal do Azure. Para obter as etapas detalhadas, vá para Adicionar uma máquina
virtual existente ao conjunto de disponibilidade.
Para uma VM criada por meio do modelo de implantação do Resource Manager: Salve a configuração
da VM e, em seguida, exclua e recrie as VMs no conjunto de disponibilidade. Para fazer isso, use o
script em Definir Conjunto de Disponibilidade de VM do Azure Resource Manager. Antes de executar
esse script, verifique as limitações dele e planeje o tempo de inatividade.
2. Exclua VMs e discos antigos . Verifique se os discos Premium são consistentes com os discos de
origem e se as novas VMs realizam a mesma função que as VMs de origem. Exclua a VM e exclua os
discos das contas de armazenamento de origem no Portal do Azure. Se houver um problema no qual o
disco não é excluído, mesmo que você exclua a VM, consulte Solucionar problemas de erros de exclusão
de recursos de armazenamento.
3. Limpe a infraestrutura do Azure Site Recover y . Se o Site Recovery não for mais necessário, você
poderá limpar a infraestrutura dele. Exclua itens duplicados, o servidor de configuração e a política de
recuperação, então exclua o cofre do Azure Site Recovery.
Monitorar e solucionar problemas de proteção para máquinas virtuais e sites físicos
Página de perguntas de P e R da Microsoft para o Microsoft Azure Site Recovery
Próximas etapas
Para cenários específicos de migração de máquinas virtuais, consulte as seguintes fontes:
Migrar Máquinas Virtuais do Azure entre as Contas de Armazenamento
Fazer upload de um disco rígido virtual do Linux
Migrando Máquinas Virtuais do Amazon AWS para o Microsoft Azure
Confira também as fontes a seguir para saber mais sobre o Armazenamento do Azure e as Máquinas Virtuais
do Azure:
Armazenamento do Azure
Máquinas Virtuais do Azure
Selecionar um tipo de disco para VMs de IaaS
Migrar para o Armazenamento Premium usando o
Azure Site Recovery
Os SSDs premium do Azure oferecem suporte de disco de alto desempenho e baixa latência para máquinas
virtuais (VMs) que estão executando cargas de trabalho intensivas para entradas e saídas. Este guia ajuda você a
migrar os discos de VM de uma conta de armazenamento Standard para uma conta de armazenamento
Premium usando o Azure Site Recovery.
O Site Recovery é um serviço do Azure que colabora com sua estratégia de continuidade dos negócios e de
recuperação de desastre por meio da coordenação da replicação de servidores físicos locais e VMs na nuvem
(Azure) ou em um datacenter secundário. Quando ocorrem paralisações em seu local primário, você realiza o
failover em um local secundário a fim de manter aplicativos e cargas de trabalho disponíveis. Quando o local
primário retoma as operações normais, você realiza o failback.
O Site Recovery fornece failovers de teste para dar suporte à simulações de recuperação de desastre sem afetar
os ambientes de produção. É possível executar failovers com perda mínima de dados (dependendo da
frequência de replicação) para desastres inesperados. No cenário de migração para o Armazenamento
Premium, é possível usar um failover no Site Recovery para migrar os discos de destino para uma conta de
É recomendável migrar para o armazenamento Premium usando o Site Recovery, porque essa opção fornece
tempo de inatividade mínimo. Essa opção também evita a execução manual de copiar discos e criar novas VMs.
O Site Recovery vai copiar os discos sistematicamente e criar novas VMs durante o failover.
O Site Recovery oferece suporte a vários tipos de failover com pouco ou nenhum tempo de inatividade. Para
planejar o tempo de inatividade e estimar a perda de dados, consulte os tipos de failover no Site Recovery. Se
você se preparar para se conectar a VMs do Azure após o failover, você conseguirá se conectar à VM do Azure
usando RDP após o failover.
Componentes do Azure Site Recovery

Esses componentes do Site Recovery são relevantes para este cenário de migração:
O ser vidor de configuração é uma VM do Azure que coordena a comunicação e gerencia os processos
de recuperação e replicação de dados. Nesta VM, você executa um arquivo único de instalação para
instalar o servidor de configuração e um componente adicional, chamado de servidor de processo, como
um gateway de replicação. Leia sobre os pré-requisitos do servidor de configuração. Você define o
servidor de configuração apenas uma vez e pode usá-lo em todas as migrações para a mesma região.
O ser vidor de processo é um gateway de replicação que:
1. Recebe dados de replicação de VMs de origem.
2. Otimiza os dados com armazenamento em cache, compactação e criptografia.
3. Envia os dados para uma conta de armazenamento.
Ele também manipula a instalação por push do serviço de mobilidade nas VMs de origem e executa a
descoberta automática destas. O servidor de processo padrão é instalado no servidor de configuração.
Você pode implantar servidores de processo autônomo adicionais para dimensionar sua implantação.
Leia sobre práticas recomendadas para implantação de servidor de processo e implantação de servidores
de processo adicionais. Você define o servidor de processo apenas uma vez e pode usá-lo em todas as
migrações para a mesma região.
O ser viço de mobilidade é um componente que é implantado em todas as VMs padrão que você
deseja replicar. Ele captura gravações de dados na VM padrão e as encaminha ao servidor de processo.
Leia sobre pré-requisitos de máquinas replicadas.
Este gráfico mostra como esses componentes interagem:
NOTE
O Site Recovery não dá suporte à migração de discos dos espaços de armazenamento.
Para componentes adicionais para outros cenários, consulte Arquitetura de cenário.

Conceitos básicos do Azure
Estes são os requisitos do Azure para esse cenário de migração:
Uma assinatura do Azure.
Uma conta de armazenamento Premium do Azure para armazenar os dados replicados.
Uma rede virtual do Azure à qual as VMs serão conectadas quando forem criadas no failover. A rede virtual
do Azure tem que estar na mesma região em que o Site Recovery é executado.
Uma conta de armazenamento Standard do Azure para armazenar logs de replicação. Ela pode ser a mesma
conta de armazenamento dos discos de VM que estão sendo migrados.
Pré-requisitos
Compreenda os componentes relevantes do cenário de migração na seção anterior.
Planeje o tempo de inatividade sabendo mais sobre o Failover no Site Recovery.
Etapas de configuração e migração

Você pode usar o Site Recovery para migrar VMs IaaS do Azure entre regiões ou na mesma região. As
instruções a seguir foram adaptadas para este cenário de migração com base no artigo Replicar VMs VMware
ou servidores físicos para o Azure. Siga os links para obter as etapas detalhadas que complementam as
instruções deste artigo.
Etapa 1: Criar um cofre dos Serviços de Recuperação
2. Selecione Criar um recurso > Gerenciamento > Backup e Site Recover y (OMS) . Como alternativa,
você pode selecionar Procurar > Cofre dos Ser viços de Recuperação > Adicionar .
NOTE
Backup e Recuperação de Site foi anteriormente parte da OMS suite.
3. Especifique uma região para a qual as VMs serão replicadas. Para fins de migração na mesma região,
selecione a região em que estão as VMs e as contas de armazenamento de origem.
Etapa 2: Escolher as metas de proteção
1. Na VM em que você deseja instalar o servidor de configuração, abra o portal do Azure.
2. Vá para Cofres dos Ser viços de Recuperação > Configurações > Site Recover y > Etapa 1:
Preparar a Infraestrutura > Meta de proteção .
3. Em Objetivo de proteção , na primeira lista suspensa, selecione Para o Azure . Na segunda lista
suspensa, selecione Não vir tualizados / outros e selecione OK .
Etapa 3: Configure o ambiente de origem (servidor de configuração )

1. Baixe a Configuração unificada do Azure Site Recover y e a chave de registro do cofre indo para os
painéis Preparar infraestrutura > Preparar origem > Adicionar ser vidor .
Você vai precisar da chave de registro do cofre para executar a instalação unificada. A chave é válida por
cinco dias após ser gerada.
2. No painel Adicionar Ser vidor , adicione um servidor de configuração.
3. Na VM que você está usando como servidor de configuração, execute a Instalação Unificada para instalar
o servidor de configuração e o servidor de processo. Você pode percorrer as capturas de tela para
concluir a instalação. Você pode consultar as capturas de tela a seguir para ver as etapas especificadas
para este cenário de migração.
a. Em Antes de começar , selecione Instalar o ser vidor de configuração e o ser vidor em
processo .
b. Em Registro , procure e selecione a chave de registro que você baixou do cofre.
c. Em Detalhes do Ambiente , selecione se você replicará as VMs VMware. Para esse cenário de
migração, escolha Não .
4. Quando a instalação estiver concluída, faça o seguinte na janela Ser vidor de Configuração do
Microsoft Azure Site Recover y :
a. Use a guia Gerenciar contas para criar a conta que o Site Recovery pode usar para descoberta
automática. (No cenário sobre proteção de computadores físicos, configurar a conta não é
relevante, mas você precisa de pelo menos uma conta para habilitar uma das etapas a seguir.
Nesse caso, você pode nomear a conta e a senha como qualquer.)
b. Use a guia Registro do cofre para carregar o arquivo de credencial de cofre.
Etapa 4: Configurar o ambiente de origem

Selecione Preparar infraestrutura > Destino e especifique o modelo de implantação que você deseja usar
para as VMs após o failover. Você pode escolher Clássico ou Gerenciador de recursos , dependendo do
cenário.
A Recuperação de Site verifica se você tem uma ou mais contas de armazenamento e redes do Azure
compatíveis.
NOTE
Se estiver usando uma conta de armazenamento Premium para os dados replicados, você precisará configurar uma conta
de armazenamento Standard adicional para armazenar os logs de replicação.
Etapa 5: Definir as configurações de replicação

Para verificar se o seu servidor de configuração está corretamente associado à política de replicação que você
criou, siga Definir configurações de replicação.
Etapa 6: Planejar a capacidade
1. Use o planejador de capacidade para estimar com precisão a largura de banda de rede, o
armazenamento e outros requisitos para atender às suas necessidades de replicação.
2. Quando terminar, selecione Sim, eu fiz isso na caixa Você concluiu o planejamento da
capacidade? .
Etapa 7: Instalar o serviço de mobilidade e habilitar a replicação
1. Você pode optar pela instalação por push para suas VMs de origem ou instalação manual do serviço de
mobilidade nas suas VMs de origem. Você pode encontrar a solicitação de instalação por push e o
caminho do instalador do manual no link fornecido. Se você estiver fazendo uma instalação manual, será
preciso usar um endereço IP interno para localizar o servidor de configuração.
A VM que sofreu o failover terá dois discos temporários: um da VM primária e outro criado durante o
provisionamento da VM na região de recuperação. Para excluir o disco temporário antes da replicação,
instale o serviço de mobilidade antes de habilitar a replicação. Para saber mais sobre como excluir o disco
temporário, veja Excluir discos da replicação.
2. Habilite a replicação da seguinte maneira:
a. Selecione Replicar Aplicativo > Origem . Depois de habilitar a replicação pela primeira vez,
selecione +Replicar no cofre para habilitar a replicação para máquinas virtuais adicionais.
b. Na etapa 1, configure Origem como o servidor de processo.
c. Na etapa 2, especifique o modelo de implantação pós-failover, uma conta de armazenamento
Premium para a migração, uma conta de armazenamento padrão para salvar os logs e uma rede
virtual para falhas.
d. Na etapa 3, adicione VMs protegidas por endereço IP. (Talvez seja necessário um endereço IP interno
para localizá-las.)
e. Na etapa 4, configure as propriedades, selecionando as contas que você configurou anteriormente no
servidor de processo.
f. Na etapa 5, escolha a política de replicação que você criou anteriormente em "Etapa 5: Defina as
configurações de replicação."
g. Selecione OK .
NOTE
Quando uma VM do Azure é desalocada e reiniciada, não há nenhuma garantia de que ela receberá o mesmo
endereço IP. Se houver alteração no endereço IP do servidor de processo/configuração ou nas VMs do Azure
protegidas, a replicação pode não funcionar corretamente neste cenário.
Ao criar seu ambiente de Armazenamento do Azure, é recomendável usar contas de armazenamento separadas
para cada VM em um conjunto de disponibilidade. É recomendável que você siga a melhor prática na camada
de armazenamento para usar várias contas de armazenamento para cada conjunto de disponibilidade. A
distribuição de discos VM para várias contas de armazenamento ajuda a melhorar a disponibilidade de
armazenamento e distribui a E/S em toda a infraestrutura de armazenamento do Azure.
Se suas VMs estiverem em um conjunto de disponibilidade, em vez de replicar os discos de todas elas em uma
conta de armazenamento, é altamente recomendável migrar várias VMs várias vezes. Desse modo, as VMs em
um mesmo conjunto de disponibilidade não compartilham uma única conta de armazenamento. Use o painel
Habilitar Replicação para configurar uma conta de armazenamento de destino para cada VM, uma de cada
vez.
Você pode escolher um modelo de implantação pós-failover de acordo com suas necessidades. Se você escolher
o Azure Resource Manager como seu modelo de implantação pós-failover, você poderá fazer failover de uma
VM (Resource Manager) para uma VM (Resource Manager) ou você poderá fazer failover de uma VM (clássica)
para uma VM (Resource Manager).
Etapa 8: Execute um teste de failover
Para verificar se a replicação foi concluída, selecione sua instância do Site Recovery e, em seguida, selecione
Configurações > Itens Replicados . Você verá o status e a porcentagem do processo de replicação.
Após a conclusão da replicação inicial, execute o failover de teste para validar a estratégia de replicação. Para
obter as etapas detalhadas de um failover de teste, consulte Executar um failover de teste no Site Recovery.
NOTE
Antes de você executar qualquer failover, verifique se as VMs e a estratégia de replicação atendem aos requisitos. Para
obter mais informações e instruções sobre a execução de um failover de teste, consulte Failover de teste para o Azure no
Site Recovery.
Você pode ver o status do failover de teste em Configurações > Trabalhos >
NOME_DO_SEU_PLANO_DE_FAILOVER. No painel, você pode ver uma divisão das etapas e os resultados de
êxito/falha. Se o failover de teste falhar em alguma etapa, selecione-a para verificar a mensagem de erro.
Etapa 9: Executar um failover
Após a conclusão do failover de teste, execute um failover para migrar os discos para o Armazenamento
Premium e replicar as instâncias de VM. Siga as etapas detalhadas em Executar um failover.
Verifique se você selecionou Desligar VMs e sincronizar os dados mais recentes . Essa opção especifica
que o Site Recovery deve tentar desligar as VMs protegidas e sincronizar os dados para que ocorra o failover da
versão mais recente dos dados. Se você não selecionar essa opção ou se tentar e não tiver êxito, o failover será
do último ponto de recuperação da VM disponível.
O Site Recovery vai criar uma instância VM cujo tipo é igual ou semelhante ou de uma VM compatível com
armazenamento Premium. Para verificar o desempenho e o preço de várias instâncias de VM, vá para Preços de
Máquinas Virtuais Windows ou Preços de Máquinas Virtuais Linux.
Etapas pós-migração
1. Configurar as VMs replicadas para o conjunto de disponibilidade, se aplicável . O Site Recovery
não dá suporte à migração de VMs junto com o conjunto de disponibilidade. Dependendo da
implantação da VM replicada, siga um dos seguintes procedimentos:
Para uma VM criada por meio do modelo de implantação clássico: Adicione a VM ao conjunto de
disponibilidade no portal do Azure. Para obter as etapas detalhadas, vá para Adicionar uma máquina
virtual existente ao conjunto de disponibilidade.
Para uma VM criada por meio do modelo de implantação do Resource Manager: Salve a configuração
da VM e, em seguida, exclua e recrie as VMs no conjunto de disponibilidade. Para fazer isso, use o
script em Definir Conjunto de Disponibilidade de VM do Azure Resource Manager. Antes de executar
esse script, verifique as limitações dele e planeje o tempo de inatividade.
2. Exclua VMs e discos antigos . Verifique se os discos Premium são consistentes com os discos de
origem e se as novas VMs realizam a mesma função que as VMs de origem. Exclua a VM e exclua os
discos das contas de armazenamento de origem no Portal do Azure. Se houver um problema no qual o
disco não é excluído, mesmo que você exclua a VM, consulte Solucionar problemas de erros de exclusão
de recursos de armazenamento.
3. Limpe a infraestrutura do Azure Site Recover y . Se o Site Recovery não for mais necessário, você
poderá limpar a infraestrutura dele. Exclua itens duplicados, o servidor de configuração e a política de
recuperação, então exclua o cofre do Azure Site Recovery.
Monitorar e solucionar problemas de proteção para máquinas virtuais e sites físicos
Página de perguntas de P e R da Microsoft para o Microsoft Azure Site Recovery
Próximas etapas
Para cenários específicos de migração de máquinas virtuais, consulte as seguintes fontes:
Migrar Máquinas Virtuais do Azure entre as Contas de Armazenamento
Criar e carregar um VHD do Windows Server no Azure
Migrando Máquinas Virtuais do Amazon AWS para o Microsoft Azure
Confira também as fontes a seguir para saber mais sobre o Armazenamento do Azure e as Máquinas Virtuais
do Azure:
Armazenamento do Azure
Máquinas Virtuais do Azure
Migrar VMs do Azure para o Managed Disks no
Azure
O Azure Managed Disks simplifica o gerenciamento do armazenamento, acabando com a necessidade de

gerenciar as contas de armazenamento de forma separada. Também é possível migrar suas VMs do Azure para o
Managed Disks para aproveitar a melhor confiabilidade das VMs em um conjunto de disponibilidade. Ele
garante que os discos de VMs diferentes em um conjunto de disponibilidade estejam suficientemente isolados
entre si para evitar um ponto único de falhas. Ele coloca automaticamente os discos de VMs diferentes em um
conjunto de disponibilidade em unidades de escala (carimbos) de armazenamentos diferentes, o que limita o
impacto de falhas em uma única unidade de escala de armazenamento causadas por falhas de hardware e de
software. Com base em suas necessidades, você pode escolher entre quatro tipos de opções de armazenamento.
Para saber mais sobre os tipos de disco disponíveis, confira nosso artigo Selecionar um tipo de disco
Cenários de migração
É possível migrar para o Managed Disks nos cenários a seguir:
C EN Á RIO A RT IGO
Converter VMs autônomas e VMs em um conjunto de Converter VMs para usar discos gerenciados
disponibilidade para discos gerenciados
Converter uma única VM do clássico para o Resource Criar uma VM de um VHD clássico
Manager em discos gerenciados
Converter todas as VMs em uma vNet do clássico para o Migrar os recursos de IaaS do modo clássico para o modo
Gerenciador de recursos em discos gerenciados do Resource Manager e Converter uma VM de discos não
gerenciados para discos gerenciados
Atualizar VMs com discos não gerenciados padrão para VMs Primeiro, Converta uma máquina virtual do Windows de
com discos Premium gerenciados discos não gerenciados em discos gerenciados. Em seguida,
atualize o tipo de armazenamento de um disco gerenciado.
IMPORTANT
Próximas etapas
Saiba mais sobre o Managed disks
Confira os preços dos Managed Disks.
Converter uma máquina virtual Linux de discos não
gerenciados em Managed Disks
Se você tiver máquinas virtuais (VMs) do Linux existentes que usam discos não gerenciados, é possível
converter as VMs para usar o Azure Managed Disks. Esse processo converte o disco do sistema operacional e os
discos de dados anexados.
Este artigo mostra como converter VMs usando a CLI do Azure. Se você precisar instalar ou atualizá-lo, confira
instalar a CLI do Azure.
Antes de começar
Examine as perguntas frequentes sobre migração para Managed Disks.
A conversão requer uma reinicialização da VM, programe então a migração de suas VMs durante uma
janela de manutenção já existente.
A conversão não é reversível.
Lembre-se de que quaisquer usuários com a função Colaborador da Máquina Virtual não poderá alterar
o tamanho da VM (como podiam antes da conversão). Isso ocorre porque as VMs com discos
gerenciados requerem que o usuário tenha a permissão Microsoft.Compute/disks/write nos discos do
Não deixe de testar a conversão. Migre uma máquina virtual de teste antes de executar a migração na
produção.
Durante a conversão, você pode desalocar a VM. A VM recebe um endereço IP novo quando é iniciada
após a conversão. Se necessário, você pode atribuir um endereço IP estático à VM.
Examine a versão mínima do agente de VM do Azure necessária para oferecer suporte ao processo de
conversão. Para saber mais sobre como verificar e atualizar a versão do seu agente, confira Suporte de
versão mínima para agentes de VM no Azure
Os VHDs originais e a conta de armazenamento usados pela VM antes da conversão não são excluídos. Eles
continuam a incorrer em encargos. Para evitar ser cobrado por esses artefatos, exclua os blobs VHD originais
depois de verificar que a conversão foi concluída. Se você precisar encontrar esses discos desanexados para
excluí-los, consulte nosso artigo Localizar e excluir discos gerenciados e não geridos do Azure
desconectados.
Converter VMs de instância única

Esta seção aborda como converter suas VMs de instância única do Azure de discos não gerenciados em discos
gerenciados. (Se suas VMs estiverem em um conjunto de disponibilidade, consulte a próxima seção.) Você pode
usar esse processo para converter as VMs de discos não gerenciados Premium (SSD) em discos gerenciados
Premium ou discos não gerenciados padrão (HDD) em discos gerenciados Standard.
1. Desaloque a VM usando az vm deallocate. O seguinte exemplo desaloca a VM myVM no grupo de
recursos chamado myResourceGroup :
2. Converta a VM em Managed Disks com az vm convert. O processo a seguir converte a VM nomeada

myVM , incluindo o disco do sistema operacional e quaisquer discos de dados:
az vm convert --resource-group myResourceGroup --name myVM
3. Inicie a VM após a conversão em Managed Disks usando az vm start. O exemplo a seguir inicia a VM
myVM no grupo de recursos myResourceGroup .
Converter VMs em um conjunto de disponibilidade

Se as VMs que você deseja converter em discos gerenciados estão em um conjunto de disponibilidade, converta
primeiro o conjunto de disponibilidade em um conjunto de disponibilidade gerenciado.
Todas as VMs no conjunto de disponibilidade devem ser desalocadas antes de converter o conjunto de
disponibilidade. Planeje a conversão de todas as VMs em Managed Disks após conversão do próprio conjunto
de disponibilidade em um conjunto de disponibilidade gerenciada. Então, inicie todas as VMs e continuar a
operar normalmente.
1. Liste todas as VMs em um conjunto de disponibilidade usando az vm availability-set list. O seguinte
exemplo lista todas as VMs em um conjunto de disponibilidade myAvailabilitySet no grupo de recursos
myResourceGroup :
az vm availability-set show \
--query [virtualMachines[*].id] \
--output table
2. Desaloque todas as VMs usando az vm deallocate. O seguinte exemplo desaloca a VM myVM no grupo de
3. Converta um conjunto de disponibilidade usando az vm availability-set convert. O exemplo a seguir

converte o conjunto de disponibilidade myAvailabilitySet no grupo de recursos myResourceGroup :
az vm availability-set convert \
4. Converta todas as VMs em Managed Disks usando az vm convert. O processo a seguir converte a VM
nomeada myVM , incluindo o disco do sistema operacional e quaisquer discos de dados:
az vm convert --resource-group myResourceGroup --name myVM
5. Inicie todas as VMs após a conversão em Managed Disks usando az vm start. O seguinte exemplo inicia a
VM chamada myVM no grupo de recursos chamado myResourceGroup :
Converter usando o portal do Azure

Também é possível converter discos não gerenciados em discos gerenciados usando o portal do Azure.
2. Selecione a VM na lista de VMs no portal.
3. Na folha da VM, selecione Discos no menu.
4. Na parte superior da folha Discos , selecione Migrar para discos gerenciados .
5. Se sua VM estiver em um conjunto de disponibilidade, haverá um aviso na folha Migrar para discos
gerenciados informando que você precisa converter o conjunto de disponibilidade primeiro. O aviso deve
ter um link em que você pode clicar para converter o conjunto de disponibilidade. Quando o conjunto de
disponibilidade for convertido ou se sua VM não estiver em um conjunto de disponibilidade, clique em
Migrar para iniciar o processo de migração de seus discos para discos gerenciados.
A VM será interrompida e reiniciada após a conclusão da migração.
Próximas etapas
Para saber mais sobre as opções de armazenamento, confira a Visão geral dos Azure Managed Disks.
Converter uma máquina virtual do Windows de
discos não gerenciados em Managed Disks
Se você tiver VMs (máquinas virtuais) do Windows existentes que usam discos não gerenciados, será possível
converter as VMs para usar Managed Disks por meio do serviço Azure Managed Disks. Esse processo converte
o disco do sistema operacional e os discos de dados anexados.
Antes de começar
Revisão Planejar a migração para os Managed Disks.
Examine as perguntas frequentes sobre migração para Managed Disks.
A conversão requer uma reinicialização da VM, programe então a migração de suas VMs durante uma
janela de manutenção já existente.
A conversão não é reversível.
Lembre-se de que quaisquer usuários com a função Colaborador da Máquina Virtual não poderá alterar
o tamanho da VM (como podiam antes da conversão). Isso ocorre porque as VMs com discos
gerenciados requerem que o usuário tenha a permissão Microsoft.Compute/disks/write nos discos do
Não deixe de testar a conversão. Migre uma máquina virtual de teste antes de executar a migração na
produção.
Durante a conversão, você pode desalocar a VM. A VM recebe um endereço IP novo quando é iniciada
após a conversão. Se necessário, você pode atribuir um endereço IP estático à VM.
Examine a versão mínima do agente de VM do Azure necessária para oferecer suporte ao processo de
conversão. Para saber mais sobre como verificar e atualizar a versão do seu agente, confira Suporte de
versão mínima para agentes de VM no Azure
Os VHDs originais e a conta de armazenamento usados pela VM antes da conversão não são excluídos. Eles
continuam a incorrer em encargos. Para evitar ser cobrado por esses artefatos, exclua os blobs VHD originais
depois de verificar que a conversão foi concluída. Se você precisar encontrar esses discos desanexados para
excluí-los, consulte nosso artigo Localizar e excluir discos gerenciados e não geridos do Azure
desconectados.
Converter VMs de instância única

Esta seção aborda como converter suas VMs de instância única do Azure de discos não gerenciados em discos
gerenciados. (Se suas VMs estão em uma conjunto de disponibilidade, consulte a próxima seção.)
1. Desaloque a VM usando o cmdlet Stop-AzVM. O seguinte exemplo desaloca a VM myVM no grupo de
$vmName = "myVM"
2. Converter a VM em Managed Disks usando o cmdlet ConvertTo-AzVMManagedDisk. O seguinte
processo converte a VM anterior, incluindo o disco do sistema operacional e discos de dados, e inicia a
Máquina Virtual:
ConvertTo-AzVMManagedDisk -ResourceGroupName $rgName -VMName $vmName
Converter VMs em um conjunto de disponibilidade

Se as VMs que você deseja converter em discos gerenciados estão em um conjunto de disponibilidade, converta
primeiro o conjunto de disponibilidade em um conjunto de disponibilidade gerenciado.
1. Converter o conjunto de disponibilidade usando o cmdlet Update-AzAvailabilitySet. O exemplo a seguir
atualiza o conjunto de disponibilidade nomeado myAvailabilitySet no grupo de recursos nomeado
myResourceGroup :
$avSetName = 'myAvailabilitySet'
$avSet = Get-AzAvailabilitySet -ResourceGroupName $rgName -Name $avSetName

Update-AzAvailabilitySet -AvailabilitySet $avSet -Sku Aligned
Se a região em que o conjunto de disponibilidade está localizado tem apenas 2 domínios de falha
gerenciados, mas o número de domínios de falha não gerenciado é 3, este comando mostra um erro
semelhante a "O total de domínio de falha especificado é 3 e deve estar no intervalo de 1 a 2". Para
resolver o erro, atualize o domínio de falha para 2 e atualize Sku para Aligned da seguinte maneira:
$avSet.PlatformFaultDomainCount = 2
Update-AzAvailabilitySet -AvailabilitySet $avSet -Sku Aligned
2. Desaloque e converta as VMs no conjunto de disponibilidade. O seguinte script desaloca cada VM

usando o cmdlet Stop-AzVM, converte-a usando ConvertTo-AzVMManagedDisk e reinicia-a
automaticamente como parte do processo de conversão:
$avSet = Get-AzAvailabilitySet -ResourceGroupName $rgName -Name $avSetName
foreach($vmInfo in $avSet.VirtualMachinesReferences)
{
$vm = Get-AzVM -ResourceGroupName $rgName | Where-Object {$_.Id -eq $vmInfo.id}
Stop-AzVM -ResourceGroupName $rgName -Name $vm.Name -Force
ConvertTo-AzVMManagedDisk -ResourceGroupName $rgName -VMName $vm.Name
}
Se houver um erro durante a conversão ou se uma VM estiver em um estado de falha devido a problemas em
uma conversão anterior, execute o cmdlet ConvertTo-AzVMManagedDisk novamente. Normalmente, uma repetição
simples desbloqueia a situação. Antes de converter, verifique se todas as extensões de VM estão no estado
'Provisionamento bem-sucedido' ou a conversão falhará com o código de erro 409.
Converter usando o portal do Azure

Também é possível converter discos não gerenciados em discos gerenciados usando o portal do Azure.
2. Selecione a VM na lista de VMs no portal.
3. Na folha da VM, selecione Discos no menu.
4. Na parte superior da folha Discos , selecione Migrar para discos gerenciados .
5. Se sua VM estiver em um conjunto de disponibilidade, haverá um aviso na folha Migrar para discos
gerenciados informando que você precisa converter o conjunto de disponibilidade primeiro. O aviso deve
ter um link em que você pode clicar para converter o conjunto de disponibilidade. Quando o conjunto de
disponibilidade for convertido ou se sua VM não estiver em um conjunto de disponibilidade, clique em
Migrar para iniciar o processo de migração de seus discos para discos gerenciados.
A VM será interrompida e reiniciada após a conclusão da migração.
Próximas etapas
Converter Managed Disks padrão em premium
Faça uma cópia somente leitura de uma VM usando instantâneos.
Adicionar um disco a uma VM do Linux
Este artigo mostra a você como anexar um disco persistente à sua VM para que você possa preservar dados,
mesmo que sua VM seja provisionada novamente devido à manutenção ou ao redimensionamento.
Anexar um novo disco a uma VM

Se você quiser adicionar um disco de dados novo vazio em sua VM, use o comando az vm disk attach com o
parâmetro --new . Se a VM estiver em uma zona de disponibilidade, o disco será criado automaticamente na
mesma zona que a VM. Para obter mais informações, consulte Visão geral de zonas de disponibilidade. O
exemplo a seguir cria um disco chamado myDataDisk que tem tamanho de 50 Gb:
az vm disk attach \
--vm-name myVM \
--name myDataDisk \
--new \
--size-gb 50
Anexar um disco existente

Para anexar um disco existente, localize a ID do disco e passe-a para o comando az vm disk attach. A exemplo a
seguir consulta em busca de um disco chamado myDataDisk em myResourceGroup, em seguida, anexa-o à VM
denominada 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 participar, formatar e montar o novo disco para que sua VM do Linux possa usá-lo, Secure Shell em sua
VM. Para saber mais, confira Como usar o SSH com o Linux no Azure. O exemplo a seguir se conecta a uma VM
com o endereço IP público de 10.123.123.25 com o nome de usuário azureuser:
Localize o disco
Uma vez conectado à sua VM, você precisa encontrar o disco. Neste exemplo, estamos usando lsblk para listar
os discos.
lsblk -o NAME,HCTL,SIZE,MOUNTPOINT | grep -i "sd"

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 está o disco que desejamos, porque ele é 50g. Se você não tiver certeza de qual disco ele se baseia
apenas no tamanho, poderá ir para a página VM no portal, selecionar discos e verificar o número de LUN para
o disco em discos de dados .
Formatar o disco
Formate o disco com parted , se o tamanho do disco for 2 tebibytes (TIB) ou maior, você deverá usar o
particionamento GPT, se ele estiver em 2TiB, você poderá usar o particionamento MBR ou GPT.
NOTE
É recomendável que você use a versão mais recente parted que está disponível para seu distribuição. Se o tamanho do
disco for 2 tebibytes (TiB) ou maior, você deverá usar o particionamento GPT. Se o tamanho do disco estiver abaixo de 2
TiB, você poderá usar o particionamento MBR ou GPT.
O exemplo a seguir usa parted on /dev/sdc , que é onde o primeiro disco de dados normalmente estará na
maioria das VMs. Substitua sdc pela opção correta para seu disco. Também estamos Formatando-a usando o
sistema de arquivos xfs .
Use o partprobe Utilitário para verificar se o kernel está ciente da nova partição e do sistema de arquivos. A
falha ao usar partprobe pode fazer com que os comandos blkid ou lslbk não retornem o UUID para o novo
FileSystem imediatamente.
Monte o disco
Agora, crie um diretório para montar o novo sistema de arquivos usando o mkdir . O exemplo a seguir cria um
diretório em /datadrive :
sudo mkdir /datadrive
Use mountpara montar então o sistema de arquivos. O exemplo a seguir monta a /dev/sdc1 partição para o
/datadrive ponto de montagem:
sudo mount /dev/sdc1 /datadrive
Persista a montagem
Para garantir que a unidade seja remontada automaticamente após uma reinicialização, ela deve ser adicionada
ao arquivo /etc/fstab. Também é altamente recomendável que o UUID (identificador universal exclusivo) seja
usado em /etc/fstab para se referir à unidade em vez de apenas ao nome do dispositivo (como, /dev/sdc1). Se o
sistema operacional detectar um erro de disco durante a inicialização, usar o UUID evita que o disco incorreto
seja montado em um determinado local. Os discos de dados restantes seriam então atribuídos a essas mesmas
IDs de dispositivo. Para localizar o UUID da nova unidade, use o utilitário blkid :
sudo blkid
A saída deve ser 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"
NOTE
Em seguida, abra o arquivo /etc/fstab em um editor de texto, conforme descrito a seguir:
Neste exemplo, use o valor UUID para o /dev/sdc1 dispositivo que foi criado nas etapas anteriores e o
mountpoint de /datadrive . Adicione a seguinte linha ao final do /etc/fstab arquivo:
Neste exemplo, estamos usando o editor do nano, portanto, quando você terminar de editar o arquivo, use
Ctrl+O para gravar o arquivo e Ctrl+X sair do editor.
NOTE
Remover um disco de dados posteriormente sem editar fstab pode fazer com que a VM falhe ao ser inicializada. A maioria
das distribuições fornecem as opções de fstab nofail e/ou nobootwait. Essas opções permitem que um sistema inicialize
mesmo se o disco não for montado no momento da inicialização. Consulte a documentação da distribuição para obter
mais informações sobre esses parâmetros.
A opção nofail garante que a VM inicie mesmo que o sistema de arquivos esteja corrompido ou que o disco não exista no
momento da inicialização. Sem essa opção, você poderá encontrar um comportamento conforme descrito em Não é
possível conectar-se a uma VM Linux via SSH devido a erros no FSTAB
O console serial da VM do Azure pode ser usado para acesso ao console para sua VM se a modificação de fstab resultar
em uma falha de inicialização. Mais detalhes estão disponíveis na documentação do console serial.
Suporte a TRIM/UNMAP para Linux no Azure

Alguns kernels Linux permitem operações TRIM/UNMAP para descartar os blocos não utilizados no disco. Esse
recurso é útil principalmente no Armazenamento Standard, para informar o Azure de que as páginas excluídas
não são mais válidas e podem ser descartadas, podendo também economizar dinheiro se você criar arquivos
grandes e depois excluí-los.
Há duas maneiras de habilitar o suporte a TRIM em sua VM do Linux. Como de costume, consulte sua
distribuição para obter a abordagem recomendada:
Use a opção de montagem discard 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 afetar o desempenho. Como alternativa, você pode executar o
comando fstrim manualmente na linha de comando ou adicioná-lo a crontab para ser executado
normalmente:
Ubuntu
sudo apt-get install util-linux

sudo fstrim /datadrive
RHEL/CentOS
sudo yum install util-linux

Ao adicionar discos de dados a uma VM Linux, você poderá encontrar erros se não existir um disco no LUN 0. Se
você estiver adicionando um disco manualmente usando o comando az vm disk attach -new e especificar um
LUN ( --lun ) em vez de deixar que a plataforma Azure determine o LUN apropriado, verifique com atenção se
já existe (ou existirá) um disco no LUN 0.
Considere o exemplo a seguir que mostra um snippet da saída do 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 no LUN 0 e no LUN 1 (a primeira coluna nos detalhes da saída de
lsscsi``[host:channel:target:lun] ). Ambos os discos devem estar acessíveis na VM. Se você tivesse
especificado manualmente o primeiro disco para ser adicionado ao LUN 1 e o segundo disco ao LUN 2, os
discos não apareceriam corretamente para a VM.
NOTE
O valor de host do Azure é 5 nestes exemplos, mas ele poderá variar dependendo do tipo de armazenamento
selecionado.
Esse comportamento de disco não é um problema do Azure, mas da maneira em que o kernel do Linux segue as
especificações do SCSI. Quando o kernel do Linux verifica os dispositivos conectados no barramento do SCSI,
um dispositivo deve estar presente no LUN 0 para que o sistema continue a verificar outros dispositivos. Assim:
Examine a saída do lsscsi depois de adicionar um disco de dados para verificar se há um disco no LUN 0.
Se o disco não aparecer corretamente para a VM, verifique se existe um disco no LUN 0.
Próximas etapas
Para garantir que a VM Linux seja configurada corretamente, leia as recomendações em Otimizar sua VM do
Linux no Azure .
Expanda a capacidade de armazenamento adicionando mais discos e configure o RAID para obter
desempenho adicional.
Utilize o portal para anexar um disco de dados a
uma VM Linux
Este artigo mostra como anexar discos novos e existentes a uma máquina virtual Linux por meio do portal do
Azure. Você também pode anexar um disco de dados a uma VM do Windows no Portal do Azure.
Antes de anexar discos à sua VM, veja estas dicas:
O tamanho da máquina virtual controla quantos discos de dados você pode anexar a ela. Para obter detalhes,
consulte Tamanhos das máquinas virtuais.
Discos anexados às máquinas virtuais são, na verdade, os arquivos. vhd armazenados no Azure. Para obter
detalhes, confira a Introdução aos discos gerenciados.
Depois de anexar o disco, será necessário conectar a VM Linux para montar o novo disco.
Localizar a máquina virtual

1. Acesse o portal do Azure para encontrar a VM. Pesquise por Máquinas vir tuais e selecione essa opção.
2. Escolha a VM na lista.
3. Na página máquinas vir tuais , em configurações , escolha discos .
Anexar um novo disco

1. No painel discos , em discos de dados , selecione criar e anexar um novo disco .
2. Insira um nome para o disco gerenciado. Examine as configurações padrão e atualize o tipo de
armazenamento , o tamanho (GIB) , a criptografia e o cache de host conforme necessário.
3. Quando terminar, selecione salvar na parte superior da página para criar o disco gerenciado e atualizar a
configuração da VM.
Anexar um disco existente

1. No painel discos , em discos de dados , selecione anexar discos existentes .
2. Clique no menu suspenso para nome do disco e selecione um disco na lista de discos gerenciados
disponíveis.
3. Clique em Salvar para anexar o disco gerenciado existente e atualizar a configuração da VM:
Conectar-se à VM do Linux para montar o novo disco

Para participar, formatar e montar o novo disco para que sua VM do Linux possa usá-lo, Secure Shell em sua
VM. Para saber mais, confira Como usar o SSH com o Linux no Azure. O exemplo a seguir se conecta a uma VM
com o endereço IP público de 10.123.123.25 com o nome de usuário azureuser:
Localize o disco
Uma vez conectado à sua VM, você precisa encontrar o disco. Neste exemplo, estamos usando lsblk para listar
os discos.
sda 0:0:0:0 30G

├─sda1 29.9G /
├─sda14 4M
sdb 1:0:1:0 14G
└─sdb1 14G /mnt
sdc 3:0:0:0 4G
Neste exemplo, o disco que adicionei é sdc . É um LUN 0 e 4 GB.

Para obter um exemplo mais complexo, veja a aparência de vários discos de dados no Portal:
Na imagem, você pode ver que há três discos de dados: 4 GB no LUN 0, 16 GB no LUN 1 e 32G no LUN 2.
Esta é a aparência que pode ser semelhante ao uso de lsblk :
sda 0:0:0:0 30G

├─sda1 29.9G /
├─sda14 4M
sdb 1:0:1:0 14G
└─sdb1 14G /mnt
sdc 3:0:0:0 4G
sdd 3:0:0:1 16G
sde 3:0:0:2 32G
Da saída de lsblk você pode ver que o disco de 4 GB no LUN 0 é sdc , o disco 16 GB na LUN 1 é sdd ,eo
disco 32G no LUN 2 é sde .
Particionar um novo disco
Se você estiver usando um disco existente que contenha dados, pule para montar o disco. Se você estiver
anexando um novo disco, precisará particionar o disco.
O parted utilitário pode ser usado para particionar e formatar um disco de dados.
NOTE
É recomendável que você use a versão mais recente parted que está disponível para seu distribuição. Se o tamanho do
disco for 2 tebibytes (TiB) ou maior, você deverá usar o particionamento GPT. Se o tamanho do disco estiver abaixo de 2
TiB, você poderá usar o particionamento MBR ou GPT.
O exemplo a seguir usa parted on /dev/sdc , que é onde o primeiro disco de dados normalmente estará na
maioria das VMs. Substitua sdc pela opção correta para seu disco. Também estamos Formatando-a usando o
sistema de arquivos xfs .
Use o partprobe Utilitário para verificar se o kernel está ciente da nova partição e do sistema de arquivos. A
falha ao usar partprobe pode fazer com que os comandos blkid ou lslbk não retornem o UUID para o novo
FileSystem imediatamente.
Monte o disco
Crie um diretório para montar o novo sistema de arquivos usando o mkdir . O exemplo a seguir cria um
diretório em /datadrive :
sudo mkdir /datadrive
Use mount para montar então o sistema de arquivos. O exemplo a seguir monta a partição /dev/sdc1 para o
/datadrive ponto de montagem:
Para garantir que a unidade seja remontada automaticamente após uma reinicialização, ela deve ser adicionada
ao arquivo /etc/fstab. Também é altamente recomendável que o UUID (identificador universal exclusivo) seja
usado em /etc/fstab para se referir à unidade em vez de apenas ao nome do dispositivo (como, /dev/sdc1). Se o
sistema operacional detectar um erro de disco durante a inicialização, usar o UUID evita que o disco incorreto
seja montado em um determinado local. Os discos de dados restantes seriam então atribuídos a essas mesmas
IDs de dispositivo. Para localizar o UUID da nova unidade, use o utilitário blkid :
sudo blkid
/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"
NOTE
Em seguida, abra o arquivo /etc/fstab em um editor de texto, conforme descrito a seguir:
Neste exemplo, use o valor UUID para o /dev/sdc1 dispositivo que foi criado nas etapas anteriores e o
mountpoint de /datadrive . Adicione a seguinte linha ao final do /etc/fstab arquivo:
Usamos o editor do nano, portanto, quando você terminar de editar o arquivo, use Ctrl+O para gravar o
arquivo e Ctrl+X sair do editor.
NOTE
Remover um disco de dados posteriormente sem editar fstab pode fazer com que a VM falhe ao ser inicializada. A maioria
das distribuições fornecem as opções de fstab nofail e/ou nobootwait. Essas opções permitem que um sistema inicialize
mesmo se o disco não for montado no momento da inicialização. Consulte a documentação da distribuição para obter
mais informações sobre esses parâmetros.
A opção nofail garante que a VM inicie mesmo que o sistema de arquivos esteja corrompido ou que o disco não exista no
momento da inicialização. Sem essa opção, você poderá encontrar um comportamento conforme descrito em Não é
possível conectar-se a uma VM Linux via SSH devido a erros no FSTAB
Verificar o disco
Agora você pode usar lsblk novamente para ver o disco e o mountpoint.
sda 0:0:0:0 30G

├─sda1 29.9G /
├─sda14 4M
sdb 1:0:1:0 14G
└─sdb1 14G /mnt
sdc 3:0:0:0 4G
└─sdc1 4G /datadrive
Você pode ver que sdc agora está montado em /datadrive .

Suporte a TRIM/UNMAP para Linux no Azure
Alguns kernels Linux permitem operações TRIM/UNMAP para descartar os blocos não utilizados no disco. Esse
recurso é útil principalmente no Armazenamento Standard, para informar o Azure de que as páginas excluídas
não são mais válidas e podem ser descartadas, podendo também economizar dinheiro se você criar arquivos
grandes e depois excluí-los.
Há duas maneiras de habilitar o suporte a TRIM em sua VM do Linux. Como de costume, consulte sua
distribuição para obter a abordagem recomendada:
Use a opção de montagem discard 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 afetar o desempenho. Como alternativa, você pode executar o
comando fstrim manualmente na linha de comando ou adicioná-lo a crontab para ser executado
normalmente:
Ubuntu
sudo apt-get install util-linux

RHEL/CentOS
sudo yum install util-linux

Próximas etapas
Para obter mais informações e para ajudar a solucionar problemas de disco, consulte solucionar problemas de
nome do dispositivo VM Linux.
Você também pode anexar um disco de dados utilizando a CLI do Azure.
Anexar um disco de dados a uma VM do Windows
com o PowerShell
Este artigo mostra como anexar discos novos e existentes a uma máquina virtual do Windows usando o
PowerShell.
Primeiro, leia estas dicas:
O tamanho da máquina virtual controla quantos discos de dados você pode anexar a ela. Para obter mais
informações, consulte tamanhos das máquinas virtuais.
Para usar os SSDs premium, você precisará de um tipo de VM ativado para armazenamento premium, como
a máquina virtual da série DS ou da série GS.
Este artigo usa o PowerShell dentro do Azure cloud Shell, que é constantemente atualizado para a versão mais
recente. Para abrir o Cloud Shell, selecione Experimentar na parte superior de um bloco de código qualquer.
Adicionar um disco de dados vazio a uma máquina virtual

Este exemplo mostra como adicionar um disco de dados vazio a uma máquina virtual existente.
Usar discos gerenciados
$vmName = 'myVM'
$location = 'East US'
$dataDiskName = $vmName + '_datadisk1'
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Empty -DiskSizeGB 128
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName $rgName

Usando discos gerenciados em uma zona de disponibilidade

Para criar um disco em uma zona de disponibilidade, use New-AzDiskConfig com o parâmetro -Zone .O
exemplo a seguir cria um disco na zona 1.
$vmName = 'myVM'
$location = 'East US 2'
$dataDiskName = $vmName + '_datadisk1'
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Empty -DiskSizeGB 128
-Zone 1
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName $rgName

Inicializar o disco
Depois de adicionar um disco vazio, você precisará inicializá-lo. Para inicializar o disco, você pode entrar em
uma VM e usar o gerenciamento de disco. Se você habilitou o WinRM e um certificado na VM quando o criou,
poderá usar o PowerShell remoto para inicializar o disco. Você também pode usar uma extensão de script
personalizado:
$location = "location-name"
$scriptName = "script-name"
$fileName = "script-file-name"
Set-AzVMCustomScriptExtension -ResourceGroupName $rgName -Location $locName -VMName $vmName -Name
$scriptName -TypeHandlerVersion "1.4" -StorageAccountName "mystore1" -StorageAccountKey "primary-key" -
FileName $fileName -ContainerName "scripts"
O arquivo de script pode conter código para inicializar os discos, por exemplo:
$disks = Get-Disk | Where partitionstyle -eq 'raw' | sort number
$letters = 70..89 | ForEach-Object { [char]$_ }

$count = 0
$labels = "data1","data2"
foreach ($disk in $disks) {

$driveLetter = $letters[$count].ToString()
$disk |
Initialize-Disk -PartitionStyle MBR -PassThru |
New-Partition -UseMaximumSize -DriveLetter $driveLetter |
Format-Volume -FileSystem NTFS -NewFileSystemLabel $labels[$count] -Confirm:$false -Force
$count++
}
Anexar um disco de dados existente a uma VM

Você pode anexar um disco gerenciado existente a uma VM como um disco de dados.
$vmName = "myVM"
$dataDiskName = "myDisk"
$disk = Get-AzDisk -ResourceGroupName $rgName -DiskName $dataDiskName
$vm = Add-AzVMDataDisk -CreateOption Attach -Lun 0 -VM $vm -ManagedDiskId $disk.Id
Próximas etapas
Você também pode implantar discos gerenciados usando modelos. Para obter mais informações, consulte
usando Managed disks em modelos de Azure Resource Manager ou o modelo de início rápido para implantar
vários discos de dados.
Anexar um disco de dados gerenciado a uma VM
Windows usando o portal do Azure
Este artigo mostra como anexar um novo disco de dados gerenciados a uma VM (máquina virtual) do Windows
usando o portal do Azure. O tamanho da VM determina quantos discos de dados você pode anexar. Para obter
mais informações, consulte tamanhos das máquinas virtuais.
Adicionar um disco de dados

1. Vá para a portal do Azure para adicionar um disco de dados. Pesquise por Máquinas vir tuais e selecione
essa opção.
2. Selecione uma máquina virtual na lista.
3. Na página Máquina vir tual , selecione Discos .
4. Na página Discos , selecione Adicionar disco de dados .
5. No menu suspenso do novo disco, selecione Criar disco .
6. Na página Criar disco gerenciado , digite um nome para o disco e ajuste as outras configurações,
conforme necessário. Quando terminar, selecione Criar .
7. Na página Discos , selecione Salvar para salvar a nova configuração de disco da VM.
8. Depois que o Azure cria o disco e o anexa à máquina virtual, o novo disco é listado nas configurações de
disco da máquina virtual em discos de dados .
Inicializar um novo disco de dados

1. Conecte-se à VM.
2. Selecione o menu Iniciar do Windows na VM em execução e insira diskmgmt.msc na caixa de pesquisa. O
console Gerenciamento de Disco é aberto.
3. O Gerenciamento de Disco reconhece que você tem um disco novo não inicializado e a janela Inicializar
Disco é exibida.
4. Verifique se o novo disco está selecionado e, em seguida, selecione OK para inicializá-lo.
5. O novo disco é exibido como não alocado . Clique com o botão direito do mouse em qualquer lugar do
disco e selecione Novo volume simples . A janela Assistente de Novo Volume Simples é aberta.
6. Percorra o assistente, mantendo todos os padrões e, quando terminar, selecione Concluir .
7. Feche Gerenciamento de Disco .
8. Uma janela pop-up será exibida informando que é necessário formatar o novo disco antes de usá-lo.
Selecione Formatar disco .
9. Na janela Formatar novo disco , verifique as configurações e, em seguida, selecione Iniciar .
10. Será exibido um aviso informando que formatar os discos apaga todos os dados. Selecione OK .
11. Quando a formatação estiver concluída, selecione OK .
Próximas etapas
Você também pode anexar um disco de dados usando o PowerShell.
Caso seu aplicativo precise usar a unidade D: para armazenar dados, é possível alterar a letra da unidade do
disco temporário do Windows.
Usar a unidade D: como uma unidade de dados em
uma VM do Windows
Se seu aplicativo precisar usar a unidade D para armazenar dados, siga estas instruções para usar uma letra da
unidade diferente para o disco temporário. Nunca use o disco temporário para armazenar os dados que você
precisa manter.
Caso você redimensione ou use a opção Parar (Desalocar) para uma máquina virtual, isso poderá disparar o
posicionamento da máquina virtual para um novo hipervisor. Um evento de manutenção planejada ou não
planejada também pode disparar esse posicionamento. Nesse cenário, o disco temporário será reatribuído à
primeira letra da unidade disponível. Caso você tenha um aplicativo que exija especificamente a unidade D:, é
necessário seguir estas etapas para mover temporariamente o pagefile.sys, anexar um novo disco de dados e
atribuí-lo à letra D, bem como mover o pagefile.sys de volta à unidade temporária. Depois de concluído, o Azure
não usará novamente a unidade D: se a VM for movida para um hipervisor diferente.
Para obter mais informações sobre como o Azure usa o disco temporário, veja Noções básicas sobre a unidade
temporária nas Máquinas Virtuais do Microsoft Azure
Anexar o disco de dados

Primeiro, você precisará anexar o disco de dados à máquina virtual. Para fazer isso usando o portal, veja Como
anexar um disco de dados gerenciado no Portal do Azure.
Mover temporariamente o pagefile.sys para a unidade C

1. Conectar-se à máquina virtual.
2. Clique com o botão direito do mouse no menu Iniciar e selecione sistema .
3. No menu à esquerda, selecione Configurações avançadas do sistema .
4. Na seção Desempenho , selecione Configurações .
5. Selecione a guia Avançado .
6. Na seção Memória vir tual , selecione Alterar .
7. Selecione a unidade C , em seguida, clique em Tamanho gerenciado pelo sistema e clique em Definir .
8. Selecione a unidade C , em seguida, clique em Nenhum arquivo de paginação e clique em Definir .
9. Clique em Aplicar. Você receberá um aviso de que o computador precisa ser reiniciado para que as alterações
entrem em vigor.
10. Reinicie a máquina virtual.
Alterar a letra da unidade

1. Depois que a VM for reiniciada, faça logon novamente na VM.
2. Clique no menu Iniciar , digite diskmgmt.msc e pressione Enter. O Gerenciamento de Disco será iniciado.
3. Clique com o botão direito do mouse em D , a unidade de Armazenamento Temporário e selecione Alterar
Letra da Unidade e Caminhos .
4. Na Letra da unidade, selecione uma nova unidade como, por exemplo, T e clique em OK .
5. Clique com o botão direito do mouse no disco de dados e selecione Alterar Letra da Unidade e
Caminhos .
6. Na Letra da unidade, selecione a unidade D e clique em OK .
Mova o pagefile.sys de volta para a unidade de armazenamento

temporário
1. Clique com o botão direito do mouse no menu Iniciar e selecione sistema
2. No menu à esquerda, selecione Configurações avançadas do sistema .
3. Na seção Desempenho , selecione Configurações .
4. Selecione a guia Avançado .
5. Na seção Memória vir tual , selecione Alterar .
6. Selecione a unidade C do SO, em seguida, clique em Nenhum arquivo de paginação e clique em Definir .
7. Selecione a unidade T de armazenamento temporário, em seguida, clique em Tamanho gerenciado pelo
sistema e clique em Definir .
8. Clique em Aplicar . Você receberá um aviso de que o computador precisa ser reiniciado para que as
alterações entrem em vigor.
9. Reinicie a máquina virtual.
Próximas etapas
Você pode aumentar o armazenamento disponível para sua máquina virtual anexando um disco de dados
adicional.
Como desanexar um disco de dados de uma
máquina virtual Linux
Quando não precisar mais de um disco de dados conectado a uma máquina virtual, você poderá desanexá-lo
facilmente. Essa ação remove o disco da máquina virtual, mas não o remove do armazenamento. Neste artigo,
estamos trabalhando com uma distribuição do Ubuntu LTS 16.04. Se estiver usando uma distribuição diferente,
as instruções para desmontar o disco poderão ser diferentes.
WARNING
Se você desanexar um disco, ele não será excluído automaticamente. Se você se inscreveu para o armazenamento
Premium, você continuará incorrendo em encargos de armazenamento para o disco. Para obter mais informações,
consulte Preços e cobrança ao usar o Armazenamento Premium.
Se desejar usar os dados existentes no disco novamente, você pode reanexá-lo à mesma máquina virtual ou
anexá-lo a uma outra máquina virtual.
Conectar a VM para desmontar o disco

Antes de poder desanexar o disco usando a CLI ou o portal, será necessário desmontar o disco e remover as
referências para if do arquivo fstab.
Conecte-se à VM. Neste exemplo, o endereço IP público da VM é 10.0.1.4 com o nome de usuário azureuser:
Primeiro, localize o disco de dados que você quer desanexar. O exemplo a seguir usa o dmesg para filtrar em
discos SCSI:
dmesg | grep SCSI
[ 0.294784] SCSI subsystem initialized

[ 0.573458] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 7.110271] sd 2:0:0:0: [sda] Attached SCSI disk
[ 8.079653] sd 3:0:1:0: [sdb] Attached SCSI disk
[ 1828.162306] sd 5:0:0:0: [sdc] Attached SCSI disk
Aqui, sdc é o disco que queremos destacar. Também é necessário capturar o UUID do disco.
sudo -i blkid

/dev/sda1: UUID="11111111-1b1b-1c1c-1d1d-1e1e1e1e1e1e" TYPE="ext4"
/dev/sdb1: UUID="22222222-2b2b-2c2c-2d2d-2e2e2e2e2e2e" TYPE="ext4"
/dev/sdc1: UUID="33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e" TYPE="ext4"
Edite o arquivo /etc/fstab para remover referências ao disco.
NOTE
Abra o arquivo /etc/fstab em um editor de texto conforme a seguir:
sudo vi /etc/fstab
Neste exemplo, a linha a seguir deve ser excluída do arquivo /etc/fstab:
UUID=33333333-3b3b-3c3c-3d3d-3e3e3e3e3e3e /datadrive ext4 defaults,nofail 1 2
Use umount para desmontar o disco. O exemplo a seguir desmonta a partição /dev/sdc1 do ponto de
montagem /datadrive:
sudo umount /dev/sdc1 /datadrive
Desanexar um disco de dados usando a CLI do Azure

Este exemplo desanexa o disco myDataDisk da VM nomeada myVM em myResourceGroup.
az vm disk detach \
--vm-name myVm \
-n myDataDisk
O disco permanecerá no armazenamento, mas não estará mais conectado a uma máquina virtual.
Desanexar um disco de dados usando o portal

1. No menu à esquerda, selecione Máquinas Vir tuais .
2. Na folha da máquina virtual, selecione Discos .
3. Na parte superior da folha Discos , selecione Editar .
4. Na folha Discos , mais à direita do disco de dados que você deseja desanexar, clique no botão Desanexar .
5. Depois que o disco for removido, clique em Salvar na parte superior da folha.
Próximas etapas
Se deseja reutilizar o disco de dados, basta anexá-lo a outra VM.
Se você quiser excluir o disco, para que não incorra mais nos custos de armazenamento, consulte Localizar e
excluir discos gerenciados e não-portal do Azure do Azure desconectados.
Como desanexar um disco de dados de uma
máquina virtual Windows
Quando não precisar mais de um disco de dados conectado a uma máquina virtual, você poderá desanexá-lo
facilmente. Essa ação remove o disco da máquina virtual, mas não o remove do armazenamento.
WARNING
Se você desanexar um disco, ele não será excluído automaticamente. Se você se inscreveu para o armazenamento
Premium, você continuará incorrendo em encargos de armazenamento para o disco. Para obter mais informações,
consulte Preços e cobrança ao usar o Armazenamento Premium.
Se desejar usar os dados existentes no disco novamente, você pode reanexá-lo à mesma máquina virtual ou
anexá-lo a uma outra máquina virtual.
Desanexar um disco de dados usando o PowerShell

É possível remover um disco de dados hot usando o PowerShell, mas certifique-se de que nada esteja usando
ativamente o disco antes de desanexá-lo da VM.
Neste exemplo, removemos o disco nomeado myDisk da VM myVM no grupo de recursos
myResourceGroup . Primeiro, remova o disco usando o cmdlet Remove-AzVMDataDisk. Em seguida, atualize o
estado da máquina virtual, usando o cmdlet Update-AzVM para concluir o processo de remoção do disco de
dados.
$VirtualMachine = Get-AzVM `
-Name "myVM"
Remove-AzVMDataDisk `
-Name "myDisk"
Update-AzVM `
-VM $VirtualMachine
Desanexar um disco de dados usando o portal

É possível remover um disco de dados a quente, mas verifique se nada está usando ativamente o disco antes de
desanexá-lo da VM.
1. No menu à esquerda, selecione Máquinas Vir tuais .
2. Selecione a máquina virtual que tem o disco de dados que você deseja desanexar.
3. Em Configurações , selecione Discos .
4. No painel discos , na extrema direita do disco de dados que você deseja desanexar, clique no botão
desanexar X .
5. Selecione Salvar na parte superior da página para salvar as alterações.
Próximas etapas
Se deseja reutilizar o disco de dados, basta anexá-lo a outra VM.
Se você quiser excluir o disco, para que não incorra mais nos custos de armazenamento, consulte Localizar e
excluir discos gerenciados e não-portal do Azure do Azure desconectados.
Expandir discos rígidos virtuais em uma VM do
Linux com a CLI do Azure
Este artigo descreve como expandir discos gerenciados para uma máquina virtual (VM) do Linux com a CLI do
Azure. Você pode adicionar discos de dados para fornecer espaço de armazenamento adicional e também
expandir um disco de dados existente. O tamanho padrão do disco rígido virtual do sistema operacional (SO) é
geralmente de 30 GB em uma VM do Linux no Azure.
WARNING
Sempre certifique-se de que seu sistema de arquivos está em um estado íntegro, o tipo de tabela de partição de disco
dará suporte ao novo tamanho e certifique-se de que o backup dos dados seja feito antes de executar operações de
redimensionamento de disco. Para obter mais informações, consulte início rápido do backup do Azure.
Expandir um disco gerenciado do Azure

Verifique se você tem o CLI do Azure mais recente do Azure instalada e está conectada a uma conta do Azure
usando az login.
Este artigo requer uma VM existente no Azure com, pelo menos, um disco de dados anexado e preparado. Caso
ainda não tenha uma VM que possa ser usada, confira Criar e preparar uma VM com discos de dados.
Nos exemplos a seguir, substitua os nomes de parâmetro de exemplo, como myResourceGroup e myVM com
seus próprios valores.
1. Operações em discos rígidos virtuais não podem ser executadas com a VM em execução. Desaloque a
VM com az vm deallocate. O exemplo a seguir Desaloca a VM denominada myVM no grupo de recursos
chamado MyResource Group:
NOTE
A VM deve ser desalocada para que o disco rígido virtual seja expandido. Parar a VM com az vm stop não libera
os recursos de computação. Para liberar os recursos de computação, use az vm deallocate .
2. Veja uma lista de discos gerenciados em um grupo de recursos com az disk list. O exemplo a seguir exibe
uma lista de discos gerenciados no grupo de recursos chamado myResourceGroup:
az disk list \
--query '[*].{Name:name,Gb:diskSizeGb,Tier:accountType}' \
--output table
Expanda o disco necessário com az disk update. O exemplo a seguir expande o disco gerenciado
denominado myDataDisk para 200 GB:
az disk update \
--name myDataDisk \
--size-gb 200
NOTE
Quando você expande um disco gerenciado, o tamanho atualizado é arredondado para o tamanho de disco
gerenciado mais próximo. Para obter uma tabela dos tamanhos de disco gerenciado e as camadas disponíveis,
consulte Visão geral do Azure Managed Disks – Preço e cobrança.
3. Inicie a VM com az vm start. O exemplo a seguir inicia a VM chamada myVM no grupo de recursos
chamado myResourceGroup:
Expanda uma partição de disco e o sistema de arquivos

Para usar um disco expandido, expanda a partição subjacente e o sistema de arquivos.
1. SSH da VM com as credenciais apropriadas. Você pode ver o endereço IP público de sua VM com az vm
show:
az vm show --resource-group myResourceGroup --name myVM -d --query [publicIps] --output tsv
2. Expanda a partição subjacente e o sistema de arquivos.

a. Se o disco já estiver montado, desmonte-o:
sudo umount /dev/sdc1
b. Use parted para exibir informações de disco e redimensionar a partição:
sudo parted /dev/sdc
Exiba informações sobre o layout da partição existente com print . A saída é semelhante ao exemplo a
seguir, que mostra que o disco subjacente é de 215 GB:
GNU Parted 3.2

Using /dev/sdc1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Unknown Msft Virtual Disk (scsi)
Disk /dev/sdc1: 215GB
Partition Table: loop
Disk Flags:
Number Start End Size File system Flags

1 0.00B 107GB 107GB ext4
c. Expanda a partição com resizepart . Insira o número de partição, 1, e um tamanho para a nova
partição:
(parted) resizepart
Partition number? 1
End? [107GB]? 215GB
d. Para sair, digite quit .

3. Com a partição redimensionada, verifique a consistência da partição com e2fsck :
sudo e2fsck -f /dev/sdc1
4. Redimensione o sistema de arquivos com resize2fs :
sudo resize2fs /dev/sdc1
5. Monte a partição no local desejado, como /datadrive :
6. Para verificar se o disco de dados foi redimensionado, use df -h . A seguinte saída de exemplo mostra a
unidade de dados /dev/sdc1 agora é de 200 GB:

/dev/sdc1 197G 60M 187G 1% /datadrive
Próximas etapas
Se precisar de armazenamento adicional, você também pode adicionar discos de dados a uma VM Linux.
Para obter mais informações sobre criptografia de disco, consulte Azure Disk Encryption para VMs do Linux.
Como expandir a unidade do sistema operacional
de uma máquina virtual
Quando você cria uma nova VM (máquina virtual) em um grupo de recursos implantando uma imagem do
Azure Marketplace, a unidade do sistema operacional padrão geralmente é de 127 GB (algumas imagens têm
tamanhos de disco do sistema operacional menores por padrão). Embora seja possível adicionar discos de
dados à VM (o número depende do SKU escolhido) e recomendamos a instalação de aplicativos e cargas de
trabalho com uso intensivo de CPU nesses discos de adendo, muitas vezes, os clientes precisam expandir a
unidade do sistema operacional para oferecer suporte a cenários específicos:
Para dar suporte a aplicativos herdados que instalam componentes na unidade do sistema operacional.
Para migrar um PC físico ou VM do local com uma unidade de sistema operacional maior.
IMPORTANT
O redimensionamento de um sistema operacional ou de um disco de dados de uma máquina virtual do Azure requer que
a máquina virtual seja desalocada.
A redução de um disco existente não tem suporte e pode resultar em perda de dados.
Depois de expandir os discos, você precisará expandir o volume no sistema operacional para aproveitar o disco maior.
Redimensionar um disco gerenciado no portal do Azure

1. Na portal do Azure, vá para a máquina virtual na qual você deseja expandir o disco. Selecione parar para
desalocar a VM.
2. Quando a VM for interrompida, no menu à esquerda em configurações , selecione discos .
3. Em nome do disco , selecione o disco que você deseja redimensionar.

4. No menu à esquerda em configurações , selecione configuração .
5. Em tamanho (GIB) , selecione o tamanho do disco desejado.
WARNING
O novo tamanho deve ser maior que o tamanho do disco existente. O máximo permitido é de 2.048 GB para
discos do sistema operacional. (É possível expandir o blob VHD para além desse tamanho, mas o sistema
operacional funciona apenas com os primeiros 2.048 GB de espaço.)
Redimensionar um disco gerenciado usando o PowerShell

Abra o ISE do PowerShell ou a janela do PowerShell no modo administrativo e siga as etapas abaixo:
1. Entre em sua conta do Microsoft Azure no modo de gerenciamento de recursos e selecione sua
assinatura:
Connect-AzAccount
Select-AzSubscription –SubscriptionName 'my-subscription-name'
2. Defina o nome do grupo de recursos e o nome da VM:
$rgName = 'my-resource-group-name'
$vmName = 'my-vm-name'
3. Obtenha uma referência à sua VM:
$vm = Get-AzVM -ResourceGroupName $rgName -Name $vmName
4. Pare a VM antes de redimensionar o disco:
Stop-AzVM -ResourceGroupName $rgName -Name $vmName

5. Obtenha uma referência ao disco do sistema operacional gerenciado. Defina o tamanho do disco do
sistema operacional gerenciado para o valor desejado e atualize o disco:
$disk= Get-AzDisk -ResourceGroupName $rgName -DiskName $vm.StorageProfile.OsDisk.Name

$disk.DiskSizeGB = 1023
Update-AzDisk -ResourceGroupName $rgName -Disk $disk -DiskName $disk.Name
WARNING
operacional funciona apenas com os primeiros 2.048 GB de espaço.)
6. A atualização da VM pode levar alguns segundos. Quando o comando terminar a execução, reinicie a VM:
É isso. Agora, com o RDP na VM, abra Gerenciamento do Computador (ou Gerenciamento de Disco) e expanda a
unidade usando o espaço recentemente alocado.
Redimensionar um disco não gerenciado usando o PowerShell

Abra o ISE do PowerShell ou a janela do PowerShell no modo administrativo e siga as etapas abaixo:
1. Entre em sua conta do Microsoft Azure no modo de gerenciamento de recursos e selecione sua
assinatura:
Connect-AzAccount
Select-AzSubscription –SubscriptionName 'my-subscription-name'
2. Defina o nome do grupo de recursos e os nomes da VM:
3. Obtenha uma referência à sua VM:
4. Pare a VM antes de redimensionar o disco:
5. Defina o tamanho do disco do sistema operacional não gerenciado para o valor desejado e atualize a VM:
$vm.StorageProfile.OSDisk.DiskSizeGB = 1023
Update-AzVM -ResourceGroupName $rgName -VM $vm
WARNING
operacional só poderá trabalhar com os primeiros 2.048 GB de espaço).
6. A atualização da VM pode levar alguns segundos. Quando o comando terminar a execução, reinicie a VM:
Scripts para o disco do sistema operacional

Abaixo está o script completo para sua referência para discos gerenciados e não gerenciados:
Discos gerenciados
Connect-AzAccount
Select-AzSubscription -SubscriptionName 'my-subscription-name'
$disk= Get-AzDisk -ResourceGroupName $rgName -DiskName $vm.StorageProfile.OsDisk.Name
Update-AzDisk -ResourceGroupName $rgName -Disk $disk -DiskName $disk.Name
Discos não gerenciados
Connect-AzAccount
Select-AzSubscription -SubscriptionName 'my-subscription-name'
$vm.StorageProfile.OSDisk.DiskSizeGB = 1023
Update-AzVM -ResourceGroupName $rgName -VM $vm
Redimensionando discos de dados

Este artigo se concentra principalmente em expandir o disco do SO da VM, mas o script também pode ser usado
para expandir os discos de dados conectados à VM. Por exemplo, para expandir o primeiro disco de dados
conectado à VM, substitua o objeto OSDisk de StorageProfile pela matriz DataDisks e use um índice
numérico para obter uma referência para o primeiro disco de dados conectado, como mostrado abaixo:
Disco gerenciado
$disk= Get-AzDisk -ResourceGroupName $rgName -DiskName $vm.StorageProfile.DataDisks[0].Name

Disco não gerenciado

$vm.StorageProfile.DataDisks[0].DiskSizeGB = 1023
Da mesma forma, você pode fazer referência a outros discos de dados anexados à VM, seja usando um índice,
conforme mostrado acima ou a propriedade Name do disco:
Disco gerenciado
(Get-AzDisk -ResourceGroupName $rgName -DiskName ($vm.StorageProfile.DataDisks | Where ({$_.Name -eq 'my-

second-data-disk'})).Name).DiskSizeGB = 1023
Disco não gerenciado
($vm.StorageProfile.DataDisks | Where ({$_.Name -eq 'my-second-data-disk'})).DiskSizeGB = 1023
Expandir o volume no sistema operacional

Quando você tiver expandido o disco para a VM, precisará entrar no sistema operacional e expandir o volume
para abranger o novo espaço. Há vários métodos para expandir uma partição. Esta seção aborda como conectar
a VM usando uma conexão RDP para expandir a partição usando DiskPar t .
1. Abra uma conexão RDP com a VM.
2. Abra um prompt de comando e digite diskpar t .
3. No prompt DISKPART , digite list volume . Anote o volume que você deseja estender.
4. No prompt DISKPART , digite select volume <volumenumber> . Isso seleciona o volume volumenumber
que você deseja estender no espaço vazio contíguo no mesmo disco.
5. No prompt DISKPART , digite extend [size=<size>] . Isso estende o volume selecionado pelo tamanho
em megabytes (MB).
Próximas etapas
Você também pode conectar discos usando o portal do Azure.
Usando discos em modelos de Azure Resource
Manager
Este documento aborda as diferenças entre discos gerenciados e não gerenciados ao utilizar os modelos do
Azure Resource Manager para provisionar máquinas virtuais. O exemplo ajuda você a atualizar os modelos
existentes que estão usando Discos não gerenciados para os discos gerenciados. Para referência, estamos
usando o modelo 101-vm-simple-windows como um guia. É possível visualizar o modelo utilizando ambos os
Discos gerenciados e uma versão anterior utilizando discos não gerenciados, se você deseja compará-los
diretamente.
Formatação de modelo de Discos não gerenciados

Para começar, veremos como os discos não gerenciados são implantados. Ao criar discos não gerenciados, é
necessária uma conta de armazenamento para armazenar os arquivos de VHD. É possível criar uma nova conta
de armazenamento ou utilizar uma conta já existente. Este artigo mostra como criar uma nova conta de
armazenamento. Crie um recurso de conta de armazenamento em bloco de recursos, conforme mostrado
abaixo.
{
"apiVersion": "2018-07-01",
"sku": {
},
"kind": "Storage",
"properties": {}
}
Dentro do objeto de máquina virtual, adicione uma dependência na conta de armazenamento para garantir que
é criada antes da máquina virtual. Na seção storageProfile , especifique o URI completo do local do VHD que
faz referência à conta de armazenamento e necessário para o disco do SO e qualquer disco de dados.
{
"apiVersion": "2018-10-01",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {...},
"osProfile": {...},
"storageProfile": {
"imageReference": {
"sku": "[parameters('windowsOSVersion')]",
"version": "latest"
},
"osDisk": {
"name": "osdisk",
"vhd": {
"uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob, 'vhds/osdisk.vhd')]"
},
},
"dataDisks": [
{
"name": "datadisk1",
"diskSizeGB": 1023,
"lun": 0,
"vhd": {
"uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob, 'vhds/datadisk1.vhd')]"
},
}
]
},
"networkProfile": {...},
"diagnosticsProfile": {...}
}
}
Formatação de modelo de discos gerenciados

Com o Azure Managed Disks, o disco torna-se um recurso de nível superior e não exige mais uma conta de
armazenamento a ser criada pelo usuário. Os discos gerenciados foram expostos pela primeira vez na versão da
API 2016-04-30-preview . Eles estão disponíveis em todas as versões de API subsequentes e agora são o tipo de
disco padrão. As seções a seguir percorrem as configurações padrão e detalham como personalizar ainda mais
seus discos.
NOTE
Recomendamos usar uma versão da API posterior a 2016-04-30-preview , pois houve alterações consideráveis entre
2016-04-30-preview e 2017-03-30 .
Configurações de disco gerenciados padrão

Para criar uma VM com discos gerenciados, você não precisa mais criar o recurso de conta de armazenamento.
Fazendo referência ao exemplo de modelo a seguir, há algumas diferenças dos exemplos de disco não
gerenciado anteriores a serem observados:
O apiVersion é uma versão que dá suporte a discos gerenciados.
osDisk e dataDisks não se referem mais a um URI específico para o VHD.
Ao implantar sem especificar propriedades adicionais, o disco usará um tipo de armazenamento com base
no tamanho da VM. Por exemplo, se você estiver usando um tamanho de VM que dá suporte ao
armazenamento Premium (tamanhos com "s" em seu nome, como Standard_D2s_v3), os discos Premium
serão configurados por padrão. Você pode alterar isso usando a configuração de SKU do disco para
especificar um tipo de armazenamento.
Se nenhum nome para o disco for especificado, ele usará o formato de <VMName>_OsDisk_1_<randomstring>
para o disco do sistema operacional e <VMName>_disk<#>_<randomstring> para cada disco de dados.
Se uma VM estiver sendo criada a partir de uma imagem personalizada, as configurações padrão para
o tipo de conta de armazenamento e o nome do disco serão recuperadas das propriedades do disco
definidas no recurso de imagem personalizada. Eles podem ser substituídos especificando-se valores
para eles no modelo.
Por padrão, a criptografia de disco do Azure está desabilitada.
Por padrão, o cache de disco é de leitura/gravação para o disco do sistema operacional e nenhum para
discos de dados.
No exemplo abaixo, ainda há uma dependência de conta de armazenamento, embora isso seja apenas para o
armazenamento de diagnósticos e não seja necessário para o armazenamento em disco.
{
"apiVersion": "2018-10-01",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"osProfile": {...},
"storageProfile": {
"imageReference": {
"version": "latest"
},
"osDisk": {
},
"dataDisks": [
{
"diskSizeGB": 1023,
"lun": 0,
}
]
},
}
}
Utilizar um recurso de disco gerenciado de nível superior

Como alternativa para especificar a configuração do disco no objeto da máquina virtual, você pode criar um
recurso de disco de nível superior e anexá-lo como parte da criação da máquina virtual. Por exemplo, é possível
criar um recurso de disco da seguinte forma para utiiza como um disco de dados.
{
"type": "Microsoft.Compute/disks",
"apiVersion": "2018-06-01",
"name": "[concat(variables('vmName'),'-datadisk1')]",
"sku": {
},
"properties": {
"creationData": {
},
"diskSizeGB": 1023
}
}
Dentro do objeto da VM é possível fazer referência a este objeto de disco para ser anexado. Especificar o ID do
recurso do disco gerenciado criado na propriedade managedDisk permite a conexão do disco à medida que a
VM é criada. O apiVersion para o recurso da VM está definido como 2017-03-30 . Uma dependência no recurso
de disco é adicionada para garantir que tenha sido criado com êxito antes da criação da VM.
{
"apiVersion": "2018-10-01",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]",
"[resourceId('Microsoft.Compute/disks/', concat(variables('vmName'),'-datadisk1'))]"
],
"properties": {
"osProfile": {...},
"storageProfile": {
"imageReference": {
"version": "latest"
},
"osDisk": {
},
"dataDisks": [
{
"lun": 0,
"name": "[concat(variables('vmName'),'-datadisk1')]",
"createOption": "attach",
"managedDisk": {
"id": "[resourceId('Microsoft.Compute/disks/', concat(variables('vmName'),'-
datadisk1'))]"
}
}
]
},
}
}
Criar conjuntos de disponibilidade gerenciados com VMs utilizando discos gerenciados
Para criar conjuntos de disponibilidade gerenciados com VMs utilizando discos gerenciados, adicione o objeto
sku ao recurso do conjunto de disponibilidade e defina a propriedade name para Aligned . Essa propriedade
garante que os discos para cada VM estejam suficientemente isolados uns dos outros para evitar pontos únicos
de falha. Observe também que o apiVersion para o recurso do conjunto de disponibilidade está definido como
2018-10-01 .
{
"type": "Microsoft.Compute/availabilitySets",
"apiVersion": "2018-10-01",
"name": "[variables('avSetName')]",
"properties": {
"PlatformUpdateDomainCount": 3,
"PlatformFaultDomainCount": 2
},
"sku": {
"name": "Aligned"
}
}
Discos SSD Standard

Abaixo estão os parâmetros necessários no modelo do Gerenciador de Recursos para criar discos SSD padrão:
apiVersion para Microsoft.Compute deve ser definido como 2018-04-01 (ou posterior)
Especifique managedDisk.storageAccountType como StandardSSD_LRS
A exemplo a seguir mostra a seção properties.storageProfile.osDisk de uma VM que usa discos SSD padrão:
"osDisk": {
"osType": "Windows",
"name": "myOsDisk",
"managedDisk": {
}
}
Para obter um exemplo de modelo completo de como criar um disco SSD padrão com um modelo, consulte
Criar uma máquina virtual a partir de uma imagem do Windows com discos de dados padrão SSD.
Cenários e personalizações adicionais
Para encontrar informações completas sobre as especificações de API REST, revise criar uma documentação de
API REST de disco gerenciado. Você encontrará cenários adicionais, assim como valores padrão e aceitáveis que
podem ser enviados para a API por meio de implantações de modelos.
Próximas etapas
Para modelos completos que utilizam discos gerenciados, visite os seguintes links do Repositório de Início
Rápido do Azure.
VM do Windows VM com disco gerenciado
VM do Linux VM com disco gerenciado
Consulte o documento Visão Geral do Azure Managed Disks para saber mais sobre discos gerenciados.
Revise a documentação de referência do modelo para recursos da máquina virtual, visitando o documento
em Microsoft.Compute/referência de modelo de virtualMachines.
Revise a documentação de referência do modelo para recursos de disco, visitando o documento em
Microsoft.Compute/referência de modelo de discos.
Para obter informações sobre como usar discos gerenciados em conjuntos de Dimensionamento de
Máquinas Virtuais do Microsoft Azure, visite o documento Usar discos de dados com conjuntos de escala.
CLI do Azure – Restringir o acesso de
importação/exportação aos discos gerenciados com
Links Privados
Use pontos de extremidade privados para restringir a exportação e a importação de discos gerenciados e acesse
dados com segurança em um Link Privado em clientes na sua rede virtual do Azure. O ponto de extremidade
privado usa um endereço IP do espaço de endereço de rede virtual para o serviço de discos gerenciados. O
tráfego de rede entre os clientes na rede virtual e os discos gerenciados atravessa somente a rede virtual e um
link privado na rede de backbone da Microsoft, eliminando a exposição na Internet pública.
Para usar Links Privados para exportar/importar discos gerenciados, primeiro crie um recurso de acesso a disco
e vincule-o a uma rede virtual na mesma assinatura criando um ponto de extremidade privado. Em seguida,
associe um disco ou um instantâneo a uma instância de acesso a disco. Por fim, defina a propriedade
NetworkAccessPolicy do disco ou o instantâneo como AllowPrivate . Isso limitará o acesso à sua rede virtual.
Você pode definir a propriedade NetworkAccessPolicy como DenyAll para impedir que qualquer pessoa
exporte os dados de um disco ou de um instantâneo. O valor padrão da propriedade NetworkAccessPolicy é
AllowAll .
Limitações
Sua rede virtual precisa estar na mesma assinatura do objeto de acesso a disco para que o vínculo seja
estabelecido.
Até dez discos ou instantâneos podem ser importados ou exportados simultaneamente com o mesmo
objeto de acesso a disco.
Não é possível solicitar a aprovação manual para vincular uma rede virtual a um objeto de acesso a disco.
Faça logon na sua assinatura e defina as variáveis

subscriptionId=yourSubscriptionId
resourceGroupName=yourResourceGroupName
region=northcentralus
diskAccessName=yourDiskAccessForPrivateLinks
vnetName=yourVNETForPrivateLinks
subnetName=yourSubnetForPrivateLinks
privateEndPointName=yourPrivateLinkForSecureMDExportImport
privateEndPointConnectionName=yourPrivateLinkConnection
#The name of an existing disk which is the source of the snapshot

sourceDiskName=yourSourceDiskForSnapshot
#The name of the new snapshot which will be secured via Private Links
snapshotNameSecuredWithPL=yourSnapshotNameSecuredWithPL
az login

Criar um acesso a disco usando a CLI do Azure
az disk-access create -n $diskAccessName -g $resourceGroupName -l $region
diskAccessId=$(az disk-access show -n $diskAccessName -g $resourceGroupName --query [id] -o tsv)
Criar uma rede virtual

Não há suporte para políticas de rede, como NSG (grupos de segurança de rede), em pontos de extremidade
privados. Para implantar um ponto de extremidade privado em determinada sub-rede, uma configuração de
desabilitação explícita é necessária nessa sub-rede.
az network vnet create --resource-group $resourceGroupName \

--name $vnetName \
--subnet-name $subnetName
Desabilitar políticas de ponto de extremidade privado de sub-rede

O Azure implanta recursos em uma sub-rede dentro de uma rede virtual. Portanto, você precisa atualizar a sub-
rede para desabilitar as políticas de rede do ponto de extremidade privado.
az network vnet subnet update --resource-group $resourceGroupName \

--disable-private-endpoint-network-policies true
Criar um ponto de extremidade privado para o objeto de acesso a

disco
az network private-endpoint create --resource-group $resourceGroupName \
--name $privateEndPointName \
--subnet $subnetName \
--private-connection-resource-id $diskAccessId \
--group-ids disks \
--connection-name $privateEndPointConnectionName
Configurar a Zona DNS Privada

Crie uma Zona DNS Privada para o domínio do blob de armazenamento, crie um link de associação com a Rede
Virtual e crie um Grupo de Zona DNS para associar o ponto de extremidade privado à Zona DNS Privada.
az network private-dns zone create --resource-group $resourceGroupName \
--name "privatelink.blob.core.windows.net"
az network private-dns link vnet create --resource-group $resourceGroupName \

--zone-name "privatelink.blob.core.windows.net" \
--name yourDNSLink \
--virtual-network $vnetName \
--registration-enabled false
az network private-endpoint dns-zone-group create \

--resource-group $resourceGroupName \
--endpoint-name $privateEndPointName \
--name yourZoneGroup \
--private-dns-zone "privatelink.blob.core.windows.net" \
--zone-name disks
Criar um disco protegido com Links Privados

diskAccessName=yourDiskAccessName
diskSkuName=Standard_LRS
diskSizeGB=128
diskAccessId=$(az resource show -n $diskAccessName -g $resourceGroupName --namespace Microsoft.Compute --

resource-type diskAccesses --query [id] -o tsv)
az disk create -n $diskName \

-g $resourceGroupName \
-l $region \
--size-gb $diskSizeGB \
--sku $diskSkuName \
--network-access-policy AllowPrivate \
--disk-access $diskAccessId
Criar um instantâneo de um disco protegido com Links Privados

diskAccessName=yourDiskAccessName
sourceDiskName=yourSourceDiskForSnapshot
snapshotNameSecuredWithPL=yourSnapshotName
diskId=$(az disk show -n $sourceDiskName -g $resourceGroupName --query [id] -o tsv)
diskAccessId=$(az resource show -n $diskAccessName -g $resourceGroupName --namespace Microsoft.Compute --

resource-type diskAccesses --query [id] -o tsv)
az snapshot create -n $snapshotNameSecuredWithPL \

-g $resourceGroupName \
-l $region \
--source $diskId \
--network-access-policy AllowPrivate \
--disk-access $diskAccessId
Próximas etapas
Perguntas frequentes sobre os Links Privados
Exportar/copiar instantâneos gerenciados como VHD para uma conta de armazenamento em outa região
com a CLI
Usar o portal do Azure para restringir o acesso de
importação/exportação aos discos gerenciados com
Links Privados
O suporte dos Links Privados para discos gerenciados permite que você restrinja a exportação e a importação
de discos gerenciados para que elas ocorram somente dentro da sua rede virtual do Azure. Gere um URI de SAS
(Assinatura de Acesso Compartilhado) com limite de tempo para discos gerenciados e instantâneos
desanexados a fim de exportar os dados para outra região para expansão regional, recuperação de desastre e a
fim de ler os dados para análise forense. Use também o URI de SAS para carregar diretamente o VHD em um
disco vazio do local. O tráfego de rede entre os clientes na rede virtual e os discos gerenciados atravessa
somente a rede virtual e um link privado na rede de backbone da Microsoft, eliminando a exposição à Internet
pública.
Crie um recurso de acesso a disco e vincule-o à sua rede virtual na mesma assinatura criando um ponto de
extremidade privado. Você precisará associar um disco ou um instantâneo a um acesso a disco para exportar e
importar os dados por meio de Links Privados. Além disso, você precisará definir a propriedade
NetworkAccessPolicy do disco ou do instantâneo como AllowPrivate .
Você pode definir a propriedade NetworkAccessPolicy como DenyAll para impedir que qualquer pessoa gere o
URI de SAS para um disco ou um instantâneo. O valor padrão da propriedade NetworkAccessPolicy é AllowAll .
Limitações
Sua rede virtual precisa estar na mesma assinatura do objeto de acesso a disco para que o vínculo seja
estabelecido.
Até dez discos ou instantâneos podem ser importados ou exportados simultaneamente com o mesmo
objeto de acesso a disco.
Não é possível solicitar a aprovação manual para vincular uma rede virtual a um objeto de acesso a disco.
Criar um recurso de acesso a disco

1. Entre no portal do Azure e procure Acesso a Disco com este link.
IMPORTANT
Use o link fornecido para procurar a folha Acesso a Disco. No momento, ela não está visível no portal público sem
o uso do link.
2. Selecione + Adicionar para criar um recurso de acesso a disco.

3. Na folha Criar, selecione sua assinatura e um grupo de recursos, insira um nome e selecione uma região.
Quando o recurso for criado, acesse-o diretamente.
Criar um ponto de extremidade privado

Agora que você tem um recurso de acesso a disco, use-o para lidar com o acesso às exportações/importações
do disco. Isso é feito por meio de pontos de extremidade privados. Por isso, você precisará criar um ponto de
extremidade privado e configurá-lo para acesso a disco.
1. No recurso de acesso a disco, selecione Conexões de ponto de extremidade privado .
2. Selecione + Ponto de extremidade privado .
3. Selecionar um grupo de recursos

4. Preencha o nome e selecione a mesma região em que o recurso de acesso a disco foi criado.
5. Selecione Avançar : Recurso >
6. Na folha Recurso , selecione Conectar-se a um recurso do Azure em meu diretório .
7. Em Tipo de recurso selecione Microsoft.Compute/diskAccesses
8. Em Recurso , selecione o recurso de acesso a disco que você criou anteriormente
9. Mantenha o Sub-recurso de destino como discos
10. Selecione Avançar : Configuração > .
11. Selecione a rede virtual para a qual deseja limitar a exportação de disco; as outras redes virtuais não
poderão exportar o disco.
NOTE
Se houver um NSG (grupo de segurança de rede) habilitado para a sub-rede selecionada, ele será desabilitado
para os pontos de extremidade privados somente nessa sub-rede. Os outros recursos na sub-rede ainda terão a
imposição do NSG.
12. Selecione a sub-rede apropriada

Habilitar o ponto de extremidade privado no seu disco
1. Procure o disco que deseja configurar
2. Selecione Rede
3. Selecione Ponto de extremidade privado (por meio do acesso a disco) e escolha o acesso a disco
criado anteriormente.
Agora você concluiu a configuração de Links Privados que podem ser usados ao importar/exportar seu disco
gerenciado.
Próximas etapas
Perguntas frequentes sobre os Links Privados
Exportar/copiar instantâneos gerenciados como VHD para uma conta de armazenamento em outa região
com o PowerShell
Carregar um VHD no Azure ou copiar um disco
gerenciado para outra região-Azure PowerShell
Este artigo explica como carregar um VHD do computador local para um disco gerenciado do Azure ou copiar
um disco gerenciado para outra região usando AzCopy. Esse processo, upload direto, também permite que você
carregue um VHD de até 32 TiB de tamanho diretamente em um disco gerenciado. Atualmente, o carregamento
direto tem suporte para discos gerenciados HDD padrão, SSD Standard e SSD Premium. Ainda não há suporte
para ultra discos.
Se você estiver fornecendo uma solução de backup para VMs IaaS no Azure, recomendamos o uso do
carregamento direto para restaurar os backups do cliente para o Managed disks. Ao carregar um VHD de uma
origem externa para o Azure, as velocidades dependeriam da largura de banda local. Ao carregar ou copiar de
uma VM do Azure, sua largura de banda será a mesma que a HDDs padrão.
Pré-requisitos
Baixe a versão mais recente do AzCopy V10.
Instale o módulo Azure PowerShell.
Se você pretende carregar um VHD do local: um VHD de tamanho fixo que foi preparado para o Azure,
armazenado localmente.
Ou, um disco gerenciado no Azure, se você pretende executar uma ação de cópia.
Introdução
Se preferir carregar discos por meio de uma GUI, você pode fazer isso usando Gerenciador de Armazenamento
do Azure. Para obter detalhes, consulte: usar Gerenciador de armazenamento do Azure para gerenciar o Azure
Managed disks
Para carregar o VHD no Azure, você precisará criar um disco gerenciado vazio que esteja configurado para esse
processo de carregamento. Antes de criar uma, há algumas informações adicionais que você deve saber sobre
esses discos.
Esse tipo de disco gerenciado tem dois Estados exclusivos:
ReadToUpload, que significa que o disco está pronto para receber um upload, mas nenhuma assinatura de
acesso seguro (SAS) foi gerada.
ActiveUpload, o que significa que o disco está pronto para receber um upload e a SAS foi gerada.
NOTE
Em qualquer um desses Estados, o disco gerenciado será cobrado no preço de HDD padrão, independentemente do tipo
real de disco. Por exemplo, um P10 será cobrado como um S10. Isso será verdadeiro até que revoke-access seja
chamado no disco gerenciado, que é necessário para anexar o disco a uma VM.
Criar um disco gerenciado vazio

Para poder criar um HDD padrão vazio para carregamento, você precisará do tamanho do arquivo do VHD que
deseja carregar, em bytes. O código de exemplo o levará para você, mas, para você mesmo, você pode usar:
$vhdSizeBytes = (Get-Item "<fullFilePathHere>").length . Esse valor é usado ao especificar o parâmetro -
UploadSizeInBytes .
Agora, no Shell local, crie um HDD padrão vazio para carregamento, especificando a configuração de
carregamento no parâmetro -createoption , bem como o parâmetro -UploadSizeInBytes no cmdlet New-
AzDiskConfig . Em seguida, chame New-AzDisk para criar o disco.
Substitua <yourdiskname> , <yourresourcegroupname> e <yourregion> Execute os seguintes comandos:
TIP
Se você estiver criando um disco do sistema operacional, adicione -HyperVGeneration '<yourGeneration>' a
New-AzDiskConfig .
$vhdSizeBytes = (Get-Item "<fullFilePathHere>").length
$diskconfig = New-AzDiskConfig -SkuName 'Standard_LRS' -OsType 'Windows' -UploadSizeInBytes $vhdSizeBytes -

Location '<yourregion>' -CreateOption 'Upload'
New-AzDisk -ResourceGroupName '<yourresourcegroupname>' -DiskName '<yourdiskname>' -Disk $diskconfig
Se você quiser carregar um SSD Premium ou um SSD padrão, substitua Standard_LRS por Premium_LRS ou
StandardSSD_LRS . Ainda não há suporte para ultra discos.
Agora que você criou um disco gerenciado vazio que está configurado para o processo de carregamento, você
pode carregar um VHD para ele. Para carregar um VHD no disco, você precisará de uma SAS gravável, para que
você possa referenciá-lo como o destino do upload.
Para gerar uma SAS gravável de seu disco gerenciado vazio, substitua <yourdiskname> e
<yourresourcegroupname> , em seguida, use os seguintes comandos:
$diskSas = Grant-AzDiskAccess -ResourceGroupName '<yourresourcegroupname>' -DiskName '<yourdiskname>' -

DurationInSecond 86400 -Access 'Write'
$disk = Get-AzDisk -ResourceGroupName '<yourresourcegroupname>' -DiskName '<yourdiskname>'
Carregar um VHD
Agora que você tem uma SAS para seu disco gerenciado vazio, você pode usá-lo para definir o disco gerenciado
como o destino para o comando de carregamento.
Use AzCopy V10 para carregar o arquivo VHD local em um disco gerenciado especificando o URI SAS gerado.
Esse carregamento tem a mesma taxa de transferência que o HDD padrãoequivalente. Por exemplo, se você tiver
um tamanho que é igual a S4, terá uma taxa de transferência de até 60 MiB/s. Mas, se você tiver um tamanho
igual a S70, terá uma taxa de transferência de até 500 MiB/s.
AzCopy.exe copy "c:\somewhere\mydisk.vhd" $diskSas.AccessSAS --blob-type PageBlob
Depois que o upload for concluído e você não precisar mais gravar mais dados no disco, revogue a SAS. A
revogação da SAS alterará o estado do disco gerenciado e permitirá que você anexe o disco a uma VM.
Substitua <yourdiskname> e <yourresourcegroupname> , em seguida, execute o seguinte comando:
Revoke-AzDiskAccess -ResourceGroupName '<yourresourcegroupname>' -DiskName '<yourdiskname>'
Copiar um disco gerenciado

O carregamento direto também simplifica o processo de cópia de um disco gerenciado. Você pode copiar na
mesma região ou copiar o disco gerenciado para outra região.
O script a seguir fará isso para você, o processo é semelhante às etapas descritas anteriormente, com algumas
diferenças, já que você está trabalhando com um disco existente.
IMPORTANT
Você precisa adicionar um deslocamento de 512 quando estiver fornecendo o tamanho do disco em bytes de um disco
gerenciado do Azure. Isso ocorre porque o Azure omite o rodapé ao retornar o tamanho do disco. A cópia falhará se você
não fizer isso. O script a seguir já faz isso para você.
Substitua o <sourceResourceGroupHere> , <sourceDiskNameHere> , ,

<targetDiskNameHere>
<targetResourceGroupHere> <yourOSTypeHere> e <yourTargetLocationHere> (um exemplo de um valor de local
seria uswest2) por seus valores e, em seguida, execute o script a seguir para copiar um disco gerenciado.
TIP
Se você estiver criando um disco do sistema operacional, adicione-HyperVGeneration ' ' a New-AzDiskConfig .
$sourceRG = <sourceResourceGroupHere>
$sourceDiskName = <sourceDiskNameHere>
$targetDiskName = <targetDiskNameHere>
$targetRG = <targetResourceGroupHere>
$targetLocate = <yourTargetLocationHere>
#Expected value for OS is either "Windows" or "Linux"
$targetOS = <yourOSTypeHere>
$sourceDisk = Get-AzDisk -ResourceGroupName $sourceRG -DiskName $sourceDiskName
# Adding the sizeInBytes with the 512 offset, and the -Upload flag
$targetDiskconfig = New-AzDiskConfig -SkuName 'Standard_LRS' -osType $targetOS -UploadSizeInBytes
$($sourceDisk.DiskSizeBytes+512) -Location $targetLocate -CreateOption 'Upload'
$targetDisk = New-AzDisk -ResourceGroupName $targetRG -DiskName $targetDiskName -Disk $targetDiskconfig
$sourceDiskSas = Grant-AzDiskAccess -ResourceGroupName $sourceRG -DiskName $sourceDiskName -DurationInSecond

86400 -Access 'Read'
$targetDiskSas = Grant-AzDiskAccess -ResourceGroupName $targetRG -DiskName $targetDiskName -DurationInSecond

86400 -Access 'Write'
azcopy copy $sourceDiskSas.AccessSAS $targetDiskSas.AccessSAS --blob-type PageBlob
Revoke-AzDiskAccess -ResourceGroupName $sourceRG -DiskName $sourceDiskName
Revoke-AzDiskAccess -ResourceGroupName $targetRG -DiskName $targetDiskName
Próximas etapas
Agora que você carregou com êxito um VHD em um disco gerenciado, você pode anexar o disco a uma VM e
começar a usá-lo.
Para saber como anexar um disco de dados a uma VM, consulte nosso artigo sobre o assunto: anexar um disco
de dados a uma VM do Windows com o PowerShell. Para usar o disco como o disco do sistema operacional,
consulte criar uma VM do Windows de um disco especializado.
Carregar um VHD no Azure ou copiar um disco
gerenciado para outra região-CLI do Azure
Este artigo explica como carregar um VHD do computador local para um disco gerenciado do Azure ou copiar
um disco gerenciado para outra região usando AzCopy. Esse processo, upload direto, também permite que você
carregue um VHD de até 32 TiB de tamanho diretamente em um disco gerenciado. Atualmente, o carregamento
direto tem suporte para discos gerenciados HDD padrão, SSD Standard e SSD Premium. Ainda não há suporte
para ultra discos.
Se você estiver fornecendo uma solução de backup para VMs IaaS no Azure, recomendamos o uso do
carregamento direto para restaurar os backups do cliente para o Managed disks. Ao carregar um VHD de uma
origem externa para o Azure, as velocidades dependeriam da largura de banda local. Ao carregar ou copiar de
uma VM do Azure, sua largura de banda será a mesma que a HDDs padrão.
Pré-requisitos
Baixe a versão mais recente do AzCopy V10.
Instale a CLI do Azure.
Se você pretende carregar um VHD do local: um VHD de tamanho fixo que foi preparado para o Azure,
armazenado localmente.
Ou, um disco gerenciado no Azure, se você pretende executar uma ação de cópia.
Introdução
Se preferir carregar discos por meio de uma GUI, você pode fazer isso usando Gerenciador de Armazenamento
do Azure. Para obter detalhes, consulte: usar Gerenciador de armazenamento do Azure para gerenciar o Azure
Managed disks
Para carregar o VHD no Azure, você precisará criar um disco gerenciado vazio que esteja configurado para esse
processo de carregamento. Antes de criar uma, há algumas informações adicionais que você deve saber sobre
esses discos.
Esse tipo de disco gerenciado tem dois Estados exclusivos:
ReadToUpload, que significa que o disco está pronto para receber um upload, mas nenhuma assinatura de
acesso seguro (SAS) foi gerada.
ActiveUpload, o que significa que o disco está pronto para receber um upload e a SAS foi gerada.
NOTE
Em qualquer um desses Estados, o disco gerenciado será cobrado no preço de HDD padrão, independentemente do tipo
real de disco. Por exemplo, um P10 será cobrado como um S10. Isso será verdadeiro até que revoke-access seja
chamado no disco gerenciado, que é necessário para anexar o disco a uma VM.
Criar um disco gerenciado vazio

Para poder criar um HDD padrão vazio para carregamento, você precisará do tamanho do arquivo do VHD que
deseja carregar, em bytes. Para obtê-lo, você pode usar o wc -c <yourFileName>.vhd ou o
ls -al <yourFileName>.vhd . Esse valor é usado ao especificar o parâmetro --upload-size-bytes .
Crie um HDD padrão vazio para carregamento, especificando o parâmetro -– para-upload e o parâmetro --
upload-size-bytes em um cmdlet Create de disco :
Substitua , <yourresourcegroupname> , <yourregion> com os valores de sua escolha. O
<yourdiskname>
--upload-size-bytes parâmetro contém um valor de exemplo de 34359738880 , substitua-o por um valor
apropriado para você.
TIP
Se você estiver criando um disco do sistema operacional, adicione--Hyper-v-Generation ao az disk create .
az disk create -n <yourdiskname> -g <yourresourcegroupname> -l <yourregion> --for-upload --upload-size-bytes

34359738880 --sku standard_lrs
Se você quiser carregar um SSD Premium ou um SSD padrão, substitua standard_lrs por premium_LRS ou
standardssd_lrs . Os ultra discos não têm suporte por enquanto.
Agora que você criou um disco gerenciado vazio que está configurado para o processo de carregamento, você
pode carregar um VHD para ele. Para carregar um VHD no disco, você precisará de uma SAS gravável, para que
você possa referenciá-lo como o destino do upload.
Para gerar uma SAS gravável de seu disco gerenciado vazio, substitua <yourdiskname> e
<yourresourcegroupname> , em seguida, use o seguinte comando:
az disk grant-access -n <yourdiskname> -g <yourresourcegroupname> --access-level Write --duration-in-seconds

86400
Valor retornado de exemplo:
{
"accessSas": "https://md-impexp-t0rdsfgsdfg4.blob.core.windows.net/w2c3mj0ksfgl/abcd?sv=2017-04-
17&sr=b&si=600a9281-d39e-4cc3-91d2-923c4a696537&sig=xXaT6mFgf139ycT87CADyFxb%2BnPXBElYirYRlbnJZbs%3D"
}
Carregar um VHD
Agora que você tem uma SAS para seu disco gerenciado vazio, você pode usá-lo para definir o disco gerenciado
como o destino para o comando de carregamento.
Use AzCopy V10 para carregar o arquivo VHD local em um disco gerenciado especificando o URI SAS gerado.
Esse carregamento tem a mesma taxa de transferência que o HDD padrãoequivalente. Por exemplo, se você tiver
um tamanho que é igual a S4, terá uma taxa de transferência de até 60 MiB/s. Mas, se você tiver um tamanho
igual a S70, terá uma taxa de transferência de até 500 MiB/s.
AzCopy.exe copy "c:\somewhere\mydisk.vhd""sas-URI" --blob-type PageBlob
Depois que o upload for concluído e você não precisar mais gravar mais dados no disco, revogue a SAS. A
revogação da SAS alterará o estado do disco gerenciado e permitirá que você anexe o disco a uma VM.
Substitua <yourdiskname> e <yourresourcegroupname> , em seguida, use o seguinte comando para tornar o disco
utilizável:
az disk revoke-access -n <yourdiskname> -g <yourresourcegroupname>

O carregamento direto também simplifica o processo de cópia de um disco gerenciado. Você pode copiar na
mesma região ou em uma região cruzada (para outra região).
O script a seguir fará isso para você, o processo é semelhante às etapas descritas anteriormente, com algumas
diferenças, já que você está trabalhando com um disco existente.
IMPORTANT
Você precisa adicionar um deslocamento de 512 quando estiver fornecendo o tamanho do disco em bytes de um disco
gerenciado do Azure. Isso ocorre porque o Azure omite o rodapé ao retornar o tamanho do disco. A cópia falhará se você
não fizer isso. O script a seguir já faz isso para você.
Substitua o <sourceResourceGroupHere> , , <targetDiskNameHere> ,

<sourceDiskNameHere>
<targetResourceGroupHere> e <yourTargetLocationHere> (um exemplo de um valor de local seria uswest2) por
seus valores e, em seguida, execute o script a seguir para copiar um disco gerenciado.
TIP
Se você estiver criando um disco do sistema operacional, adicione--Hyper-v-Generation ao az disk create .
sourceDiskName=<sourceDiskNameHere>
sourceRG=<sourceResourceGroupHere>
targetDiskName=<targetDiskNameHere>
targetRG=<targetResourceGroupHere>
targetLocation=<yourTargetLocationHere>
sourceDiskSizeBytes=$(az disk show -g $sourceRG -n $sourceDiskName --query '[diskSizeBytes]' -o tsv)
az disk create -g $targetRG -n $targetDiskName -l $targetLocation --for-upload --upload-size-bytes

$(($sourceDiskSizeBytes+512)) --sku standard_lrs
targetSASURI=$(az disk grant-access -n $targetDiskName -g $targetRG --access-level Write --duration-in-

seconds 86400 -o tsv)
sourceSASURI=$(az disk grant-access -n $sourceDiskName -g $sourceRG --duration-in-seconds 86400 --query

[accessSas] -o tsv)
.\azcopy copy $sourceSASURI $targetSASURI --blob-type PageBlob
az disk revoke-access -n $sourceDiskName -g $sourceRG
az disk revoke-access -n $targetDiskName -g $targetRG
Próximas etapas
Agora que você carregou com êxito um VHD em um disco gerenciado, é possível anexar o disco como um disco
de dados a uma VM existente ou anexar o disco a uma VM como um disco do sistema operacional, para criar
uma nova VM.
Baixar um VHD do Linux por meio do Azure
Neste artigo, você aprende a baixar um arquivo de VHD (disco rígido virtual) do Linux do Azure usando o portal
do Azure.
Pare a VM.
Não é possível baixar um VHD por meio do Azure se ele estiver anexado a uma VM em execução. Você precisa
parar a VM para baixar o VHD.
2. No menu à esquerda, selecione máquinas vir tuais .
4. Na página da VM, selecione parar .
Gerar a URL de SAS

Para baixar o arquivo VHD, você precisa gerar uma URL de SAS (assinatura de acesso compartilhado). Quando a
URL é gerada, uma hora de expiração é atribuída à URL.
1. No menu da página da VM, selecione discos .
2. Selecione o disco do sistema operacional para a VM e, em seguida, selecione expor tação de disco .
3. Se necessário, atualize o valor da URL expira em (segundos) para fornecer tempo suficiente para concluir
o download. O padrão é 3600 segundos (uma hora).
4. Selecione gerar URL .
Baixar o VHD
1. Na URL que foi gerada, selecione baixar o arquivo VHD .
2. Talvez seja necessário selecionar salvar no navegador para iniciar o download. O nome padrão do
arquivo VHD é abcd.
Próximas etapas
Saiba como carregar e criar uma VM do Linux com base em um disco personalizado com a CLI do Azure.
Gerenciar discos do Azure com a CLI do Azure.
Baixar um VHD do Windows Azure
Neste artigo, você aprenderá a fazer o download de um arquivo VHD (disco rígido virtual do Windows) do
Azure usando o portal do Azure.
Opcional: generalizar a VM
Se você quiser usar o VHD como uma imagem para criar outras VMS, deverá usar o Sysprep para generalizar o
Para usar o VHD como uma imagem para criar outras VMs, generalizar a VM.
1. Se você ainda não fez isso, entre no portal do Azure.
2. Conecte-se à VM.
3. Na VM, abra uma janela de prompt de comando como administrador.
4. Altere o diretório para %windir%\system32\sysprep e execute sysprep.exe.
5. Na caixa de diálogo Ferramenta de Preparação do Sistema, selecione Entrar na Configuração Inicial pelo
Usuário do Sistema (OOBE) e verifique se a opção Generalizar está marcada.
6. Em Opções de Desligamento, selecione Desligar e OK .
Pare a VM.
Não é possível baixar um VHD por meio do Azure se ele estiver anexado a uma VM em execução. Você precisa
parar a VM para baixar um VHD.
1. No menu Hub no portal do Azure, clique em Máquinas Vir tuais .
3. Na folha da VM, clique em Parar .
Gerar URL de download

Para baixar o arquivo VHD, você precisa gerar uma URL de SAS (assinatura de acesso compartilhado). Quando a
URL é gerada, uma hora de expiração é atribuída à URL.
1. Na página da VM, clique em discos no menu à esquerda.
2. Selecione o disco do sistema operacional para a VM.
3. Na página do disco, selecione exportação de disco no menu à esquerda.
4. O tempo de expiração padrão da URL é de 3600 segundos. Aumente isso para 36000 para discos do
sistema operacional Windows.
5. Clique em Gerar URL .
NOTE
O tempo de expiração é aumentado de padrão a fim de fornecer tempo suficiente para baixar o arquivo VHD grande para
um sistema operacional Windows Server. Você pode esperar que um arquivo VHD que contém o sistema operacional
Windows Server leve várias horas para ser baixado, dependendo da conexão. Se você estiver baixando um VHD para um
disco de dados, a hora padrão será suficiente.
Baixar o VHD
1. Na URL que foi gerada, clique em Baixar o arquivo VHD.
2. Talvez seja necessário clicar em salvar no navegador para iniciar o download. O nome padrão do arquivo
VHD é abcd.
Próximas etapas
Saiba como carregar um arquivo VHD no Azure.
Crie discos gerenciados de discos não gerenciados em uma conta de armazenamento.
Gerenciar discos do Azure com o PowerShell.
Usar Gerenciador de Armazenamento do Azure
para gerenciar o Azure Managed disks
Gerenciador de Armazenamento 1.10.0 permite que os usuários carreguem, baixem e copiem discos
gerenciados, bem como criem instantâneos. Por causa desses recursos adicionais, você pode usar Gerenciador
de Armazenamento para migrar dados do local para o Azure e migrar dados entre regiões do Azure.
Pré-requisitos
Para concluir este artigo, você precisará do seguinte:
Uma assinatura do Azure
Um ou mais Azure Managed disks
A versão mais recente do Gerenciador de armazenamento do Azure
Conectar-se a uma assinatura do Azure

Se o Gerenciador de Armazenamento não estiver conectado ao Azure, você não poderá usá-lo para gerenciar
recursos. Esta seção vai se conectar à sua conta do Azure para que você possa gerenciar recursos usando
Gerenciador de Armazenamento.
1. Inicie o Gerenciador de Armazenamento do Azure e clique no ícone de plug-in à esquerda.
2. Selecione Adicionar uma conta do Azure e clique em Avançar .
3. Na caixa de diálogo entrar no Azure , insira suas credenciais do Azure.

4. Selecione sua assinatura na lista e, em seguida, clique em Aplicar .
Carregar um disco gerenciado de um VHD local
1. No painel esquerdo, expanda discos e selecione o grupo de recursos no qual você deseja carregar o
disco.
2. Escolha Carregar .
3. Em carregar VHD , ESPECIFIQUE o VHD de origem, o nome do disco, o tipo de sistema operacional, a
região em que você deseja carregar o disco, bem como o tipo de conta. Em algumas regiões, as zonas de
disponibilidade têm suporte, para essas regiões, você pode selecionar uma zona de sua escolha.
4. Selecione criar para começar a carregar o disco.
5. O status do carregamento agora será exibido em atividades .
6. Se o upload tiver sido concluído e você não vir o disco no painel direito, selecione Atualizar .
Baixar um disco gerenciado

As etapas a seguir explicam como baixar um disco gerenciado para um VHD local. O estado de um disco deve
ser desanexado para ser baixado, você não pode baixar um disco anexado .
1. No painel esquerdo, se ainda não estiver expandido, expanda discos e selecione o grupo de recursos do
qual você deseja baixar o disco.
2. No painel direito, selecione o disco que você deseja baixar.
3. Selecione baixar e, em seguida, escolha onde deseja salvar o disco.
4. Selecione salvar e seu disco começará a ser baixado. O status do download será exibido em atividades .

Com o Gerenciador de Armazenamento, você pode copiar um disco de gerenciada dentro ou entre regiões. Para
copiar um disco:
1. No menu suspenso discos à esquerda, selecione o grupo de recursos que contém o disco que você
deseja copiar.
2. No painel direito, selecione o disco que você deseja copiar e selecione copiar .
3. No painel esquerdo, selecione o grupo de recursos no qual você gostaria de colar o disco.
4. Selecione colar no painel à direita.
5. Na caixa de diálogo colar disco , preencha os valores. Você também pode especificar uma zona de
disponibilidade em regiões com suporte.
6. Selecione colar e o disco começará a ser copiado, o status será exibido em atividades .
Criar um instantâneo
1. No menu suspenso discos à esquerda, selecione o grupo de recursos que contém o disco que você
deseja fazer o instantâneo.
2. À direita, selecione o disco que você gostaria de fazer o instantâneo e selecione criar instantâneo .
3. Em criar instantâneo , especifique o nome do instantâneo, bem como o grupo de recursos no qual você
deseja criá-lo. Em seguida, selecione Criar .
4. Depois que o instantâneo tiver sido criado, você poderá selecionar abrir no por tal em atividades para
exibir o instantâneo no portal do Azure.
Próximas etapas
Saiba como criar uma VM de um VHD usando o portal do Azure.
Saiba como anexar um disco de dados gerenciado a uma VM do Windows usando o portal do Azure.
Mudar o disco do sistema operacional usado por
uma VM do Azure usando a CLI
Se você tiver uma VM já existente, mas quiser trocar o disco por um disco de backup ou outro disco do sistema
operacional, você pode usar a CLI do Azure para trocar os discos do SO. Você não precisa excluir e recriar a VM.
Você pode até usar um disco gerenciado em outro grupo de recursos, desde que ele não esteja em uso.
A VM precisa ser interrompida\desalocada e, em seguida, a ID de recurso do disco gerenciado pode ser
substituída pela ID de recurso de um disco gerenciado diferente.
Certifique-se de que o tipo de armazenamento e o tamanho da VM sejam compatíveis com o disco que você
deseja anexar. Por exemplo, se o disco que você deseja usar estiver no armazenamento Premium, a VM precisa
ter capacidade de armazenamento Premium (como um tamanho da série DS).
Este tutorial requer a CLI do Azure, versão 2.0.25 ou superior. Execute az --version para encontrar a versão. Se
você precisa instalar ou atualizar, consulte Instalar a CLI do Azure.
Use az disk list para obter uma lista dos discos no grupo de recursos.
az disk list \
--query '[*].{diskId:id}' \
--output table
Use az vm stop para interromper\desalocar a VM antes de trocar os discos.
az vm stop \
-n myVM \
-g myResourceGroup
Use az vm update com a ID de recurso completo do novo disco para o parâmetro --osdisk
az vm update \
-n myVM \
--os-disk /subscriptions/<subscription ID>/resourceGroups/swap/providers/Microsoft.Compute/disks/myDisk
Reinicie a VM usando az vm start.
az vm start \
-n myVM \
-g myResourceGroup
Próximas etapas
Para criar uma cópia de um disco, consulte Instantâneo de um disco.
Mudar o disco do sistema operacional usado por
uma VM do Azure usando o PowerShell
Se você tiver uma VM existente, mas deseja trocar o disco para um disco de backup ou outro disco do sistema
operacional, você pode usar o PowerShell do Azure para trocar os discos do sistema operacional. Você não
precisa excluir e recriar a VM. Você pode até usar um disco gerenciado em outro grupo de recursos, desde que
ele não esteja em uso.
A VM precisa ser interrompida\desalocada e, em seguida, a ID de recurso do disco gerenciado pode ser
substituída pela ID de recurso de um disco gerenciado diferente.
Certifique-se de que o tipo de armazenamento e o tamanho da VM sejam compatíveis com o disco que você
deseja anexar. Por exemplo, se o disco que você deseja usar estiver no armazenamento Premium, a VM precisa
ter capacidade de armazenamento Premium (como um tamanho da série DS). Ambos os discos também devem
ter o mesmo tamanho. E certifique-se de que você não está misturando uma VM não criptografada com um
disco do sistema operacional criptografado, isso não é suportado. Se a VM não usar Azure Disk Encryption, o
disco do sistema operacional que está sendo trocado não deverá estar usando Azure Disk Encryption.
Obter uma lista de discos em um grupo de recursos usando Get-AzDisk
Get-AzDisk -ResourceGroupName myResourceGroup | Format-Table -Property Name
Quando você tiver o nome do disco que você deseja usar, defina esse disco como o disco do sistema
operacional para a VM. Este exemplo interrompe\desaloca a VM denominada myVM e atribui o disco
denominado newDisk como o novo disco de sistema operacional.
# Get the VM
# Make sure the VM is stopped\deallocated

Stop-AzVM -ResourceGroupName myResourceGroup -Name $vm.Name -Force
# Get the new disk that you want to swap in

$disk = Get-AzDisk -ResourceGroupName myResourceGroup -Name newDisk
# Set the VM configuration to point to the new disk

Set-AzVMOSDisk -VM $vm -ManagedDiskId $disk.Id -Name $disk.Name
# Update the VM with the new OS disk

Update-AzVM -ResourceGroupName myResourceGroup -VM $vm
# Start the VM
Start-AzVM -Name $vm.Name -ResourceGroupName myResourceGroup
Próximas etapas
Para criar uma cópia de um disco, consulte Instantâneo de um disco.
Como mapear discos do Azure para discos
convidados da VM do Linux
Talvez seja necessário determinar os discos do Azure que retornam os discos convidados de uma VM. Em alguns
cenários, você pode comparar o tamanho do disco ou do volume com o tamanho dos discos do Azure anexados.
Em cenários em que há vários discos do Azure com o mesmo tamanho anexado à VM, você precisa usar o LUN
(número de unidade lógica) dos discos de dados.
O que é um LUN?
Um LUN (número de unidade lógica) é um número usado para identificar um dispositivo de armazenamento
específico. Cada dispositivo de armazenamento recebe um identificador numérico exclusivo, começando em
zero. O caminho completo para um dispositivo é representado pelo número de barramento, número de ID de
destino e LUN (número de unidade lógica).
Por exemplo: *número de barramento 0, ID de destino 0, LUN 3 _
Para nosso exercício, você só precisa usar o LUN.
Encontrando o LUN
Abaixo, listamos dois métodos para localizar o LUN de um disco no Linux.
lsscsi
2. sudo lsscsi
A primeira coluna listada conterá o LUN, o formato é [host: Channel: target: _ * LUN * *].
Listando dispositivos de bloco
2. sudo ls -l /sys/block/*/device
A última coluna listada conterá o LUN, o formato é [host: Channel: target:LUN ]
Encontrando o LUN para os discos do Azure

Você pode localizar o LUN para um disco do Azure usando o portal do Azure, CLI do Azure.
Localizando um LUN do disco do Azure no portal do Azure
1. No portal do Azure, selecione "máquinas virtuais" para exibir uma lista de suas máquinas virtuais
2. Selecione a Máquina Virtual
3. Selecione "discos"
4. Selecione um disco de dados na lista de discos anexados.
5. O LUN do disco será exibido no painel detalhes do disco. O LUN exibido aqui está correlacionado aos LUNs
que você procurou no convidado usando lsscsi ou listando os dispositivos de bloqueio.
Localizando um LUN do disco do Azure usando CLI do Azure
az vm show -g myResourceGroup -n myVM --query "storageProfile.dataDisks"
Como mapear discos do Azure para discos
convidados da VM do Windows
Talvez seja necessário determinar os discos do Azure que retornam os discos convidados de uma VM. Em alguns
cenários, você pode comparar o tamanho do disco ou do volume com o tamanho dos discos do Azure anexados.
Em cenários em que há vários discos do Azure com o mesmo tamanho anexado à VM, você precisa usar o LUN
(número de unidade lógica) dos discos de dados.
O que é um LUN?
Um LUN (número de unidade lógica) é um número usado para identificar um dispositivo de armazenamento
específico. Cada dispositivo de armazenamento recebe um identificador numérico exclusivo, começando em
zero. O caminho completo para um dispositivo é representado pelo número de barramento, número de ID de
destino e LUN (número de unidade lógica).
Por exemplo: número de barramento 0, ID de destino 0, LUN 3
Para nosso exercício, você só precisa usar o LUN.
Encontrando o LUN
Há dois métodos para localizar o LUN, que você escolher dependerá se você estiver usando espaços de
armazenamento ou não.
Gerenciamento de disco
Se você não estiver usando pools de armazenamento, poderá usar o Gerenciamento de disco para localizar o
LUN.
1. Conecte-se à VM e abra o gerenciamento de disco a. Clique com o botão direito do mouse no botão Iniciar e
escolha "gerenciamento de disco" a. Você também pode digitar diskmgmt.msc na caixa Iniciar pesquisa
2. No painel inferior, clique com o botão direito do mouse em qualquer um dos discos e escolha "Propriedades"
3. O LUN será listado na propriedade "Location" na guia "General"
Pools de armazenamento
1. Conecte-se à VM e abra Gerenciador do Servidor
2. Selecione "serviços de arquivo e armazenamento", "volumes", "pools de armazenamento"
3. No canto inferior direito de Gerenciador do Servidor, haverá uma seção "discos físicos". Os discos que
compõem o pool de armazenamento estão listados aqui, bem como o LUN para cada disco.
Encontrando o LUN para os discos do Azure

Você pode localizar o LUN para um disco do Azure usando o portal do Azure, CLI do Azure ou Azure PowerShell
Localizando um LUN do disco do Azure no portal do Azure
1. No portal do Azure, selecione "máquinas virtuais" para exibir uma lista de suas máquinas virtuais
2. Selecione a Máquina Virtual
3. Selecione "discos"
4. Selecione um disco de dados na lista de discos anexados.
5. O LUN do disco será exibido no painel detalhes do disco. O LUN exibido aqui se correlaciona com os LUNs
que foram pesquisados no convidado usando Gerenciador de Dispositivos ou Gerenciador do Servidor.
Localizando um LUN do disco do Azure usando CLI do Azure ou Azure PowerShell
CLI do Azure
PowerShell do Azure
az vm show -g myResourceGroup -n myVM --query "storageProfile.dataDisks"

Localizar e excluir discos gerenciados e não
gerenciados desanexados do Azure usando a CLI
do Azure
Quando você exclui uma VM (máquina virtual) no Azure, por padrão, nenhum disco anexado à máquina virtual
é excluído. Esse recurso ajuda a evitar a perda de dados devido à exclusão não intencional de VMs. Depois que
uma VM for excluída, você continuará a pagar pelos discos desanexados. Este artigo mostra como localizar e
excluir discos desanexados e reduzir custos desnecessários.
Discos gerenciados: Localizar e excluir discos desanexados

O script a seguir procura discos gerenciados desanexados examinando o valor da propriedade ManagedBy .
Quando um disco gerenciado é anexado a uma VM, a propriedade ManagedBy contém a ID de recurso da VM.
Quando um disco gerenciado é desanexado, a propriedade ManagedBy é nula. O script examina todos os
discos gerenciados em uma assinatura do Azure. Quando o script localiza um disco gerenciado com a
propriedade ManagedBy definida como null, o script determina que o disco está desanexado.
IMPORTANT
Primeiro, execute o script definindo a variável deleteUnattachedDisks como 0. Essa ação permite localizar e exibir todos
os discos gerenciados desanexados.
Depois de examinar todos os discos desanexados, execute o script novamente e defina a variável
deleteUnattachedDisks como 1. Essa ação permite excluir todos os discos gerenciados desanexados.
# Set deleteUnattachedDisks=1 if you want to delete unattached Managed Disks

# Set deleteUnattachedDisks=0 if you want to see the Id of the unattached Managed Disks
deleteUnattachedDisks=0
unattachedDiskIds=$(az disk list --query '[?managedBy==`null`].[id]' -o tsv)
for id in ${unattachedDiskIds[@]}
do
if (( $deleteUnattachedDisks == 1 ))
then
echo "Deleting unattached Managed Disk with Id: "$id

az disk delete --ids $id --yes
echo "Deleted unattached Managed Disk with Id: "$id
else
echo $id
fi
done
Discos não gerenciados: Localizar e excluir discos desanexados

Discos não gerenciados são arquivos VHD armazenados como blobs de páginas nas Contas de Armazenamento
do Microsoft Azure. O script a seguir procura discos não gerenciados desanexados (blobs de página)
examinando o valor da propriedade LeaseStatus . Se um disco não gerenciado estiver conectado a uma
máquina virtual, a propriedade LeaseStatus estará configurada como Locked . Quando um disco não
gerenciado é desanexado, a propriedade LeaseStatus está definida como Unlocked . O script examina todos os
discos não gerenciados em todas as contas de armazenamento do Azure em uma assinatura do Azure. Quando
o script localiza um disco não gerenciado com uma propriedade LeaseStatus propriedade definida como
Unlocked , o script determina que o disco está desanexado.
IMPORTANT
Primeiro, execute o script definindo a variável deleteUnattachedVHDs como 0. Essa ação permite localizar e exibir
todos os VHDs não gerenciados desanexados.
deleteUnattachedVHDs como 1. Essa ação permite excluir todos os VHDs não gerenciados desanexados.
# Set deleteUnattachedVHDs=1 if you want to delete unattached VHDs

# Set deleteUnattachedVHDs=0 if you want to see the details of the unattached VHDs
deleteUnattachedVHDs=0
storageAccountIds=$(az storage account list --query [].[id] -o tsv)
for id in ${storageAccountIds[@]}
do
connectionString=$(az storage account show-connection-string --ids $id --query connectionString -o tsv)
containers=$(az storage container list --connection-string $connectionString --query [].[name] -o tsv)
for container in ${containers[@]}

do
blobs=$(az storage blob list -c $container --connection-string $connectionString --query "[?

properties.blobType=='PageBlob' && ends_with(name,'.vhd')].[name]" -o tsv)
for blob in ${blobs[@]}

do
leaseStatus=$(az storage blob show -n $blob -c $container --connection-string $connectionString
--query "properties.lease.status" -o tsv)
if [ "$leaseStatus" == "unlocked" ]
then
if (( $deleteUnattachedVHDs == 1 ))
then
echo "Deleting VHD: "$blob" in container: "$container" in storage account: "$id
az storage blob delete --delete-snapshots include -n $blob -c $container --connection-

string $connectionString
echo "Deleted VHD: "$blob" in container: "$container" in storage account: "$id

else
echo "StorageAccountId: "$id" container: "$container" VHD: "$blob
fi
fi
done
done
done
Próximas etapas
Para obter mais informações, confira Excluir uma conta de armazenamento.
Localizar e excluir discos gerenciados e não
gerenciados do Azure desconectados
é excluído. Esse recurso ajuda a evitar a perda de dados devido à exclusão não intencional de VMs. Depois que
uma VM for excluída, você continuará a pagar pelos discos desanexados. Este artigo mostra como localizar e
excluir discos desanexados e reduzir custos desnecessários.

O script a seguir procura discos gerenciados desanexados examinando o valor da propriedade ManagedBy .
Quando um disco gerenciado é anexado a uma VM, a propriedade ManagedBy contém a ID de recurso da VM.
Quando um disco gerenciado é desanexado, a propriedade ManagedBy é nula. O script examina todos os
discos gerenciados em uma assinatura do Azure. Quando o script localiza um disco gerenciado com a
propriedade ManagedBy definida como null, o script determina que o disco está desanexado.
IMPORTANT
Primeiro, execute o script definindo a variável deleteUnattachedDisks como 0. Essa ação permite localizar e exibir todos
os discos gerenciados desanexados.
deleteUnattachedDisks como 1. Essa ação permite excluir todos os discos gerenciados desanexados.
# Set deleteUnattachedDisks=1 if you want to delete unattached Managed Disks

# Set deleteUnattachedDisks=0 if you want to see the Id of the unattached Managed Disks
$deleteUnattachedDisks=0
$managedDisks = Get-AzDisk
foreach ($md in $managedDisks) {
# ManagedBy property stores the Id of the VM to which Managed Disk is attached to
# If ManagedBy property is $null then it means that the Managed Disk is not attached to a VM
if($md.ManagedBy -eq $null){
if($deleteUnattachedDisks -eq 1){
Write-Host "Deleting unattached Managed Disk with Id: $($md.Id)"
$md | Remove-AzDisk -Force
Write-Host "Deleted unattached Managed Disk with Id: $($md.Id) "
}else{
$md.Id
}
}
}

do Microsoft Azure. O script a seguir procura discos não gerenciados desanexados (blobs de página)
examinando o valor da propriedade LeaseStatus . Se um disco não gerenciado estiver conectado a uma
máquina virtual, a propriedadeLeaseStatus estará configurada como Locked . Quando um disco não
gerenciado é desanexado, a propriedade LeaseStatus está definida como Unlocked . O script examina todos os
discos não gerenciados em todas as contas de armazenamento do Azure em uma assinatura do Azure. Quando
o script localiza um disco não gerenciado com uma propriedade LeaseStatus propriedade definida como
Unlocked , o script determina que o disco está desanexado.
IMPORTANT
Primeiro, execute o script definindo a variável deleteUnattachedVHDs como $false . Essa ação permite localizar e
exibir todos os VHDs não gerenciados desanexados.
deleteUnattachedVHDs como $true . Essa ação permite excluir todos os VHDs não gerenciados desanexados.
# Set deleteUnattachedVHDs=$true if you want to delete unattached VHDs

# Set deleteUnattachedVHDs=$false if you want to see the Uri of the unattached VHDs
$deleteUnattachedVHDs=$false
$storageAccounts = Get-AzStorageAccount
foreach($storageAccount in $storageAccounts){
$storageKey = (Get-AzStorageAccountKey -ResourceGroupName $storageAccount.ResourceGroupName -Name
$storageAccount.StorageAccountName)[0].Value
$context = New-AzStorageContext -StorageAccountName $storageAccount.StorageAccountName -
StorageAccountKey $storageKey
$containers = Get-AzStorageContainer -Context $context
foreach($container in $containers){
$blobs = Get-AzStorageBlob -Container $container.Name -Context $context
#Fetch all the Page blobs with extension .vhd as only Page blobs can be attached as disk to Azure
VMs
$blobs | Where-Object {$_.BlobType -eq 'PageBlob' -and $_.Name.EndsWith('.vhd')} | ForEach-Object {
#If a Page blob is not attached as disk then LeaseStatus will be unlocked
if($_.ICloudBlob.Properties.LeaseStatus -eq 'Unlocked'){
if($deleteUnattachedVHDs){
Write-Host "Deleting unattached VHD with Uri: $($_.ICloudBlob.Uri.AbsoluteUri)"
$_ | Remove-AzStorageBlob -Force
Write-Host "Deleted unattached VHD with Uri: $($_.ICloudBlob.Uri.AbsoluteUri)"
}
else{
$_.ICloudBlob.Uri.AbsoluteUri
}
}
}
}
}
Próximas etapas
Para obter mais informações, confira Excluir uma conta de armazenamento e Identificar discos órfãos usando o
PowerShell
Encontrar e excluir discos gerenciados e não
gerenciados desanexados do Azure – portal do
Azure
é excluído. Isso ajuda a evitar a perda de dados devido à exclusão não intencional de VMs. Depois que uma VM
for excluída, você continuará a pagar pelos discos desanexados. Este artigo mostra como encontrar e excluir
discos desanexados usando o portal do Azure e reduzir custos desnecessários. As exclusões são permanentes,
você não poderá recuperar os dados depois de excluir um disco.

Se você tiver discos gerenciados desanexados e não precisar mais dos dados deles, o seguinte processo
explicará como encontrá-los no portal do Azure:
2. Procure e selecione Discos .
Na folha Discos , você verá uma lista de todos os seus discos. Qualquer disco que tenha " - " na coluna
Proprietário é um disco desanexado.
3. Selecione o disco desanexado que deseja excluir; isso abrirá a folha do disco.
4. Na folha do disco, confirme se o estado do disco é desanexado e selecione Excluir .

do Microsoft Azure.
Se você tiver discos não gerenciados que não estão anexados a uma VM, não precisar mais dos dados deles e
desejar excluí-los, o seguinte processo explicará como fazer isso no portal do Azure:
2. Procure e selecione Discos (Clássico) .
Você verá uma lista de todos os discos não gerenciados. Qualquer disco que tenha " - " na coluna
Anexado a é um disco desanexado.
3. Selecione o disco desanexado que deseja excluir; isso abrirá a folha do disco.
4. Na folha do disco, confirme se ele está desanexado, pois o estado Anexado a ainda estará - .
5. Selecione Excluir .
Próximas etapas
Caso deseje obter uma forma automatizada de localizar e excluir contas de armazenamento desanexadas,
confira nossos artigos sobre a CLI ou o PowerShell.
Para obter mais informações, confira Excluir uma conta de armazenamento e Identificar discos órfãos usando o
PowerShell
Perguntas frequentes sobre discos de VM IaaS do
Azure e discos premium gerenciados e não
gerenciados
Este artigo responde a algumas perguntas frequentes sobre o Azure Managed Disks e os discos Azure Premium
SSD.
Managed Disks
O que é o Azure Managed Disks?
Managed Disks é um recurso que simplifica o gerenciamento de disco para VMs IaaS do Azure manipulando o
gerenciamento de conta de armazenamento para você. Para saber mais, veja Visão geral dos Managed Disks.
Se eu criar um disco gerenciado standard com base em um VHD existente que tem 80 GB, quanto
isso custará?
Um disco gerenciado standard criado com base em um VHD de 80 GB é tratado como o próximo tamanho de
disco standard disponível, um disco S10. Você será cobrado de acordo com o preço do disco S10. Para saber
mais, confira a página de preço.
Existem custos de transação de discos gerenciados standard?
Sim. Você é cobrado por cada transação. Para saber mais, confira a página de preço.
Para um disco gerenciado standard, eu serei cobrado pelo tamanho real dos dados no disco ou
pela capacidade provisionada do disco?
Você é cobrado com base na capacidade provisionada do disco. Para saber mais, confira a página de preço.
O preço dos discos premium gerenciados é diferente do preço dos discos não gerenciados?
O preço dos discos premium gerenciados é o mesmo que os discos premium não gerenciados.
Posso alterar o tipo de conta de armazenamento (Standard ou Premium) de meus discos
gerenciados?
Sim. Você pode alterar o tipo de conta de armazenamento de seus discos gerenciados usando o portal do Azure,
PowerShell ou a CLI do Azure.
Posso usar um arquivo VHD em uma conta de armazenamento do Azure para criar um disco
gerenciado com uma assinatura diferente?
Sim.
Posso usar um arquivo VHD em uma conta de armazenamento do Azure para criar um disco
gerenciado em uma região diferente?
Não.
Existem limitações de escala para clientes que usam discos gerenciados?
O Managed Disks elimina os limites associados a contas de armazenamento. Porém, o limite máximo é de
50.000 discos gerenciados por região e por tipo de disco para uma assinatura.
As VMs em um conjunto de disponibilidade podem consistir de uma combinação de discos
gerenciados e não gerenciados?
Não. As VMs em um conjunto de disponibilidade devem usar todos os discos gerenciados ou não gerenciados.
Ao criar um conjunto de disponibilidade, você pode escolher qual tipo de discos que deseja usar.
O Managed Disks é a opção padrão no por tal do Azure?
Sim.
É possível criar um disco gerenciado vazio?
Sim. Você pode criar um disco vazio. Um disco gerenciado pode ser criado independentemente de uma VM, por
exemplo, sem anexá-lo a uma VM.
O que é a contagem de domínios de falha com supor te para um conjunto de disponibilidade que
usa o Managed Disks?
Dependendo da região em que o conjunto de disponibilidade que usa o Managed Disks está localizado, a
contagem de domínios de falha com suporte é 2 ou 3.
Como é conta de armazenamento standard para a configuração de diagnóstico?
Você configura uma conta de armazenamento privado para diagnóstico da VM.
Que tipo de supor te ao controle de acesso baseado em função do Azure está disponível para
Managed Disks?
O Managed Disks oferece suporte a três funções principais padrão:
Proprietário: Pode gerenciar tudo, incluindo o acesso
Colaborador: Pode gerenciar tudo, exceto o acesso.
Leitor: Pode ver tudo, mas não pode fazer alterações
É possível copiar ou expor tar um disco gerenciado para uma conta de armazenamento privado?
Você pode gerar uma assinatura de acesso compartilhado somente leitura URI (SAS) para o disco gerenciado e
usá-la para copiar o conteúdo para uma conta de armazenamento privado ou armazenamento local. Você pode
usar o URI de SAS no Portal do Azure, no Azure PowerShell, na CLI do Azure ou no AzCopy.
Posso criar uma cópia do meu disco gerenciado?
Os clientes podem tirar um instantâneo de seus discos gerenciados e, em seguida, usar o instantâneo para criar
outro disco gerenciado.
Ainda há supor te para discos não gerenciados?
Sim, há suporte para discos gerenciados e não gerenciados. Recomendamos que você use discos gerenciados
para novas cargas de trabalho e migre suas cargas de trabalho atuais para discos gerenciados.
Posso colocalizar discos gerenciados e não gerenciadas na mesma VM?
Não.
Se eu criar um disco de 128 GB e aumentar o tamanho para 130 gibibytes (GiB), serei cobrado
pelo próximo tamanho de disco (256 GiB)?
Sim.
Posso criar armazenamento com redundância local, armazenamento com redundância geográfica
e discos de armazenamento com redundância de zona gerenciados?
O Azure Managed Disks atualmente dá suporte apenas a discos gerenciados de armazenamento com
redundância local.
Posso reduzir ou diminuir o tamanho de meus discos gerenciados?
Não. Não há suporte para esse recurso no momento.
Posso interromper uma concessão no disco?
Não. Isso não é compatível no momento porque uma concessão está presente para impedir a exclusão acidental
quando o disco está sendo usado.
Posso alterar a propriedade de nome do computador quando um disco do sistema operacional
especializado (não criado usando a ferramenta de Preparação do Sistema ou generalizado) é
usado para provisionar uma máquina vir tual?
Não. Não é possível atualizar a propriedade de nome do computador. A nova VM a herda do pai, que foi usado
para criar o disco do sistema operacional.
Onde posso encontrar modelos do Azure Resource Manager de exemplo para criar VMs com
discos gerenciados?
Lista de modelos que usam o Managed Disks
https://github.com/chagarw/MDPP
Ao criar um disco a par tir de um blob, existe alguma relação existente com esse blob de origem?
Não, quando o novo disco é criado é uma cópia autônoma completa do blob no momento e não há nenhuma
conexão entre os dois. Se você quiser, depois de criar o disco, o blob de origem pode ser excluído sem afetar o
disco recém-criado de alguma forma.
Posso renomear um disco gerenciado ou não gerenciado depois que ele foi criado?
Para discos gerenciados, você não pode renomeá-los. No entanto, você pode renomear um disco não
gerenciado, desde que ele não está anexado a uma VM ou VHD.
Posso usar o par ticionamento de GPT em um Disco do Azure?
As imagens de Geração 1 só podem usar o particionamento GPT em discos de dados, não em discos do sistema
operacional. Os discos do sistema operacional devem usar o estilo de partição MBR.
As imagens de Geração 2 podem usar o particionamento GPT no disco do sistema operacional e nos discos de
dados.
Quais tipos de disco dão supor te a instantâneos?
Os SSD Premium, SSD Standard e HDD Standard dão suporte a instantâneos. Para esses três tipos de disco, os
instantâneos têm suporte em todos os tamanhos de disco (incluindo discos de até 32 TiB de tamanho). Discos
Ultra não dão suporte a instantâneos.
O que são as reser vas de discos do Azure? A reserva de discos é a opção de comprar um ano de
armazenamento em disco com antecedência, reduzindo o custo total. Para obter detalhes sobre as reservas de
discos do Azure, confira nosso artigo sobre o assunto: Entenda como o desconto de reserva é aplicado ao
Armazenamento em Disco do Azure.
Quais opções a reser va de discos do Azure oferece?
A reserva de discos do Azure fornece a opção de comprar SSDs Premium nas SKUs especificadas de P30 (1 TiB)
até P80 (32 TiB) pelo período de um ano. Não há nenhuma limitação na quantidade mínima de discos
necessária para comprar uma reserva de discos. Além disso, você pode optar por fazer um único pagamento
antecipado ou pagamentos mensais. Não há nenhum custo transacional adicional aplicado aos Managed Disks
SSD Premium.
As reservas são feitas na forma de discos, não de capacidade. Em outras palavras, ao reservar um disco P80 (32
TiB), você obterá um único disco P80, ou seja, não é possível dividir essa reserva específica em dois discos
menores de P70 (16 TiB). É claro que você pode reservar tantos discos quanto desejar, incluindo dois discos P70
(16 TiB) diferentes.
Como a reser va de discos do Azure funciona?
A reserva de discos segue um modelo semelhante às instâncias de VM (máquina virtual) reservadas. A
diferença é que uma reserva de discos não pode ser aplicada a SKUs diferentes, mas uma instância de VM pode.
Confira Economizar custos com Instâncias de VM Reservadas do Azure para obter mais informações sobre
instâncias de VM.
Posso usar meu armazenamento de dados adquirido por meio da reser va de discos do Azure em
várias regiões?
A reserva de discos do Azure é adquirida para uma região e uma SKU específicas (como P30 no Leste dos EUA
2) e, portanto, não pode ser usada fora desses constructos. Você sempre pode comprar uma reserva de discos
do Azure adicional para suas necessidades de armazenamento em disco em outras regiões ou SKUs.
O que acontece quando minha reser va de discos do Azure expira?
Você receberá notificações por email 30 dias antes da expiração e novamente na data de validade. Depois que a
reserva expirar, os discos implantados continuarão a ser executados e serão cobrados pelas taxas mais recentes
de pagamento conforme o uso.
Os discos SSD padrão têm supor te para "SL A de VM de Instância Única"?
Sim, todos os tipos de disco dão suporte ao SLA de VM de instância única.
Discos compartilhados do Azure
Os discos não gerenciados ou blobs de páginas dão supor te a recursos de discos compar tilhados?
Não, há suporte apenas para ultra discos e discos gerenciados do SSD Premium.
Quais regiões dão supor te a discos compar tilhados?
Para obter informações regionais, consulte nosso artigo conceitual.
Os discos compar tilhados podem ser usados como um disco do sistema operacional?
Não, os discos compartilhados só têm suporte por discos de dados.
Quais tamanhos de disco dão supor te a discos compar tilhados?
Para tamanhos com suporte, consulte nosso artigo conceitual.
Se eu tiver um disco existente, posso habilitar discos compar tilhados nele?
Todos os discos gerenciados criados com a versão de API 2019-07-01 ou superior podem habilitar discos
compartilhados. Para fazer isso, você precisará desmontar o disco de todas as VMs às quais ele está anexado.
Em seguida, edite a propriedade maxShares no disco.
Se eu não quiser mais usar um disco no modo compar tilhado, como posso desabilitá-lo?
Desmonte o disco de todas as VMs às quais ele está anexado. Em seguida, edite a propriedade maxShare no
disco para 1.
Você pode redimensionar um disco compar tilhado?
Sim.
Posso habilitar o acelerador de gravação em um disco que também tem discos compar tilhados
habilitados?
Não.
Posso habilitar o cache de host para um disco que tem disco compar tilhado habilitado?
A única opção de cache de host com suporte é None .
Discos Ultra
Como que devo definir a taxa de transferência do Disco Ultra? Se você não tiver certeza de como
definir sua taxa de transferência, recomendamos que comece supondo um tamanho de E/S de 16 KiB e ajuste o
desempenho a partir daí enquanto monitora o aplicativo. A fórmula é: Taxa de transferência em MBps = nº de
IOPS * 16/1000.
Configurei meu disco para 40.000 IOPS, mas estou vendo apenas 12.800 IOPS. Por que não estou
vendo o desempenho do disco? Além do acelerador de disco, há um acelerador de E/S que é imposto no
nível da VM. Verifique se o tamanho da VM que você está usando pode dar suporte aos níveis que estão
configurados em seus discos. Para obter detalhes sobre os limites de e/s impostos pela sua VM, consulte
tamanhos de máquinas virtuais no Azure.
Posso usar níveis de cache com um Disco Ultra? Não, os Discos Ultra não dão suporte aos diferentes
métodos de cache que têm suporte em outros tipos de disco. Defina o cache de disco como nenhum .
Posso anexar um Disco Ultra à minha VM existente? Talvez, mas sua VM precisa estar em um par de
região e zona de disponibilidade que dê suporte a Discos Ultra. Confira Introdução aos Discos Ultra para obter
detalhes.
Posso usar um Disco Ultra como o disco do sistema operacional da minha VM? Não, os Discos Ultra
só têm suporte como discos de dados e apenas como discos nativos de 4K.
Posso conver ter um disco existente em um Disco Ultra? Não, mas você pode migrar os dados de um
disco existente para um Disco Ultra. Para migrar um disco existente para um disco ultra, anexe ambos os discos
à mesma VM e copie os dados de um disco para outro ou aproveite uma solução de terceiros para migração de
dados.
Posso criar instantâneos para Disco Ultras? Não, os instantâneos ainda não estão disponíveis.
O Backup do Azure está disponível para Disco Ultras? Não, o suporte ao Backup do Azure ainda não está
disponível.
Posso anexar um Disco Ultra a uma VM em execução em um conjunto de disponibilidade? Não, ele
ainda não tem suporte.
Posso habilitar o Azure Site Recover y para VMs usando Discos Ultra? Não, o Azure Site Recovery ainda
não dá suporte a Discos Ultra.
Fazendo upload para um disco gerenciado

Posso carregar dados em um disco gerenciado existente?
Não, o upload só pode ser usado durante a criação de um novo disco vazio com o estado ReadyToUpload .
Como fazer upload para um disco gerenciado?
Crie um disco gerenciado com a propriedade createOption de creationData definida como "Upload"; em
seguida, você poderá carregar dados nele.
Posso anexar um disco a uma VM enquanto ela está em um estado de upload?
Não.
Posso tirar um instantâneo de um disco gerenciado em um estado de upload?
Não.
Discos SSD Standard

Quais são os discos SSD Standard do Microsoft Azure? Os discos SSD padrão são discos padrão com o
apoio de mídia de estado sólida, otimizada como armazenamento econômico para cargas de trabalho que
precisam de desempenho consistente em níveis inferiores de IOPS.
Quais são as regiões atualmente supor tadas para discos SSD padrão? Todas as regiões do Azure agora
oferecem suporte a discos SSD Standard.
O Backup do Azure está disponível ao usar SSDs Standard? Sim, o Backup do Azure agora está
disponível.
O que é a vantagem de usar discos SSD padrão em vez de HDD? Os discos SSD Standard oferecem
melhor latência, consistência, disponibilidade e confiabilidade em comparação aos discos HDD. As cargas de
trabalho de aplicativos são executadas muito mais suavemente no SSD padrão por causa disso. Observe que os
discos SSD premium são a solução recomendada para a maioria das cargas de trabalho de produção com uso
intenso de I / O.
Posso usar o padrão de SSDs como discos não gerenciados? Não, os discos SSDs Padrão somente estão
disponíveis como discos gerenciados.
Como migrar para Managed Disks

Há algum impacto da migração sobre o desempenho de Discos Gerenciados?
Migração envolve a movimentação do disco de um local de armazenamento para outro. Isso é orquestrado por
meio de cópia em segundo plano de dados que pode levar várias horas para ser concluída, geralmente menos
de 24 horas, dependendo da quantidade de dados nos discos. Durante esse tempo seu aplicativo pode
apresentar latência de leitura maior do que o normal uma vez que as leituras podem ser redirecionadas para o
local original e podem demorar para serem concluídas. Não há nenhum impacto na latência de gravação
durante esse período.
Quais alterações são necessárias em uma já existente configuração de ser viço do Backup do Azure
antes/depois da migração para os Managed Disks?
Nenhuma alteração é necessária.
Os meus backups de VM criados pelo Ser viço de Backup do Azure continuarão a funcionar antes
da migração?
Sim, os backups funcionam perfeitamente.
Quais alterações são necessárias em uma já existente configuração de criptografia de discos do
Azure antes/depois da migração para os Managed Disks?
Nenhuma alteração é necessária.
Há supor te para a migração automatizada de um conjunto de dimensionamento de VMs (VMSS)
existente desde discos não gerenciados para os Managed Disks com supor te?
Não. Você pode criar um novo conjunto de dimensionamento com os Managed Disks usando a imagem do seu
antigo conjunto de dimensionamento com discos não gerenciados.
Posso criar um disco gerenciado de um instantâneo de blob de páginas tirado antes da migração
para os Managed Disks?
Não. Você pode exportar um instantâneo de blob de páginas como um blob de páginas e, em seguida, criar um
disco gerenciado a partir do blob de páginas exportado.
Posso fazer failover de meus computadores locais protegidos pelo Azure Site Recover y em uma
VM com os Managed Disks?
Sim, você pode optar por fazer failover para uma VM com os Managed Disks.
A migração tem algum impacto sobre as VMs do Azure protegidas pelo Azure Site Recover y por
meio da replicação do Azure para o Azure?
Não. A proteção Azure a Azure do Azure Site Recovery está disponível para VMs com Managed Disks.
Posso migrar VMs com discos não gerenciados localizados em contas de armazenamento ou
criptografados anteriormente em discos gerenciados?
Sim
Managed Disks e Criptografia de Serviço de Armazenamento

A Criptografia do Ser vidor é habilitada por padrão quando eu crio um disco gerenciado?
Sim. Os Managed Disks são criptografados com criptografia do servidor com chaves gerenciadas pela
plataforma.
O volume de inicialização é criptografado por padrão em um disco gerenciado?
Sim. Por padrão, todos os discos gerenciados são criptografados, incluindo o disco do sistema operacional.
Quem gerencia as chaves de criptografia?
As chaves gerenciadas pela plataforma são gerenciadas pela Microsoft. Você também pode usar e gerenciar
suas próprias chaves armazenadas no Azure Key Vault.
Posso desabilitar a Criptografia do Ser vidor em meus discos gerenciados?
Não.
A Criptografia do Ser vidor está disponível somente em regiões específicas?
Não. A Criptografia do Servidor com chaves gerenciadas pelo cliente e pela plataforma estão disponíveis em
todas as regiões nas quais os Managed Disks estão disponíveis.
O Azure Site Recover y dá supor te à criptografia do ser vidor com chave gerenciada pelo cliente
para cenários do local para o Azure e do Azure para a recuperação de desastre do Azure?
Sim.
Posso fazer backup de Managed Disks criptografados com criptografia do ser vidor e chave
gerenciada pelo cliente usando o ser viço de Backup do Azure?
Sim.
Os instantâneos gerenciados e as imagens são criptografados?
Sim. Todos os instantâneos e imagens gerenciados são criptografados automaticamente.
Posso conver ter máquinas vir tuais com discos não gerenciados que estão localizados em contas
de armazenamento ou criptografados anteriormente em discos gerenciados?
Sim
Um VHD expor tado de um disco gerenciado ou instantâneo também será criptografado?
Não. Mas se você exportar um VHD para uma conta de armazenamento criptografada de um disco gerenciado
ou instantâneo criptografado, ele estará criptografado.
Discos premium: Gerenciados e não gerenciados

Se uma VM usa uma série de tamanho que dá supor te aos discos Premium SSD, como um DSv2, é
possível anexar discos de dados standard e premium?
Sim.
É possível anexar discos de dados standard e premium a uma série de tamanho que não oferece
supor te a discos Premium SSD, como D, Dv2, G ou F?
Não. Você só pode anexar discos de dados standard às VMs que não usam uma série de tamanho que dá
suporte aos discos Premium SSD.
Se criar um disco de dados premium com base em um VHD existente que tinha 80 GB, quanto isso
custará?
Um disco de dados premium criado com base em um VHD de 80 GB é tratado como o próximo tamanho de
disco premium disponível, um disco P10. Você será cobrado de acordo com o preço do disco P10.
Existem custos de transação para usar os Discos Premium SSD?
Há um custo fixo para cada tamanho de disco, que vem provisionado com limites específicos de IOPS e taxa de
transferência. Os outros custos são largura de banda de saída e recurso de instantâneos, caso aplicável. Para
saber mais, confira a página de preço.
Quais são os limites de IOPS e taxa de transferência que posso obter do cache de disco?
Os limites combinados para cache e SSD local para um item da série DS são 4.000 IOPS por núcleo e 33 MiB
por segundo por núcleo. A série GS oferece 5.000 IOPS por núcleo e 50 MiB por segundo por núcleo.
O SSD local tem supor te para uma VM do Managed Disks?
O SSD local é um armazenamento temporário fornecido com uma VM do Managed Disks. Não há custo
adicional para esse armazenamento temporário. Recomendamos que você não use esse SSD local para
armazenar os dados do aplicativo porque ele não é mantido no Armazenamento de Blobs do Azure.
Existem repercussões pelo uso de TRIM em discos premium?
Não há nenhuma desvantagem em usar CORTE nos Discos do Azure Premium ou Standard.
Novos tamanhos de disco: Gerenciados e não gerenciados

Quais regiões dão supor te à capacidade de intermitência no tamanho de disco SSD Premium
aplicável?
Atualmente, há suporte à capacidade de intermitência em todas as regiões na nuvem pública do Azure, e o
suporte a nuvens soberanas virá em breve.
Quais regiões dão supor te a tamanhos de Managed Disks (P1/P2/P3, E1/E2/E3) de 4/8/16 GiB?
Atualmente, esses novos tamanhos de disco têm suporte em todas as regiões na nuvem pública do Azure, e o
suporte a nuvens soberanas virá em breve.
Os tamanhos de disco P1/P2/P3 têm supor te por discos não gerenciados ou blobs de páginas?
Não, apenas os Managed Disks SSD Premium dão suporte.
Os tamanhos de disco E1/E2/E3 têm supor te para discos não gerenciados ou blobs de páginas?
Não, nenhum disco gerenciado SSD Standard de qualquer tamanho pode ser usado com discos não
gerenciados ou blobs de páginas.
Qual é o maior tamanho de disco gerenciado com supor te para o sistema operacional e discos de
dados em VMs Gen1?
O tipo de partição que o Azure dá suporte para discos do sistema operacional Gen1 é o MBR (registro mestre
de inicialização). Embora os discos do so Gen1 suportem somente a MBR, os discos de dados dão suporte a GPT.
Embora você possa alocar até um disco de sistema operacional de 4 TiB, o tipo de partição MBR só pode usar
até 2 TiB desse espaço em disco para o sistema operacional. O Azure dá suporte a até 32 TB em discos de dados.
Qual é o maior tamanho de disco gerenciado com supor te para o sistema operacional e discos de
dados em VMs Gen2?
O tipo de partição que o Azure dá suporte para discos do sistema operacional Gen2 é GPT (tabela de partição
GUID). As VMs Gen2 dão suporte a até um disco de sistema operacional de 4 TiB. O Azure dá suporte a até 32
TB em discos de dados.
Qual é o maior tamanho de disco não gerenciado com supor te para o sistema operacional e os
discos de dados?
O tipo de partição que o Azure dá suporte para um disco do sistema operacional usando discos não
gerenciados é o MBR (registro mestre de inicialização). Embora você possa alocar até um disco de sistema
operacional de 4 TiB, o tipo de partição MBR só pode usar até 2 TiB desse espaço em disco para o sistema
operacional. O Azure dá suporte a até 4 TiB para discos de dados não gerenciados.
Qual é o maior tamanho de blob de página com supor te?
O maior tamanho de blob de página a que o Azure dá suporte é 8 TiB (8.191 GiB). O tamanho máximo do blob
da página quando conectado a uma VM como dados ou discos do sistema operacional é de 4 TiB (4.095 GiB).
Preciso usar uma nova versão das ferramentas do Azure para criar, anexar, redimensionar e
carregar discos maiores que 1 TiB?
Você não precisa atualizar as ferramentas existentes do Azure para criar, anexar ou redimensionar discos
maiores que 1 TiB. Para carregar o arquivo VHD local diretamente no Azure como um blob de página ou disco
não gerenciado, você precisará usar os conjuntos de ferramentas mais recentes, listadas abaixo. Só há suporte
para carregamentos VHD de até 8 TiB.
F ERRA M EN TA S DO A Z URE VERSÕ ES C O M SUP O RT E
Azure PowerShell Número de versão 4.1.0: Versão de junho de 2017 ou

posterior
CLI do Azure v1 Número de versão 0.10.13: Versão de maio de 2017 ou

posterior
CLI do Azure v2 Número da versão 2.0.12: Versão de julho de 2017 ou

posterior
AzCopy Número da versão 6.1.0: Versão de junho de 2017 ou

posterior
Os tamanhos de disco P4 e P6 têm supor te para discos não gerenciados ou blobs de página?
Tamanhos de disco P4 (32 GiB) e P6 (64 GiB) não têm suporte como as camadas de disco padrão para discos
não gerenciados e blobs de página. Você precisa explicitamente definir a camada de Blob para P4 e P6 ter seu
disco mapeado para essas camadas. Se você implantar um blob de página ou disco não gerenciado com o
tamanho do disco ou o comprimento de conteúdo de menor que 32 GiB ou entre 32 GiB para 64 GiB sem
definir a camada de Blob, você continuará a chegar em P10 com 500 IOPS e 100 MiB/s e o nível de preço
mapeado.
Se o meu disco gerenciado premium existente com menos de 64 GiB foi criado antes da
habilitação da pequeno disco (por volta de 15 de junho de 2017), como ele é cobrado?
Os discos pequenos premium com menos de 64 GiB continuam a ser cobrados de acordo com o tipo de preços
P10.
Como alternar a camada de disco dos discos premium pequenos com menos de 64 GiB de P10
para P4 ou P6?
Você pode tirar um instantâneo dos discos pequenos e criar um disco para alternar automaticamente o tipo de
preço para P4 ou P6 com base no tamanho provisionado.
Pode você redimensionar os discos gerenciados existentes de tamanhos abaixo de 4 tebibytes
(TiB) para novos tamanhos de disco recém-introduzidos até 32 TiB?
Sim.
Quais são os maiores tamanhos de disco com supor te pelo ser viço de Backup do Azure e pelo
Azure Site Recover y?
O maior tamanho de disco com suporte pelo Backup do Azure é 32 TiB (4 TiB para discos criptografados). O
maior tamanho de disco com suporte pelo Azure Site Recovery é 8 TiB. O suporte a discos maiores, de até 32
TiB, ainda não está disponível no Azure Site Recovery.
Quais são os tamanhos de VM recomendada para tamanhos de discos maiores (>4 TiB) otimizados
SSD Standard e HDD Standard para alcançar o disco IOPS e Largura de Banda?
Para obter a taxa de transferência dos tamanhos de disco grandes do SSD Standard e HDD Standard (>4 TiB)
além de 500 IOPS e 60 MiB/s, recomendamos que você use um dos seguintes tamanhos de VM para otimizar o
seu desempenho: VMs de série B, série DSv2, série Dsv3, série ESv3, série Fs, série Fsv2, série M, série GS, série
NCv2, série NCv3 ou série Ls. A anexação de discos grandes a VMs existentes ou que não usam os tamanhos
recomendados acima pode gerar um desempenho inferior.
Como posso atualizar meus discos (> 4 TiB) que foram implantados durante a versão prévia de
tamanhos de disco maiores para obter IOPS e largura de banda mais altos em GA?
Você pode parar e iniciar a VM à qual o disco está anexado ou desanexar e anexar o disco novamente. Os alvos
de desempenho de tamanhos de disco maiores foram aumentados para SSDs Premium e SSDs Standard na GA.
Quais regiões dão supor te a tamanhos de disco gerenciado de 8 TiB, 16 TiB e 32 TiB?
As SKUs de discos de 8 TiB, 16 TiB e 32 TiB têm suporte em todas as regiões no Azure global, no Microsoft
Azure Governamental e no Azure China 21Vianet.
Damos supor te à habilitação do cache de host em todos os tamanhos de disco?
O cache de host (ReadOnly e Read/Write ) tem suporte em tamanhos de disco inferiores a 4 Tib. Isso significa
que qualquer disco provisionado em até 4095 GiB pode tirar proveito do cache de host. O cache de host não
tem suporte para tamanhos de disco mais de ou igual a 4096 GiB. Por exemplo, um disco P50 Premium
provisionado em 4095 GiB pode tirar proveito do cache de host e um disco P50 provisionado em 4096 GiB não
pode tirar proveito do cache de host. É recomendável aproveitar o cache para tamanhos menores de disco em
que você pode esperar para observar o aumento de desempenho melhor com dados armazenados em cache
para a máquina virtual.
Links privados para exportar e importar Managed Disks com

segurança
Qual é o benefício de usar links privados para expor tar e impor tar Managed Disks?
Você pode aproveitar os links privados para restringir a exportação e a importação para Managed Disks
somente de sua rede virtual do Azure.
O que posso garantir que um disco possa ser expor tado ou impor tado somente por meio de links
privados?
Você deve definir a DiskAccessId propriedade para uma instância de um objeto de acesso a disco e também
definir a propriedade NetworkAccessPolicy como AllowPrivate .
Posso vincular várias redes vir tuais ao mesmo objeto de acesso ao disco?
Não. No momento, você pode vincular um objeto de acesso ao disco a apenas uma rede virtual.
Posso vincular uma rede vir tual a um objeto de acesso ao disco em outra assinatura?
Não. No momento, você pode vincular um objeto de acesso ao disco a uma rede virtual na mesma assinatura.
Posso vincular uma rede vir tual a um objeto de acesso ao disco em outra assinatura?
Não. No momento, você pode vincular um objeto de acesso ao disco a uma rede virtual na mesma assinatura.
Quantas expor tações ou impor tações usando o mesmo objeto de acesso ao disco podem ocorrer
ao mesmo tempo?
5
Posso usar um URI de SAS de um disco/instantâneo para baixar o VHD subjacente de uma VM na
mesma sub-rede que a sub-rede do ponto de extremidade privado associado ao disco?
Sim.
Posso usar um URI de SAS de um disco/instantâneo para baixar o VHD subjacente de uma VM que
não está na mesma sub-rede que a sub-rede do ponto de extremidade privado não associado ao
disco?
Não.
E se dúvida não foi respondida aqui?

Se sua pergunta não estiver listada aqui, fale conosco e nós ajudaremos a encontrar uma resposta. Você pode
postar uma pergunta no final deste artigo nos comentários. Para se envolver com a equipe de armazenamento
do Azure e outros membros da Comunidade sobre este artigo, use o Microsoft Q&uma página de perguntas
para o armazenamento do Azure.
Para solicitar recursos, envie suas solicitações e ideias para o Fórum de comentários do Armazenamento do
Azure.
Redes virtuais e máquinas virtuais no Azure
Ao criar uma VM (máquina virtual) do Azure, você deve criar uma VNet (rede virtual) ou usar uma VNet
existente. Você também precisa decidir como suas VMs devem ser acessadas na VNet. É importante planejar
antes de criar recursos e compreender os limites de recursos de rede.
Na figura a seguir, as VMs são representadas como servidores Web e servidores de banco de dados. Cada
conjunto de VMs é atribuído a sub-redes separadas na VNet.
Você pode criar uma rede virtual antes de criar uma máquina virtual ou pode criar uma máquina virtual. Você
cria esses recursos para dar suporte à comunicação com uma VM:
Interfaces de rede
Endereços IP
Rede virtual e sub-redes
Além desses recursos básicos, você também deve considerar estes recursos opcionais:
Balanceadores de carga
Interfaces de rede
Uma NIC (interface de rede) é a interconexão entre uma VM e uma VNet (rede virtual). Uma VM deve ter pelo
menos uma NIC, mas pode ter mais de uma, dependendo do tamanho da VM que você criar. Saiba mais sobre
quantas NICs cada tamanho de VM dá suporte, consulte tamanhos de VM.
Você pode criar uma VM com várias placas de rede e, em seguida, adicionar ou remover NICs por meio do ciclo
de vida de uma VM. Várias NICs permitem que uma máquina virtual se conecte a várias sub-redes e envie ou
receba tráfego na interface mais apropriada. VMs com qualquer número de interfaces de rede podem existir no
mesmo conjunto de disponibilidade, até o número suportado pelo tamanho da VM.
Cada NIC conectada a uma VM deve existir no mesmo local e assinatura que a VM. Cada NIC deve ser conectada
a uma VNet que existe na mesma localização e assinatura do Azure que a NIC. Você pode alterar a sub-rede à
qual uma VM está conectada depois de criá-la, mas não é possível alterar a rede virtual. Um endereço MAC é
atribuído a cada NIC conectada a uma VM e ele não é alterado até que a VM seja excluída.
Esta tabela lista os métodos que você pode usar para criar uma interface de rede.
Portal do Azure Quando você cria uma VM no portal do Azure, uma

interface de rede é criada automaticamente para você (não é
possível usar uma NIC que você cria separadamente). O
portal cria uma VM com apenas uma NIC. Se quiser criar
uma VM com mais de uma NIC, você deverá criá-la com um
método diferente.
PowerShell do Azure Use New-AzNetworkInterface com o parâmetro -

PublicIpAddressId para fornecer o identificador do
endereço IP público que você criou anteriormente.
CLI do Azure Para fornecer o identificador do endereço IP público que

você criou anteriormente, use az network nic create com o
parâmetro --public-ip-address .
Modelo Use Interface de rede em uma rede Virtual com endereço IP

público como um guia para a implantação de uma interface
de rede usando um modelo.
Endereços IP
Você pode atribuir estes tipos de endereços IP a uma NIC no Azure:
Endereços IP públicos - usados para comunicação de entrada e saída (sem NAT (conversão de endereços
de rede)) com a Internet e outros recursos do Azure não conectados a uma VNet. Atribuir um endereço IP
público a uma NIC é opcional. Os endereços IP públicos têm um custo nominal, e há um número máximo
que pode ser usado por assinatura.
Endereços IP privados - usados para comunicação em uma VNet, sua rede local e a Internet (com NAT).
Você deve atribuir pelo menos um endereço IP privado a uma VM. Para saber mais sobre NAT no Azure, leia
Noções básicas sobre conexões de saída no Azure.
Você pode atribuir endereços IP públicos a VMs ou balanceadores de carga voltados para a Internet. Você pode
atribuir endereços IP a VMs e balanceadores de carga internos. Você atribui endereços IP a uma VM usando
uma interface de rede.
Há dois métodos de alocar um endereço IP para um recurso - dinâmico ou estático. O método de alocação
padrão é dinâmico, em que um endereço IP não é alocado quando ele é criado. Em vez disso, o endereço IP é
alocado quando você cria uma VM ou inicia uma VM parada. O endereço IP é liberado quando você para ou
exclui a VM.
Para garantir que o endereço IP para a VM permaneça o mesmo, você pode definir o método de alocação
explicitamente como estático. Nesse caso, um endereço IP é atribuído imediatamente. Ele é liberado apenas
quando você exclui a VM ou altera seu método de alocação para dinâmico.
Esta tabela lista os métodos que você pode usar para criar um endereço IP.
Azure portal Por padrão, endereços IP públicos são dinâmicos, e o

endereço associado a eles pode ser alterado quando a VM é
parada ou excluída. Para assegurar que a VM sempre use o
mesmo endereço IP público, crie um endereço IP público
estático. Por padrão, o portal atribui um endereço IP privado
dinâmico a uma NIC ao criar uma VM. Você pode alterar
esse endereço IP para estático após a criação da VM.
PowerShell do Azure Você usa New-AzPublicIpAddress com o parâmetro -

AllocationMethod como Dinâmico ou Estático.
CLI do Azure Você usa az network public-ip create com o parâmetro --

allocation-method como Dinâmico ou Estático.
Modelo Use Interface de rede em uma rede Virtual com endereço IP

público como um guia para implantar um IP público de
endereço usando um modelo.
Após criar um endereço IP público, você pode associá-lo a uma VM, atribuindo-o a uma NIC.
Rede virtual e sub-redes

Uma sub-rede é um intervalo de endereços IP na rede virtual. Você pode dividir a VNet em várias sub-redes
para fins de organização e segurança. Cada NIC em uma VM está conectada a uma sub-rede em uma VNet.
NICs conectadas às sub-redes (iguais ou diferentes) em uma VNet podem se comunicar entre si sem nenhuma
configuração adicional.
Ao configurar uma rede virtual, você pode especificar a topologia, incluindo os espaços de endereço e sub-redes
disponíveis. Se a VNet is precisar ser conectada a outras VNets ou redes locais, você deverá selecionar
intervalos de endereços que não se sobreponham. Os endereços IP são privados e não podem ser acessados
pela Internet, o que era verdadeiro apenas para os endereços IP não roteáveis, como 10.0.0.0/8, 172.16.0.0/12
ou 192.168.0.0/16. Agora, o Azure trata qualquer intervalo de endereços como parte do espaço de endereço IP
VNet particular que está acessível apenas através da VNet, em VNets interconectadas e do seu local.
Se trabalha em uma organização em que outra pessoa é responsável por redes internas, você deve conversar
com essa pessoa antes de selecionar o espaço de endereço. Verifique se não há sobreposição e informe o
espaço que deseja usar para que eles não tentem usar o mesmo intervalo de endereços IP.
Por padrão, não há limite de segurança entre sub-redes. Portanto, as VMs em cada uma das sub-redes podem
se comunicar entre si. No entanto, você pode configurar NSGs (Grupos de Segurança de Rede), que permitem
controlar o fluxo de tráfego de e para sub-redes e de e para VMs.
Esta tabela lista os métodos que você pode usar para criar uma VNet e sub-redes.
Azure portal Se você permitir que o Azure crie uma VNet quando você
criar uma VM, o nome será uma combinação do nome do
grupo de recursos que contém a VNet e -vnet . O espaço de
endereço é 10.0.0.0/24, o nome da sub-rede necessária é
default e o intervalo de endereços de sub-rede é
10.0.0.0/24.
PowerShell do Azure Você usa New-AzVirtualNetworkSubnetConfig e New-

AzVirtualNetwork para criar uma sub-rede e uma VNet. Você
também pode usar Add-AzVirtualNetworkSubnetConfig
para adicionar uma sub-rede a uma rede virtual existente.
CLI do Azure A sub-rede e a VNet são criadas ao mesmo tempo. Forneça

um parâmetro --subnet-name para az network vnet create
com o nome da sub-rede.
Modelo A maneira mais fácil de criar uma VNet e sub-redes é fazer o

download de um modelo existente, como Rede Virtual com
duas sub-redes, e modificá-lo de acordo com suas
necessidades.

Um NSG (grupo de segurança de rede) contém uma lista de regras de ACL (Lista de Controle de Acesso) que
permitem ou negam o tráfego de rede para sub-redes, NICs ou ambos. Os NSGs podem ser associados a sub-
redes ou NICs individuais conectadas a uma sub-rede. Quando um NSG é associado a uma sub-rede, as regras
de ACL se aplicam a todas as VMs na sub-rede. Além disso, o tráfego para uma NIC individual pode ser
restringido associando um NSG diretamente a uma NIC.
Os NSGs contêm dois conjuntos de regras: entrada e saída. A prioridade de uma regra deve ser exclusiva em
cada conjunto. Cada regra tem propriedades de protocolo, origem e intervalos de porta de destino, prefixos de
endereço, direção de tráfego, prioridade e tipo de acesso.
Quando um NSG é associado a uma NIC, as regras de acesso à rede no NSG são aplicadas somente a essa NIC.
Se um NSG for aplicado a uma única NIC em uma VM com várias NICS, isso não afetará o tráfego para as
outras NICs. É possível associar diferentes NSGs a um NIC (ou VM, dependendo do modelo de implantação) e à
sub-rede a qual uma NIC ou VM está associada. A prioridade é fornecida com base na direção do tráfego.
Não se esqueça de planejar seus NSGs ao planejar suas VMs e a VNet.
Esta tabela lista os métodos que você pode usar para criar um grupo de segurança de rede.
Azure portal Quando você cria uma VM no portal do Azure, um NSG é

criado e associado automaticamente à NIC que o portal cria.
O nome do NSG é uma combinação do nome da VM e -
nsg . Este NSG contém uma regra de entrada com uma
prioridade de 1000, o serviço definido como RDP, o
protocolo definido como TCP, a porta configurada para 3389
e as ações definidas para Permitir. Se quiser permitir qualquer
outro tráfego de entrada para a VM, você deverá incluir
regras adicionais para o NSG.
PowerShell do Azure Use New-AzNetworkSecurityRuleConfig e forneça as

informações de regra necessárias. Use New-
AzNetworkSecurityGroup para criar o NSG. Use Set-
AzVirtualNetworkSubnetConfig para configurar o NSG da
sub-rede. Use Set-AzVirtualNetwork para adicionar o NSG à
rede virtual.
CLI do Azure Use az network nsg create para criar inicialmente o NSG. Use
az network nsg rule create para adicionar regras para o NSG.
Use az network vnet subnet update para adicionar o NSG à
sub-rede.
Modelo Use Criar um grupo de segurança de rede como um guia

para a implantação de um grupo de segurança de rede
usando um modelo.
Balanceadores de carga
O Azure Load Balancer oferece alta disponibilidade e desempenho de rede para seus aplicativos. Um
balanceador de carga pode ser configurado para equilibrar o tráfego da Internet para VMs ou equilibrar o
tráfego entre VMs em uma rede virtual. Um balanceador de carga também pode equilibrar o tráfego entre
computadores locais e VMs em uma rede entre locais ou encaminhar tráfego externo para uma VM específica.
O balanceador de carga mapeia o tráfego de entrada e saída entre o endereço IP público e a porta do
balanceador de carga e o endereço IP privado e a porta da VM.
Ao criar um balanceador de carga, você também deve considerar estes elementos de configuração:
Configuração de IP front-end – um balanceador de carga pode incluir um ou mais endereços IP front-
end. Esses endereços IP servem como entrada para o tráfego.
Pool de endereços de back-end – endereços IP que estão associados à NIC para a qual a carga é
distribuída.
Encaminhamento de por ta – define como o tráfego de entrada flui pelo IP de front-end e é distribuído
para o IP de back-end usando regras NAT de entrada.
Regras do balanceador de carga -mapeia determinada combinação de porta e IP front-end para um
conjunto de endereços IP back-end e combinação de portas. Um balanceador de carga único pode ter várias
regras de balanceamento de carga. Cada regra é uma combinação de um IP de front-end e IP de porta e
back-end e porta associada a VMs.
Sondas - monitora a integridade das VMs. Quando uma investigação não responde, o balanceador de carga
interrompe o envio de novas conexões para a VM não íntegra. As conexões existentes não são afetadas e
novas conexões são enviadas para VMs íntegras.
Regras de saída – uma regra de saída configura a NAT (conversão de endereços de rede) de saída para
todas as máquinas virtuais identificadas pelo pool de back-end do Standard Load Balancer a serem
convertidas no front-end.
Esta tabela lista os métodos que você pode usar para criar um balanceador de carga voltado para a Internet.
Portal do Azure Você pode balancear a carga de tráfego de Internet para

VMs que estejam usando o portal do Azure.
PowerShell do Azure Para fornecer o identificador do endereço IP público que

você criou anteriormente, use New-
AzLoadBalancerFrontendIpConfig com o parâmetro -
PublicIpAddress . Use New-
AzLoadBalancerBackendAddressPoolConfig para criar a
configuração do pool de endereços de back-end. Use New-
AzLoadBalancerInboundNatRuleConfig para criar regras NAT
de entrada associadas à configuração de IP front-end que
você criou. Use New-AzLoadBalancerProbeConfig para criar
os testes de que você precisa. Use New-
AzLoadBalancerRuleConfig para criar a configuração de
balanceador de carga. Use New-AzLoadBalancer para criar o
CLI do Azure Use az network lb create para criar a configuração de

balanceador de carga inicial. Use az network lb frontend-ip
create para adicionar o endereço IP público que você criou
anteriormente. Use az network lb address-pool create para
adicionar a configuração do pool de endereços de back-end.
Use az network lb inbound-nat-rule create para adicionar
regras de NAT. Use az network lb rule create para adicionar
as regras do balanceador de carga. Use az network lb probe
create para adicionar as sondas.
Modelo Use 3 VMs em um Load Balancer como um guia para

implantar um balanceador de carga usando um modelo.
Esta tabela lista os métodos que você pode usar para criar um balanceador de carga interno.
Portal do Azure É possível balancear carga de tráfego interna com um

balanceador de carga no portal do Azure.
PowerShell do Azure Para fornecer um endereço IP privado na sub-rede, use

New-AzLoadBalancerFrontendIpConfig com o parâmetro -
PrivateIpAddress . Use New-
AzLoadBalancerBackendAddressPoolConfig para criar a
configuração do pool de endereços de back-end. Use New-
AzLoadBalancerInboundNatRuleConfig para criar regras NAT
de entrada associadas à configuração de IP front-end que
você criou. Use New-AzLoadBalancerProbeConfig para criar
os testes de que você precisa. Use New-
AzLoadBalancerRuleConfig para criar a configuração de
balanceador de carga. Use New-AzLoadBalancer para criar o
CLI do Azure Use o comando az network lb create para criar a

configuração de balanceador de carga inicial. Para definir o
endereço IP privado, use az network lb frontend-ip create
com o parâmetro --private-ip-address . Use az network lb
address-pool create para adicionar a configuração do pool
de endereços de back-end. Use az network lb inbound-nat-
rule create para adicionar regras de NAT. Use az network lb
rule create para adicionar as regras do balanceador de carga.
Use az network lb probe create para adicionar as sondas.
Modelo Use duas VMs em um Load Balancer como um guia para

implantar um balanceador de carga usando um modelo.
conjuntos de escala de máquina virtual

Para obter mais informações sobre o balanceador de carga e conjuntos de dimensionamento de máquinas
virtuais, confira Rede para conjuntos de dimensionamento de máquinas virtuais do Azure.
VMs
As VMs podem ser criadas na mesma VNet e podem se conectar entre si usando endereços IP privados. Eles
podem se conectar mesmo que estejam em sub-redes diferentes, sem a necessidade de configurar um gateway
ou usar endereços IP públicos. Para colocar as VMs em uma rede virtual, crie a rede virtual e, ao criar cada VM,
atribua-a à VNet e à sub-rede. As VMs adquirem suas configurações de rede durante a implantação ou a
inicialização.
Um endereço IP é atribuído às VMs quando elas são implantadas. Se você implantar várias VMs em uma rede
virtual ou sub-rede, endereços IP serão atribuídos quando elas forem inicializadas. Você também pode alocar
um IP estático para uma VM. Se você alocar um IP estático, considere usar uma sub-rede específica para evitar a
reutilização acidental de um IP estático para outra VM.
Se você criar uma VM e, depois, quiser migrá-la para uma rede virtual, essa não será uma alteração simples na
configuração. Você deve reimplantar a VM na VNet. A maneira mais fácil der reimplantar é excluir a VM, mas
não os discos anexados a ela e, em seguida, recriar a VM usando os discos originais na VNet.
Esta tabela lista os métodos que você pode usar para criar uma VM em uma VNet.
Azure portal Usa as configurações de rede padrão mencionadas

anteriormente para criar uma VM com uma única NIC. Para
criar uma VM com várias NICs, você deve usar um método
diferente.
PowerShell do Azure Inclui o uso de Add-AzVMNetworkInterface para adicionar o

NIC que você criou anteriormente para a configuração da
VM.
CLI do Azure Crie e conecte a uma VM para uma rede virtual, sub-rede e
NIC criar como etapas individuais.
Modelo Use Implantação muito simples de uma VM do Windows

como um guia para implantar uma VM usando um modelo.
Próximas etapas
Para etapas de VM específicas sobre como gerenciar redes virtuais do Azure para máquinas virtuais, veja os
tutoriais do Windows ou Linux.
Também existem tutoriais sobre como balancear a carga de VMs e criar aplicativos altamente disponíveis para
Windows ou Linux.
Saiba como configurar rotas definidas pelo usuário e encaminhamento IP.
Saiba como configurar conexões de VNet para VNet.
Saiba como Solucionar problemas de rotas.
Saiba mais sobre largura de banda de rede da máquina virtual.
Início Rápido: Criar uma rede virtual usando a CLI
do Azure
Uma rede virtual permite que recursos do Azure, como VMs (máquinas virtuais), comuniquem-se em modo
privado e com a Internet. Neste início rápido, você aprende como criar uma rede virtual. Após criar uma rede
virtual, você implantará duas VMs na rede virtual. Você fará a conexão com as VMs usando a Internet e se
comunicará de modo privado na nova rede virtual.
Pré-requisitos
Caso não tenha uma assinatura do Azure, crie uma conta gratuita agora.





Se você optar por instalar e usar a CLI do Azure localmente, este guia de início rápido exigirá a versão 2.0.28 ou
posterior da CLI do Azure. Execute az --version para localizar a versão instalada. Para informações sobre como
instalar ou atualizar, confira Instalar a CLI do Azure.
Crie um grupo de recursos e uma rede virtual

Antes de poder criar uma rede virtual, você deverá criar um grupo de recursos para hospedá-la. Crie um grupo
de recursos com az group create. Este exemplo cria um grupo de recursos chamado myResourceGroup na
região eastus:
Crie a rede virtual com az network vnet create. O exemplo cria uma rede virtual padrão nomeada
myVirtualNetwork com uma sub-rede nomeada padrão:

--name myVirtualNetwork \
--subnet-name default

Crie duas VMs na rede virtual.
Criar a primeira VM
Crie uma VM com az vm create. Se as chaves SSH ainda não existirem em uma localização de chave padrão, o
comando as criará. Para usar um conjunto específico de chaves, use a opção --ssh-key-value . A opção
--no-wait cria a VM em segundo plano para que você possa prosseguir para a próxima etapa. O exemplo a
seguir cria uma VM nomeada myVm1:
az vm create \
--name myVm1 \
--image UbuntuLTS \
--no-wait
Criar a segunda VM
Como você usou a opção --no-wait na etapa anterior, poderá seguir e criar a segunda VM chamada myVm2.
az vm create \
--name myVm2 \
--image UbuntuLTS \
--generate-ssh-keys
Mensagem de saída da CLI do Azure

As VMs podem levar alguns minutos para serem criadas. Depois que o Azure cria as VMs, a CLI do Azure
retorna uma saída como esta:
{
"fqdns": "",
000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVm2",
"macAddress": "00-0D-3A-23-9A-49",
"zones": ""
}
Anote o publicIpAddress . Você usará esse endereço para conectar-se à VM pela Internet na próxima etapa.
Conecte uma VM a partir da Internet

Neste comando, substitua <publicIpAddress> pelo endereço IP público da VM myVm2:
Comunicação entre VMs

Para confirmar a comunicação privada entre as VMs myVm2 e myVm1, insira este comando:
ping myVm1 -c 4
Quatro respostas serão recebidas de 10.0.0.4.

Encerre a sessão SSH com a VM myVm2.
Limpar os recursos
Quando não for mais necessário, você poderá usar az group delete para remover o grupo de recursos e todos
os recursos que ele contém:
az group delete --name myResourceGroup --yes
Próximas etapas
Neste início rápido, você criou uma rede virtual padrão e duas VMs. Você se conectou a uma VM pela Internet e
executou uma comunicação entre duas VMs em modo privado. O Azure permite comunicação privada irrestrita
entre VMs. Por padrão, ele só permite conexões de área de trabalho remota de entrada para VMs do Windows
da Internet. Prossiga para o próximo artigo para aprender a configurar diferentes tipos de comunicações de
rede de VMs:
Filtrar tráfego de rede
Abrir portas e pontos de extremidade para uma VM
com o CLI do Azure
No Azure, você abre uma porta, ou cria um ponto de extremidade, para uma VM (máquina virtual) criando um
filtro de rede ou uma sub-rede ou interface de rede de VM. Coloque os filtros, que controlam o tráfego de
entrada e saída, em um Grupo de Segurança de Rede anexado ao recurso que recebe o tráfego. Vamos usar um
exemplo comum de tráfego da Web na porta 80. Este artigo mostra como abrir uma porta para uma VM
Para criar regras e um Grupo de Segurança de Rede, é necessário ter a última CLI do Azure instalada e
conectada a uma conta do Azure usando az login.
parâmetro de exemplo incluem myResourceGroup, myNetworkSecurityGroup e myVnet.
Abrir uma porta rapidamente para uma máquina virtual

Se você precisar abrir uma porta rapidamente para uma máquina virtual em um cenário de
desenvolvimento/teste, você pode usar o comando az vm open-port. Este comando cria um Grupo de
Segurança de Rede, adiciona uma regra e a aplica a uma VM ou sub-rede. O exemplo a seguir abre a porta 80
na VM chamada myVM no grupo de recursos chamado myResourceGroup.
az vm open-port --resource-group myResourceGroup --name myVM --port 80
Para obter mais controle sobre as regras, como a definição de um intervalo de endereços IP de origem, continue
com as etapas adicionais neste artigo.
Criar um Grupo de Segurança de Rede e suas regras

Crie o grupo de segurança de rede com az network nsg create. O exemplo a seguir cria um grupo de segurança
de rede chamado myNetworkSecurityGroup no local eastus :

--location eastus \
Adicione uma regra com az network nsg rule create para permitir o tráfego HTTP para o servidor Web (ou faça
ajustes para seu próprio cenário, como acesso ao SSH ou conectividade de banco de dados). O exemplo a seguir
cria uma regra chamada myNetworkSecurityGroupRule para permitir o tráfego TCP na porta 80:

--name myNetworkSecurityGroupRule \
--protocol tcp \
--priority 1000 \
Aplicar o Grupo de Segurança de Rede à VM
Associe o Grupo de Segurança de Rede à NIC (adaptador de rede) da VM com az network nic update. O exemplo
a seguir associa uma NIC existente chamada myNic ao Grupo de Segurança de Rede chamado
myNetworkSecurityGroup:
az network nic update \

--name myNic \
Como alternativa, você pode associar o Grupo de Segurança de Rede a uma sub-rede de uma rede virtual com
az network vnet subnet update em vez de apenas ao adaptador de rede em uma única VM. O exemplo a seguir
associa uma sub-rede existente chamada mySubnet na rede virtual myVnet ao Grupo de Segurança de Rede
chamado myNetworkSecurityGroup:

--name mySubnet \
Mais informações sobre os Grupos de Segurança de Rede

Os comandos rápidos aqui permitem que você coloque tudo em funcionamento com o tráfego que flui para sua
VM. Os Grupos de Segurança de Rede fornecem muitos recursos excelentes e granularidade para controlar o
acesso aos recursos. Você pode ler mais sobre a criação de um Grupo de Segurança de Rede e as regras ACL
aqui.
Para aplicativos Web altamente disponíveis, você deve colocar suas VMs atrás de um balanceador de carga do
Azure. O balanceador de carga distribui o tráfego para VMs, com um Grupo de Segurança de rede que fornece
filtragem. Para saber mais, veja Como balancear a carga de máquinas virtuais Linux no Azure para criar um
aplicativo altamente disponível.
Próximas etapas
Neste exemplo, você criou uma regra simples para permitir o tráfego HTTP. Você pode encontrar informações
sobre a criação de ambientes mais detalhados nos seguintes artigos:
Visão geral do Azure Resource Manager
O que é um Grupo de Segurança de Rede (NSG)?
Como abrir portas e pontos de extremidade para
uma VM usando o PowerShell
filtro de rede ou uma sub-rede ou adaptador de rede de VMs. Coloque os filtros, que controlam o tráfego de
entrada e de saída, em um grupo de segurança de rede anexado ao recurso que recebe o tráfego.
O exemplo neste artigo demonstra como criar um filtro de rede que usa a porta TCP 80 padrão (supõe-se que
você já iniciou os serviços adequados e abriu quaisquer regras de firewall do sistema operacional na VM).
Após criar uma VM configurada para servir solicitações da Web na porta TCP 80 padrão, é possível:
1. Crie um grupo de segurança de rede.
2. Criar uma regra de segurança de entrada que permite o tráfego e atribuir valores às seguintes
configurações:
Inter valos de por tas de destino : 80
Inter valos de por ta de origem : * (permite qualquer porta de origem)
Valor de prioridade : Insira um valor menor que 65.500 e maior em prioridade do que a regra de
entrada de negação padrão que captura tudo.
3. Associe o grupo de segurança de rede ao adaptador de rede de VMs ou à sub-rede.
Embora esse exemplo use uma regra simples para permitir o tráfego HTTP, também é possível usar regras e
grupos de segurança de rede para criar configurações de rede mais complexas.
Comandos rápidos
Para criar um Grupo de Segurança de Rede e as regras de ACL, você precisa ter a versão mais recente do Azure
PowerShell instalada. Você também pode executar essas etapas usando o Portal do Azure.
Faça logon na sua Conta do Azure:
Connect-AzAccount
Nos exemplos a seguir, substitua os nomes de parâmetro pelos seus próprios valores. Os nomes de parâmetro
de exemplo incluem myResourceGroup , myNetworkSecurityGroup e myVnet .
Crie uma regra com New-AzNetworkSecurityRuleConfig. O exemplo a seguir cria uma regra chamada
myNetworkSecurityGroupRule para permitir o tráfego tcp na porta 80 :
$httprule = New-AzNetworkSecurityRuleConfig `
-Name "myNetworkSecurityGroupRule" `
-Description "Allow HTTP" `
-Access "Allow" `
-Protocol "Tcp" `
-Priority "100" `
-SourceAddressPrefix "Internet" `
-DestinationPortRange 80
Em seguida, crie seu Grupo de Segurança de Rede com New-AzNetworkSecurityGroup e atribua a regra de
HTTP que você acabou de criar conforme descrito a seguir. O exemplo a seguir cria um Grupo de Segurança de
Rede chamado myNetworkSecurityGroup :
-Name "myNetworkSecurityGroup" `
-SecurityRules $httprule
Agora, vamos atribuir seu Grupo de Segurança de Rede a uma sub-rede. O exemplo a seguir atribui uma rede
virtual existente chamada myVnet à variável $vnet com Get-AzVirtualNetwork:
-Name "myVnet"
Associe seu Grupo de Segurança de Rede à sub-rede com Set-AzVirtualNetworkSubnetConfig. O exemplo a

seguir associa a sub-rede chamada mySubnet ao seu Grupo de Segurança de Rede:
$subnetPrefix = $vnet.Subnets|?{$_.Name -eq 'mySubnet'}
Set-AzVirtualNetworkSubnetConfig `
-Name "mySubnet" `
-AddressPrefix $subnetPrefix.AddressPrefix `
-NetworkSecurityGroup $nsg
Por fim, atualize sua rede virtual com Set-AzVirtualNetwork para que suas alterações entrem em vigor:
Mais informações sobre os Grupos de Segurança de Rede

Os comandos rápidos aqui permitem que você coloque tudo em funcionamento com o tráfego que flui para sua
VM. Os Grupos de Segurança de Rede fornecem muitos recursos excelentes e granularidade para controlar o
acesso aos recursos. Você pode ler mais sobre a criação de um Grupo de Segurança de Rede e as regras ACL
aqui.
Para aplicativos Web altamente disponíveis, você deve colocar suas VMs atrás de um balanceador de carga do
Azure. O balanceador de carga distribui o tráfego para VMs, com um Grupo de Segurança de rede que fornece
filtragem. Para saber mais, veja Como balancear a carga de máquinas virtuais Linux no Azure para criar um
Próximas etapas
Neste exemplo, você criou uma regra simples para permitir o tráfego HTTP. Você pode encontrar informações
sobre a criação de ambientes mais detalhados nos seguintes artigos:
O que é um grupo de segurança de rede?
Visão geral do Azure Load Balancer
Como abrir portas para uma máquina virtual com o
Portal do Azure
filtro de rede ou uma sub-rede ou adaptador de rede de VMs. Coloque os filtros, que controlam o tráfego de
entrada e de saída, em um grupo de segurança de rede anexado ao recurso que recebe o tráfego.
O exemplo neste artigo demonstra como criar um filtro de rede que usa a porta TCP 80 padrão (supõe-se que
você já iniciou os serviços adequados e abriu quaisquer regras de firewall do sistema operacional na VM).
Após criar uma VM configurada para servir solicitações da Web na porta TCP 80 padrão, é possível:
1. Crie um grupo de segurança de rede.
2. Criar uma regra de segurança de entrada que permite o tráfego e atribuir valores às seguintes
configurações:
Inter valos de por tas de destino : 80
Inter valos de por ta de origem : * (permite qualquer porta de origem)
Valor de prioridade : Insira um valor menor que 65.500 e maior em prioridade do que a regra de
entrada de negação padrão que captura tudo.
3. Associe o grupo de segurança de rede ao adaptador de rede de VMs ou à sub-rede.
Embora esse exemplo use uma regra simples para permitir o tráfego HTTP, também é possível usar regras e
grupos de segurança de rede para criar configurações de rede mais complexas.
Entrar no Azure
Entre no Portal do Azure em https://portal.azure.com.

1. Pesquise e selecione o grupo de recursos para a VM, escolha Adicionar e, em seguida, pesquise e
selecione Grupo de segurança de rede .
A janela Criar grupo de segurança de rede é aberta.
3. Insira um nome para o grupo de segurança de rede.
4. Selecione ou crie um grupo de recursos e, então, selecione um local.
5. Selecione Criar para criar o grupo de segurança de rede.
Criar uma regra de segurança de entrada

1. Selecione o novo Grupo de Segurança de Rede.
2. Selecione Regras de segurança de entrada no menu à esquerda e, então, selecione Adicionar .
3. Na página Adicionar uma regra de segurança de entrada , alterne para Avançado de Básico na
parte superior da página.
4. Escolha um Ser viço comum no menu suspenso, como HTTP . Você também poderá selecionar
Personalizado caso queira fornecer uma porta específica a ser usada.
5. Como alternativa, altere a Prioridade ou o Nome . A prioridade afeta a ordem na qual as regras são
aplicadas: quanto menor for o valor numérico, mais cedo a regra será aplicada.
6. Selecione Adicionar para criar a regra.
Associe seu grupo de segurança de rede à sua sub-rede

A etapa final é associar o grupo de segurança de rede com uma sub-rede ou uma interface de rede específica.
Neste exemplo, associaremos o grupo de segurança de rede a uma sub-rede.
1. Selecione Sub-redes no menu esquerdo e selecione Associar .
2. Selecione sua rede virtual e selecione a sub-rede apropriada.
3. Quando terminar, selecione OK .
Informações adicionais
Você também pode executar as etapas neste artigo usando o Azure PowerShell.
Os comandos descritos neste artigo permitem que você rapidamente obtenha tráfego para sua VM. Os Grupos
de Segurança de Rede fornecem muitos recursos excelentes e granularidade para controlar o acesso aos
recursos. Para obter mais informações, consulte Filtrar o tráfego de rede com grupos de segurança de rede.
Para aplicativos Web altamente disponíveis, considere colocar suas VMs atrás do Azure Load Balancer. O
balanceador de carga distribui o tráfego para VMs, com um Grupo de Segurança de rede que fornece filtragem.
Para obter mais informações, veja Balancear carga de máquinas virtuais do Windows no Azure para criar um
Próximas etapas
Neste artigo, você criou um grupo de segurança de rede, criou uma regra de entrada que permite o tráfego
HTTP na porta 80 e, então, associou essa regra a uma sub-rede.
Você pode encontrar informações sobre a criação de ambientes mais detalhados nos seguintes artigos:
Grupos de segurança
Crie uma máquina virtual com um endereço IP
público estático usando a CLI do Azure
Você pode criar uma máquina virtual com um endereço IP público estático. Um endereço IP público permite que
você se comunique com uma máquina virtual pela Internet. Atribua um endereço IP público estático, em vez de
um endereço dinâmico, para garantir que o endereço nunca seja alterado. Saiba mais sobre os endereços IP
públicos estáticos. Para alterar um endereço IP público atribuído a uma máquina virtual existente de dinâmico
para estático, ou para trabalhar com endereços IP, consulte adicionar, alterar ou remover endereços IP.
Endereços IP públicos têm carga nominal, e há um limite para o número de endereços IP públicos que você
pode usar por assinatura.

Você pode concluir as etapas a seguir no seu computador local ou usando o Shell de Nuvem do Azure. Para usar
seu computador local, verifique se você tem o CLI do Azure instalado. Para usar o Azure Cloud Shell, selecione
Experimente no canto superior direito de qualquer caixa de comando a seguir. O Cloud Shell entrará no Azure.
1. Se usar o Cloud Shell, vá para a etapa 2. Abra uma sessão de comando e entre no Azure com az login .
2. Crie um grupo de recursos com o comando az group create. O exemplo a seguir cria um grupo de
recursos na região Leste do Azure dos EUA:
3. Crie uma máquina virtual com o comando az vm create. O --public-ip-address-allocation=static opção

atribui um endereço IP público estático para a máquina virtual. O exemplo a seguir cria uma máquina
virtual Ubuntu com um endereço IP público SKU estático e básico chamado myPublicIpAddress:
az vm create \
--name myVM \
--image UbuntuLTS \
--public-ip-address myPublicIpAddress \
--public-ip-address-allocation static
Se o endereço IP público precisar ser um SKU padrão, adicione --public-ip-sku Standard ao comando
anterior. Saiba mais sobre SKUs de endereço IP público. Se a máquina virtual for adicionada ao pool de
back-end de um Azure Load Balancer público, o SKU do endereço IP público da máquina virtual deverá
corresponder ao SKU do endereço IP público do balanceador de carga. Para obter detalhes, consulte
balanceador de carga do Azure.
4. Visualize o endereço IP público atribuído e confirme se ele foi criado como um endereço SKU estático
básico, com az network public-ip show:
--name myPublicIpAddress \
--query [ipAddress,publicIpAllocationMethod,sku] \
--output table
O Azure atribuiu um endereço IP público dos endereços usados na região na qual você criou a máquina
virtual. Você pode baixar a lista de intervalos (prefixos) para as nuvens pública, do governo dos EUA, da
China e da Alemanha do Azure.
WARNING
Não modifique as configurações do endereço IP no sistema operacional da máquina virtual. O sistema operacional fica
ciente dos endereços IP públicos do Azure. Embora você possa adicionar configurações de endereço IP privado ao sistema
operacional, recomendamos não fazê-lo, a menos que seja necessário, e somente depois de ler Adicionar um endereço IP
privado a um sistema operacional.
Limpar os recursos
Quando não for mais necessário, você poderá usar az group delete para remover o grupo de recursos e todos
os recursos que ele contém:
az group delete --name myResourceGroup --yes
Próximas etapas
Saiba mais sobre endereços IP públicos no Azure
Saiba mais sobre todas as configurações de endereço IP público
Saiba mais sobre endereços IP privados e atribuir uma endereço IP privado estático para uma máquina
virtual do Azure
Saiba mais sobre como criar Linux e Windows máquinas virtuais
Como criar uma máquina virtual Linux no Azure
com várias placas de adaptador de rede
Este artigo fornece detalhes sobre como criar uma VM com várias NICs com a CLI do Azure.
Criar recursos de suporte

Instale a CLI do Azure mais recente do Azure e faça logon em uma conta do Azure usando az login.
parâmetro de exemplo incluem myResourceGroup, mystorageaccount e myVM.
Primeiro, crie um grupo de recursos com az group create. O exemplo a seguir cria um grupo de recursos
Crie a rede virtual com az network vnet create. O exemplo a seguir cria uma rede virtual chamada myVnet e
uma sub-rede chamada mySubnetFrontEnd:

--name myVnet \
--address-prefix 10.0.0.0/16 \
--subnet-name mySubnetFrontEnd \
Crie uma sub-rede para o tráfego de back-end com az network vnet subnet create. O exemplo a seguir cria uma
sub-rede chamada mySubnetBackEnd:
az network vnet subnet create \

--name mySubnetBackEnd \
--address-prefix 10.0.2.0/24
Crie um grupo de segurança de rede com az network nsg create. O exemplo a seguir cria um grupo de
segurança de rede denominado myNetworkSecurityGroup:

Criar e configurar várias NICs

Crie duas NICs com az network nic create. O exemplo a seguir cria duas NICs, chamadas myNic1 e myNic2,
conectadas ao Grupo de Segurança de Rede, com uma NIC se conectando a cada sub-rede:
--name myNic1 \
--subnet mySubnetFrontEnd \
--name myNic2 \
--subnet mySubnetBackEnd \
Criar uma VM e conectar as NICs

Quando você criar a VM, especifica as NICs que criou com --nics . Você também precisa tomar cuidado ao
selecionar o tamanho da VM. Há limites para o número total de NICs que podem ser adicionados a uma VM.
Leia mais sobre Tamanhos de VM Linux.
Crie uma VM com az vm create. O exemplo a seguir cria uma VM chamada myVM:
az vm create \
--name myVM \
--image UbuntuLTS \
--nics myNic1 myNic2
Adicione tabelas de roteamento ao SO convidado concluindo as etapas em Configure o SO convidado para

várias NICs.
Adicionar uma NIC a uma VM

As etapas anteriores criaram uma VM com várias NICs. Também é possível adicionar NICs a uma VM existente
com a CLI do Azure. Diferentes tamanhos de VM dão suporte a um número variável de NICs, sendo assim,
dimensione sua VM adequadamente. Se necessário, é possível redimensionar uma VM.
Crie outra NIC com az network nic create. O exemplo a seguir cria uma NIC chamada myNic3 conectada à sub-
rede de back-end e ao Grupo de Segurança de Rede criado nas etapas anteriores:

--name myNic3 \
--subnet mySubnetBackEnd \
Para adicionar uma NIC a uma VM existente, primeiro desaloque a VM com az vm deallocate. O exemplo a
seguir desaloca a VM chamada myVM:
Adicione a NIC com az vm nic add. O exemplo a seguir adiciona myNic3 à myVM:
az vm nic add \
--vm-name myVM \
--nics myNic3
Inicie a VM com az vm start:

várias NICs.
Remover uma NIC de uma VM

Para remover uma NIC de uma VM existente, primeiro desaloque a VM com az vm deallocate. O exemplo a
seguir desaloca a VM chamada myVM:
Remova a NIC com az vm nic remove. O exemplo a seguir remove myNic3 de myVM:
az vm nic remove \
--vm-name myVM \
--nics myNic3
Inicie a VM com az vm start:
Criar várias NICs usando modelos do Resource Manager

Os modelos do Azure Resource Manager usam arquivos JSON declarativos para definir o seu ambiente. Você
pode ler uma visão geral do Azure Resource Manager. Os modelos do Gerenciador de Recursos oferecem uma
maneira de criar várias instâncias de um recurso durante a implantação, como a criação de várias NICs. Você usa
copiar para especificar o número de instâncias a serem criadas:
"copy": {
"name": "multiplenics"
"count": "[parameters('count')]"
}
Leia mais sobre a criação de várias instâncias usando copiar.

Você também pode usar um copyIndex() para, em seguida, acrescentar um número a um nome de recurso, que
permite criar myNic1 , myNic2 , etc. Veja a seguir um exemplo de acréscimo do valor de índice:
"name": "[concat('myNic', copyIndex())]",
Você pode ler um exemplo completo em Criando várias NICs usando modelos do Gerenciador de Recursos.
várias NICs.
Configurar o SO convidado para várias NICs

As etapas anteriores criaram uma rede virtual e uma sub-rede, conectaram adaptadores de rede e, em seguida,
criaram uma VM. Um endereço IP público e regras de grupo de segurança de rede que permitem tráfego SSH
não foram criados. Para configurar o SO convidado para vários adaptadores de rede, é necessário permitir
conexões remotas e executar comandos localmente na VM.
Para permitir tráfego SSH, crie uma regra de grupo de segurança de rede com az network nsg rule create,
conforme a seguir:

--name allow_ssh \
--priority 101 \
--destination-port-ranges 22
Crie um endereço IP público com az network public-ip create e atribua-o ao primeiro adaptador de rede com az
network nic ip-config update:
az network public-ip create --resource-group myResourceGroup --name myPublicIP
az network nic ip-config update \

--nic-name myNic1 \
--name ipconfig1 \
--public-ip myPublicIP
Para exibir o endereço IP público da VM, use az vm show, conforme a seguir:
az vm show --resource-group myResourceGroup --name myVM -d --query publicIps -o tsv
Exemplo de SSH para o endereço IP público da VM. O nome de usuário padrão fornecido em uma etapa anterior
era azureuser. Forneça seu próprio nome de usuário e endereço IP público:
Para enviar para ou de um adaptador de rede secundário, é necessário adicionar manualmente rotas
persistentes ao sistema operacional para cada adaptador de rede secundário. Neste artigo, eth1 é o adaptador
de rede secundário. As instruções para adicionar rotas persistentes ao sistema operacional variam de acordo
com a distribuição. Consulte a documentação da sua distribuição para obter mais instruções.
Ao adicionar a rota ao sistema operacional, o endereço do gateway será .1 para qualquer sub-rede na qual o
adaptador de rede está. Por exemplo, se o adaptador de rede tiver o endereço 10.0.2.4, o gateway especificado
para a rota será 10.0.2.1. É possível definir uma rede específica para o destino da rota ou especificar um destino
0.0.0.0, se você quiser que todo o tráfego do adaptador passe pelo gateway especificado. O gateway de cada
sub-rede é gerenciado pela rede virtual.
Após adicionar a rota para um adaptador de rede secundário, verifique se a rota está na tabela de rotas com
route -n . A saída de exemplo a seguir é para a tabela de rotas que tem as dois adaptadores de rede
adicionadas à VM neste artigo:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.1.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 10.0.2.1 0.0.0.0 UG 0 0 0 eth1
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
168.63.129.16 10.0.1.1 255.255.255.255 UGH 0 0 0 eth0
169.254.169.254 10.0.1.1 255.255.255.255 UGH 0 0 0 eth0
Confirme se a rota que você adicionou persistiu entre os reinícios, verificando a tabela de rotas novamente após
reiniciar. Para testar a conectividade, é possível inserir o comando a seguir, por exemplo, em que eth1 é o nome
de um adaptador de rede secundário:
ping bing.com -c 4 -I eth1
Próximas etapas
Examine Tamanhos de VM Linux ao tentar criar uma VM com várias NICs. Preste atenção ao número máximo de
NICs a que cada VM dá suporte.
Para proteger ainda mais as VMs, use acesso just-in-time à VM. Esse recurso abre regras de grupo de segurança
de rede para tráfego SSH quando necessário e por um período de tempo definido. Para saber mais, confira
Gerenciar o acesso à máquina virtual usando o just in time.
Cria e gerencia uma máquina virtual do Windows
que tem várias NICs
As máquinas virtuais (VMs) no Azure podem ter várias placas de interface de rede virtual (NICs) anexadas a elas.
Um cenário comum é ter sub-redes diferentes para conectividade de front-end e back-end. Você pode associar
várias NICs em uma VM para várias sub-redes, mas essas sub-redes devem residir na mesma rede virtual
(vNet). Este artigo fornece detalhes sobre como criar uma VM que tem várias NICs anexadas. Você também
aprenderá a adicionar ou remover as NICs de uma VM existente. Diferentes tamanhos de VM dão suporte a um
número variável de NICs, sendo assim, dimensione sua VM adequadamente.
Pré-requisitos
parâmetro de exemplo incluem myResourceGroup, myVnet e myVM.
Criar uma VM com diversos NICs

Em primeiro lugar, crie um grupo de recursos. O exemplo a seguir cria um grupo de recursos chamado
MyResource Group no local eastus :
Crie a rede virtual e as sub-redes

Um cenário comum é para uma rede virtual ter duas ou mais sub-redes. Uma sub-rede pode ser usada para o
tráfego de front-end, a outra para o tráfego de back-end. Para se conectar a ambas as sub-redes, você usa várias
NICs em sua VM.
1. Defina duas sub-redes de rede virtual com New-AzVirtualNetworkSubnetConfig. O exemplo a seguir
define as sub-redes, para mySubnetFrontEnd e mySubnetBackEnd:
$mySubnetFrontEnd = New-AzVirtualNetworkSubnetConfig -Name "mySubnetFrontEnd" `

-AddressPrefix "192.168.1.0/24"
$mySubnetBackEnd = New-AzVirtualNetworkSubnetConfig -Name "mySubnetBackEnd" `
-AddressPrefix "192.168.2.0/24"
2. Crie uma rede virtual e sub-redes com New-AzVirtualNetwork. O seguinte exemplo cria uma rede virtual
chamada myVnet:
$myVnet = New-AzVirtualNetwork -ResourceGroupName "myResourceGroup" `

-Location "EastUs" `
-Name "myVnet" `
-AddressPrefix "192.168.0.0/16" `
-Subnet $mySubnetFrontEnd,$mySubnetBackEnd
Crie múltiplas NICs

Crie dois adaptadores de rede com New-AzNetworkInterface. Anexe uma NIC à sub-rede de front-end e uma
NIC à sub-rede de back-end. O exemplo a seguir cria NICs, chamadas myNic1 e myNic2:
$frontEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetFrontEnd'}
$myNic1 = New-AzNetworkInterface -ResourceGroupName "myResourceGroup" `
-Name "myNic1" `
-SubnetId $frontEnd.Id
$backEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetBackEnd'}

-Name "myNic2" `
-SubnetId $backEnd.Id
Normalmente, você também criaria um grupo de segurança de rede para filtrar o tráfego de rede para a VM e
um balanceador de carga para distribuir o tráfego entre diversas VMs.
Criar a máquina virtual
Agora, comece a criar sua configuração de VM. Cada tamanho de VM tem um limite para o número total de
NICs que podem ser adicionada a uma VM. Para obter mais informações, consulte Tamanhos da VM no
Windows .
1. Defina suas credenciais de VM para a variável $cred da seguinte maneira:
2. Defina sua VM com New-AzVMConfig. O exemplo a seguir define uma VM chamada myVM e usa um
tamanho de VM que dá suporte a até duas NICs (Standard_DS3_v2):
$vmConfig = New-AzVMConfig -VMName "myVM" -VMSize "Standard_DS3_v2"
3. Crie o restante da configuração da VM com Set-AzVMOperatingSystem e Set-AzVMSourceImage. O

exemplo a seguir cria uma VM do Windows Server 2016:
$vmConfig = Set-AzVMOperatingSystem -VM $vmConfig `

-Windows `
-ComputerName "myVM" `
-Credential $cred `
-ProvisionVMAgent `
-EnableAutoUpdate
$vmConfig = Set-AzVMSourceImage -VM $vmConfig `
-PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer" `
-Skus "2016-Datacenter" `
-Version "latest"
4. Anexe os dois adaptadores de rede que você criou anteriormente com Add-AzVMNetworkInterface:
$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $myNic1.Id -Primary

$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $myNic2.Id
5. Crie sua VM com New-AzVM:
New-AzVM -VM $vmConfig -ResourceGroupName "myResourceGroup" -Location "EastUs"
6. Adicione rotas para NICs secundárias ao SO, concluindo as etapas em Configurar o sistema operacional
para várias NICs.
Adicionar uma NIC a uma VM existente
Para adicionar uma NIC virtual a uma VM existente, você desalocar a VM, adiciona a NIC virtual e inicia a VM.
Diferentes tamanhos de VM dão suporte a um número variável de NICs, sendo assim, dimensione sua VM
adequadamente. Se necessário, é possível redimensionar uma VM.
1. Desaloque a VM com Stop-AzVM. O seguinte exemplo desaloca a VM chamada myVM no
myResourceGroup:
Stop-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"
2. Obtenha a configuração existente da VM com Get-AzVm. O exemplo a seguir obtém informações sobre a
VM chamada myVM no myResourceGroup:
$vm = Get-AzVm -Name "myVM" -ResourceGroupName "myResourceGroup"
3. O exemplo a seguir cria um adaptador de rede virtual com New-AzNetworkInterface chamado myNic3
que está anexado a mySubnetBackEnd. O adaptador de rede virtual é anexado à VM chamada myVM no
myResourceGroup com Add-AzVMNetworkInterface:
# Get info for the back end subnet

$myVnet = Get-AzVirtualNetwork -Name "myVnet" -ResourceGroupName "myResourceGroup"
$backEnd = $myVnet.Subnets|?{$_.Name -eq 'mySubnetBackEnd'}
# Create a virtual NIC

-Name "myNic3" `
-SubnetId $backEnd.Id
# Get the ID of the new virtual NIC and add to VM

$nicId = (Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -Name "MyNic3").Id
Add-AzVMNetworkInterface -VM $vm -Id $nicId | Update-AzVm -ResourceGroupName "myResourceGroup"
NICs virtuais primárias

Uma das NICs em uma VM com várias NICs precisa ser primária. Se uma das NICs virtuais existentes na
VM já estiver definida como primária, você pode ignorar esta etapa. O exemplo a seguir presume que
duas NICs virtuais agora estão presentes em uma VM e você deseja adicionar a primeira NIC ( [0] )
como a primária:
# List existing NICs on the VM and find which one is primary

$vm.NetworkProfile.NetworkInterfaces
# Set NIC 0 to be primary

$vm.NetworkProfile.NetworkInterfaces[0].Primary = $true
$vm.NetworkProfile.NetworkInterfaces[1].Primary = $false
# Update the VM state in Azure

Update-AzVM -VM $vm -ResourceGroupName "myResourceGroup"
4. Inicie a VM com Start-AzVm:
Start-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM"
5. Adicione rotas para NICs secundárias ao SO, concluindo as etapas em Configurar o sistema operacional
para várias NICs.
Remover uma NIC de uma VM existente

Para remover uma NIC virtual de uma VM existente, você desaloca a VM, remove a NIC virtual e inicia a VM.
1. Desaloque a VM com Stop-AzVM. O seguinte exemplo desaloca a VM chamada myVM no
myResourceGroup:
Stop-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"
2. Obtenha a configuração existente da VM com Get-AzVm. O exemplo a seguir obtém informações sobre a
VM chamada myVM no myResourceGroup:
$vm = Get-AzVm -Name "myVM" -ResourceGroupName "myResourceGroup"
3. Obtenha informações sobre a remoção do adaptador de rede com Get-AzNetworkInterface. O seguinte

exemplo obtém informações sobre myNic3:
# List existing NICs on the VM if you need to determine NIC name

$vm.NetworkProfile.NetworkInterfaces
$nicId = (Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -Name "myNic3").Id
4. Remova o adaptador de rede com Remove-AzVMNetworkInterface e atualize a VM com Update-AzVm. O

exemplo a seguir remove myNic3 conforme obtidas pelo $nicId na etapa anterior:
Remove-AzVMNetworkInterface -VM $vm -NetworkInterfaceIDs $nicId | `

Update-AzVm -ResourceGroupName "myResourceGroup"
5. Inicie a VM com Start-AzVm:
Start-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"
Criar várias NICs com modelos

Os modelos do Azure Resource Manager oferecem uma maneira de criar várias instâncias de um recurso
durante a implantação, como a criação de várias NICs. Os modelos do Resource Manager usam arquivos JSON
declarativos para definir o seu ambiente. Para saber mais, consulte Visão geral do Azure Resource Manager.
Você usa copiar para especificar o número de instâncias a serem criadas:
"copy": {
"name": "multiplenics",
"count": "[parameters('count')]"
}
Para obter mais informações, consulte criando várias instâncias usando cópia.
Você também pode usar copyIndex() para acrescentar um número a um nome de recurso. Você pode criar
myNic1, MyNic2 e assim por diante. O código a seguir mostra um exemplo de como acrescentar o valor de
índice:
"name": "[concat('myNic', copyIndex())]",
Você pode ler um exemplo completo em criando várias NICs usando modelos do Resource Manager.
Adicione rotas para NICs secundárias ao SO, concluindo as etapas em Configurar o sistema operacional para
várias NICs.
Configurar o SO convidado para várias NICs

O Azure atribui um gateway padrão ao primeiro adaptador de rede (primário) anexado à máquina virtual. O
Azure não atribui um gateway padrão aos adaptadores de rede adicionais (secundários) anexados à máquina
virtual. Portanto, por padrão, não é possível se comunicar com os recursos fora da sub-rede na qual um
adaptador de rede secundária se encontra. Entretanto, adaptadores de rede secundários podem se comunicar
com recursos fora da sub-rede deles, embora as etapas para habilitar a comunicação sejam diferentes para os
diversos sistemas operacionais.
1. Em um prompt de comando do Windows, execute o comando route print , que retorna uma saída
semelhante à seguinte saída para uma máquina virtual com dois adaptadores de rede anexados:
===========================================================================
Interface List
3...00 0d 3a 10 92 ce ......Microsoft Hyper-V Network Adapter #3
7...00 0d 3a 10 9b 2a ......Microsoft Hyper-V Network Adapter #4
===========================================================================
Neste exemplo, o Adaptador de Rede nº 4 do Microsoft Hyper-V (interface 7) é o adaptador de rede

secundário que não tem um gateway padrão atribuído a ele.
2. Em um prompt de comando, execute o comando ipconfig para ver qual endereço IP é atribuído ao
adaptador de rede secundário. Neste exemplo, 192.168.2.4 está atribuído à interface 7. Nenhum
endereço de gateway padrão é retornado para o adaptador de rede secundário.
3. Para rotear todo o tráfego destinado a endereços fora da sub-rede do adaptador de rede secundário para
o gateway para a sub-rede, execute o seguinte comando:
route add -p 0.0.0.0 MASK 0.0.0.0 192.168.2.1 METRIC 5015 IF 7
O endereço de gateway para a sub-rede é o primeiro endereço IP (terminando em .1) no intervalo de

endereços definido para a sub-rede. Se você não quiser para rotear todo o tráfego para fora da sub-rede,
adicione rotas individuais para destinos específicos. Por exemplo, se você quiser rotear o tráfego do
adaptador de rede secundário para a rede 192.168.3.0, digite o comando:
route add -p 192.168.3.0 MASK 255.255.255.0 192.168.2.1 METRIC 5015 IF 7
4. Para confirmar a comunicação com êxito com um recurso na rede 192.168.3.0, por exemplo, digite o
seguinte comando para executar o ping 192.168.3.4 usando a interface 7 (192.168.2.4):
ping 192.168.3.4 -S 192.168.2.4
Talvez seja necessário abrir o ICMP através do firewall do Windows do dispositivo no qual você está
fazendo o ping com o seguinte comando:
netsh advfirewall firewall add rule name=Allow-ping protocol=icmpv4 dir=in action=allow
5. Para confirmar se a rota adicionada está na tabela de rotas, insira o comando route print , que retorna
uma saída semelhante ao seguinte texto:
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.4 15
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.4 5015
A rota listada com 192.168.1.1 em Gateway é aquela que existe por padrão para o adaptador de rede
primário. A rota 192.168.2.1 em Gateway é aquela que você adicionou.
Próximas etapas
Analise os tamanhos de VM do Windows quando estiver tentando criar uma VM que tem várias NICs. Preste
atenção ao número máximo de NICs a que cada VM dá suporte.
Criar uma máquina virtual Linux com Rede
Acelerada usando CLI do Azure
Neste tutorial, você aprenderá a criar uma VM (máquina virtual) do Linux com Rede Acelerada. Para criar uma
VM Windows com Rede Acelerada, consulte Criar uma VM Windows com Rede Acelerada. Rede acelerada
permite SR-IOV (virtualização de E/S de raiz única) para uma VM, melhorando muito seu desempenho de rede.
Esse caminho de alto desempenho ignora o host do caminho de dados, reduzindo a latência, a tremulação e a
utilização da CPU para uso com as cargas de trabalho de rede mais exigentes nos tipos de VM compatíveis. A
figura abaixo mostra a comunicação entre duas VMs com e sem rede acelerada:
Sem rede acelerada, todo o tráfego de rede que entra e sai da VM deve cruzar o host e o comutador virtual. O
comutador virtual fornece toda a imposição de política, como grupos de segurança de rede, listas de controle de
acesso, isolamento e outros serviços virtualizados de rede para tráfego de rede. Para saber mais sobre
comutadores virtuais, leia o artigo Virtualização de rede Hyper-V e comutador virtual.
Com Rede Acelerada, o tráfego de rede chega ao NIC (adaptador de rede) da máquina virtual e então é
encaminhado para a VM. Todas as políticas de rede que o comutador virtual aplica agora são descarregadas e
aplicadas em hardware. Aplicar a política de hardware permite que a NIC encaminhe tráfego de rede
diretamente à VM, ignorando o host e o comutador virtual, mantendo toda a política que aplicou no host.
Os benefícios da rede acelerada aplicam-se somente à VM em que ela está habilitada. Para obter melhores
resultados, é ideal habilitar esse recurso em pelo menos duas VMs conectadas à mesma VNet (rede virtual) do
Azure. Ao se comunicar entre VNets ou fazer conexão local, esse recurso tem impacto mínimo sobre a latência
geral.
Benefícios
Latência menor/mais pps (pacotes por segundo): remover o comutador virtual do caminho de dados
elimina o tempo que os pacotes gastam no host para processamento da política e aumenta o número de
pacotes que podem ser processados dentro da VM.
Tremulação reduzida: processamento de comutador virtual depende da quantidade de política que precisa
ser aplicada e da carga de trabalho da CPU que está fazendo o processamento. O descarregamento da
imposição de política para o hardware remove essa variabilidade ao entregar pacotes diretamente à VM,
removendo a comunicação do host para a VM e todas as interrupções e mudanças de contexto de software.
Menor utilização da CPU: ignorar o comutador virtual no host resulta em menor utilização da CPU para
processar o tráfego de rede.
Sistemas operacionais compatíveis

As seguintes distribuições têm suporte imediato da Galeria do Azure:
Ubuntu 14, 4 com o kernel Linux-Azure
Ubuntu 16.04 ou posterior
SLES12 SP3 ou posterior
RHEL 7,4 ou posterior
CentOS 7,4 ou posterior
CoreOS Linux
Debian "Stretch" com kernel de backpor ts, Debian "Buster" ou posterior
Oracle Linux 7,4 e posterior com kernel compatível com Red Hat (RHCK)
Oracle Linux 7,5 e posterior com UEK versão 5
FreeBSD 10,4, 11,1 & 12,0 ou posterior
Limitações e Restrições
Instâncias de VM compatíveis
A Rede Acelerada é compatível com os tamanhos de instância de uso geral e de computação otimizada com 2
ou mais vCPUs. Em instâncias que são compatíveis com hyperthreading, a Rede Acelerada é compatível com
instâncias de VM com 4 ou mais vCPUs.
O suporte para rede acelerada pode ser encontrado na documentação de tamanhos de máquinas virtuais
individuais.
Imagens personalizadas
Se você estiver usando uma imagem personalizada e sua imagem der suporte à rede acelerada, certifique-se de
ter os drivers necessários para trabalhar com NICs Mellanox ConnectX-3 e ConnectX-4 LX no Azure.
Regiões
Disponível em todas as regiões do Azure públicas e também na Nuvem do Azure Governamental.
Habilitando Rede Acelerada em uma VM em execução
Um tamanho de VM com suporte sem rede acelerada habilitada só pode ter o recurso habilitado quando ele for
interrompido e desalocado.
Implantação por meio do Azure Resource Manager
Máquinas virtuais (clássicas) não podem ser implantadas com Rede Acelerada.
Criar uma VM do Linux com Rede Acelerada do Azure

Criação de portal
Embora este artigo forneça etapas para criar uma máquina virtual com a rede acelerada usando a CLI do Azure,
você também pode criar uma máquina virtual com a rede acelerada usando o portal do Azure. Ao criar uma
máquina virtual no portal, na folha criar uma máquina vir tual , escolha a guia rede . Nessa guia, há uma
opção para rede acelerada . Se você tiver escolhido um sistema operacional com suporte e um tamanho de VM,
essa opção será preenchida automaticamente como "ativada". Caso contrário, ele preencherá a opção
"desativado" para rede acelerada e dará ao usuário um motivo pelo qual ele não está habilitado.
Observação: Somente sistemas operacionais com suporte podem ser habilitados por meio do Portal. Se você
estiver usando uma imagem personalizada e sua imagem der suporte à rede acelerada, crie sua VM usando
a CLI ou o PowerShell.
Depois que a máquina virtual for criada, você poderá confirmar se a rede acelerada está habilitada seguindo as
instruções em confirmar se a rede acelerada está habilitada.
Criação de CLI
Criar uma rede virtual
Instale a CLI do Azure mais recente do Azure e faça logon em uma conta do Azure usando az login. Nos
exemplos a seguir, substitua os nomes de parâmetro de exemplo com seus próprios valores. Os nomes de
parâmetro de exemplo incluem myResourceGroup, myNic e myVm.
Crie um grupo de recursos com az group create. O exemplo a seguir cria um grupo de recursos chamado
myResourceGroup na localização centralus:
az group create --name myResourceGroup --location centralus
Selecione uma região do Linux compatível listada em Rede acelerada Linux.

Crie a rede virtual com az network vnet create. O exemplo a seguir cria uma rede virtual chamada myVnet com
uma sub-rede:

--name myVnet \
--address-prefix 192.168.0.0/16 \

Crie um grupo de segurança de rede com az network nsg create. O exemplo a seguir cria um grupo de
segurança de rede denominado myNetworkSecurityGroup:

O grupo de segurança de rede contém várias regras padrão, uma das quais desabilita todo o acesso de entrada
proveniente da Internet. Abra uma porta para permitir o acesso SSH à máquina virtual com az network nsg rule
create:

--name Allow-SSH-Internet \
--access Allow \
--protocol Tcp \
--priority 100 \
--source-address-prefix Internet \
Criar um adaptador de rede com rede acelerada

Crie um endereço IP público com az network public-ip create. Você não precisa de um endereço IP público se
não planeja acessar a máquina virtual por meio da Internet, mas precisa para concluir as etapas deste artigo.

--name myPublicIp \
--resource-group myResourceGroup
Crie um adaptador de rede com az network nic create com a rede acelerada habilitada. O exemplo a seguir cria
um adaptador de rede denominado myNic na sub-rede mySubnet da rede virtual myVnet e associa o grupo de
segurança de rede myNetworkSecurityGroup ao adaptador de rede:
--name myNic \
--subnet mySubnet \
--accelerated-networking true \
--public-ip-address myPublicIp \
Criar uma VM e anexar o NIC

Ao criar a VM, especifique o NIC que criou com --nics . Selecione um tamanho e uma distribuição listados em
Rede acelerada Linux.
Crie uma VM com az vm create. O exemplo a seguir cria uma VM denominada myVM com a imagem
UbuntuLTS e um tamanho que é compatível com a Rede Acelerada (Standard_DS4_v2):
az vm create \
--name myVM \
--image UbuntuLTS \
--nics myNic
Para obter uma lista de todos os tamanhos e características de VM, consulte Tamanhos de VM do Linux.
Depois que a VM é criada, é retornada uma saída semelhante ao exemplo a seguir. Anote o publicIpAddress .
Esse endereço é usado para acessar a VM em etapas subsequentes.
{
"fqdns": "",
"id":
"/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM",
"location": "centralus",
"macAddress": "00-0D-3A-23-9A-49",
}
Confirmar se a rede acelerada está habilitada

Use o comando a seguir para criar uma sessão SSH com a VM. Substitua <your-public-ip-address> pelo
endereço IP público atribuído à máquina virtual que você criou e substitua azureuser se você usou um valor
diferente para --admin-username ao criar a VM.
ssh azureuser@<your-public-ip-address>
No shell Bash, insira uname -r e confirme se a versão do kernel é uma das seguintes versões, ou superior:
Ubuntu 16.04 : 4.11.0-1013
SLES SP3 : 4.4.92-6.18
RHEL : 7.4.2017120423
CentOS : 7.4.20171206
Confirme se o dispositivo Mellanox VF está exposto à VM com o comando lspci . A saída retornada é
semelhante à seguinte saída:
0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 03)
0000:00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
0000:00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
0000:00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
0000:00:08.0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA
0001:00:02.0 Ethernet controller: Mellanox Technologies MT27500/MT27520 Family [ConnectX-3/ConnectX-3 Pro
Virtual Function]
Verifique se há atividade na VF (função virtual) com o comando ethtool -S eth0 | grep vf_ . Se você receber
uma saída semelhante ao seguinte exemplo de saída, a rede acelerada estará habilitada e funcionando.
vf_rx_packets: 992956
vf_rx_bytes: 2749784180
vf_tx_packets: 2656684
vf_tx_bytes: 1099443970
vf_tx_dropped: 0
A Rede Acelerada agora está habilitada para sua VM.
Manipular associação dinâmica e revogação da função virtual

Os aplicativos devem ser executados sobre a NIC sintética que é exposta na VM. Se o aplicativo for executado
diretamente pela NIC VF, ele não receberá todos os pacotes destinados à VM, já que alguns pacotes aparecem
na interface sintética. Se você executar um aplicativo na NIC sintética, ele garante que o aplicativo receba todos
os pacotes destinados a ele. Ele também garante que o aplicativo continue em execução, mesmo que o FV seja
revogado quando o host estiver sendo atendido. A associação de aplicativos à NIC sintética é um requisito
obrigatório para todos os aplicativos que aproveitam a rede acelerada .
Habilitar Rede Acelerada em VMs existentes

Se você tiver criado uma VM sem Rede Acelerada, será possível habilitar esse recurso em uma VM existente. A
VM deve dar suporte à Rede Acelerada atendendo aos pré-requisitos a seguir que também estão descritos
acima:
A VM deve ter um tamanho com suporte para Rede Acelerada
A VM deve ser uma imagem da Galeria do Azure com suporte (e a versão de kernel do Linux)
Todas as VMs em um conjunto de disponibilidade ou VMSS devem ser interrompidas/desalocadas antes de
se habilitar a Rede Acelerada em uma NIC
VMs individuais e VMs em um conjunto de disponibilidade
Primeiro interrompa/desaloque a VM ou, se for um Conjunto de Disponibilidade, todas as VMs no conjunto:
az vm deallocate \
--name myVM
Importante: observe que se sua VM tiver sido criada individualmente, sem um conjunto de disponibilidade, você
só precisará interromper/desalocar a VM individual para habilitar a Rede Acelerada. Se sua VM tiver sido criada
com um conjunto de disponibilidade, todas as VMs contidas no conjunto de disponibilidade precisarão ser
interrompidas/desalocadas antes de habilitar a Rede Acelerada em qualquer uma das NICs.
Uma vez interrompida, habilite a Rede Acelerada na NIC de sua VM:
az network nic update \

--name myNic \
--accelerated-networking true
Reinicie a VM ou, se em um Conjunto de Disponibilidade, todas as VMs no conjunto, e confirme se a Rede

Acelerada está habilitada:
az vm start --resource-group myResourceGroup \

--name myVM
VMSS
O VMSS é ligeiramente diferente, mas segue o mesmo fluxo de trabalho. Em primeiro lugar, interrompa as VMs:
az vmss deallocate \
--name myvmss \
--resource-group myrg
Depois que as VMs forem interrompidas, atualize a propriedade de Rede Acelerada na interface de rede:
az vmss update --name myvmss \

--resource-group myrg \
--set
virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].enableAcceleratedNetworking=true
Observe que um VMSS tem upgrades de VM que aplicam atualizações usando três diferentes configurações:
automática, sem interrupção e manual. Nessas instruções, a política é definida como automática para que o
VMSS acompanhe as alterações imediatamente após a reinicialização. Para defini-la como automática para que
as alterações sejam aplicadas imediatamente:
az vmss update \
--name myvmss \
--resource-group myrg \
--set upgradePolicy.mode="automatic"
Finalmente, reinicie o VMSS:
az vmss start \
--name myvmss \
--resource-group myrg
Após você reiniciar, aguarde o término dos upgrades. Após a conclusão, o VF será exibido dentro da VM.
(Verifique se você está usando um tamanho de VM e um sistema operacional com suporte.)
Redimensionar VMs existentes com Rede Acelerada
VMs com Rede Acelerada habilitada só podem ser redimensionadas para VMs com suporte para Rede
Acelerada.
Uma VM com Rede Acelerada habilitada não pode ser redimensionada para uma instância de VM que não
oferece suporte a Rede Acelerada usando a operação de redimensionamento. Em vez disso, para redimensionar
uma dessas VMs:
Interrompa/desaloque a VM ou, em um conjunto de disponibilidade/VMSS, interrompa/desaloque todas as
VMs no conjunto/VMSS.
A Rede Acelerada deve ser desabilitada na NIC da VM ou, se em um conjunto de disponibilidade/VMSS,
todas as VMs no conjunto/VMSS.
Quando a Rede Acelerada é desabilitada, a VM/o conjunto de disponibilidade/o VMSS podem ser movidos
para um novo tamanho que não oferece suporte para Rede Acelerada e reiniciados.
Criar um nome de domínio totalmente qualificado
no Portal do Azure para uma VM Linux
Quando você cria uma máquina virtual (VM) no portal do Azure, um recurso de IP público para a máquina
virtual é criado automaticamente. Use esse endereço IP para acessar a VM remotamente. Embora o portal não
crie um nome de domínio totalmente qualificado ou FQDN, você poderá adicionar um depois que a VM for
criada. Este artigo apresenta as etapas para criar um nome DNS ou FQDN.
Criar um FQDN
Este artigo pressupõe que você já tenha criado uma VM. Se necessário, você pode criar uma VM do Linux ou do
Windows no Portal. Siga estas etapas depois que a VM estiver em execução:
1. Selecione sua VM no portal.
2. No menu à esquerda, selecione configuração
3. Em rótulo de nome DNS , insira o prefixo que você deseja usar.
4. No início da página, selecione Salvar .
5. Retorne à folha visão geral da VM selecionando visão geral no menu à esquerda.
6. Verifique se o nome DNS aparece corretamente.
Próximas etapas
Você também pode gerenciar o DNS usando zonas DNS do Azure.
Como encontrar e excluir as placas de interface de
rede não anexadas (NICs) para as máquinas virtuais
do Azure
Quando você exclui uma máquina virtual (VM) no Azure, as placas de interface de rede (NICs) são excluídas por
padrão. Se você criar e excluir várias máquinas virtuais, os NICs não usados continuarão a usar as concessões
de endereço de IP internas. Conforme você cria outras NICs de máquina virtual, podem não conseguir obter
uma concessão de IP no espaço de endereço da sub-rede. Esse artigo mostra como encontrar e excluir NICs não
anexadas.
Localizar e excluir NICs desconectados

A propriedade da virtualMachine para NIC armazena a ID e o grupo de recurso da máquina virtual que o NIC
está anexado. Os loops de script a seguir através de todos os NICs em uma assinatura e verifica se a
propriedade virtualMachine é nula. Se a propriedade for nula, o NIC não está anexado à máquina virtual.
Para visualizar NICs não anexados, é altamente recomendado primeiro executar o script com a variável
deleteUnattachedVHDs como 0. Para excluir os NICs não anexados após revisar a saída da lista, execute o script
com deleteUnattachedNics para 1.
# Set deleteUnattachedNics=1 if you want to delete unattached NICs

# Set deleteUnattachedNics=0 if you want to see the Id(s) of the unattached NICs
deleteUnattachedNics=0
unattachedNicsIds=$(az network nic list --query '[?virtualMachine==`null`].[id]' -o tsv)

for id in ${unattachedNicsIds[@]}
do
if (( $deleteUnattachedNics == 1 ))
then
echo "Deleting unattached NIC with Id: "$id

az network nic delete --ids $id
echo "Deleted unattached NIC with Id: "$id
else
echo $id
fi
done
Próximas etapas
Para obter mais informações sobre como riar e gerenciar redes virtuais no Azure, consulte criar e gerenciar
redes de máquinas virtuais.
Opções de resolução de nomes DNS para
máquinas virtuais Linux no Azure
O Azure fornece resolução de nomes DNS por padrão para todas as máquinas virtuais que estão em uma única
rede virtual. Você pode implementar sua própria solução de resolução de nomes DNS configurando seus
próprios serviços DNS em suas máquinas virtuais que o Azure hospeda. Os cenários a seguir devem ajudá-lo a
escolher a que funciona para sua situação.
Resolução de nomes que o Azure fornece
Resolução de nome usando o seu próprio servidor DNS
O tipo de resolução de nomes que você usa depende de como as máquinas virtuais e as instâncias de função
precisam se comunicar entre si.
A tabela a seguir ilustra os cenários e as soluções de resolução de nomes correspondentes:
C EN Á RIO SO L UÇ Ã O SUF F IX
Resolução de nomes entre as Resolução de nomes que o Azure nome de host ou FQDN (nome de
instâncias de função ou as máquinas fornece domínio totalmente qualificado)
virtuais na mesma rede virtual
Resolução de nomes entre as Servidores DNS gerenciados pelo Somente FQDN

instâncias de função ou as máquinas cliente que encaminham consultas
virtuais em redes virtuais diferentes entre redes virtuais para resolução
pelo Azure (proxy DNS). Consulte
resolução de nomes usando seu
próprio servidor DNS.
Resolução de nomes de serviço e de Servidores DNS gerenciados pelo Somente FQDN

computador locais em instâncias de cliente (por exemplo, controlador de
função ou máquinas virtuais no Azure domínio local, controlador de domínio
somente leitura local ou DNS
secundário sincronizados usando
transferências de zona). Consulte
Resolução de nomes de host do Azure Encaminhe consultas para um servidor Somente FQDN
de computadores locais de proxy de DNS gerenciada pelo
cliente na rede virtual correspondente.
O servidor proxy encaminha consultas
para o Azure para resolução. Consulte
DNS inverso para IPs internos Resolução de nome usando o seu n/a
próprio servidor DNS
Resolução de nomes que o Azure fornece

Junto com a resolução de nomes DNS públicos, o Azure fornece uma resolução de nomes interna para
máquinas virtuais e instâncias de função que estão na mesma rede virtual. Em redes virtuais baseadas no Azure
Resource Manager, o sufixo DNS é consistente em toda a rede virtual; o FQDN não é necessário. Os nomes DNS
podem ser atribuídos a máquinas virtuais e placas de adaptador de rede (NICs). Embora a resolução de nomes
que o Azure fornece não solicite qualquer configuração, ela não é a escolha apropriada para todos os cenários
de implantação, como mostrado na tabela acima.
Recursos e considerações
Features
não é necessária nenhuma configuração para usar a resolução de nomes que o Azure fornece.
O serviço de resolução de nomes que o Azure fornece está altamente disponível. Você não precisa criar e
gerenciar clusters de seus próprios servidores DNS.
O serviço de resolução de nomes que o Azure fornece pode ser usado junto com seus próprios servidores
DNS para resolver nomes de host locais e do Azure.
A resolução de nomes é fornecida entre máquinas virtuais em redes virtuais sem a necessidade de FQDN.
Você pode usar nomes de host que descrevem melhor as suas implantações, em vez de trabalhar com
nomes gerados automaticamente.
Considerações:
O sufixo DNS que o Azure cria não pode ser modificado.
Não é possível registrar manualmente seus próprios registros.
Não há suporte para o WINS e NetBIOS.
Os nomes de host devem ser compatíveis com DNS. Os nomes devem usar somente 0-9, a-z e '-' e não
podem começar ou terminar com um '-'. Veja a RFC 3696, seção 2.
O tráfego da consulta DNS é restrita a cada máquina virtual. Essa limitação não deve afetar a maioria dos
aplicativos. Se a limitação da solicitação for observada, certifique-se de que o armazenamento em cache do
cliente está habilitado. Para obter mais detalhes, confira Obtendo o máximo de resolução de nomes que o
Azure fornece.
Obtendo o máximo de resolução de nomes que o Azure fornece
Armazenamento em cache no lado cliente:
Algumas consultas DNS não são enviadas pela rede. O armazenamento em cache do lado do cliente ajuda a
reduzir a latência e melhorar a resistência a inconsistências de rede resolvendo consultas de DNS recorrentes a
partir de um cache local. Os registros DNS contêm um Time-To-Live (TTL) que permite que o cache armazene o
registro o maior tempo possível sem afetar a atualização de registro. Como resultado disso, o cache do lado do
cliente é adequado para a maioria das situações.
Algumas distribuições do Linux não incluem o armazenamento em cache por padrão. É recomendável que você
adicione um cache para cada máquina virtual do Linux, depois de verificar se já não há um cache local.
Vários pacotes de cache DNS diferentes, como dnsmasq, estão disponíveis. Aqui estão as etapas para instalar o
dnsmasq nas distribuições mais comuns:
Ubuntu (usa resolvconf )
Instale o pacote dnsmasq ("sudo apt-get install dnsmasq").
SuSE (usa netconf ) :
1. Instale o pacote dnsmasq ("sudo zypper install dnsmasq").
2. Habilite o serviço dnsmasq ("systemctl enable dnsmasq.service").
3. Inicie o serviço dnsmasq ("systemctl start dnsmasq.service").
4. Edite "/etc/sysconfig/network/config" e altere NETCONFIG_DNS_FORWARDER = "" para "dnsmasq".
5. Atualize resolv.conf ("netconfig update") para definir o cache do resolvedor DNS local.
CentOS por software de Wave não autorizado (anteriormente OpenLogic; usa NetworkManager)
1. Instale o pacote de dnsmasq ("sudo yum install dnsmasq").
2. Habilite o serviço dnsmasq ("systemctl enable dnsmasq.service").
3. Inicie o serviço dnsmasq ("systemctl start dnsmasq.service").
4. Adicione "prepend domain-name-servers 127.0.0.1;" a "/etc/dhclient-eth0.conf".
5. Reinicie o serviço de rede ("service network restart") para definir o cache como o resolvedor DNS local
NOTE
: O pacote 'dnsmasq' é apenas um dos vários caches DNS disponíveis para o Linux. Antes de usá-lo, verifique sua
adequação para suas necessidades e se nenhum outro cache está instalado.
Tentativas do lado do cliente

O DNS é principalmente um protocolo UDP. Como o protocolo UDP não garante a entrega de mensagens, o
próprio protocolo DNS manipula a lógica de repetição. Cada cliente DNS (sistema operacional) pode apresentar
uma lógica de repetição diferente dependendo da preferência dos criadores:
Os sistemas operacionais Windows tentam novamente após um segundo e, em seguida, novamente após
mais dois, quatro e outros quatro segundos.
A configuração padrão do Linux tenta novamente após cinco segundos. Altere isso para tentar novamente
cinco vezes em intervalos de um segundo.
Para verificar as configurações atuais em uma máquina virtual do Linux, 'cat /etc/resolv.conf' e examine a linha
'options', por exemplo:
options timeout:1 attempts:5
O arquivo resolv.conf é gerado automaticamente e não deve ser editado. As etapas específicas que adicionam a
linha 'options' variam de acordo com a distribuição:
Ubuntu (usa resolvconf)
1. Adicione a linha de opções a '/etc/resolvconf/resolv.conf.d/Head '.
2. Execute 'resolvconf -u' para atualizar.
SUSE (usa netconf)
1. Adicione 'timeout:1 tentativas: 5' ao parâmetro NETCONFIG_DNS_RESOLVER_OPTIONS = "" em '/
etc/sysconfig/rede/config'.
2. Execute 'netconfig update' para atualizar.
CentOS por software de Wave não autorizado (anteriormente OpenLogic) (usa NetworkManager)
1. Adicione 'RES_OPTIONS="timeout:1 attempts:5"' to '/etc/sysconfig/network'.
2. Execute 'service network restart' para atualizar.
Resolução de nome usando o seu próprio servidor DNS

Suas necessidades de resolução de nomes podem ir além dos recursos do Azure. Por exemplo, você pode exigir
a resolução DNS entre redes virtuais. Para abordar esse cenário, você poderá usar seus próprios servidores
DNS.
Os servidores DNS em uma rede virtual podem encaminhar consultas DNS para os resolvedores recursivos do
Azure a fim de resolver nomes de host que estão na mesma rede virtual. Por exemplo, um servidor DNS que é
executado o Azure pode responder a consultas DNS dos seus próprios arquivos de zona DNS e encaminhar
todas as outras consultas ao Azure. Essa funcionalidade permite que máquinas virtuais vejam as entradas nos
arquivos de zona e os nomes de host que o Azure fornece (via o encaminhador). O acesso a resolvedores
recursivos do Azure é fornecido por meio da IP virtual 168.63.129.16.
O encaminhamento de DNS também habilita a resolução de DNS entre redes virtuais e habilita que suas
máquinas locais resolvam os nomes de host que o Azure fornece. Para resolver o nome de host da máquina
virtual, a máquina virtual do servidor DNS deve residir na mesma rede virtual e ser configurado para
encaminhar consultas de nome de host ao Azure. Como o sufixo DNS é diferente em cada rede virtual, você
pode usar regras de encaminhamento condicionais para enviar consultas DNS a fim de serem resolvidas pela
rede virtual correta. A imagem a seguir mostra duas redes virtuais e uma rede local fazendo a resolução do
DNS entre redes virtuais usando esse método:
Quando você usa a resolução de nomes que o Azure fornece, o sufixo DNS interno é fornecido para cada
máquina virtual usando o DHCP. Quando você usa sua própria solução de resolução de nomes, esse sufixo não
será fornecido para as máquinas virtuais porque o sufixo interfere com outras arquiteturas de DNS. Para fazer
referência a máquinas pelo FQDN, ou para configurar o sufixo em suas máquinas virtuais, você pode usar o
PowerShell ou a API para determinar o sufixo:
Para redes virtuais que são gerenciadas pelo Azure Resource Manager, o sufixo está disponível por meio do
recurso placa de adaptador de rede. Você também pode executar o comando
azure network public-ip show <resource group> <pip name> para exibir os detalhes de seu IP público, que
inclui o FQDN da NIC.
Se o encaminhamento de consultas para o Azure não atender às suas necessidades, você precisará fornecer sua
própria solução DNS. A solução do DNS precisa:
Fornecer resolução de nome de host apropriada, por exemplo, DDNS. Se você usar DDNS, convém
desabilitar a limpeza de registro de DNS. As concessões de DHCP do Azure são muito longas e a eliminação
pode remover os registros DNS prematuramente.
Fornecer a resolução recursiva apropriada para permitir a resolução de nomes de domínio externo.
Ser acessível (TCP e UDP na porta 53) dos clientes a que ela serve e ser capaz de acessar a Internet.
Ter proteção contra acesso da Internet, para atenuar as ameaças impostas por agentes externos.
NOTE
Para obter o melhor desempenho, quando usar máquinas virtuais em servidores DNS do Azure, desabilite o IPv6 e
atribua um IP público em nível de instância para cada máquina virtual do servidor DNS.
Criar placas de adaptador de rede virtual e usar
DNS interno para resolução de nome da VM no
Azure
Este artigo mostra como definir nomes DNS internos estáticos para VMs do Linux usando vNics (adaptadores
de rede de rede virtual) e nomes de rótulo DNS com a CLI do Azure. Nomes DNS estáticos são usados para
serviços de infraestrutura permanentes como um servidor de build Jenkins, que é usado para este documento
ou um servidor Git.
Esses requisitos são:
uma conta do Azure
arquivos de chave SSH pública e privada
Comandos rápidos
Se você precisar executar a tarefa rapidamente, a seção a seguir fornecerá detalhes dos comandos necessários.
Informações mais detalhadas e contexto para cada etapa podem ser encontrados no restante do documento,
começando aqui. Para realizar essas etapas, é preciso ter a CLI do Azure mais recente instalada e conectada a
uma conta do Azure usando az login.
Pré-requisitos: grupo de recursos, rede virtual e sub-rede, grupo de segurança de rede com o SSH de entrada.
Criar uma placa de interface de rede virtual com um nome DNS interno estático
Crie a vNic com az network nic create. O sinalizador --internal-dns-name da CLI serve para configurar o rótulo
DNS, que fornece o nome DNS estático para a vNic (placa de interface de rede virtual). O exemplo a seguir cria
uma vNic chamada myNic , conecta-a à rede virtual myVnet e cria um registro de nome DNS interno chamado
jenkins :

--name myNic \
--subnet mySubnet \
--internal-dns-name jenkins
Implantar uma VM e conectar a vNic

Crie uma VM com az vm create. O sinalizador --nics conecta a vNic à VM durante a implantação no Azure. O
exemplo a seguir cria uma VM denominada myVM com Azure Managed Disks e anexa a vNic chamada myNic da
etapa anterior:
az vm create \
--name myVM \
--nics myNic \
--image UbuntuLTS \
Passo a passo detalhado
Uma infraestrutura completa de CiCd (implantação e integração contínuas) no Azure exige que alguns
servidores sejam estáticos ou de longa duração. Recomendamos que os ativos do Azure, por exemplo as redes
virtuais e os grupos de segurança de rede, sejam recursos estáticos e de longa duração que raramente sejam
implantados. Após a implantação de uma rede virtual, ela pode ser reutilizada por novas implantações sem
nenhum efeito negativo sobre a infraestrutura. Você pode adicionar posteriormente um servidor de repositório
Git ou então um servidor de automação Jenkins fornece CiCd para essa rede virtual para os ambientes de
desenvolvimento ou teste.
Nomes DNS internos podem ser resolvidos apenas em uma rede virtual do Azure. Como os nomes DNS são
internos, eles não podem ser resolvidos para a Internet externa, fornecendo segurança adicional para a
infraestrutura.
parâmetro de exemplo incluem myResourceGroup , myNic e myVM .
Criar o grupo de recursos

Primeiro, crie o grupo de recursos com az group create. O exemplo a seguir cria um grupo de recursos
denominado myResourceGroup no local westus :
Criar a rede virtual

A próxima etapa é criar uma rede virtual na qual iniciar as VMs. A rede virtual contém uma sub-rede para este
passo a passo. Para obter mais informações sobre as redes virtuais do Azure, consulte Criar uma rede virtual.
Crie a rede virtual com az network vnet create. O exemplo a seguir cria uma rede virtual chamada myVnet e
uma sub-rede chamada mySubnet :

--name myVnet \
--address-prefix 192.168.0.0/16 \
Criar o grupo de segurança de rede

Os grupos de segurança de rede do Azure são equivalentes a um firewall na camada de rede. Para obter mais
informações sobre os grupos de segurança de rede, confira Como criar NSGs na CLI do Azure.
Crie o grupo de segurança de rede com az network nsg create. O seguinte exemplo cria um grupo de segurança
de rede chamado myNetworkSecurityGroup :

Adicionar uma regra de entrada para permitir SSH

Adicione uma regra de entrada para o grupo de segurança de rede com az network nsg rule create. O exemplo a
seguir cria uma regra chamada myRuleAllowSSH :

--name myRuleAllowSSH \
--protocol tcp \
--direction inbound \
--priority 1000 \
--source-address-prefix '*' \
--source-port-range '*' \
--destination-address-prefix '*' \
--access allow
Associar uma sub-rede ao Grupo de Segurança de Rede

Para associar a sub-rede ao grupo de segurança de rede, use az network vnet subnet update. O exemplo a
seguir associa a sub-rede denominada mySubnet ao Grupo de Segurança de Rede denominado
myNetworkSecurityGroup :

--name mySubnet \
Criar a placa de interface de rede virtual e nomes DNS estáticos

O Azure é muito flexível, mas para usar nomes DNS para a resolução de nomes de VM, você precisa criá-los
como vNics (placas de adaptador de rede virtual) que incluam um rótulo DNS. Placas de vNics são importantes,
uma vez que você pode reutilizá-las conectando-as a diferentes VMs. Essa abordagem mantém a vNic como um
recurso estático, enquanto as VMs podem ser temporárias. Ao usar a rotulagem DNS na vNic, podemos habilitar
a resolução de nomes simples em outras VMs na VNet. Usar nomes que podem ser resolvidos permite que
outras VMs acessem o servidor de automação com o nome DNS Jenkins ou o servidor Git como gitrepo .
Crie a vNic com az network nic create. O exemplo a seguir cria uma vNic chamada myNic , conecta-a à rede
virtual myVnet chamada myVnet e cria um registro de nome DNS interno chamado jenkins :

--name myNic \
--subnet mySubnet \
--internal-dns-name jenkins
Implantar a VM na infra-estrutura de rede virtual

Agora temos uma rede virtual, uma sub-rede, uma vNic e um grupo de segurança de rede atuando como um
firewall, para proteger nossa sub-rede bloqueando todo o tráfego de entrada, exceto pela porta 22 para o SSH.
Agora a VM pode ser implantada nessa infraestrutura de rede existente.
Crie uma VM com az vm create. O exemplo a seguir cria uma VM denominada myVM com Azure Managed Disks
e anexa a vNic chamada myNic da etapa anterior:
az vm create \
--name myVM \
--nics myNic \
--image UbuntuLTS \
Ao usar sinalizadores da CLI para chamar os recursos existentes, instruímos o Azure a implantar a VM na rede
existente. Em outras palavras, depois que uma VNET e uma sub-rede forem implantadas, elas poderão ser
mantidas como recursos estáticos ou permanentes na região do Azure.
Próximas etapas
Criar seu próprio ambiente personalizado para uma VM do Linux usando os comandos da CLI do Azure
diretamente
Criar uma VM do Linux no Azure usando modelos
Visão geral de segurança de máquinas virtuais do
Azure
Este artigo fornece uma visão geral dos principais recursos de segurança do Azure que podem ser usados com
máquinas virtuais.
Use as Máquinas Virtuais do Azure para implantar uma ampla gama de soluções de computação com agilidade.
O serviço dá suporte ao Microsoft Windows, Linux, Microsoft SQL Server, Oracle, IBM, SAP e Serviços BizTalk do
Azure. Portanto, você pode implantar qualquer carga de trabalho e qualquer linguagem em praticamente
qualquer sistema operacional.
Uma máquina virtual do Azure oferece a flexibilidade da virtualização sem a necessidade de comprar e manter
o hardware físico que executa a máquina virtual. Crie e implante aplicativos com a garantia de que seus dados
estarão protegidos e seguros em datacenters altamente seguros.
Com o Azure, você pode compilar soluções compatíveis, com segurança avançada, que:
Protegem suas máquinas virtuais contra vírus e malware.
Criptografam seus dados confidenciais.
Protegem o tráfego de rede.
Identificam e detectam ameaças.
Atendem aos requisitos de conformidade.
Antimalware
Com o Azure, você pode usar um software antimalware de fornecedores de segurança, como a Microsoft,
Symantec, Trend Micro e Kaspersky. Esse software ajuda a proteger suas máquinas virtuais contra arquivos mal-
intencionados, adware e outras ameaças.
O Microsoft Antimalware para Serviços de Nuvem e Máquinas Virtuais do Azure é uma funcionalidade de
proteção em tempo real que ajuda a identificar e remover vírus, spyware e outros softwares mal-intencionados.
O Microsoft Antimalware para Azure fornece alertas configuráveis quando um software mal-intencionado ou
indesejado conhecido tenta se instalar ou ser executado nos sistemas do Azure.
O Microsoft Antimalware para Azure é uma solução de agente único para aplicativos e ambientes de locatário.
Foi projetado para execução em segundo plano sem intervenção humana. Você pode implantar a proteção
baseada nas necessidades de suas cargas de trabalho do aplicativo, com configuração básica padronizada ou
personalizada avançada, incluindo monitoramento de antimalware.
Saiba mais sobre o Microsoft antimalware para Azure e os principais recursos disponíveis.
Saiba mais sobre o software antimalware para ajudar a proteger suas máquinas virtuais:
Implantando soluções antimalware em máquinas virtuais do Azure
Como instalar e configurar o Trend Micro Deep Security as a Service em uma VM do Windows
Como instalar e configurar o Symantec Endpoint Protection em uma VM do Windows
Soluções de segurança no Azure Marketplace
Para uma proteção ainda mais poderosa, considere o uso da Proteção Avançada contra Ameaças do Windows
Defender. Com o Windows Defender ATP, você obtém:
Redução da superfície de ataque
Proteção de próxima geração
Resposta e a proteção de ponto de extremidade
Correção e investigação automatizada
Pontuação segura
Procura avançada
Gerenciamento e APIs
Proteção contra Ameaças da Microsoft
Saiba mais:
Introdução ao WDATP
Visão geral dos recursos WDATP
Módulo de segurança de hardware

A melhoria da segurança das chaves pode aprimorar as proteções de criptografia e de autenticação. Você pode
simplificar o gerenciamento e a segurança dos seus principais segredos e chaves armazenando-os no Cofre de
Chaves do Azure.
O Cofre de Chaves oferece a opção de armazenar as chaves em HSMs (módulos de segurança de hardware)
certificados para os padrões FIPS 140-2 nível 2. Suas chaves de criptografia do SQL Server para backup ou
Transparent Data Encryption podem ser armazenadas no Cofre de Chaves com quaisquer chaves ou segredos
dos seus aplicativos. As permissões e o acesso a esses itens protegidos são gerenciados pelo Azure Active
Directory.
Saiba mais:
Blog do Cofre de Chaves do Azure
Criptografia de disco da máquina virtual

O Azure Disk Encryption é uma nova funcionalidade para criptografia de discos de máquinas virtuais do
Windows e Linux. O Azure Disk Encryption usa o recurso BitLocker padrão do setor do Windows e o recurso
DM-cript do Linux para fornecer criptografia de volume para o sistema operacional e os discos de dados.
A solução é integrada ao Azure Key Vault para ajudá-lo a controlar e gerenciar os segredos e as chaves de
criptografia de disco em sua assinatura do cofre de chaves. Ela também garante que todos os dados nos discos
da máquina virtual sejam criptografados em repouso no Armazenamento do Azure.
Saiba mais:
Azure Disk Encryption para VMs de IaaS
Início Rápido: Criptografar uma VM de IaaS do Windows com o Azure PowerShell
Backup de máquinas virtuais

O Backup do Azure é uma solução escalonável que ajuda a proteger os dados de seu aplicativo com zero
investimento de capital e custos operacionais mínimos. Erros de aplicativo podem corromper seus dados e erros
humanos podem introduzir bugs em seus aplicativos. Com o Backup do Azure, suas máquinas virtuais
executando Windows e Linux estão protegidas.
Saiba mais:
O que é o Backup do Azure?
Perguntas frequentes do serviço de backup do Azure
Azure Site Recovery

Uma parte importante da estratégia de BCDR de sua organização é descobrir como manter cargas de trabalho e
aplicativos corporativos em execução durante interrupções planejadas e não planejadas. O Azure Site Recovery
ajuda a orquestrar a replicação, o failover e a recuperação de cargas de trabalho e aplicativos, de modo que eles
estejam disponíveis em um local secundário, caso o local primário fique inativo.
Recuperação de Site:
Simplifica sua estratégia de BCDR : o Site Recovery facilita lidar com a replicação, o failover e a
recuperação de várias cargas de trabalho e aplicativos de negócios em um só local. O Site Recovery
orquestra a replicação e o failover, mas não intercepta os dados do aplicativo nem mantém informações
sobre ele.
Fornece uma replicação flexível : usando o Site Recovery, você pode replicar cargas de trabalho em
execução em máquinas virtuais do Hyper-V e do VMware e em servidores físicos do Windows/Linux.
Dá supor te a failover e recuperação : o Site Recovery fornece failovers de teste para dar suporte a
simulações de recuperação de desastre sem afetar os ambientes de produção. Você também pode executar
failovers planejados sem perder qualquer dado durante interrupções esperadas, ou failovers não planejados
com perda mínima de dados (dependendo da frequência de replicação) para desastres inesperados. Após o
failover, faça failback para os sites primários. A Recuperação de Site fornece planos de recuperação que
podem incluir scripts e pastas de trabalho de automação do Azure, para que você possa personalizar o
failover e a recuperação de aplicativos de várias camadas.
Elimina datacenters secundários : você pode fazer a replicação para um site local secundário ou para o
Azure. Usar o Azure como um destino de recuperação de desastres elimina o custo e a complexidade de
manter um site secundário. Os dados replicados são colocados no Armazenamento do Azure.
Integra-se às tecnologias de BCDR existentes : o Site Recovery faz uma parceria com outros recursos de
BCDR dos aplicativos. Por exemplo, você pode usar o Site Recovery para ajudar a proteger o back-end do
SQL Server de cargas de trabalho corporativas. Isso inclui o suporte nativo ao SQL Server Always On para
gerenciar o failover de grupos de disponibilidade.
Saiba mais:
O que é Azure Site Recovery?
Como funciona Azure Site Recovery?
Quais cargas de trabalho são protegidas por Azure Site Recovery?
Rede Virtual
As máquinas virtuais precisam de conectividade de rede. Para dar suporte a esse requisito, o Azure exige que as
máquinas virtuais estejam conectadas a uma Rede Virtual do Azure.
Uma Rede Virtual do Azure é um constructo lógico criado na malha de rede física do Azure. Cada rede virtual
lógica do Azure é isolada de todas as outras redes virtuais do Azure. Esse isolamento ajuda a garantir que o
tráfego da rede nas implantações não seja acessível para os outros clientes do Microsoft Azure.
Saiba mais:
Visão geral da segurança de rede do Azure
Visão geral da Rede Virtual
Recursos de rede e parcerias para cenários empresariais
Gerenciamento de política de segurança e emissão de relatórios

A Central de Segurança do Azure ajuda você a evitar, detectar e responder a ameaças. A Central de Segurança
proporciona a você maior visibilidade e controle da segurança de seus recursos do Azure. Ela fornece
monitoramento de segurança integrado e gerenciamento de políticas em suas assinaturas do Azure. Ela ajuda a
detectar ameaças que poderiam não ser notadas de outra forma e funciona com um amplo ecossistema de
soluções de segurança.
A Central de Segurança ajuda você a otimizar e monitorar a segurança de suas máquinas virtuais:
Fornecendo recomendações de segurança para as máquinas virtuais. Entre os exemplos de recomendações
estão a aplicação de atualizações do sistema, a configuração de pontos de extremidade de ACLs, a habilitação
de antimalware, a habilitação de grupos de segurança de rede e a aplicação da criptografia de disco.
Monitorando o estado das máquinas virtuais.
Saiba mais:
Introdução à Central de Segurança do Azure
Perguntas frequentes sobre a Central de Segurança do Azure
Planejamento e operações da Central de Segurança do Azure
Conformidade
As Máquinas Virtuais do Azure são certificados para FISMA, FedRAMP, HIPAA, PCI DSS Nível 1 e outros
programas de conformidade de chaves. Essa certificação facilita que seus próprios aplicativos do Azure atendam
aos requisitos de conformidade e que sua empresa enderece uma ampla variedade de requisitos normativos
nacionais e internacionais.
Saiba mais:
Microsoft Trust Center: Compliance (Central de Confiabilidade da Microsoft: conformidade)
Trusted Cloud: Microsoft Azure Security, Privacy, and Compliance (A nuvem confiável: segurança, privacidade
e conformidade do Microsoft Azure)
Computação Confidencial
Embora a computação confidencial não seja tecnicamente parte da segurança da máquina virtual, o tópico da
segurança da máquina virtual pertence ao assunto de "computação" de nível superior. A computação
confidencial pertence dentro da categoria de segurança de "computação".
A computação confidencial garante que quando os dados estiverem "em claro", o que é necessário para um
processamento eficiente, os dados serão protegidos dentro de um ambiente de execução confiável
https://en.wikipedia.org/wiki/Trusted_execution_environment (também conhecido como enclave), um exemplo
do que é mostrado na figura abaixo.
Os TEEs garantem que não há como visualizar os dados ou as operações internas de fora, mesmo com um
depurador. Eles até garantem que apenas o código autorizado tenha permissão para acessar os dados. Se o
código for alterado ou adulterado, as operações serão negadas e o ambiente desativado. O TEE aplica essas
proteções durante a execução do código dentro dele.
Saiba mais:
Apresentando a computação confidencial do Azure
Computação confidencial do Azure
Próximas etapas
Saiba mais sobre as práticas recomendadas de segurança para VMs e sistemas operacionais.
O que é a Central de Segurança do Azure?
A Central de Segurança do Azure é um sistema de gerenciamento de segurança de infraestrutura unificado que

fortalece a postura de segurança de seus data centers e fornece proteção avançada contra ameaças em suas
cargas de trabalho híbridas locais e na nuvem, estejam elas no Azure ou não.
Manter seus recursos seguros é um esforço conjunto entre seu provedor de nuvem, o Azure e você, o cliente.
Você precisa verificar se suas cargas de trabalho estão seguras ao mudar para a nuvem e, ao mesmo tempo,
quando ao ir para IaaS (infraestrutura como serviço), há mais responsabilidade do cliente do que havia em PaaS
(plataforma como serviço) e SaaS (software como serviço). A Central de Segurança do Azure fornece as
ferramentas necessárias para proteger sua rede, proteger seus serviços e verificar se você está atualizado
quanto à sua postura de segurança.
A Central de Segurança do Azure aborda os três desafios de segurança mais urgentes:
Cargas de trabalho que mudam rapidamente – são tanto um ponto forte quanto um desafio da
nuvem. Por um lado, os usuários finais estão capacitados a fazer mais. Por outro, como você garante que
os serviços em constante mudança que as pessoas estão usando e criando estejam atualizados com seus
padrões de segurança e sigam as melhores práticas de segurança?
Ataques cada vez mais sofisticados – onde quer que você execute suas cargas de trabalho, os
ataques continuam a ficar cada vez mais sofisticados. Você precisará proteger suas cargas de trabalho de
nuvem pública, que são, na verdade, uma carga de trabalho voltada para a Internet que poderão deixá-lo
ainda mais vulnerável se você não seguir as melhores práticas de segurança.
Habilidades de segurança são escassas – o número de alertas de segurança e sistemas de alertas
ultrapassa em muito o número de administradores com experiência e preparação necessárias para
verificar se seus ambientes estão protegidos. Permanecer atualizado quanto aos ataques mais recentes é
um desafio constante, tornando impossível permanecer em vigor enquanto o mundo de segurança é um
front em constante mudança.
Para ajudá-lo a se proteger contra esses desafios, a Central de Segurança fornece ferramentas para:
For talecer a postura de segurança : A Central de Segurança avalia seu ambiente e permite que você
entenda o status de seus recursos e se eles são seguros.
Proteger contra ameaças : a Central de Segurança avalia a suas cargas de trabalho e gera
recomendações de prevenção de ameaças e alertas de segurança.
Ficar seguro com mais rapidez : Na Central de Segurança, tudo é feito na velocidade da nuvem. Por
ser integrada nativamente, a implantação da Central de Segurança é fácil, oferecendo provisionamento
automático e proteção com os serviços do Azure.
NOTE
Esse serviço dá suporte ao Azure Lighthouse, que permite que os provedores de serviços entrem no próprio locatário
para gerenciar assinaturas e grupos de recursos delegados pelos clientes. Para cenários da Central de Segurança do Azure,
uma assinatura precisa ser delegada em vez de grupos de recursos individuais.
Arquitetura
Como a Central de Segurança nativamente faz parte do Azure, os serviços de PaaS no Azure, incluindo o Service
Fabric, o Banco de Dados SQL, a Instância Gerenciada de SQL e as contas de armazenamento, são monitorados e
protegidos pela Central de Segurança sem necessidade de nenhuma implantação.
Além disso, a Central de Segurança protege servidores e máquinas virtuais que não são do Azure na nuvem ou
localmente, em servidores Windows e Linux, instalando o agente do Log Analytics neles. Máquinas virtuais do
Azure são provisionadas automaticamente na Central de Segurança.
Os eventos coletados dos agentes e do Azure são correlacionados no mecanismo de análise de segurança para
fornecer alertas de segurança e recomendações (tarefas de proteção) personalizados, que você deve seguir para
que suas cargas de trabalho fiquem seguras. Você deve investigar esses alertas assim que possível para verificar
se ataques mal-intencionados não estão ocorrendo em suas cargas de trabalho.
Quando você habilita a Central de Segurança, a política de segurança interna da Central de Segurança é refletida
no Azure Policy como uma iniciativa interna, sob a categoria Central de Segurança. A iniciativa interna é
atribuída automaticamente a todas as assinaturas registradas da Central de Segurança (independentemente de
elas terem ou não o Azure Defender habilitado). A iniciativa interna contém somente políticas de Auditoria. Para
obter mais informações sobre as políticas da Central de Segurança no Azure Policy, confira Trabalhando com
políticas de segurança.
Fortalecer a postura de segurança

A Central de Segurança do Azure permite que você fortaleça sua postura de segurança. Isso significa que ajuda
você a identificar e executar as tarefas de proteção recomendadas como melhores práticas de segurança e
implementá-las em seus aplicativos, serviços de dados e computadores. Isso inclui gerenciar e impor políticas
de segurança e verificar se suas máquinas virtuais do Azure, servidores não Azure e serviços PaaS do Azure
estão em conformidade. A Central de Segurança fornece as ferramentas de que você precisa para ter um
panorama de suas cargas de trabalho, com visibilidade focada no estado de segurança de rede da sua.
Gerenciar a conformidade e a política de segurança da organização
É um fundamento de segurança conhecer e verificar se suas cargas de trabalho estão seguras e isso começa
com estabelecer políticas de segurança sob medida. Como todas as políticas na Central de Segurança são
criadas sobre controles do Azure Policy, você está obtendo a toda a gama e a flexibilidade de uma solução de
política de alto nível . Na Central de Segurança, você pode definir suas políticas a serem executadas nos
grupos de gerenciamento, entre assinaturas e até mesmo para um locatário inteiro.
A Central de Segurança o ajuda a identificar as assinaturas de TI sombra . Examinando as assinaturas

rotuladas como não cober tas no seu painel, você pode saber imediatamente quando há assinaturas criadas
recentemente e garantir que elas sejam cobertas pelas suas políticas e protegidas pela Central de Segurança do
Azure.
Avaliações contínuas
A Central de Segurança descobre novos recursos que estão sendo implantados em suas cargas de trabalho e
avalia se estão configurados de acordo com as práticas recomendadas de segurança, caso contrário, são
sinalizados e você obtém uma lista priorizada de recomendações do que você precisará consertar
continuamente para de proteger seus computadores. A lista de recomendações é habilitada e compatível com o
Azure Security Benchmark, o conjunto específico de diretrizes do Azure, criado pela Microsoft, para as melhores
práticas de segurança e conformidade baseadas em estruturas de conformidade comuns. Esse parâmetro de
comparação amplamente respeitado se baseia nos controles do CIS (Center for Internet Security) e do NIST
(National Institute of Standards and Technology) com foco na segurança centrada na nuvem.
Para ajudar você a entender a importância de cada recomendação para sua postura de segurança geral, a
Central de Segurança agrupa as recomendações em controles de segurança e adiciona um valor de
classificação de segurança a cada controle. Isso é fundamental para permitir que você priorize seu
trabalho de segurança .
Mapa de rede
Uma das ferramentas mais avançadas que a Central de Segurança oferece para monitoramento contínuo do
status de segurança da sua rede é o Mapa de rede . O mapa permite que você veja a topologia de suas cargas
de trabalho para que você possa ver se cada nó está configurado corretamente. Você pode ver como os nós
estão conectados, o que ajuda a bloquear conexões indesejadas que poderiam potencialmente tornar mais fácil
para um invasor entrar na sua rede.
Otimizar e melhorar a segurança configurando controles recomendados
O cerne do valor da Central de Segurança do Azure está em suas recomendações. As recomendações são
personalizadas conforme as preocupações de segurança específicas encontradas em suas cargas de trabalho e a
Central de Segurança faz o trabalho de administração de segurança para você, não apenas encontrando suas
vulnerabilidades, como fornecendo instruções específicas sobre como eliminá-las.
Dessa forma, a Central de Segurança permite que você não apenas defina políticas de segurança, como aplique
padrões de configuração segura em todos os seus recursos.
As recomendações ajudam a reduzir a superfície de ataque em cada um de seus recursos. Isso inclui máquinas
virtuais do Azure, servidores não Azure e serviços de PaaS do Azure, como SQL e contas de Armazenamento e
mais – em que cada tipo de recurso é avaliado de maneira diferente e tem seus próprios padrões.
Proteção contra ameaças
A proteção contra ameaças da Central de Segurança permite que você detecte e evite ameaças na camada de
IaaS (infraestrutura como serviço), servidores não Azure, bem como para PaaS (Plataforma como Serviço) no
Azure.
A proteção contra ameaças da Central de Segurança inclui análise de cadeia de eliminação de fusão, que
correlaciona automaticamente alertas em seu ambiente com base na análise de cadeia de eliminação de
cibernéticos para ajudá-lo a entender melhor a história completa de uma campanha de ataque, o ponto de
partida e que tipo de impacto causou aos seus recursos.
Integração ao Microsoft Defender para Ponto de Extremidade

O Azure Defender para servidores inclui a integração automática e nativa ao Microsoft Defender para Ponto de
Extremidade. Saiba mais em Proteger seus pontos de extremidade com a solução EDR integrada da Central de
Segurança: Microsoft Defender para Ponto de extremidade
Proteger PaaS
A Central de Segurança ajuda a detectar ameaças em todos os serviços de PaaS do Azure. Você pode detectar
ameaças que tenham como alvo serviços do Azure, incluindo o Serviço de Aplicativo do Azure, SQL Azure,
Conta de Armazenamento do Azure e outros serviços de dados. Você também pode aproveitar a integração
nativa com o UEBA (Análise Comportamental de Entidade e Usuário do Microsoft Cloud App Security) para
executar a detecção de anomalias em seus logs de atividades do Azure.
Bloquear ataques de força bruta
A Central de Segurança ajuda a limitar a exposição a ataques de força bruta. Ao reduzir o acesso às portas de
máquina virtual, usando o acesso de VM Just-In-Time, você pode proteger sua rede, impedindo acesso
desnecessário. Você pode definir políticas de acesso seguro em portas selecionadas somente para usuários
autorizados, endereços IP ou intervalos de endereços IP de origem permitida por um tempo limitado.
Proteger serviços de dados
A Central de Segurança inclui funcionalidades que ajudam você a realizar a classificação automática dos seus
dados no SQL Azure. Você também pode obter avaliações de possíveis vulnerabilidades nos serviços de
Armazenamento e SQL do Azure e recomendações de como mitigá-las.
Ficar seguro com mais rapidez

A integração nativa do Azure (incluindo o Azure Policy e os logs do Azure Monitor) combinada com a integração
ininterrupta a outras soluções de segurança da Microsoft, como o Microsoft Cloud App Security e o Microsoft
Defender para Ponto de Extremidade, ajuda a garantir que a solução de segurança seja abrangente e simples de
integrar e distribuir.
Além disso, você pode estender a solução completa além do Azure para cargas de trabalho em execução em
outras nuvens e data centers locais.
Descobrir e integrar automaticamente recursos do Azure
A Central de Segurança fornece integração nativa perfeita do Azure com recursos do Azure. Isso significa que
você pode efetuar pull de uma história de segurança completa envolvendo o Azure Policy e políticas internas da
Central de Segurança em todos os seus recursos do Azure e verificar se tudo isso é aplicado automaticamente
para recursos recém-descobertos conforme você os cria no Azure.
Ampla coleta de log – logs do Windows e do Linux são todos aproveitados no mecanismo de análise de
segurança e usados para criar recomendações e alertas.
Próximas etapas
Para começar a usar a Central de Segurança, você precisa ter uma assinatura do Microsoft Azure. Se você
não tiver uma assinatura, você pode se inscrever em uma avaliação gratuita.
O tipo de preço Gratuito da Central de Segurança é habilitado em todas as suas assinaturas atuais do
Azure quando você acessa o painel da Central de Segurança do Azure no portal do Azure pela primeira
vez ou se ele é habilitado de maneira programática por meio da API. Para aproveitar as funcionalidades
avançadas de gerenciamento de segurança e detecção de ameaças, você deve habilitar o Azure Defender.
O Azure Defender pode ser avaliado gratuitamente durante 30 dias. Consulte a página de preços da
Central de Segurança para obter mais informações.
Se você estiver pronto para habilitar o Azure Defender agora, o Início Rápido: configuração da Central de
Segurança do Azure orienta você ao longo das etapas.
Linha de base de segurança do Azure para
Máquinas Virtuais do Linux
A linha de base de segurança do Azure para Máquinas Virtuais do Linux contém recomendações que ajudarão
você a melhorar a postura de segurança de sua implantação.
A linha de base para esse serviço é extraída do Azure Security Benchmark versão 1.0, que fornece
recomendações sobre como proteger suas soluções de nuvem no Azure com nossas diretrizes de melhores
práticas.
Para obter mais informações, consulte Visão geral sobre linhas de base de segurança do Azure.
Segurança de rede
Para saber mais, confira Controle de segurança: Segurança de rede.
1,1: proteger os recursos do Azure em redes virtuais
Orientação : ao criar uma VM (máquina virtual) do Azure, você deve criar uma rede virtual (vnet) ou usar uma
vnet existente e configurar a VM com uma sub-rede. Verifique se todas as sub-redes implantadas têm um grupo
de segurança de rede aplicado com controles de acesso à rede específicos para suas portas e fontes confiáveis
de aplicativos.
Como alternativa, se você tiver um caso de uso específico para um firewall centralizado, o Firewall do Azure
também poderá ser usado para atender a esses requisitos.
Como criar uma Rede Virtual
Como criar um NSG com uma configuração de segurança
Como implantar e configurar o Firewall do Azure
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
1,2: monitorar e registrar a configuração e o tráfego de redes virtuais, sub-redes e interfaces de rede
Diretrizes : Use a central de segurança do Azure para identificar e seguir as recomendações de proteção de rede
para ajudar a proteger seus recursos de VM (máquina virtual) do Azure no Azure. Habilite logs de fluxo NSG e
envie logs para uma conta de armazenamento para a auditoria de tráfego para as VMs para atividades
incomuns.
Como habilitar logs de fluxo de NSG
Entender a segurança de rede fornecida pela central de segurança do Azure
1.3: proteger aplicativos Web críticos
Orientação : se estiver usando sua VM (máquina virtual) para hospedar aplicativos Web, use um NSG (grupo
de segurança de rede) na sub-rede da VM para limitar o tráfego de rede, as portas e os protocolos que têm
permissão para se comunicar. Siga uma abordagem de rede com privilégios mínimos ao configurar o NSGs
para permitir somente o tráfego necessário para seu aplicativo.
Você também pode implantar o WAF (firewall do aplicativo Web) do Azure na frente de aplicativos Web críticos
para inspeção adicional do tráfego de entrada. Habilite a configuração de diagnóstico para WAF e ingerir logs
em uma conta de armazenamento, Hub de eventos ou espaço de trabalho de Log Analytics.
Criar um gateway de aplicativo com um firewall do aplicativo Web usando o portal do Azure
Informações sobre grupos de segurança de rede
1,4: negar comunicações com endereços IP mal-intencionados conhecidos
Orientação : habilitar a proteção padrão de DDoS (negação de serviço distribuído) nas redes virtuais para
proteger contra ataques de DDoS. Usando a inteligência de ameaças integrada da central de segurança do
Azure, você pode monitorar as comunicações com endereços IP mal-intencionados conhecidos. Configure o
Firewall do Azure em cada um de seus segmentos de rede virtual, com inteligência contra ameaças habilitada e
configurada para "alertar e negar" para tráfego de rede mal-intencionado.
Você pode usar o acesso à rede just in time da central de segurança do Azure para limitar a exposição de
Máquinas Virtuais do Linux aos endereços IP aprovados por um período limitado. Além disso, use a proteção de
rede adaptável da central de segurança do Azure para recomendar configurações de NSG que limitam portas e
IPs de origem com base no tráfego real e na inteligência contra ameaças.
Como configurar a proteção contra DDoS
Como implantar o Firewall do Azure
Compreender a inteligência contra ameaças integrada da Central de Segurança do Azure
Entender a proteção de rede adaptável da central de segurança do Azure
Entender o controle de acesso à rede just in time da central de segurança do Azure
1,5: gravar pacotes de rede
Orientação : você pode registrar os logs de fluxo do NSG em uma conta de armazenamento para gerar
registros de fluxo para suas máquinas virtuais do Azure. Ao investigar a atividade anômala, você pode habilitar
a captura de pacotes do observador de rede para que o tráfego de rede possa ser examinado quanto a
atividades incomuns e inesperadas.
Como habilitar o Observador de Rede
1,6: implantar os sistemas de detecção de intrusão/prevenção de invasão baseado em rede (IDS/IPS )
Orientação : combinando as capturas de pacote fornecidas pelo observador de rede e uma ferramenta de IDs
de código-fonte aberto, você pode executar a detecção de invasão de rede para uma ampla gama de ameaças.
Além disso, você pode implantar o Firewall do Azure nos segmentos de rede virtual conforme apropriado, com
inteligência contra ameaças habilitada e configurada para "alertar e negar" para tráfego de rede mal-
intencionado.
Executar a detecção de intrusão de rede com o observador de rede e ferramentas de código-fonte aberto
Como configurar alertas com o Firewall do Azure
1.7: gerenciar o tráfego para aplicativos Web
Orientação : você pode implantar aplicativo Azure gateway para aplicativos Web com HTTPS/SSL habilitado
para certificados confiáveis. Com o gateway de Aplicativo Azure, você direciona o tráfego da Web do aplicativo
para recursos específicos atribuindo ouvintes a portas, criando regras e adicionando recursos a um pool de
back-end, como máquinas virtuais do Linux.
Como implantar o gateway de aplicativo
Como configurar o gateway de aplicativo para usar HTTPS
Entender o balanceamento de carga de camada 7 com gateways de aplicativo Web do Azure
Monitoramento da central de segurança do Azure : não disponível
1.8: Minimizar a complexidade e a sobrecarga administrativa de regras de segurança de rede
Diretrizes : use marcas de serviço de rede virtual para definir controles de acesso à rede em grupos de
segurança de rede ou firewall do Azure configurados para suas máquinas virtuais do Azure. Você pode usar
marcas de serviço em vez de endereços IP específicos ao criar regras de segurança. Ao especificar o nome da
marca de serviço (por exemplo, ApiManagement) no campo correto de origem ou destino de uma regra, você
poderá permitir ou negar o tráfego para o serviço correspondente. A Microsoft gerencia os prefixos de endereço
englobados pela marca de serviço e atualiza automaticamente a marca de serviço em caso de alteração de
endereços.
Entender e usar marcas de serviço
1.9: manter configurações de segurança padrão para dispositivos de rede
Orientação : definir e implementar configurações de segurança padrão para VMs (máquinas virtuais) do Azure
usando o Azure Policy. Você também pode usar plantas do Azure para simplificar implantações de VM do Azure
de grande escala empacotando artefatos de ambiente-chave, como modelos de Azure Resource Manager,
atribuições de função e atribuições de Azure Policy, em uma única definição de Blueprint. Você pode aplicar o
plano gráfico às assinaturas e habilitar o gerenciamento de recursos por meio do controle de versão do
Blueprint.
Como configurar e gerenciar o Azure Policy
Exemplos de Azure Policy para rede
Como criar um blueprint do Azure
Monitoramento da central de segurança do Azure : não aplicável
1.10: documentar regras de configuração de tráfego
Orientação : você pode usar marcas para NSGs e outros recursos relacionados à segurança de rede e ao fluxo
de tráfego configurados para suas máquinas virtuais do Azure. Para regras NSG individuais, use o campo
"Descrição" para especificar a necessidade de negócios e/ou a duração de qualquer regra que permita o tráfego
de/para uma rede.
Como criar e usar marcas
1.11: usar ferramentas automatizadas para monitorar as configurações de recursos de rede e detectar
alterações
Diretrizes : Use o log de atividades do Azure para monitorar alterações em configurações de recursos de rede
relacionadas às suas máquinas virtuais. Crie alertas no Azure Monitor que serão disparados quando ocorrerem
alterações em configurações de rede ou recursos críticos.
Use Azure Policy para validar (e/ou corrigir) as configurações do recurso de rede relacionado a Máquinas
Virtuais do Linux.
Como exibir e recuperar eventos do log de atividades do Azure
Como criar alertas no Azure Monitor
Log e monitoramento
Para saber mais, confira Controle de segurança: Registro em log e monitoramento.
2.1: Usar fontes de sincronização de tempo aprovadas
Diretrizes : a Microsoft mantém fontes de tempo para recursos do Azure, no entanto, você tem a opção de
gerenciar as configurações de sincronização de tempo para seu máquinas virtuais do Linux.
Como configurar a sincronização de horário para recursos de computação do Azure
Responsabilidade : Compartilhado
2.2: configurar o gerenciamento central de log de segurança
Orientação : a central de segurança do Azure fornece monitoramento de log de eventos de segurança para
máquinas virtuais do Linux.
Coleta de dados na Central de Segurança do Azure
Para capturar os dados do syslog para monitoramento, será necessário habilitar a extensão Log Analytics
2.3: habilitar o registro em log de auditoria para recursos do Azure
Diretrizes : os logs de atividades podem ser usados para auditar operações e ações executadas em recursos de
máquina virtual. O log de atividades contém todas as operações de gravação (PUT, POST, DELETE) para seus
recursos, exceto operações de leitura (GET). Os logs de atividades podem ser usados para encontrar um erro ao
solucionar problemas ou para monitorar como um usuário em sua organização modificou um recurso.
Habilite a coleta de dados de diagnóstico do SO convidado implantando a extensão de diagnóstico em suas
máquinas virtuais (VM). Você pode usar a extensão de diagnóstico para coletar dados de diagnóstico como logs
de aplicativo ou contadores de desempenho de uma máquina virtual do Azure.
Para obter visibilidade avançada dos aplicativos e serviços com suporte nas máquinas virtuais, você pode
habilitar o Azure Monitor para VMs e o Application insights. Com Application Insights, você pode monitorar seu
aplicativo e capturar a telemetria, como solicitações HTTP, exceções e outras, para que você possa correlacionar
os problemas entre as VMs e seu aplicativo.
Além disso, habilite Azure Monitor para acesso aos seus logs de auditoria e de atividades que incluem origem
do evento, data, usuário, carimbo de data/hora, endereços de origem, endereços de destino e outros elementos
úteis.
Como coletar logs e métricas de plataforma com Azure Monitor
Visão geral do agente do log Analytics
Extensão da máquina virtual do log Analytics para Linux
Exibir e recuperar eventos do log de atividades do Azure
Visão geral do Application Insights
2.4: coletar logs de segurança de sistemas operacionais
Diretrizes : Use a central de segurança do Azure para fornecer monitoramento de log de eventos de segurança
para máquinas virtuais do Azure. Dado o volume de dados gerado pelo log de eventos de segurança, ele não é
armazenado por padrão.
Se sua organização quiser manter os dados do log de eventos de segurança da máquina virtual, ela poderá ser
armazenada em um espaço de trabalho Log Analytics na camada de coleta de dados desejada configurada na
central de segurança do Azure.
2.5: Configurar a retenção de armazenamento do log de segurança
Orientação : Verifique se as contas de armazenamento ou os espaços de trabalho log Analytics usados para
armazenar logs de máquina virtual têm o período de retenção de log definido de acordo com os regulamentos
de conformidade da sua organização.
Como monitorar máquinas virtuais no Azure
Como configurar Log Analytics período de retenção do espaço de trabalho
2,6: monitorar e examinar os logs
Diretrizes : habilite o agente de log Analytics, também conhecido como o Microsoft Monitoring Agent (MMA)
ou o agente do OMS Linux, e configure-o para enviar logs para um espaço de trabalho log Analytics. O agente
do Linux envia dados coletados de fontes diferentes para seu espaço de trabalho do Log Analytics no Azure
Monitor, bem como quaisquer logs ou métricas exclusivos, conforme definido em uma solução de
monitoramento.
Analise e monitore logs de comportamento anormal e Examine regularmente os resultados. Use Azure Monitor
para examinar os logs e executar consultas nos dados de log.
Como alternativa, você pode habilitar o e os dados integrados para o Azure Sentinel ou um SIEM de terceiros
para monitorar e examinar seus logs.
Extensão da máquina virtual do log Analytics para Linux
Como integrar o Azure Sentinel
Compreender o workspace do Log Analytics
Como realizar consultas personalizadas no Azure Monitor
2,7: habilitar alertas para atividades anômalas
Orientação : Use a central de segurança do Azure configurada com um espaço de trabalho log Analytics para
monitoramento e alerta em atividade anômala encontrada em logs de segurança e eventos para suas máquinas
virtuais do Azure.
para configurar alertas para atividades anormais.
Como gerenciar alertas na central de segurança do Azure
Como alertar sobre dados de log do log Analytics
2.8: centralizar o registro em log de antimalware
Orientação : você precisará de uma ferramenta de terceiros para a detecção de vulnerabilidades de anti-
malware para dentro do sistema operacional Linux.
Instruções para integração de servidores Linux à central de segurança do Azure
O link a seguir fornece as diretrizes de segurança recomendadas da Microsoft, que podem servir como
uma lista de critérios para o software de vulnerabilidade selecionado
2.9: habilitar o registro em log de consulta DNS
Diretrizes : implemente uma solução de terceiros do Azure Marketplace para a solução de registro em log DNS
de acordo com as necessidades da sua organização.
2.10: habilitar o registro em log de auditoria de linha de comando
Orientação : você pode configurar manualmente o log do console por nó e usar syslogs para armazenar os
dados. Além disso, use o espaço de trabalho Log Analytics do Azure Monitor para examinar os logs e executar
consultas em dados de syslog de máquinas virtuais do Azure.
Fontes de dados do Syslog no Azure Monitor
Identidade e controle de acesso

Para saber mais, confira Controle de segurança: Identidade e controle de acesso.
3.1: Manter um inventário de contas administrativas
Orientação : embora Azure Active Directory seja o método recomendado para administrar o acesso do usuário,
as máquinas virtuais do Azure podem ter contas locais. As contas locais e de domínio devem ser examinadas e
gerenciadas, normalmente com uma superfície mínima. Além disso, aproveite o Azure Privileged Identity
Management para contas administrativas usadas para acessar os recursos de máquinas virtuais.
As informações para contas locais estão disponíveis em
Informações sobre o Privileged Identity Manager
3.2: alterar senhas padrão quando aplicável
Diretrizes : Máquinas Virtuais do Linux e Azure Active Directory não têm o conceito de senhas padrão. Cliente
responsável por aplicativos de terceiros e serviços do Marketplace que podem usar senhas padrão.
Monitoramento da Central de Segurança do Azure : Não disponível
3.3: usar contas administrativas dedicadas
Diretrizes : Crie procedimentos operacionais padrão em relação ao uso de contas administrativas dedicadas
que têm acesso às suas máquinas virtuais. Use o gerenciamento de acesso e identidade da central de segurança
do Azure para monitorar o número de contas administrativas. Todas as contas de administrador usadas para
acessar os recursos de máquina virtual do Azure também podem ser gerenciadas pelo PIM (Privileged Identity
Management do Azure). O Azure Privileged Identity Management fornece várias opções, como a elevação just-
in-time, exigindo a autenticação multifator antes de assumir uma função e opções de delegação para que as
permissões só estejam disponíveis para intervalos de tempo específicos e exijam um Aprovador.
Entender a identidade e o acesso da central de segurança do Azure
3,4: usar o logon único (SSO ) do Azure Active Directory
Diretrizes : sempre que possível, o cliente pode usar o SSO com Azure Active Directory em vez de configurar
credenciais autônomas individuais por serviço. Use as recomendações de gerenciamento de acesso e identidade
da central de segurança do Azure.
Entendendo o SSO com o Azure AD
Como monitorar identidade e acesso na Central de Segurança do Azure
3,5: usar a autenticação multifator para todo o acesso baseado em Azure Active Directory
Diretrizes : Habilite a MFA do Azure AD e siga as recomendações de gerenciamento de acesso e identidade da
Central de Segurança do Azure.
Como habilitar a MFA no Azure
3,6: usar estações de trabalho seguras e gerenciadas pelo Azure para tarefas administrativas
Diretrizes : Use PAWs (estações de trabalho com acesso privilegiado) com a MFA configurada para fazer logon e
configurar recursos do Azure.
Saiba mais sobre Estações de Trabalho com Acesso Privilegiado
3,7: registrar em log e alertar sobre atividades suspeitas de contas administrativas
Orientação : Use Azure ad PRIVILEGED Identity Management (PIM) para a geração de logs e alertas quando
uma atividade suspeita ou não segura ocorrer no ambiente. Use as detecções de risco do Azure AD para ver
alertas e relatórios sobre o comportamento do usuário suspeito. Opcionalmente, o cliente pode ingerir alertas
de detecção de riscos da central de segurança do Azure em Azure Monitor e configurar alertas/notificações
personalizados usando grupos de ação.
Como implantar o Privileged Identity Management (PIM)
Noções básicas sobre as detecções de riscos da central de segurança do Azure (atividade suspeita)
Como integrar os logs de atividades do Azure ao Azure Monitor
Como configurar grupos de ação para alertas e notificações personalizados
3.8: gerenciar recursos do Azure provenientes somente de locais aprovados
Orientação : Use Azure Active Directory políticas de acesso condicional e locais nomeados para permitir o
acesso somente de agrupamentos lógicos específicos de intervalos de endereços IP ou países/regiões.
Como configurar localizações nomeadas no Azure
3.9: Use o Azure Active Directory Domain Services
Diretrizes : Use Azure Active Directory (AD do Azure) como o sistema de autenticação e autorização central. O
Azure AD protege os dados usando criptografia forte para dados em repouso e em trânsito. O Azure Active
Directory também inclui sais, hashes e armazena com segurança as credenciais do usuário. Você pode usar
identidades gerenciadas para autenticar em qualquer serviço que ofereça suporte à autenticação do Azure AD,
incluindo Key Vault, sem nenhuma credencial em seu código. Seu código em execução em uma máquina virtual
pode usar sua identidade gerenciada para solicitar tokens de acesso para serviços que dão suporte à
autenticação do Azure AD.
Como criar e configurar uma instância do Azure AD
Identidades gerenciadas para visão geral de recursos do Azure
3.10: revisar e reconciliar regularmente o acesso do usuário
Diretrizes : O Azure AD fornece logs para ajudar a descobrir contas obsoletas. Além disso, use Azure Active
Directory as revisões de acesso de identidade para gerenciar com eficiência as associações de grupo, o acesso
aos aplicativos empresariais e as atribuições de função. O acesso do usuário pode ser revisado regularmente
para garantir que apenas os usuários certos tenham acesso contínuo. Ao usar as máquinas virtuais do Azure,
você precisará examinar os grupos de segurança locais e os usuários para garantir que não haja contas
inesperadas que possam comprometer o sistema.
Como usar as revisões de acesso de identidade do Azure
3,11: monitorar tentativas de acessar credenciais desativadas
Orientação : definir configurações de diagnóstico para Azure Active Directory enviar os logs de auditoria e os
logs de entrada para um espaço de trabalho log Analytics. Além disso, use Azure Monitor para examinar os logs
e executar consultas em dados de syslog de autenticação de máquinas virtuais do Azure.
Fontes de dados do Syslog no Azure Monitor
3,12: alerta sobre o desvio do comportamento de entrada da conta
Orientação : Use os recursos de proteção de risco e identidade do Azure Active Directory para configurar
respostas automatizadas para ações suspeitas detectadas relacionadas aos recursos da sua conta de
armazenamento. Você deve habilitar respostas automatizadas por meio do Azure Sentinel para implementar as
respostas de segurança da sua organização.
Como exibir entradas suspeitas do Azure Active Directory
Como configurar e habilitar políticas de risco de proteção de identidade
3.13: fornecer à Microsoft acesso a dados relevantes do cliente durante cenários de suporte
Orientação : nos casos em que um terceiro precisa acessar os dados do cliente (como durante uma solicitação
de suporte), use sistema de proteção de dados do cliente para que as máquinas virtuais do Azure revisem e
aprovem ou rejeitem solicitações de acesso a dados do cliente.
Sistema de Proteção de Dados do Cliente para Microsoft Azure
Proteção de dados
Para saber mais, confira Controle de segurança: Proteção de dados.
4.1: Manter um inventário de informações confidenciais
Diretrizes : use marcas para ajudar a controlar as máquinas virtuais do Azure que armazenam ou processam
informações confidenciais.
4.2: isolar sistemas que armazenam ou processam informações confidenciais
Diretriz : implemente assinaturas e/ou grupos de gerenciamento separados para desenvolvimento, teste e
produção. Os recursos devem ser separados por rede virtual/sub-rede, marcados adequadamente e protegidos
em um NSG (grupo de segurança de rede) ou por um firewall do Azure. Para máquinas virtuais que armazenam
ou processam dados confidenciais, implemente políticas e procedimentos para desligá-los quando não
estiverem em uso.
Como criar assinaturas adicionais do Azure
Como criar Grupos de Gerenciamento
Como configurar alerta ou alerta e negar com o Firewall do Azure
4.3: monitorar e bloquear a transferência não autorizada de informações confidenciais
Orientação : implemente uma solução de terceiros em perímetros de rede que monitora a transferência não
autorizada de informações confidenciais e bloqueia tais transferências ao alertar os profissionais de segurança
de informações.
Para a plataforma subjacente que é gerenciada pela Microsoft, a Microsoft trata todo o conteúdo do cliente
como confidencial para proteger contra exposição e perda de dados do cliente. Para garantir que os dados do
cliente no Azure permaneçam seguros, a Microsoft implementou e mantém um conjunto de recursos e
controles robustos de proteção de dados.
Entender a proteção de dados do cliente no Azure
4.4: criptografar todas as informações confidenciais em trânsito
Orientação : os dados em trânsito para, de e entre as máquinas virtuais (VM) que executam o Linux são
criptografados de várias maneiras, dependendo da natureza da conexão, como ao se conectar a uma VM em
uma sessão RDP ou SSH.
A Microsoft usa o protocolo TLS para proteger dados quando está viajando entre os serviços de nuvem e os
clientes.
Criptografia em trânsito em VMs
4.5: usar uma ferramenta de descoberta ativa para identificar dados confidenciais
Orientação : Use uma ferramenta de descoberta ativa de terceiros para identificar todas as informações
confidenciais armazenadas, processadas ou transmitidas pelos sistemas de tecnologia da organização, incluindo
aquelas localizadas no local ou em um provedor de serviços remoto e atualize o inventário de informações
confidenciais da organização.
4.6: Usar o RBAC do Azure para controlar o acesso a recursos
Orientação : usando o Azure RBAC (controle de acesso baseado em função), você pode separar as tarefas
dentro de sua equipe e conceder apenas a quantidade de acesso aos usuários em sua VM que eles precisam
para executar seus trabalhos. Em vez de apresentar todas as permissões irrestritas na VM, você pode permitir
que apenas determinadas ações. Você pode configurar o controle de acesso para a VM no portal do Azure,
usando o CLI do Azure ou Azure PowerShell.
RBAC do Azure
Funções internas do Azure
4.7: usar a prevenção contra perda de dados baseada em host para impor controle de acesso
Orientação : implemente uma ferramenta de terceiros, como uma solução de prevenção contra perda de dados
baseada em host automatizada, para impor controles de acesso para atenuar o risco de violações de dados.
4.8: Criptografar informações confidenciais em repouso
Diretrizes : discos virtuais em máquinas virtuais do Linux (VM) são criptografados em repouso usando a
criptografia do lado do servidor ou o Ade (Azure Disk Encryption). Azure Disk Encryption aproveita o recurso
DM-Crypt do Linux para criptografar discos gerenciados com chaves gerenciadas pelo cliente na VM convidada.
A criptografia do lado do servidor com chaves gerenciadas pelo cliente aprimora o ADE, permitindo usar
quaisquer tipos de sistema operacional e imagens para as VMs, criptografando dados no serviço de
armazenamento.
Criptografia do lado do servidor de Azure Managed disks
VMs do Azure Disk Encryption para Linux
4.9: Registrar e alertar sobre alterações em recursos críticos do Azure
Diretrizes : Use Azure monitor com o log de atividades do Azure para criar alertas para quando as alterações
ocorrerem em máquinas virtuais e recursos relacionados.
Como criar alertas para eventos do log de atividades do Azure
Log da análise do Armazenamento do Azure
Gerenciamento de vulnerabilidades
Para saber mais, confira Controle de segurança: Gerenciamento de vulnerabilidades.
5.1: Executar ferramentas automatizadas de verificação de vulnerabilidade
Orientação : você precisará de uma ferramenta de terceiros para a detecção de vulnerabilidades de anti-
malware para dentro do sistema operacional Linux.
Instruções para integração de servidores Linux à central de segurança do Azure
Diretrizes de segurança recomendadas da Microsoft
5.2: implantar solução automatizada de gerenciamento de patch de sistema operacional
Diretrizes : Use a solução de gerenciamento de atualizações do Azure para gerenciar atualizações e patches
para suas máquinas virtuais. Gerenciamento de Atualizações se baseia no repositório de atualização
configurado localmente para corrigir os sistemas com suporte.
Solução Gerenciamento de Atualizações no Azure
Gerenciar atualizações e patches para suas VMs
5,3: implantar solução de gerenciamento de patch automatizado para títulos de software de terceiros
Orientação : você pode usar uma solução de gerenciamento de patches de terceiros. Você pode usar a solução
de Gerenciamento de Atualizações do Azure para gerenciar atualizações e patches para suas máquinas virtuais.
Gerenciamento de Atualizações se baseia no repositório de atualização configurado localmente para corrigir os
sistemas com suporte.
5.4: Comparar verificações de vulnerabilidade consecutivas
Diretrizes : exporte os resultados da verificação em intervalos consistentes e compare os resultados para
verificar se as vulnerabilidades foram corrigidas. Ao usar a recomendação de gerenciamento de vulnerabilidade
sugerida pela central de segurança do Azure, o cliente pode dinamizar o portal da solução selecionada para
exibir os dados de verificação históricas.
5.5: Usar um processo de avaliação de risco para priorizar a correção das vulnerabilidades descobertas
Diretrizes : Use as classificações de risco padrão (Pontuação segura) fornecidas pela central de segurança do
Azure.
Entender a pontuação segura da central de segurança do Azure
Inventário e gerenciamento de ativos

Para saber mais, confira Controle de segurança: Inventário e gerenciamento de ativos.
6,1: usar solução de descoberta de ativos automatizada
Orientação : Use o grafo de recursos do Azure para consultar e descobrir todos os recursos (incluindo
máquinas virtuais) em suas assinaturas. Verifique se você tem permissões (leitura) apropriadas em seu locatário
e é capaz de enumerar todas as assinaturas do Azure, bem como os recursos nas suas assinaturas.
Como criar consultas com o Azure Graph
Como exibir suas assinaturas do Azure
Entender o RBAC do Azure
6.2: manter metadados de ativo
Diretrizes : aplique marcas aos recursos do Azure, fornecendo metadados para organizá-los logicamente de
acordo com uma taxonomia.
6.3: excluir recursos do Azure não autorizados
Diretrizes : use marcação, grupos de gerenciamento e assinaturas separadas, quando apropriado, para
organizar e rastrear máquinas virtuais e recursos relacionados. Reconcilie o inventário regularmente e garanta
que os recursos não autorizados sejam excluídos da assinatura em tempo hábil.
6,4: definir e manter o inventário de recursos aprovados do Azure
Orientação : você deve criar um inventário de recursos aprovados do Azure e software aprovado para seus
recursos de computação. Você também pode usar controles de aplicativo adaptáveis, um recurso da central de
segurança do Azure para ajudá-lo a definir um conjunto de aplicativos que têm permissão para serem
executados em grupos de computadores configurados. Esse recurso está disponível para Windows Azure e não
Azure (todas as versões, clássicas ou Azure Resource Manager) e computadores Linux.
Como habilitar o controle de aplicativo adaptável
6.5: Monitorar recursos do Azure não aprovados
Diretrizes : Use o Azure Policy para colocar restrições nos tipos de recursos que podem ser criados em
assinaturas do cliente usando as seguintes definições de política interna:
Tipos de recursos não permitidos
Tipos de recursos permitidos
Além disso, use o Azure Resource Graph para consultar/descobrir recursos em sua(s) assinatura(s). Isso pode
ajudar em ambientes baseados em alta segurança, como aqueles com contas de armazenamento.
6.6: monitorar aplicativos de software não aprovados nos recursos de computação
Orientação : a automação do Azure fornece controle completo durante a implantação, operações e
encerramento de cargas de trabalho e recursos. Aproveite o inventário de máquina virtual do Azure para
automatizar a coleta de informações sobre todos os softwares em máquinas virtuais. Observação: o nome do
software, a versão, o Publicador e o tempo de atualização estão disponíveis no portal do Azure. Para obter
acesso a métricas e outras informações, o cliente precisou habilitar o diagnóstico em nível de convidado e pode
enviar informações de syslog para uma conta de armazenamento designada.
Além de usar Controle de Alterações para o monitoramento de aplicativos de software, os controles de
aplicativo adaptáveis na central de segurança do Azure usam o aprendizado de máquina para analisar os
aplicativos em execução em seus computadores e criar uma lista de permissões dessa inteligência. Esse recurso
simplifica muito o processo de configuração e manutenção de políticas de lista de permissões de aplicativo,
permitindo que você evite o uso de software indesejado em seu ambiente. Você pode configurar o modo de
auditoria ou o modo impor. O modo de auditoria só audita a atividade nas VMs protegidas. O modo impor
impõe as regras e verifica se os aplicativos que não têm permissão de execução estão bloqueados.
Extensão de diagnóstico para máquinas virtuais do Linux
Uma introdução à Automação do Azure
Como habilitar o inventário de VM do Azure
Entender os controles de aplicativo adaptáveis
6.7: Remover recursos e aplicativos de software não aprovados do Azure
encerramento de cargas de trabalho e recursos. Você pode usar Controle de Alterações para identificar todos os
softwares instalados em máquinas virtuais. Você pode implementar seu próprio processo ou usar a
configuração de estado da automação do Azure para remover software não autorizado.
Noções básicas sobre Controle de Alterações
6.8: Usar somente aplicativos aprovados
Orientação : Use os controles de aplicativo adaptáveis da central de segurança do Azure para garantir que
apenas o software autorizado seja executado e todos os softwares não autorizados sejam impedidos de serem
executados em máquinas virtuais do Azure.
Como usar os controles de aplicativo adaptáveis da central de segurança do Azure
6.9: Usar somente serviços do Azure aprovados
Como negar um tipo de recurso específico com o Azure Policy
6,10: manter um inventário de títulos de software aprovados
Orientação : o controle de aplicativo adaptável é uma solução inteligente, automatizada e de ponta a ponta da
central de segurança do Azure que ajuda a controlar quais aplicativos podem ser executados em suas máquinas
do Azure e não Azure (Windows e Linux). Implemente uma solução de terceiros se isso não atender aos
requisitos da sua organização.
6,11: limitar a capacidade dos usuários de interagir com Azure Resource Manager
Diretrizes : Use o acesso condicional do Azure para limitar a capacidade dos usuários de interagir com o Azure
Resource Manager configurando "Bloquear acesso" para o aplicativo de "Gerenciamento do Microsoft Azure".
Como configurar o acesso condicional para bloquear o acesso ao Azure Resource Manager
6.12: limitar a capacidade dos usuários de executar scripts nos recursos de computação
Orientação : dependendo do tipo de scripts, você pode usar configurações específicas do sistema operacional
ou recursos de terceiros para limitar a capacidade dos usuários de executar scripts nos recursos de computação
do Azure. Você também pode aproveitar os controles de aplicativo adaptáveis da central de segurança do Azure
para garantir que apenas o software autorizado seja executado e todos os softwares não autorizados sejam
impedidos de serem executados em máquinas virtuais do Azure.
6.13: Separar física ou logicamente os aplicativos de alto risco
Orientação : aplicativos de alto risco implantados em seu ambiente do Azure podem ser isolados usando redes
virtuais, sub-redes, assinaturas, grupos de gerenciamento e suficientemente protegidos com um firewall do
Azure, o WAF (firewall do aplicativo Web) ou o NSG (grupo de segurança de rede).
Visão geral do Firewall do Azure
Visão geral de Firewall de Aplicativo Web
Visão geral da segurança da rede
Visão geral da rede virtual do Azure
Organizar seus recursos com grupos de gerenciamento do Azure
Guia de decisão da assinatura
Configuração segura
Para saber mais, confira Controle de segurança: Configuração segura.
7.1: Estabelecer configurações seguras para todos os recursos do Azure
Diretrizes : Use Azure Policy ou a central de segurança do Azure para manter as configurações de segurança
para todos os recursos do Azure. Além disso, Azure Resource Manager tem a capacidade de exportar o modelo
no JavaScript Object Notation (JSON), que deve ser revisado para garantir que as configurações
atendam/excedam os requisitos de segurança para sua empresa.
Informações sobre como baixar o modelo de VM
7.2: estabelecer configurações seguras de sistema operacional
Orientação : Use a recomendação da central de segurança do Azure [corrigir vulnerabilidades em
configurações de segurança em suas máquinas virtuais] para manter as configurações de segurança em todos
os recursos de computação.
Como monitorar as recomendações da central de segurança do Azure
Como corrigir as recomendações da central de segurança do Azure
7.3: Manter configurações seguras de recursos do Azure
Diretrizes : use modelos de Azure Resource Manager e políticas do Azure para configurar com segurança os
recursos do Azure associados às máquinas virtuais. Azure Resource Manager modelos são arquivos baseados
em JSON usados para implantar a máquina virtual junto com os recursos do Azure e o modelo personalizado
precisará ser mantido. A Microsoft realiza a manutenção nos modelos de base. Use a política do Azure [negar] e
[implantar se não existir] para impor configurações seguras em seus recursos do Azure.
Informações sobre como criar modelos de Azure Resource Manager
Compreendendo os efeitos do Azure Policy
7.4: manter configurações seguras de sistema operacional
Diretrizes : há várias opções para manter uma configuração segura para VMs (máquinas virtuais) do Azure
para implantação:
1-modelos de Azure Resource Manager: são arquivos baseados em JSON usados para implantar uma VM do
portal do Azure, e o modelo personalizado precisará ser mantido. A Microsoft realiza a manutenção nos
modelos de base.
2-disco rígido virtual (VHD) personalizado: em algumas circunstâncias, pode ser necessário ter arquivos VHD
personalizados usados, como ao lidar com ambientes complexos que não podem ser gerenciados por outros
meios.
3-configuração de estado da automação do Azure: depois que o sistema operacional base for implantado, isso
poderá ser usado para um controle mais granular das configurações e imposto por meio da estrutura de
automação.
Para a maioria dos cenários, os modelos de VM base da Microsoft combinados com a configuração de estado
desejado da automação do Azure podem ajudar na reunião e manutenção dos requisitos de segurança.
Informações sobre a criação de modelos do ARM
Como carregar um VHD de VM personalizado para o Azure
7.5: armazenar configuração de recursos do Azure com segurança
Orientação : Use o Azure DevOps/repositórios para armazenar e gerenciar com segurança seu código, como
definições de Azure Policy personalizadas, modelos de Azure Resource Manager, scripts de configuração de
estado desejado e outros códigos. Para acessar os recursos que você gerencia no Azure DevOps, como seu
código, compilações e acompanhamento de trabalho, você deve ter permissões para esses recursos específicos.
A maioria das permissões é concedida por meio de grupos de segurança internos, conforme descrito em
permissões e acesso. Você pode conceder ou negar permissões a usuários específicos, grupos de segurança
internos ou grupos definidos no Azure Active Directory (AD do Azure) se integrados ao Azure DevOps ou Active
Directory se integrado ao TFS.
Como armazenar código no Azure DevOps
Sobre permissões e grupos no Azure DevOps
7.6: armazenar imagens personalizadas do sistema operacional com segurança
Orientação : se estiver usando imagens personalizadas (por exemplo, disco rígido virtual), use o controle de
acesso baseado em função do Azure (RBAC do Azure) para garantir que somente usuários autorizados possam
acessar as imagens.
Como configurar o RBAC do Azure
7,7: implantar as ferramentas de gerenciamento de configuração para recursos do Azure
Orientação : Aproveite Azure Policy para alertar, auditar e impor configurações do sistema para suas máquinas
virtuais. Desenvolva também um processo e um pipeline para gerenciar exceções de política.
Como configurar e gerenciar a política do Azure
7,8: implantar as ferramentas de gerenciamento de configuração para sistemas operacionais
Diretrizes : a configuração de estado da automação do Azure é um serviço de gerenciamento de configuração
para nós de DSC (configuração de estado desejado) em qualquer datacenter local ou na nuvem. Ela permite a
escalabilidade entre milhares de máquinas rápida e facilmente a partir de um local central e seguro. Você pode,
facilmente, integrar máquinas, atribuir a elas configurações declarativas e exibir relatórios que mostram a
conformidade de cada computador com o estado desejado especificado.
Integrar computadores para gerenciamento por Configuração de Estado da Automação do Azure
7,9: implementar o monitoramento automatizado de configuração para recursos do Azure
Orientação : Aproveite a central de segurança do Azure para executar verificações de linha de base para suas
máquinas virtuais do Azure. Métodos adicionais para configuração automatizada incluem o uso da configuração
de estado de automação do Azure.
Como corrigir recomendações na central de segurança do Azure
Introdução à Configuração de Estado da Automação do Azure
7.10: implementar monitoramento automatizado de configuração para sistemas operacionais
7.11: Gerenciar segredos do Azure com segurança
Diretrizes : Use identidade de serviço gerenciada em conjunto com Azure Key Vault para simplificar e proteger
o gerenciamento de segredos para seus aplicativos de nuvem.
Como integrar com identidades gerenciadas do Azure
Como criar um Key Vault
Como autenticar-se no Key Vault
Como atribuir uma política de acesso de Key Vault
7.12: gerenciar identidades de maneira segura e automática
Diretrizes : Use identidades gerenciadas para fornecer aos serviços do Azure uma identidade gerenciada
automaticamente no Azure AD. As identidades gerenciadas permitem que você se autentique em qualquer
serviço que dê suporte à autenticação do Azure AD, incluindo o Key Vault, sem ter credenciais em seu código.
Como configurar identidades gerenciadas
7.13: eliminar a exposição involuntária de credenciais
Diretriz : implemente o verificador de credenciais para identificar credenciais no código. O verificador de
credenciais também encorajará a migração de credenciais descobertas para locais mais seguros, como o Azure
Key Vault.
Como configurar o verificador de credenciais
Defesa contra malware

Para saber mais, confira Controle de segurança: Defesa contra malware.
8,1: usar software antimalware gerenciado centralmente
Orientação : você precisará de uma ferramenta de terceiros para proteção contra malware na máquina virtual
Linux do Azure.
Como configurar o Microsoft antimalware para serviços de nuvem e máquinas virtuais
8.2: Arquivos de pré -verificação a serem carregados para recursos não computados do Azure
Orientação : não aplicável a máquinas virtuais do Azure, pois é um recurso de computação.
Responsabilidade : Não aplicável
8.3: garantir que o software antimalware e as assinaturas sejam atualizados
Orientação : você precisará de uma ferramenta de terceiros para proteção contra malware na máquina virtual
Linux do Azure.
Recuperação de dados
Para saber mais, confira Controle de segurança: Recuperação de dados.
9,1: garantir back-ups automatizados regulares
Orientação : habilitar o backup do Azure e configurar as máquinas virtuais (VM) do Azure, bem como a
frequência e o período de retenção desejados para backups automáticos.
Uma visão geral do backup de VM do Azure
Fazer backup de uma VM do Azure usando as configurações da VM
9,2: executar backups completos do sistema e fazer backup de qualquer chave gerenciada pelo cliente
Orientação : Crie instantâneos de suas máquinas virtuais do Azure ou os discos gerenciados anexados a essas
instâncias usando o PowerShell ou APIs REST. Faça backup de qualquer chave gerenciada pelo cliente no Azure
Key Vault.
Habilite o backup do Azure e as máquinas virtuais (VM) do Azure de destino, bem como os períodos de
frequência e retenção desejados. Isso inclui o backup completo do estado do sistema. Se você estiver usando o
Azure Disk Encryption, o backup de VM do Azure manipulará automaticamente o backup de chaves gerenciadas
pelo cliente.
Backup em VMs do Azure que usam criptografia
Visão geral do backup de VM do Azure
Entenda como funcionam os backups automáticos
Como fazer backup de chaves do cofre de chaves no Azure
9,3: validar todos os backups, incluindo chaves gerenciadas pelo cliente
Orientação : garanta a capacidade de executar periodicamente a restauração de dados de conteúdo no backup
do Azure. Se necessário, teste o conteúdo de restauração em uma assinatura ou rede virtual isolada. Cliente
para testar a restauração de chaves de backup gerenciadas pelo cliente.
Se você estiver usando o Azure Disk Encryption, poderá restaurar a VM do Azure com as chaves de criptografia
de disco. Ao usar a criptografia de disco, você pode restaurar a VM do Azure com as chaves de criptografia de
disco.
Como recuperar arquivos do backup de máquina virtual do Azure
Como restaurar chaves do cofre de chaves no Azure
Como fazer backup e restaurar uma VM criptografada
9,4: garantir a proteção de backups e chaves gerenciadas pelo cliente
Orientação : quando você faz backup de VMs do Azure com o backup do Azure, as VMs são criptografadas em
repouso com o criptografia do serviço de armazenamento (SSE). O backup do Azure também pode fazer backup
de VMs do Azure que são criptografadas usando Azure Disk Encryption. O Azure Disk Encryption também se
integra com Azure Key Vault chaves de criptografia de chave (KEKs). Habilite a exclusão reversível no Key Vault
para proteger chaves contra exclusão acidental ou mal-intencionada.
Exclusão reversível para VMs
Visão geral de exclusão reversível do Azure Key Vault
Resposta a incidentes
Para saber mais, confira Controle de segurança: Resposta a incidentes.
10.1: Criar um guia de resposta a incidentes
Diretriz : crie um guia de resposta a incidentes para sua organização. Verifique se há planos de resposta a
incidentes escritos que definem todas as funções de pessoal, bem como as fases de tratamento/gerenciamento
de incidentes, desde a detecção até a revisão após o incidente.
Orientação sobre como criar seu processo de resposta a incidentes de segurança
Anatomia de um incidente do Microsoft Security Response Center
O cliente também pode aproveitar o guia de tratamento de incidentes de segurança do computador da
NIST para ajudar na criação de seu próprio plano de resposta a incidentes
10.2: criar um procedimento de pontuação e priorização de incidentes
Diretriz : a Central de Segurança atribui uma severidade a cada alerta para ajudar você a priorizar quais alertas
devem ser investigados primeiro. A severidade se baseia na confiança que a Central de Segurança tem na
constatação ou na análise usada para emitir o alerta, bem como no nível de confiança de que houve uma ação
mal-intencionada por trás da atividade que levou ao alerta. Além disso, marque claramente as assinaturas (por
exemplo, produção, não produção) usando marcas e crie um sistema de nomeação para identificar claramente e
categorizar os recursos do Azure, em especial aqueles que processam dados confidenciais. É sua
responsabilidade priorizar a correção de alertas com base na criticalidade dos recursos do Azure e do ambiente
em que o incidente ocorreu.
Alertas na Central de Segurança do Azure
Usar marcas para organizar seus recursos do Azure
10.3: Testar procedimentos de resposta de segurança
Diretriz : Conduza regularmente exercícios para testar os recursos de resposta a incidentes de seus sistemas
para ajudar a proteger seus recursos do Azure.
Identificar pontos fracos e lacunas e revisar o plano conforme necessário. Consulte a publicação do NIST:
guia para testar, treinar e exercitar programas para planos de ti e recursos
10.4: Fornecer detalhes de contato do incidente de segurança e configurar notificações de alerta para
incidentes de segurança
Diretriz : As informações de contato do incidente serão usadas pela Microsoft para contatá-lo se o MSRC
(Microsoft Security Response Center) descobrir que seus dados foram acessados por uma pessoa não
autorizada ou ilegal. Examine os incidentes após o fato para garantir que os problemas sejam resolvidos.
Como definir o contato de segurança da Central de Segurança do Azure
10.5: Incorporar alertas de segurança em seu sistema de resposta a incidentes
Diretriz : Exporte seus alertas e recomendações da Central de Segurança do Azure usando o recurso de
exportação contínua para ajudar a identificar riscos para os recursos do Azure. A exportação contínua permite
exportar alertas e recomendações de forma manual ou contínua. Você pode usar o conector de dados da
Central de Segurança do Azure para transmitir os alertas do Azure Sentinel.
Como configurar a exportação contínua
Como transmitir alertas para o Azure Sentinel
10.6: automatizar a resposta a alertas de segurança
Diretrizes : Use o recurso de automação de fluxo de trabalho na central de segurança do Azure para disparar
automaticamente respostas por meio de "aplicativos lógicos" em alertas de segurança e recomendações para
proteger os recursos do Azure.
Como configurar a automação de fluxo de trabalho e os Aplicativos Lógicos
Testes de penetração e exercícios de Red Team

Para saber mais, confira Controle de segurança: Testes de penetração e exercícios de Red Team.
11,1: realize testes de penetração regulares de seus recursos do Azure e garanta a correção de todas as
descobertas de segurança críticas
Diretrizes : siga as regras de envolvimento da Microsoft para garantir que seus testes de penetração não sejam
violações das políticas da Microsoft. Use a estratégia da Microsoft e a execução de equipes vermelhas e testes de
penetração de sites ativos em infraestrutura de nuvem, serviços e aplicativos gerenciados pela Microsoft.
Regras de participação para testes de penetração
Equipes Vermelhas do Microsoft Cloud
Próximas etapas
Confira o Azure Security Benchmark
Saiba mais sobre a Linhas de base de segurança do Azure
Linha de base de segurança do Azure para
Máquinas Virtuais do Windows
A linha de base de segurança do Azure para Máquinas Virtuais do Windows contém recomendações que
ajudarão você a melhorar a postura de segurança de sua implantação.
A linha de base para esse serviço é extraída do Azure Security Benchmark versão 1.0, que fornece
recomendações sobre como proteger suas soluções de nuvem no Azure com nossas diretrizes de melhores
práticas.
Para obter mais informações, consulte Visão geral sobre linhas de base de segurança do Azure.
Segurança de rede
Para saber mais, confira Controle de segurança: Segurança de rede.
1,1: proteger os recursos do Azure em redes virtuais
Orientação : ao criar uma VM (máquina virtual) do Azure, você deve criar uma rede virtual (vnet) ou usar uma
vnet existente e configurar a VM com uma sub-rede. Verifique se todas as sub-redes implantadas têm um grupo
de segurança de rede aplicado com controles de acesso à rede específicos para suas portas e fontes confiáveis
de aplicativos.
Como alternativa, se você tiver um caso de uso específico para um firewall centralizado, o Firewall do Azure
também poderá ser usado para atender a esses requisitos.
Como implantar e configurar o Firewall do Azure
1,2: monitorar e registrar a configuração e o tráfego de redes virtuais, sub-redes e interfaces de rede
Diretrizes : Use a central de segurança do Azure para identificar e seguir as recomendações de proteção de rede
para ajudar a proteger seus recursos de VM (máquina virtual) do Azure no Azure. Habilite logs de fluxo NSG e
envie logs para uma conta de armazenamento para a auditoria de tráfego para as VMs para atividades
incomuns.
Entender a segurança de rede fornecida pela central de segurança do Azure
1.3: proteger aplicativos Web críticos
Orientação : se estiver usando sua VM (máquina virtual) para hospedar aplicativos Web, use um NSG (grupo
de segurança de rede) na sub-rede da VM para limitar o tráfego de rede, as portas e os protocolos que têm
permissão para se comunicar. Siga uma abordagem de rede com privilégios mínimos ao configurar o NSGs
para permitir somente o tráfego necessário para seu aplicativo.
Você também pode implantar o WAF (firewall do aplicativo Web) do Azure na frente de aplicativos Web críticos
para inspeção adicional do tráfego de entrada. Habilite a configuração de diagnóstico para WAF e ingerir logs
em uma conta de armazenamento, Hub de eventos ou espaço de trabalho de Log Analytics.
Criar um gateway de aplicativo com um firewall do aplicativo Web usando o portal do Azure
Informações sobre grupos de segurança de rede
1,4: negar comunicações com endereços IP mal-intencionados conhecidos
Orientação : habilitar a proteção padrão de DDoS (negação de serviço distribuído) nas redes virtuais para
proteger contra ataques de DDoS. Usando a inteligência de ameaças integrada da central de segurança do
Azure, você pode monitorar as comunicações com endereços IP mal-intencionados conhecidos. Configure
adequadamente o Firewall do Azure em cada um de seus segmentos de rede virtual, com inteligência contra
ameaças habilitada e configurada para "alertar e negar" para tráfego de rede mal-intencionado.
Você pode usar o acesso à rede just in time da central de segurança do Azure para limitar a exposição de
Máquinas Virtuais do Windows aos endereços IP aprovados por um período limitado. Além disso, use a
proteção de rede adaptável da central de segurança do Azure para recomendar configurações de NSG que
limitam portas e IPs de origem com base no tráfego real e na inteligência contra ameaças.
Como configurar a proteção contra DDoS
Compreender a inteligência contra ameaças integrada da Central de Segurança do Azure
Entender a proteção de rede adaptável da central de segurança do Azure
Entender o controle de acesso à rede just in time da central de segurança do Azure
1,5: gravar pacotes de rede
Orientação : você pode registrar os logs de fluxo do NSG em uma conta de armazenamento para gerar
registros de fluxo para suas máquinas virtuais do Azure. Ao investigar a atividade anômala, você pode habilitar
a captura de pacotes do observador de rede para que o tráfego de rede possa ser examinado quanto a
atividades incomuns e inesperadas.
Como habilitar o Observador de Rede
1,6: implantar os sistemas de detecção de intrusão/prevenção de invasão baseado em rede (IDS/IPS )
Orientação : combinando as capturas de pacote fornecidas pelo observador de rede e uma ferramenta de IDs
de código-fonte aberto, você pode executar a detecção de invasão de rede para uma ampla gama de ameaças.
Além disso, você pode implantar o Firewall do Azure nos segmentos de rede virtual conforme apropriado, com
inteligência contra ameaças habilitada e configurada para "alertar e negar" para tráfego de rede mal-
intencionado.
Executar a detecção de intrusão de rede com o observador de rede e ferramentas de código-fonte aberto
Como configurar alertas com o Firewall do Azure
1.7: gerenciar o tráfego para aplicativos Web
Orientação : você pode implantar aplicativo Azure gateway para aplicativos Web com HTTPS/SSL habilitado
para certificados confiáveis. Com o gateway de Aplicativo Azure, você direciona o tráfego da Web do aplicativo
para recursos específicos atribuindo ouvintes a portas, criando regras e adicionando recursos a um pool de
back-end, como máquinas virtuais do Windows.
Como implantar o gateway de aplicativo
Como configurar o gateway de aplicativo para usar HTTPS
Entender o balanceamento de carga de camada 7 com gateways de aplicativo Web do Azure
1.8: Minimizar a complexidade e a sobrecarga administrativa de regras de segurança de rede
Diretrizes : use marcas de serviço de rede virtual para definir controles de acesso à rede em grupos de
segurança de rede ou firewall do Azure configurados para suas máquinas virtuais do Azure. Você pode usar
marcas de serviço em vez de endereços IP específicos ao criar regras de segurança. Ao especificar o nome da
marca de serviço (por exemplo, ApiManagement) no campo correto de origem ou destino de uma regra, você
poderá permitir ou negar o tráfego para o serviço correspondente. A Microsoft gerencia os prefixos de endereço
englobados pela marca de serviço e atualiza automaticamente a marca de serviço em caso de alteração de
endereços.
Entender e usar marcas de serviço
1.9: manter configurações de segurança padrão para dispositivos de rede
Orientação : definir e implementar configurações de segurança padrão para VMs (máquinas virtuais) do Azure
usando o Azure Policy. Você também pode usar plantas do Azure para simplificar implantações de VM do Azure
de grande escala empacotando artefatos de ambiente-chave, como modelos de Azure Resource Manager,
atribuições de função e atribuições de Azure Policy, em uma única definição de Blueprint. Você pode aplicar o
plano gráfico às assinaturas e habilitar o gerenciamento de recursos por meio do controle de versão do
Blueprint.
Como criar um blueprint do Azure
1.10: documentar regras de configuração de tráfego
Orientação : você pode usar marcas para NSG (grupos de segurança de rede) e outros recursos relacionados à
segurança de rede e ao fluxo de tráfego configurados para suas máquinas virtuais do Windows. Para regras
NSG individuais, use o campo "Descrição" para especificar a necessidade de negócios e/ou a duração de
qualquer regra que permita o tráfego de/para uma rede.
1.11: usar ferramentas automatizadas para monitorar as configurações de recursos de rede e detectar
alterações
Diretrizes : Use o log de atividades do Azure para monitorar alterações em configurações de recursos de rede
relacionadas às suas máquinas virtuais. Crie alertas no Azure Monitor que serão disparados quando ocorrerem
alterações em configurações de rede ou recursos críticos.
Use Azure Policy para validar (e/ou corrigir) as configurações do recurso de rede relacionado a Máquinas
Virtuais do Windows.
Como exibir e recuperar eventos do log de atividades do Azure
Como criar alertas no Azure Monitor
Log e monitoramento
Para saber mais, confira Controle de segurança: Registro em log e monitoramento.
2.1: Usar fontes de sincronização de tempo aprovadas
Diretrizes : a Microsoft mantém fontes de tempo para recursos do Azure, no entanto, você tem a opção de
gerenciar as configurações de sincronização de tempo para seu máquinas virtuais do Windows.
Como configurar a sincronização de horário para recursos de computação do Azure
Responsabilidade : Microsoft
2.2: configurar o gerenciamento central de log de segurança
Orientação : a central de segurança do Azure fornece monitoramento de log de eventos de segurança para
máquinas virtuais do Windows. Dado o volume de dados gerado pelo log de eventos de segurança, ele não é
Se sua organização quiser manter os dados do log de eventos de segurança da máquina virtual, ele poderá
ser armazenado em uma camada de coleta de dados, em que ponto ele pode ser consultado em Log
Analytics. Há diferentes camadas: mínima, comum e todas, que são detalhadas no link a seguir
2.3: habilitar o registro em log de auditoria para recursos do Azure
Diretrizes : os logs de atividades podem ser usados para auditar operações e ações executadas em recursos de
máquina virtual. O log de atividades contém todas as operações de gravação (PUT, POST, DELETE) para seus
recursos, exceto operações de leitura (GET). Os logs de atividades podem ser usados para encontrar um erro ao
solucionar problemas ou para monitorar como um usuário em sua organização modificou um recurso.
Habilite a coleta de dados de diagnóstico do SO convidado implantando a extensão de diagnóstico em suas
máquinas virtuais (VM). Você pode usar a extensão de diagnóstico para coletar dados de diagnóstico como logs
de aplicativo ou contadores de desempenho de uma máquina virtual do Azure.
Para obter visibilidade avançada dos aplicativos e serviços com suporte nas máquinas virtuais, você pode
habilitar o Azure Monitor para VMs e o Application insights. Com o Application Insights, você pode monitorar
seu aplicativo e capturar a telemetria, como solicitações HTTP, exceções, etc., para que você possa correlacionar
os problemas entre as VMs e seu aplicativo.
Além disso, habilite Azure Monitor para acesso aos seus logs de auditoria e de atividades que incluem origem
do evento, data, usuário, carimbo de data/hora, endereços de origem, endereços de destino e outros elementos
úteis.
Como coletar logs e métricas de plataforma com Azure Monitor
Extensão da máquina virtual do log Analytics para Windows
Exibir e recuperar eventos do log de atividades do Azure
Visão geral do Application Insights
2.4: coletar logs de segurança de sistemas operacionais
Diretrizes : Use a central de segurança do Azure para fornecer monitoramento de log de eventos de segurança
para máquinas virtuais do Azure. Dado o volume de dados gerado pelo log de eventos de segurança, ele não é
Se sua organização quiser manter os dados do log de eventos de segurança da máquina virtual, ela poderá ser
armazenada em um espaço de trabalho Log Analytics na camada de coleta de dados desejada configurada na
central de segurança do Azure.
2.5: Configurar a retenção de armazenamento do log de segurança
Orientação : Verifique se as contas de armazenamento ou os espaços de trabalho log Analytics usados para
armazenar logs de máquina virtual têm o período de retenção de log definido de acordo com os regulamentos
de conformidade da sua organização.
Como configurar Log Analytics período de retenção do espaço de trabalho
2,6: monitorar e examinar os logs
Diretrizes : habilite o agente de log Analytics, também conhecido como Microsoft Monitoring Agent (MMA) e
configure-o para enviar logs para um espaço de trabalho log Analytics. O agente do Windows envia dados
coletados de fontes diferentes para seu espaço de trabalho do Log Analytics no Azure Monitor, bem como
quaisquer logs ou métricas exclusivos, conforme definido em uma solução de monitoramento.
Analise e monitore logs de comportamento anormal e Examine regularmente os resultados. Use Azure Monitor
para examinar os logs e executar consultas nos dados de log.
para monitorar e examinar seus logs.
Extensão da máquina virtual do log Analytics para Windows
2,7: habilitar alertas para atividades anômalas
Orientação : Use a central de segurança do Azure configurada com um espaço de trabalho log Analytics para
monitoramento e alerta em atividade anômala encontrada em logs de segurança e eventos para suas máquinas
virtuais do Azure.
para configurar alertas para atividades anormais.
Como gerenciar alertas na central de segurança do Azure
Como alertar sobre dados de log do log Analytics
2.8: centralizar o registro em log de antimalware
Orientação : você pode usar o Microsoft antimalware para serviços de nuvem do Azure e máquinas virtuais e
configurar suas máquinas virtuais para registrar eventos em uma conta de armazenamento do Azure. Configure
um espaço de trabalho Log Analytics para ingerir os eventos das contas de armazenamento e criar alertas
quando apropriado. Siga as recomendações na central de segurança do Azure: "aplicativos de computação & ".
Como habilitar o monitoramento em nível de convidado para máquinas virtuais
2.9: habilitar o registro em log de consulta DNS
Diretrizes : implemente uma solução de terceiros do Azure Marketplace para a solução de registro em log DNS
de acordo com suas necessidades de organização.
2.10: habilitar o registro em log de auditoria de linha de comando
Orientação : a central de segurança do Azure fornece monitoramento de log de eventos de segurança para VMs
(máquinas virtuais) do Azure. A central de segurança provisiona a Microsoft Monitoring Agent em todas as VMs
do Azure com suporte e quaisquer novas criadas se o provisionamento automático estiver habilitado ou se você
puder instalar o agente manualmente. O agente habilita o evento de criação de processo 4688 e o campo
CommandLine dentro do evento 4688. Novos processos criados na VM são registrados pelo log de eventos e
monitorados pelos serviços de detecção da Central de Segurança.
Identidade e controle de acesso

Para saber mais, confira Controle de segurança: Identidade e controle de acesso.
3.1: Manter um inventário de contas administrativas
Orientação : embora Azure Active Directory seja o método recomendado para administrar o acesso do usuário,
as máquinas virtuais do Azure podem ter contas locais. As contas locais e de domínio devem ser examinadas e
gerenciadas, normalmente com uma superfície mínima. Além disso, aproveite o Azure Privileged Identity
Management para contas administrativas usadas para acessar os recursos de máquinas virtuais.
As informações para contas locais estão disponíveis em
3.2: alterar senhas padrão quando aplicável
Diretrizes : Máquinas Virtuais do Windows e Azure Active Directory não têm o conceito de senhas padrão.
Cliente responsável por aplicativos de terceiros e serviços do Marketplace que podem usar senhas padrão.
Monitoramento da Central de Segurança do Azure : Não disponível
3.3: usar contas administrativas dedicadas
Diretrizes : Crie procedimentos operacionais padrão em relação ao uso de contas administrativas dedicadas
que têm acesso às suas máquinas virtuais. Use o gerenciamento de acesso e identidade da central de segurança
do Azure para monitorar o número de contas administrativas. Todas as contas de administrador usadas para
acessar os recursos de máquina virtual do Azure também podem ser gerenciadas pelo PIM (Privileged Identity
Management do Azure). O Azure Privileged Identity Management fornece várias opções, como a elevação just-
in-time, exigindo a autenticação multifator antes de assumir uma função e opções de delegação para que as
permissões só estejam disponíveis para intervalos de tempo específicos e exijam um Aprovador.
Entender a identidade e o acesso da central de segurança do Azure
3,4: usar o logon único (SSO ) do Azure Active Directory
Diretrizes : sempre que possível, o cliente pode usar o SSO com Azure Active Directory em vez de configurar
credenciais autônomas individuais por serviço. Use as recomendações de gerenciamento de acesso e identidade
da central de segurança do Azure.
Logon único em aplicativos no Azure Active Directory
3,5: usar a autenticação multifator para todo o acesso baseado em Azure Active Directory
Diretrizes : Habilite a MFA do Azure AD e siga as recomendações de gerenciamento de acesso e identidade da
Central de Segurança do Azure.
3,6: usar estações de trabalho seguras e gerenciadas pelo Azure para tarefas administrativas
Diretrizes : Use PAWs (estações de trabalho com acesso privilegiado) com a MFA configurada para fazer logon e
configurar recursos do Azure.
Saiba mais sobre Estações de Trabalho com Acesso Privilegiado
3,7: registrar em log e alertar sobre atividades suspeitas de contas administrativas
Orientação : Use Azure ad PRIVILEGED Identity Management (PIM) para a geração de logs e alertas quando
uma atividade suspeita ou não segura ocorrer no ambiente. Use as detecções de risco do Azure AD para ver
alertas e relatórios sobre o comportamento do usuário suspeito. Opcionalmente, o cliente pode ingerir alertas
de detecção de riscos da central de segurança do Azure em Azure Monitor e configurar alertas/notificações
personalizados usando grupos de ação.
Como implantar o Privileged Identity Management (PIM)
Noções básicas sobre as detecções de riscos da central de segurança do Azure (atividade suspeita)
Como configurar grupos de ação para alertas e notificações personalizados
3.8: gerenciar recursos do Azure provenientes somente de locais aprovados
Orientação : Use Azure Active Directory políticas de acesso condicional e locais nomeados para permitir o
acesso somente de agrupamentos lógicos específicos de intervalos de endereços IP ou países/regiões.
Como configurar localizações nomeadas no Azure
3.9: Use o Azure Active Directory Domain Services
Diretrizes : Use Azure Active Directory (AD do Azure) como o sistema de autenticação e autorização central. O
Azure AD protege os dados usando criptografia forte para dados em repouso e em trânsito. O Azure Active
Directory também inclui sais, hashes e armazena com segurança as credenciais do usuário. Você pode usar
identidades gerenciadas para autenticar em qualquer serviço que ofereça suporte à autenticação do Azure AD,
incluindo Key Vault, sem nenhuma credencial em seu código. Seu código em execução em uma máquina virtual
pode usar sua identidade gerenciada para solicitar tokens de acesso para serviços que dão suporte à
Como criar e configurar uma instância do Azure AD
3.10: revisar e reconciliar regularmente o acesso do usuário
Diretrizes : O Azure AD fornece logs para ajudar a descobrir contas obsoletas. Além disso, use Azure Active
Directory as revisões de acesso de identidade para gerenciar com eficiência as associações de grupo, o acesso
aos aplicativos empresariais e as atribuições de função. O acesso do usuário pode ser revisado regularmente
para garantir que apenas os usuários certos tenham acesso contínuo. Ao usar as máquinas virtuais do Azure,
você precisará examinar os grupos de segurança locais e os usuários para garantir que não haja contas
inesperadas que possam comprometer o sistema.
Como usar as revisões de acesso de identidade do Azure
3,11: monitorar tentativas de acessar credenciais desativadas
Orientação : definir configurações de diagnóstico para Azure Active Directory enviar os logs de auditoria e os
logs de entrada para um espaço de trabalho log Analytics. Além disso, use Azure Monitor para examinar os logs
e executar consultas em dados de log de máquinas virtuais do Azure.
3,12: alerta sobre o desvio do comportamento de entrada da conta
Orientação : Use os recursos de proteção de risco e identidade do Azure Active Directory para configurar
respostas automatizadas para ações suspeitas detectadas relacionadas aos recursos da sua conta de
armazenamento. Você deve habilitar respostas automatizadas por meio do Azure Sentinel para implementar as
respostas de segurança da sua organização.
Como exibir entradas suspeitas do Azure Active Directory
Como configurar e habilitar políticas de risco de proteção de identidade
3.13: fornecer à Microsoft acesso a dados relevantes do cliente durante cenários de suporte
Orientação : nos casos em que um terceiro precisa acessar os dados do cliente (como durante uma solicitação
de suporte), use sistema de proteção de dados do cliente para que as máquinas virtuais do Azure revisem e
aprovem ou rejeitem solicitações de acesso a dados do cliente.
Noções básicas sobre Sistema de Proteção de Dados do Cliente
Proteção de dados
Para saber mais, confira Controle de segurança: Proteção de dados.
4.1: Manter um inventário de informações confidenciais
Diretrizes : use marcas para ajudar a controlar as máquinas virtuais do Azure que armazenam ou processam
informações confidenciais.
4.2: isolar sistemas que armazenam ou processam informações confidenciais
Diretriz : implemente assinaturas e/ou grupos de gerenciamento separados para desenvolvimento, teste e
produção. Os recursos devem ser separados por rede virtual/sub-rede, marcados adequadamente e protegidos
em um NSG (grupo de segurança de rede) ou por um firewall do Azure. Para máquinas virtuais que armazenam
ou processam dados confidenciais, implemente políticas e procedimentos para desligá-los quando não
estiverem em uso.
Como configurar alerta ou alerta e negar com o Firewall do Azure
4.3: monitorar e bloquear a transferência não autorizada de informações confidenciais
Orientação : implemente uma solução de terceiros em perímetros de rede que monitora a transferência não
autorizada de informações confidenciais e bloqueia tais transferências ao alertar os profissionais de segurança
de informações.
Para a plataforma subjacente que é gerenciada pela Microsoft, a Microsoft trata todo o conteúdo do cliente
como confidencial para proteger contra exposição e perda de dados do cliente. Para garantir que os dados do
cliente no Azure permaneçam seguros, a Microsoft implementou e mantém um conjunto de recursos e
controles robustos de proteção de dados.
Entender a proteção de dados do cliente no Azure
4.4: criptografar todas as informações confidenciais em trânsito
Orientação : os dados em trânsito para, de e entre as máquinas virtuais (VM) que executam o Windows são
criptografados de várias maneiras, dependendo da natureza da conexão, como ao se conectar a uma VM em
uma sessão RDP ou SSH.
A Microsoft usa o protocolo TLS para proteger dados quando está viajando entre os serviços de nuvem e os
clientes.
Criptografia em trânsito em VMs
4.5: usar uma ferramenta de descoberta ativa para identificar dados confidenciais
Orientação : Use uma ferramenta de descoberta ativa de terceiros para identificar todas as informações
confidenciais armazenadas, processadas ou transmitidas pelos sistemas de tecnologia da organização, incluindo
aquelas localizadas no local ou em um provedor de serviços remoto e atualize o inventário de informações
confidenciais da organização.
4.6: Usar o RBAC do Azure para controlar o acesso a recursos
Orientação : usando o Azure RBAC (controle de acesso baseado em função), você pode separar as tarefas
dentro de sua equipe e conceder apenas a quantidade de acesso aos usuários em sua VM que eles precisam
para executar seus trabalhos. Em vez de apresentar todas as permissões irrestritas na VM, você pode permitir
que apenas determinadas ações. Você pode configurar o controle de acesso para a VM no portal do Azure,
usando a CLI do Azure ou o Azure PowerShell.
RBAC do Azure
Funções internas do Azure
4.7: usar a prevenção contra perda de dados baseada em host para impor controle de acesso
Orientação : implemente uma ferramenta de terceiros, como uma solução de prevenção contra perda de dados
baseada em host automatizada, para impor controles de acesso para atenuar o risco de violações de dados.
4.8: Criptografar informações confidenciais em repouso
Diretrizes : discos virtuais em máquinas virtuais do Windows (VM) são criptografados em repouso usando a
criptografia do lado do servidor ou o Ade (Azure Disk Encryption). O Azure Disk Encryption aproveita o recurso
BitLocker do Windows para criptografar discos gerenciados com chaves gerenciadas pelo cliente na VM
convidada. A criptografia do lado do servidor com chaves gerenciadas pelo cliente aprimora o ADE, permitindo
usar quaisquer tipos de sistema operacional e imagens para as VMs, criptografando dados no serviço de
armazenamento.
Criptografia do lado do servidor de discos gerenciados pelo Azure
Azure Disk Encryption para VMs do Windows
4.9: Registrar e alertar sobre alterações em recursos críticos do Azure
Diretrizes : Use Azure monitor com o log de atividades do Azure para criar alertas para quando as alterações
ocorrerem em máquinas virtuais e recursos relacionados.
Log da análise do Armazenamento do Azure
Gerenciamento de vulnerabilidades
Para saber mais, confira Controle de segurança: Gerenciamento de vulnerabilidades.
5.1: Executar ferramentas automatizadas de verificação de vulnerabilidade
Orientação : siga as recomendações da central de segurança do Azure sobre como executar avaliações de
vulnerabilidade em suas máquinas virtuais do Azure. Use a solução recomendada de segurança do Azure ou de
terceiros para executar avaliações de vulnerabilidade para suas máquinas virtuais.
Como implementar recomendações de avaliação de vulnerabilidade da central de segurança do Azure
5.2: implantar solução automatizada de gerenciamento de patch de sistema operacional
Diretrizes : Use a solução de gerenciamento de atualizações do Azure para gerenciar atualizações e patches
para suas máquinas virtuais. Gerenciamento de Atualizações se baseia no repositório de atualização
configurado localmente para corrigir os sistemas Windows com suporte. Ferramentas como System Center
Updates Publisher (Updates Publisher) permitem que você publique atualizações personalizadas no Windows
Server Update Services (WSUS). Esse cenário permite que Gerenciamento de Atualizações patch de máquinas
que usam Configuration Manager como seu repositório de atualizações com software de terceiros.
5,3: implantar solução de gerenciamento de patch automatizado para títulos de software de terceiros
Orientação : você pode usar uma solução de gerenciamento de patches de terceiros. Você pode usar a solução
de Gerenciamento de Atualizações do Azure para gerenciar atualizações e patches para suas máquinas virtuais.
Gerenciamento de Atualizações se baseia no repositório de atualização configurado localmente para corrigir os
sistemas Windows com suporte. Ferramentas como System Center Updates Publisher (Updates Publisher)
permitem que você publique atualizações personalizadas no Windows Server Update Services (WSUS). Esse
cenário permite que Gerenciamento de Atualizações patch de máquinas que usam Configuration Manager
como seu repositório de atualizações com software de terceiros.
5.4: Comparar verificações de vulnerabilidade consecutivas
Diretrizes : exporte os resultados da verificação em intervalos consistentes e compare os resultados para
verificar se as vulnerabilidades foram corrigidas. Ao usar a recomendação de gerenciamento de vulnerabilidade
sugerida pela central de segurança do Azure, o cliente pode dinamizar o portal da solução selecionada para
exibir os dados de verificação históricas.
5.5: Usar um processo de avaliação de risco para priorizar a correção das vulnerabilidades descobertas
Diretrizes : Use as classificações de risco padrão (Pontuação segura) fornecidas pela central de segurança do
Azure.
Entender a pontuação segura da central de segurança do Azure
Inventário e gerenciamento de ativos

Para saber mais, confira Controle de segurança: Inventário e gerenciamento de ativos.
6,1: usar solução de descoberta de ativos automatizada
Orientação : Use o grafo de recursos do Azure para consultar e descobrir todos os recursos (incluindo
máquinas virtuais) em suas assinaturas. Verifique se você tem permissões (leitura) apropriadas em seu locatário
e é capaz de enumerar todas as assinaturas do Azure, bem como os recursos nas suas assinaturas.
Como exibir suas assinaturas do Azure
6.2: manter metadados de ativo
Diretrizes : aplique marcas aos recursos do Azure, fornecendo metadados para organizá-los logicamente de
acordo com uma taxonomia.
6.3: excluir recursos do Azure não autorizados
Diretrizes : use marcação, grupos de gerenciamento e assinaturas separadas, quando apropriado, para
organizar e rastrear máquinas virtuais e recursos relacionados. Reconcilie o inventário regularmente e garanta
que os recursos não autorizados sejam excluídos da assinatura em tempo hábil.
6,4: definir e manter o inventário de recursos aprovados do Azure
Orientação : você deve criar um inventário de recursos aprovados do Azure e software aprovado para seus
recursos de computação. Você também pode usar controles de aplicativo adaptáveis, um recurso da central de
segurança do Azure para ajudá-lo a definir um conjunto de aplicativos que têm permissão para serem
executados em grupos de computadores configurados. Esse recurso está disponível para Windows Azure e não
Azure (todas as versões, clássicas ou Azure Resource Manager) e computadores Linux.
Como habilitar o controle de aplicativo adaptável
6.5: Monitorar recursos do Azure não aprovados
Além disso, use o Azure Resource Graph para consultar/descobrir recursos em sua(s) assinatura(s). Isso pode
ajudar em ambientes baseados em alta segurança, como aqueles com contas de armazenamento.
6.6: monitorar aplicativos de software não aprovados nos recursos de computação
encerramento de cargas de trabalho e recursos. Aproveite o inventário de máquina virtual do Azure para
automatizar a coleta de informações sobre todos os softwares em máquinas virtuais. Observação: o nome do
software, a versão, o Publicador e o tempo de atualização estão disponíveis no portal do Azure. Para obter
acesso à data de instalação e outras informações, o cliente precisou habilitar o diagnóstico em nível de
convidado e colocar os logs de eventos do Windows em um espaço de trabalho Log Analytics.
Além de usar Controle de Alterações para o monitoramento de aplicativos de software, os controles de
aplicativo adaptáveis na central de segurança do Azure usam o aprendizado de máquina para analisar os
aplicativos em execução em seus computadores e criar uma lista de permissões dessa inteligência. Esse recurso
simplifica muito o processo de configuração e manutenção de políticas de lista de permissões de aplicativo,
permitindo que você evite o uso de software indesejado em seu ambiente. Você pode configurar o modo de
auditoria ou o modo impor. O modo de auditoria só audita a atividade nas VMs protegidas. O modo impor
impõe as regras e verifica se os aplicativos que não têm permissão de execução estão bloqueados.
Como habilitar o inventário de VM do Azure
Entender os controles de aplicativo adaptáveis
6.7: Remover recursos e aplicativos de software não aprovados do Azure
encerramento de cargas de trabalho e recursos. Você pode usar Controle de Alterações para identificar todos os
softwares instalados em máquinas virtuais. Você pode implementar seu próprio processo ou usar a
configuração de estado da automação do Azure para remover software não autorizado.
Controlar alterações no ambiente com a solução Controle de Alterações
Visão geral da configuração do estado de automação do Azure
6.8: Usar somente aplicativos aprovados
Orientação : Use os controles de aplicativo adaptáveis da central de segurança do Azure para garantir que
apenas o software autorizado seja executado e todos os softwares não autorizados sejam impedidos de serem
executados em máquinas virtuais do Azure.
6.9: Usar somente serviços do Azure aprovados
Diretrizes : Use a política do Azure para colocar restrições no tipo de recursos que podem ser criados em
assinaturas do cliente usando as seguintes definições de política interna:-não são tipos de recursos permitidos
Como negar um tipo de recurso específico com o Azure Policy
6,10: manter um inventário de títulos de software aprovados
Orientação : o controle de aplicativo adaptável é uma solução inteligente, automatizada e de ponta a ponta da
central de segurança do Azure que ajuda a controlar quais aplicativos podem ser executados em suas máquinas
do Azure e não Azure (Windows e Linux). Implemente uma solução de terceiros se isso não atender aos
requisitos da sua organização.
6,11: limitar a capacidade dos usuários de interagir com Azure Resource Manager
Diretrizes : Use o acesso condicional do Azure para limitar a capacidade dos usuários de interagir com o Azure
Resource Manager configurando "Bloquear acesso" para o aplicativo de "Gerenciamento do Microsoft Azure".
Como configurar o acesso condicional para bloquear o acesso ao Azure Resource Manager
6.12: limitar a capacidade dos usuários de executar scripts nos recursos de computação
Orientação : dependendo do tipo de scripts, você pode usar configurações específicas do sistema operacional
ou recursos de terceiros para limitar a capacidade dos usuários de executar scripts nos recursos de computação
do Azure. Você também pode aproveitar os controles de aplicativo adaptáveis da central de segurança do Azure
para garantir que apenas o software autorizado seja executado e todos os softwares não autorizados sejam
impedidos de serem executados em máquinas virtuais do Azure.
Como controlar a execução de script do PowerShell em ambientes Windows
6.13: Separar física ou logicamente os aplicativos de alto risco
Orientação : aplicativos de alto risco implantados em seu ambiente do Azure podem ser isolados usando rede
virtual, sub-rede, assinaturas, grupos de gerenciamento, etc. e suficientemente protegidos com um firewall do
Azure, o WAF (firewall do aplicativo Web) ou o NSG (grupo de segurança de rede).
Visão geral do Firewall do Azure
Visão geral de Firewall de Aplicativo Web
Visão geral da segurança da rede
Visão geral da rede virtual do Azure
Organizar seus recursos com grupos de gerenciamento do Azure
Guia de decisão da assinatura
Configuração segura
Para saber mais, confira Controle de segurança: Configuração segura.
7.1: Estabelecer configurações seguras para todos os recursos do Azure
Diretrizes : Use Azure Policy ou a central de segurança do Azure para manter as configurações de segurança
para todos os recursos do Azure. Além disso, Azure Resource Manager tem a capacidade de exportar o modelo
no JavaScript Object Notation (JSON), que deve ser revisado para garantir que as configurações
atendam/excedam os requisitos de segurança para sua empresa.
7.2: estabelecer configurações seguras de sistema operacional
Orientação : Use a recomendação da central de segurança do Azure [corrigir vulnerabilidades em
configurações de segurança em suas máquinas virtuais] para manter as configurações de segurança em todos
os recursos de computação.
Como monitorar as recomendações da central de segurança do Azure
Como corrigir as recomendações da central de segurança do Azure
7.3: Manter configurações seguras de recursos do Azure
Diretrizes : use modelos de Azure Resource Manager e políticas do Azure para configurar com segurança os
recursos do Azure associados às máquinas virtuais. Azure Resource Manager modelos são arquivos baseados
em JSON usados para implantar a máquina virtual junto com os recursos do Azure e o modelo personalizado
precisará ser mantido. A Microsoft realiza a manutenção nos modelos de base. Use a política do Azure [negar] e
[implantar se não existir] para impor configurações seguras em seus recursos do Azure.
Informações sobre como criar modelos de Azure Resource Manager
Compreendendo os efeitos do Azure Policy
7.4: manter configurações seguras de sistema operacional
Diretrizes : há várias opções para manter uma configuração segura para VMs (máquinas virtuais) do Azure
para implantação:
1-modelos de Azure Resource Manager: são arquivos baseados em JSON usados para implantar uma VM do
portal do Azure, e o modelo personalizado precisará ser mantido. A Microsoft realiza a manutenção nos
modelos de base.
2-disco rígido virtual (VHD) personalizado: em algumas circunstâncias, pode ser necessário ter arquivos VHD
personalizados usados, como ao lidar com ambientes complexos que não podem ser gerenciados por outros
meios.
3-configuração de estado da automação do Azure: depois que o sistema operacional base for implantado, isso
poderá ser usado para um controle mais granular das configurações e imposto por meio da estrutura de
automação.
Para a maioria dos cenários, os modelos de VM base da Microsoft combinados com a configuração de estado
desejado da automação do Azure podem ajudar na reunião e manutenção dos requisitos de segurança.
Informações sobre a criação de modelos do ARM
Como carregar um VHD de VM personalizado para o Azure
7.5: armazenar configuração de recursos do Azure com segurança
Diretrizes : Use Azure Repos para armazenar e gerenciar com segurança seu código, como políticas
personalizadas do Azure, modelos de Azure Resource Manager, scripts de configuração de estado desejado etc.
Para acessar os recursos que você gerencia no Azure DevOps, como seu código, compilações e
acompanhamento de trabalho, você deve ter permissões para esses recursos específicos. A maioria das
permissões é concedida por meio de grupos de segurança internos, conforme descrito em permissões e acesso.
Você pode conceder ou negar permissões a usuários específicos, grupos de segurança internos ou grupos
definidos no Azure Active Directory (AD do Azure) se integrados ao Azure DevOps ou Active Directory se
integrado ao TFS.
Como armazenar código no Azure DevOps
Sobre permissões e grupos no Azure DevOps
7.6: armazenar imagens personalizadas do sistema operacional com segurança
Orientação : se estiver usando imagens personalizadas (por exemplo, disco rígido virtual), use o controle de
acesso baseado em função do Azure (RBAC do Azure) para garantir que somente usuários autorizados possam
acessar as imagens.
Como configurar o RBAC do Azure
7,7: implantar as ferramentas de gerenciamento de configuração para recursos do Azure
Orientação : Aproveite Azure Policy para alertar, auditar e impor configurações do sistema para suas máquinas
virtuais. Desenvolva também um processo e um pipeline para gerenciar exceções de política.
7,8: implantar as ferramentas de gerenciamento de configuração para sistemas operacionais
7,9: implementar o monitoramento automatizado de configuração para recursos do Azure
Orientação : Aproveite a central de segurança do Azure para executar verificações de linha de base para suas
máquinas virtuais do Azure. Métodos adicionais para configuração automatizada incluem o uso da configuração
de estado de automação do Azure.
Como corrigir recomendações na central de segurança do Azure
Introdução à Configuração de Estado da Automação do Azure
7.10: implementar monitoramento automatizado de configuração para sistemas operacionais
7.11: Gerenciar segredos do Azure com segurança
Diretrizes : Use identidade de serviço gerenciada em conjunto com Azure Key Vault para simplificar e proteger
o gerenciamento de segredos para seus aplicativos de nuvem.
Como integrar com identidades de Azure-Managed
Como criar um Key Vault
Como autenticar-se no Key Vault
Como atribuir uma política de acesso de Key Vault
7.12: gerenciar identidades de maneira segura e automática
Diretrizes : Use identidades gerenciadas para fornecer aos serviços do Azure uma identidade gerenciada
automaticamente no Azure AD. As identidades gerenciadas permitem que você se autentique em qualquer
serviço que dê suporte à autenticação do Azure AD, incluindo o Key Vault, sem ter credenciais em seu código.
Como configurar identidades gerenciadas
7.13: eliminar a exposição involuntária de credenciais
Diretriz : implemente o verificador de credenciais para identificar credenciais no código. O verificador de
credenciais também encorajará a migração de credenciais descobertas para locais mais seguros, como o Azure
Key Vault.
Como configurar o verificador de credenciais
Defesa contra malware

Para saber mais, confira Controle de segurança: Defesa contra malware.
8,1: usar software antimalware gerenciado centralmente
Diretrizes : Use o Microsoft antimalware para máquinas virtuais do Windows do Azure para monitorar e
defender continuamente seus recursos.
8.2: Arquivos de pré -verificação a serem carregados para recursos não computados do Azure
Orientação : não aplicável a máquinas virtuais do Azure, pois é um recurso de computação.
Responsabilidade : Não aplicável
8.3: garantir que o software antimalware e as assinaturas sejam atualizados
Orientação : quando implantado, o Microsoft antimalware para Azure instalará automaticamente as
atualizações de assinatura, plataforma e mecanismo mais recentes por padrão. Siga as recomendações na
central de segurança do Azure: " & aplicativos de computação" para garantir que todos os pontos de
extremidade estejam atualizados com as assinaturas mais recentes. O sistema operacional Windows pode estar
mais protegido com segurança adicional para limitar o risco de ataques baseados em vírus ou malware com o
serviço de proteção avançada contra ameaças do Microsoft defender, que se integra à central de segurança do
Azure.
Como implantar o Microsoft antimalware para serviços de nuvem e máquinas virtuais do Azure
Proteção Avançada contra Ameaças do Microsoft Defender
Recuperação de dados
Para saber mais, confira Controle de segurança: Recuperação de dados.
9,1: garantir back-ups automatizados regulares
Orientação : habilitar o backup do Azure e configurar as máquinas virtuais (VM) do Azure, bem como a
frequência e o período de retenção desejados para backups automáticos.
Fazer backup de uma VM do Azure usando as configurações da VM
9,2: executar backups completos do sistema e fazer backup de qualquer chave gerenciada pelo cliente
Orientação : Crie instantâneos de suas máquinas virtuais do Azure ou os discos gerenciados anexados a essas
instâncias usando o PowerShell ou APIs REST. Faça backup de qualquer chave gerenciada pelo cliente no Azure
Key Vault.
Habilite o backup do Azure e as máquinas virtuais (VM) do Azure de destino, bem como os períodos de
frequência e retenção desejados. Isso inclui o backup completo do estado do sistema. Se você estiver usando o
Azure Disk Encryption, o backup de VM do Azure manipulará automaticamente o backup de chaves gerenciadas
pelo cliente.
Visão geral do backup de VM do Azure
Como fazer backup de chaves do cofre de chaves no Azure
9,3: validar todos os backups, incluindo chaves gerenciadas pelo cliente
Orientação : garanta a capacidade de executar periodicamente a restauração de dados de conteúdo no backup
do Azure. Se necessário, teste o conteúdo de restauração em uma assinatura ou rede virtual isolada. Cliente
para testar a restauração de chaves de backup gerenciadas pelo cliente.
Se você estiver usando o Azure Disk Encryption, poderá restaurar a VM do Azure com as chaves de criptografia
de disco. Ao usar a criptografia de disco, você pode restaurar a VM do Azure com as chaves de criptografia de
disco.
Como recuperar arquivos do backup de máquina virtual do Azure
Como restaurar chaves do cofre de chaves no Azure
Como fazer backup e restaurar uma VM criptografada
9,4: garantir a proteção de backups e chaves gerenciadas pelo cliente
Orientação : quando você faz backup de discos gerenciados pelo Azure com o backup do Azure, as VMs são
criptografadas em repouso com o criptografia do serviço de armazenamento (SSE). O backup do Azure também
pode fazer backup de VMs do Azure que são criptografadas usando Azure Disk Encryption. O Azure Disk
Encryption se integra com as chaves de criptografia do BitLocker (BEKs), que são protegidas em um cofre de
chaves como segredos. O Azure Disk Encryption também se integra com Azure Key Vault chaves de criptografia
de chave (KEKs). Habilite a exclusão reversível no Key Vault para proteger chaves contra exclusão acidental ou
mal-intencionada.
Exclusão reversível para VMs
Visão geral de exclusão reversível do Azure Key Vault
Resposta a incidentes
Para saber mais, confira Controle de segurança: Resposta a incidentes.
10.1: Criar um guia de resposta a incidentes
Diretriz : crie um guia de resposta a incidentes para sua organização. Verifique se há planos de resposta a
incidentes escritos que definem todas as funções de pessoal, bem como as fases de tratamento/gerenciamento
de incidentes, desde a detecção até a revisão após o incidente.
Orientação sobre como criar seu processo de resposta a incidentes de segurança
Anatomia de um incidente do Microsoft Security Response Center
O cliente também pode aproveitar o guia de tratamento de incidentes de segurança do computador da
NIST para ajudar na criação de seu próprio plano de resposta a incidentes
10.2: criar um procedimento de pontuação e priorização de incidentes
Diretriz : a Central de Segurança atribui uma severidade a cada alerta para ajudar você a priorizar quais alertas
devem ser investigados primeiro. A severidade se baseia na confiança que a Central de Segurança tem na
constatação ou na análise usada para emitir o alerta, bem como no nível de confiança de que houve uma ação
mal-intencionada por trás da atividade que levou ao alerta.
Além disso, marque claramente as assinaturas (por exemplo, produção, não produção) usando marcas e crie um
sistema de nomeação para identificar claramente e categorizar os recursos do Azure, em especial aqueles que
processam dados confidenciais. É sua responsabilidade priorizar a correção de alertas com base na criticalidade
dos recursos do Azure e do ambiente em que o incidente ocorreu.
Alertas na Central de Segurança do Azure
Usar marcas para organizar seus recursos do Azure
10.3: Testar procedimentos de resposta de segurança
Diretriz : Conduza regularmente exercícios para testar os recursos de resposta a incidentes de seus sistemas
para ajudar a proteger seus recursos do Azure. Identifique pontos fracos e lacunas e revise o plano conforme
necessário.
Veja a publicação do NIST: Guia para testar, treinar e exercitar programas para planos de TI e recursos
10.4: Fornecer detalhes de contato do incidente de segurança e configurar notificações de alerta para
incidentes de segurança
Diretriz : As informações de contato do incidente serão usadas pela Microsoft para contatá-lo se o MSRC
(Microsoft Security Response Center) descobrir que seus dados foram acessados por uma pessoa não
autorizada ou ilegal. Examine os incidentes após o fato para garantir que os problemas sejam resolvidos.
Como definir o contato de segurança da Central de Segurança do Azure
10.5: Incorporar alertas de segurança em seu sistema de resposta a incidentes
Diretriz : Exporte seus alertas e recomendações da Central de Segurança do Azure usando o recurso de
exportação contínua para ajudar a identificar riscos para os recursos do Azure. A exportação contínua permite
exportar alertas e recomendações de forma manual ou contínua. Você pode usar o conector de dados da
Central de Segurança do Azure para transmitir os alertas do Azure Sentinel.
Como configurar a exportação contínua
Como transmitir alertas para o Azure Sentinel
10.6: automatizar a resposta a alertas de segurança
Diretrizes : Use o recurso de automação de fluxo de trabalho na central de segurança do Azure para disparar
automaticamente respostas por meio de "aplicativos lógicos" em alertas de segurança e recomendações para
proteger os recursos do Azure.
Como configurar a automação de fluxo de trabalho e os Aplicativos Lógicos
Testes de penetração e exercícios de Red Team

Para saber mais, confira Controle de segurança: Testes de penetração e exercícios de Red Team.
11,1: realize testes de penetração regulares de seus recursos do Azure e garanta a correção de todas as
descobertas de segurança críticas
Diretrizes : siga as regras de envolvimento da Microsoft para garantir que seus testes de penetração não sejam
violações das políticas da Microsoft. Use a estratégia da Microsoft e a execução de equipes vermelhas e testes de
penetração de sites ativos em infraestrutura de nuvem, serviços e aplicativos gerenciados pela Microsoft.
Regras de participação para testes de penetração
Equipes Vermelhas do Microsoft Cloud
Próximas etapas
Confira o Azure Security Benchmark
Saiba mais sobre a Linhas de base de segurança do Azure
Recomendações de segurança para máquinas
virtuais no Azure
Este artigo contém recomendações de segurança para máquinas virtuais do Azure. Siga estas recomendações
para ajudar a atender as obrigações de segurança descritas em nosso modelo para responsabilidade
compartilhada. As recomendações também ajudarão você a melhorar a segurança geral para suas soluções de
aplicativo Web. Para obter mais informações sobre o que a Microsoft faz para atender às responsabilidades do
provedor de serviços, consulte responsabilidades compartilhadas para computação em nuvem.
Algumas das recomendações deste artigo podem ser abordadas automaticamente pela central de segurança do
Azure. A central de segurança do Azure é a primeira linha de defesa para seus recursos no Azure. Ela analisa
periodicamente o estado de segurança de seus recursos do Azure para identificar possíveis vulnerabilidades na
segurança. Em seguida, ele recomenda como tratar as vulnerabilidades. Para obter mais informações, consulte
recomendações de segurança na central de segurança do Azure.
Para obter informações gerais sobre a central de segurança do Azure, consulte o que é a central de segurança
do Azure?.
Geral
REC O M EN DA Ç Ã O C O M EN TÁ RIO S C EN T RA L DE SEGURA N Ç A
Ao criar imagens de VM Antes de criar imagens, instale as -

personalizadas, aplique as atualizações atualizações mais recentes para o
mais recentes. sistema operacional e para todos os
aplicativos que serão parte da sua
imagem.
manter as VMs atualizadas. Você pode usar a solução Sim

Gerenciamento de atualizações na
automação do Azure para gerenciar
atualizações do sistema operacional
para seus computadores Windows e
Linux no Azure.
Faça backup de suas VMs. O backup do Azure ajuda a proteger -

os dados do aplicativo e tem custos
operacionais mínimos. Erros de
aplicativo podem corromper seus
dados e erros humanos podem
introduzir bugs em seus aplicativos. O
backup do Azure protege suas VMs
que executam Windows e Linux.
Use várias VMs para obter maior Se sua VM executar aplicativos que -
resiliência e disponibilidade. devem ser altamente disponíveis, use
várias VMs ou conjuntos de
disponibilidade.
Adote uma estratégia de BCDR Azure Site Recovery permite que você -
(continuidade dos negócios e escolha entre diferentes opções criadas
recuperação de desastre). para dar suporte à continuidade dos
negócios. Ele dá suporte a diferentes
cenários de replicação e failover. Para
obter mais informações, consulte
About site Recovery.
Segurança de dados
Criptografar discos do sistema Azure Disk Encryption ajuda a Sim

operacional. criptografar seus discos de VM IaaS
Windows e Linux. Sem as chaves
necessárias, o conteúdo dos discos
criptografados não podem ser lidos. A
criptografia de disco protege dados
armazenados de acesso não
autorizado que de outra forma seriam
possíveis se o disco fosse copiado.
Criptografar discos de dados. Azure Disk Encryption ajuda a -

criptografar seus discos de VM IaaS
Windows e Linux. Sem as chaves
necessárias, o conteúdo dos discos
criptografados não podem ser lidos. A
criptografia de disco protege dados
armazenados de acesso não
autorizado que de outra forma seriam
possíveis se o disco fosse copiado.
Limite o software instalado. Limite o software instalado ao que é -

necessário para aplicar a solução com
êxito. Essa diretriz ajuda a reduzir a
superfície de ataque da solução.
Use antivírus ou antimalware. No Azure, você pode usar o software -

antimalware de fornecedores de
segurança, como Microsoft, Symantec,
Trend Micro e Kaspersky. Esse software
ajuda a proteger suas VMs contra
arquivos mal-intencionados, adware e
outras ameaças. Você pode implantar
o Microsoft Antimalware com base em
suas cargas de trabalho de aplicativo.
O Microsoft Antimalware está
disponível somente para
computadores Windows. Use a
configuração básica segura por padrão
ou personalizada avançada. Para obter
mais informações, consulte Microsoft
antimalware para serviços de nuvem
do Azure e máquinas virtuais.
Armazene segredos e chaves com Simplifique o gerenciamento de seus -

segurança. segredos e chaves fornecendo aos
proprietários do aplicativo uma opção
segura e gerenciada centralmente. Esse
gerenciamento reduz o risco de um
comprometimento acidental ou
vazamento. Azure Key Vault pode
armazenar com segurança suas chaves
em HSMs (módulos de segurança de
hardware) certificados para o FIPS
140-2 nível 2. Se você precisar usar o
FIPs 140,2 nível 3 para armazenar suas
chaves e segredos, poderá usar o HSM
dedicado do Azure.
Gerenciamento de identidade e de acesso

Centralize a autenticação de VM. Você pode centralizar a autenticação -

de suas VMs Windows e Linux usando
Azure Active Directory autenticação.
Monitoramento
Monitore suas VMs. Você pode usar Azure monitor para -

VMs para monitorar o estado de suas
VMs do Azure e conjuntos de
virtuais. Problemas de desempenho
com uma máquina virtual podem levar
a interrupção do serviço, o que viola o
princípio de segurança de
disponibilidade.
Rede
Restrinja o acesso às portas de Os invasores verificam intervalos de IP -

gerenciamento. de nuvem pública para portas de
gerenciamento aberto e tentam
ataques "fáceis", como senhas comuns
e vulnerabilidades não corrigidas
conhecidas. Você pode usar o acesso à
VM just-in-time (JIT) para bloquear o
tráfego de entrada para suas VMs do
Azure, reduzindo a exposição a
ataques ao mesmo tempo em que
fornece conexões fáceis às VMs
quando elas forem necessárias.
Limite o acesso à rede. Os grupos de segurança de rede -

permitem restringir o acesso à rede e
controlar o número de pontos de
extremidade expostos. Para obter mais
informações, consulte criar, alterar ou
excluir um grupo de segurança de
rede.
Próximas etapas
Verifique com seu provedor de aplicativos para saber mais sobre os requisitos de segurança adicionais. Para
obter mais informações sobre como desenvolver aplicativos seguros, consulte a documentação de
desenvolvimento seguro.
Proteja suas portas de gerenciamento com acesso
just-in-time
Bloqueie o tráfego de entrada para suas máquinas virtuais do Azure com o recurso de acesso à VM (máquina
virtual) JIT ( just-in-time) da central de segurança do Azure. Isso reduz a exposição a ataques e, ao mesmo
tempo, fornece acesso fácil quando você precisa se conectar a uma VM.
Para obter uma explicação completa sobre como o JIT funciona e a lógica subjacente, consulte o just-in-time
explicado.
Esta página ensina como incluir o JIT em seu programa de segurança. Você aprenderá a:
Habilitar o JIT em suas VMs – você pode habilitar o JIT com suas próprias opções personalizadas para
uma ou mais VMs usando a central de segurança, o PowerShell ou a API REST. Como alternativa, você pode
habilitar o JIT com parâmetros padrão, embutidos em código, de máquinas virtuais do Azure. Quando
habilitado, o JIT bloqueia o tráfego de entrada para suas VMs do Azure criando uma regra no seu grupo de
segurança de rede.
Solicitar acesso a uma VM que tenha o JIT habilitado -o objetivo do JIT é garantir que, embora o
tráfego de entrada seja bloqueado, a central de segurança ainda fornece acesso fácil para se conectar às VMs
quando necessário. Você pode solicitar acesso a uma VM habilitada para JIT da central de segurança,
máquinas virtuais do Azure, PowerShell ou API REST.
Auditar a atividade -para garantir que suas VMs sejam protegidas adequadamente, examine os acessos às
suas VMs habilitadas para JIT como parte de suas verificações de segurança regulares.
Disponibilidade
A SP EC TO DETA L H ES
Estado da versão: GA (Disponibilidade Geral)
Preço: Requer Azure Defender para Servidores
VMs com suporte: VMs implantadas por meio de Azure Resource Manager.
VM implantada com modelos de implantação clássicos.
Saiba mais sobre esses modelos de implantação.
VMs protegidas pelos firewalls do Azure controlados pelo
Gerenciador de firewall do Azure
Funções e permissões necessárias: As funções leitor e SecurityReader podem exibir o status e

os parâmetros do JIT.
Para criar funções personalizadas que podem funcionar com
o JIT, consulte quais permissões são necessárias para
configurar e usar o JIT?.
Para criar uma função com privilégios mínimos para usuários
que precisam solicitar acesso JIT a uma VM e não executar
outras operações JIT, use o script set-JitLeastPrivilegedRole
das páginas da Comunidade do GitHub da central de
segurança.
A SP EC TO DETA L H ES
Nuvens: Nuvens comerciais

Nacionais/soberanas (US Gov, China Gov, outros Gov)
Habilitar o acesso à VM JIT

Você pode habilitar o acesso à VM JIT com suas próprias opções personalizadas para uma ou mais VMs usando
a central de segurança ou programaticamente.
Como alternativa, você pode habilitar o JIT com parâmetros padrão, embutidos em código, de máquinas virtuais
do Azure.
Cada uma dessas opções é explicada em uma guia separada abaixo.
Central de segurança do Azure
Máquinas vir tuais do Azure
PowerShell
REST API
Habilitar o JIT em suas VMs na central de segurança do Azure
Na central de segurança, você pode habilitar e configurar o acesso à VM JIT.

1. Abra o painel do Azure defender e, na área proteção avançada, selecione acesso à VM just-in-time .
A página de acesso da VM just-in-time é aberta com suas VMs agrupadas nas seguintes guias:
Configurado -VMs que já foram configuradas para dar suporte ao acesso de VM just-in-time. Para
cada VM, a guia configurada mostra:
o número de solicitações de JIT aprovadas nos últimos sete dias
a data e a hora do último acesso
os detalhes de conexão configurados
o último usuário
Não configurado -VMs sem o JIT habilitado, mas que podem dar suporte a JIT. Recomendamos que
você habilite o JIT para essas VMs.
Não há supor te para VMs sem o JIT habilitado e que não dão suporte ao recurso. Sua VM pode estar
nessa guia pelos seguintes motivos:
NSG (grupo de segurança de rede) ausente-o JIT requer que um NSG seja configurado
VM clássica-JIT dá suporte a VMs implantadas por meio de Azure Resource Manager, não '
implantação clássica '. Saiba mais sobre os modelos de implantação clássicas do vs Azure
Resource Manager.
Outros-sua VM pode estar nessa guia se a solução JIT estiver desabilitada na política de
segurança da assinatura ou do grupo de recursos.
2. Na guia não configurada , marque as VMs a serem protegidas com JIT e selecione habilitar JIT em
VMs .
A página acesso à VM JIT é aberta listando as portas que a central de segurança recomenda proteger:
22: SSH
3389: RDP
5985: WinRM
5986: WinRM
Para aceitar as configurações padrão, selecione salvar .
3. Para personalizar as opções de JIT:
Adicione portas personalizadas com o botão Adicionar .
Modifique uma das portas padrão, selecionando-a na lista.
Para cada porta (personalizada e padrão), o painel Adicionar configuração de por ta oferece as
seguintes opções:
Protocolo -o protocolo que é permitido nesta porta quando uma solicitação é aprovada
IPS de origem permitidos -os intervalos de IP que são permitidos nesta porta quando uma
solicitação é aprovada
Tempo máximo de solicitação -a janela de tempo máxima durante a qual uma porta específica
pode ser aberta
a. Defina a segurança de porta para suas necessidades.
b. Selecione OK .
Editar a configuração de JIT em uma VM habilitada para JIT usando a central de segurança
Você pode modificar a configuração Just-in-time de uma VM adicionando e configurando uma nova porta para
proteger essa VM ou alterando qualquer outra configuração relacionada a uma porta já protegida.
Para editar as regras de JIT existentes para uma VM:
1. Abra o painel do Azure defender e, na área proteção avançada, selecione controles de aplicativo
adaptáveis .
2. Na guia configurada , clique com o botão direito do mouse na VM à qual você deseja adicionar uma
porta e selecione Editar.
3. Em Configuração de acesso JIT à VM , você pode editar as configurações existentes de uma porta já
protegida ou pode adicionar uma nova porta personalizada.
4. Quando terminar de editar as portas, selecione salvar .
Solicitar acesso a uma VM habilitada para JIT

Você pode solicitar acesso a uma VM habilitada para JIT do portal do Azure (na central de segurança ou em
máquinas virtuais do Azure) ou programaticamente.
Cada uma dessas opções é explicada em uma guia separada abaixo.
Central de segurança do Azure
Máquinas vir tuais do Azure
PowerShell
REST API
Solicitar acesso a uma VM habilitada para JIT da central de segurança do Azure
Quando uma VM tem um JIT habilitado, você precisa solicitar acesso para se conectar a ele. Você pode solicitar
acesso em qualquer uma das maneiras com suporte, independentemente de como você habilitou o JIT.
1. Na página acesso da VM just-in-time , selecione a guia configurada .
2. Marque as VMs que você deseja acessar.
O ícone na coluna detalhes da conexão indica se o JIT está habilitado no grupo de segurança de
rede ou no firewall. Se ele estiver habilitado em ambos, somente o ícone de firewall será exibido.
A coluna detalhes da conexão fornece as informações necessárias para conectar a VM e suas
portas abertas.
3. Selecione Solicitar acesso . A janela solicitar acesso é aberta.
4. Em Solicitar acesso , configure para cada VM as portas a abrir, os endereços IP de origem para os quais
a porta fica aberta e o intervalo de tempo durante o qual a porta fica aberta. Só será possível solicitar
acesso às portas configuradas. Cada porta tem um tempo máximo permitido derivado da configuração
de JIT que você criou.
5. Selecione Abrir por tas .
NOTE
Se um usuário que está solicitando acesso estiver atrás de um proxy, a opção Meu IP pode não funcionar. Pode ser que
você precise definir o intervalo completo de endereços IP da organização.
Auditar atividade de acesso JIT na central de segurança

Você pode obter informações sobre as atividades de VM usando a pesquisa de logs. Para exibir os logs:
1. Em acesso à VM just-in-time , selecione a guia configurada .
2. Para a VM que você deseja auditar, abra o menu de reticências no final da linha.
3. Selecione log de atividades no menu.
O log de atividades fornece uma exibição filtrada das operações anteriores para essa VM junto com a
hora, a data e a assinatura.
4. Para baixar as informações de log, selecione baixar como CSV .
Próximas etapas
Neste artigo, você aprendeu a configurar e usar o acesso de VM just-in-time. Para saber por que o JIT deve ser
usado, leia o artigo conceito que explica as ameaças com as quais está se defendendo:
Explicou o JIT
Proteger e usar políticas em máquinas virtuais no
Azure
É importante manter sua VM (máquina virtual) segura para os aplicativos que você executa. Proteger suas VMs
pode incluir um ou mais serviços do Azure e recursos que abrangem o acesso seguro a suas máquinas virtuais
e armazenamento seguro de seus dados. Este artigo fornece informações que permite que você mantenha sua
VM e aplicativos seguros.
Antimalware
O panorama atual de ameaças a ambientes de nuvem é dinâmico, aumentando a pressão para manter uma
proteção eficaz e atender aos requisitos de conformidade e segurança na nuvem. O Microsoft Antimalware para
Azure é uma funcionalidade de proteção em tempo real que ajuda a identificar e remover vírus, spyware e
outros softwares mal-intencionados. Os alertas podem ser configurados para notificar você quando se sabe que
software mal-intencionado ou indesejado tenta se instalar ou ser executado em sua VM. Não há suporte para
ele em VMs que executam o Linux ou o Windows Server 2008.

A Central de Segurança do Azure ajuda você a evitar, detectar e responder a ameaças às suas VMs. O Centro de
Segurança permite o gerenciamento de políticas e o monitoramento da segurança integrada entre suas
assinaturas do Azure, ajuda a detectar ameaças que poderiam passar despercebidas e funciona com uma
enorme variedade de soluções de segurança.
O acesso just-in-time da central de segurança pode ser aplicado em sua implantação de VM para bloquear o
tráfego de entrada para suas VMs do Azure, reduzindo a exposição a ataques e, ao mesmo tempo, fornecendo
acesso fácil para se conectar às VMs quando necessário. Quando o Just-In-Time está habilitado e um usuário
solicita acesso a uma VM, a Central de Segurança verifica quais permissões o usuário tem para a VM. Se o
usuário tem as permissões corretas, a solicitação é aprovada e a Central de Segurança configura
automaticamente os NSGs (Grupos de Segurança de Rede) para permitir o tráfego de entrada às portas
selecionadas pelo período limitado. Depois que o tempo expirar, a Central de Segurança restaura os NSGs aos
seus estados anteriores.
Criptografia
Dois métodos de criptografia são oferecidos para discos gerenciados. Criptografia no nível do sistema
operacional, que é Azure Disk Encryption e criptografia no nível da plataforma, que é a criptografia do lado do
servidor.
Os discos gerenciados do Azure criptografam automaticamente os dados por padrão ao enviá-los para a
nuvem. A criptografia do lado do servidor protege seus dados e ajuda a atender aos compromissos de
segurança e conformidade da organização. Os dados nos discos gerenciados são criptografados de maneira
transparente usando a criptografia AES de 256 bits, uma das codificações de bloco mais fortes disponíveis, e são
compatíveis com o FIPS 140-2.
A criptografia não afeta o desempenho dos discos gerenciados. Não há nenhum custo adicional para a
criptografia.
Você pode contar com chaves gerenciadas pela plataforma para a criptografia do disco gerenciado ou gerenciar
a criptografia usando suas próprias chaves. Se você optar por gerenciar a criptografia com suas próprias chaves,
pode especificar uma chave gerenciada pelo cliente a ser usada para criptografar e descriptografar todos os
dados nos discos gerenciados.
Para saber mais sobre a criptografia do lado do servidor, consulte os artigos para Windows ou Linux.
Para conformidade e segurança aprimorados da VM do Windows e da VM do Linux, os discos virtuais no Azure
podem ser criptografados. Discos virtuais em VMs do Windows são criptografados em repouso usando o
BitLocker. Os discos virtuais em VMs do Linux são criptografados em repouso usando dm-crypt.
Não há nenhuma taxa para criptografar discos virtuais no Azure. Chaves e criptográficas são armazenadas no
Cofre de chaves do Azure usando a proteção de software ou você pode importar ou gerar as chaves em
Módulos de segurança de Hardware (HSMs) certificados para padrões de nível 2 de FIPS 140-2. Essas chaves
criptográficas são usadas para criptografar e descriptografar os discos virtuais conectados à sua VM. Você
mantém o controle dessas chaves criptográficas e pode auditar seu uso. Uma entidade de serviço do Azure
Active Directory fornece um mecanismo seguro para emitir essas chaves de criptografia, enquanto as VMs são
ligadas e desligadas.
Key Vault e chaves SSH

Os certificados e segredos podem ser modelados como recursos e fornecidos pelo Key Vault. Você pode usar o
Azure PowerShell para criar os cofres de chaves de VMs do Windows e a CLI do Azure para VMs do Linux. Você
também pode criar chaves de criptografia.
As políticas de acesso do cofre de chaves concedem permissões a chaves, segredos e certificados
separadamente. Por exemplo, você pode dar a um usuário acesso apenas a chaves, mas nenhuma permissão
para segredos. No entanto, as permissões para acessar chaves, segredos ou certificados estão no nível de cofre.
Em outras palavras, a política de acesso de cofre de chaves não dá suporte a permissões em nível de objeto.
Quando você se conectar a máquinas virtuais, deverá usar a criptografia de chave pública para fornecer uma
maneira mais segura para entrar neles. Esse processo envolve uma troca de chaves públicas e privadas usando
o comando SSH (secure shell) para autenticar a si mesmo em vez de um nome de usuário e uma senha. As
senhas são vulneráveis a ataques de força bruta, especialmente em VMs voltadas para a Internet, como os
servidores Web. Com um par de chaves SSH (secure shell), você pode criar uma VM do Linux que usa chaves
SSH para autenticação, eliminando a necessidade de senhas para fazer entrar. Você também pode usar as chaves
de SSH para conectar-se de uma VM do Windows para uma VM do Linux.
Identidades gerenciadas dos recursos do Azure

Um desafio comum ao criar aplicativos de nuvem é como gerenciar as credenciais no código para autenticar
serviços de nuvem. Proteger as credenciais é uma tarefa importante. O ideal é que as credenciais nunca
apareçam em estações de trabalho do desenvolvedor e não sejam verificadas no controle de origem. O Azure
Key Vault fornece uma maneira de armazenar com segurança as credenciais, os segredos e outras chaves, mas
seu código precisa se autenticar no Key Vault para recuperá-los.
As identidades de gerenciado para a funcionalidade de recursos do Azure no Azure AD (Azure Active Directory)
resolve esse problema. O recurso oferece aos serviços do Azure uma identidade gerenciada automaticamente
no Azure AD. Você pode usar a identidade para se autenticar em qualquer serviço que dê suporte à autenticação
do Azure AD, incluindo o Key Vault, sem ter credenciais em seu código. O código em execução na VM pode
solicitar um token de dois pontos de extremidade que só podem ser acessados de dentro da VM. Para obter
mais informações sobre esse serviço, examine a página de visão geral Identidades gerenciadas para recursos do
Azure.
Políticas
As Políticas do Azure podem ser usadas para definir o comportamento desejado para as VMs do Windows e
VMs do Linux da sua organização. Usando políticas, uma organização pode impor várias convenções e regras
em toda a empresa. A imposição do comportamento desejado pode ajudar a reduzir o risco e contribui para o
sucesso da organização.

Usando o Azure RBAC (controle de acesso baseado em função), você pode separar as tarefas dentro de sua
equipe e conceder apenas a quantidade de acesso aos usuários em sua VM que eles precisam para executar
seus trabalhos. Em vez de apresentar todas as permissões irrestritas na VM, você pode permitir que apenas
determinadas ações. Você pode configurar o controle de acesso para a VM no portal do Azure, usando a CLI do
Azure ou o Azure PowerShell.
Próximas etapas
Siga as etapas para monitorar a segurança da máquina virtual usando a Central de Segurança do Azure para
Linux ou Windows.
Controles de Conformidade Regulatória do Azure
Policy para as Máquinas Virtuais do Azure
A Conformidade Regulatória no Azure Policy fornece definições de iniciativas criadas e gerenciadas pela
Microsoft, conhecidas como internos, para os domínios de conformidade e os controles de segurança
relacionados a diferentes padrões de conformidade. Esta página lista os domínios de conformidade e os
controles de segurança para as Máquinas Virtuais do Azure. Você pode atribuir os itens internos a um
controle de segurança individualmente a fim de ajudar a manter seus recursos do Azure em conformidade
com o padrão específico.
O título de cada definição de política interna leva à definição da política no portal do Azure. Use o link na coluna
Versão da Política para ver a origem no repositório GitHub do Azure Policy.
IMPORTANT
Cada controle abaixo está associado com uma ou mais definições do Azure Policy. Essas políticas podem ajudar você a
avaliar a conformidade com o controle. No entanto, geralmente não há uma correspondência um para um ou completa
entre um controle e uma ou mais políticas. Dessa forma, Conformidade no Azure Policy refere-se somente às próprias
políticas. Não garante que você está totalmente em conformidade com todos os requisitos de um controle. Além disso, o
padrão de conformidade inclui controles que não são abordados por nenhuma definição do Azure Policy no momento.
Portanto, a conformidade no Azure Policy é somente uma exibição parcial do status de conformidade geral. As associações
entre os controles e as definições de Conformidade Regulatória do Azure Policy para esses padrões de conformidade
podem ser alteradas ao longo do tempo.
Azure Security Benchmark

Security Benchmark.
VERSÃ O DA
Segurança de rede NS-1 Implementar a As recomendações 3.0.0

segurança para da proteção de rede
tráfego interno adaptável devem ser
aplicadas nas
máquinas virtuais
para a Internet
Segurança de rede NS-1 Implementar a As máquinas virtuais 3.0.0

segurança para para a Internet
tráfego interno devem ser protegidas
com grupos de
segurança de rede
VERSÃ O DA
DO M ÍN IO ID DO C O N T RO L E C O N T RO L E
Segurança de rede NS-1 Implementar a O encaminhamento 3.0.0

segurança para IP na máquina virtual
tráfego interno deve ser desabilitado
Segurança de rede NS-1 Implementar a As portas de 3.0.0

segurança para gerenciamento de
tráfego interno máquinas virtuais
devem ser protegidas
com o controle de
acesso à rede just-in-
time
Segurança de rede NS-1 Implementar a Portas de 3.0.0

segurança para gerenciamento
tráfego interno devem ser fechadas
nas máquinas
virtuais
Segurança de rede NS-4 Proteger aplicativos e As recomendações 3.0.0

serviços contra da proteção de rede
ataques de rede adaptável devem ser
externa aplicadas nas
máquinas virtuais
para a Internet
Segurança de rede NS-4 Proteger aplicativos e As máquinas virtuais 3.0.0

serviços contra para a Internet
ataques de rede devem ser protegidas
externa com grupos de
segurança de rede
Segurança de rede NS-4 Proteger aplicativos e O encaminhamento 3.0.0

serviços contra IP na máquina virtual
ataques de rede deve ser desabilitado
externa
Segurança de rede NS-4 Proteger aplicativos e As portas de 3.0.0

serviços contra gerenciamento de
ataques de rede máquinas virtuais
externa devem ser protegidas
com o controle de
time
Proteção de dados DP-2 proteger dados A criptografia de 2.0.0

confidenciais disco deve ser
aplicada em
Máquinas virtuais
Proteção de dados DP-4 Criptografar as Os servidores Web 2.0.0

informações do Windows devem
confidenciais em ser configurados para
trânsito usar protocolos de
comunicação segura
VERSÃ O DA
Proteção de dados DP-5 criptografar dados A criptografia de 2.0.0

confidenciais em disco deve ser
repouso aplicada em
Máquinas virtuais
Gerenciamento de AM-3 usar somente As máquinas virtuais 1.0.0

Ativos serviços do Azure devem ser migradas
aprovados para os novos
recursos do Azure
Resource Manager
Gerenciamento de AM-6 Usar apenas Os controles de 3.0.0

Ativos aplicativos aprovados aplicativos adaptáveis
em recursos de para definir
computação aplicativos seguros
devem estar
habilitados nos
computadores
Log e detecção de LT-3 Habilitar o registro O agente de coleta 1.0.1 – versão prévia
ameaças em log para de dados do tráfego
atividades de rede do de rede deve ser
Azure instalado nas
máquinas virtuais do
Linux
Log e detecção de LT-3 Habilitar o registro O agente de coleta 1.0.1 – versão prévia
ameaças em log para dos dados de tráfego
atividades de rede do de rede deve ser
Azure instalado nas
Windows
Log e detecção de LT-4 Habilitar o registro os logs de recurso 2.0.1

ameaças em log para recursos nos Conjuntos de
do Azure Dimensionamento de
Máquinas Virtuais
devem ser
habilitados
Log e detecção de LT-5 Centralizar o Os problemas de 1.0.0

ameaças gerenciamento e a integridade do
análise do log de agente do Log
segurança Analytics devem ser
resolvidos nos
computadores
Log e detecção de LT-5 Centralizar o O agente do Log 1.0.0

ameaças gerenciamento e a Analytics deve ser
análise do log de instalado na máquina
segurança virtual para o
monitoramento da
Central de Segurança
do Azure
VERSÃ O DA
Log e detecção de LT-5 Centralizar o O agente do Log 1.0.0

ameaças gerenciamento e a Analytics deve ser
análise do log de instalado em seus
segurança conjuntos de
dimensionamento de
máquinas virtuais
para o
monitoramento da
Central de Segurança
do Azure
Gerenciamento de PV-4 Manter As vulnerabilidades 3.0.0

postura e configurações nas configurações de
vulnerabilidades seguras para segurança do
recursos de contêiner devem ser
computação corrigidas

postura e configurações da configuração de
vulnerabilidades seguras para segurança nas
recursos de máquinas devem ser
computação corrigidas

postura e configurações da configuração de
vulnerabilidades seguras para segurança nos
recursos de conjuntos de
computação dimensionamento de
máquinas virtuais
devem ser corrigidas
Gerenciamento de PV-6 Executar avaliações Uma solução de 3.0.0

postura e de vulnerabilidade de avaliação de
vulnerabilidades software vulnerabilidade deve
ser habilitada nas
máquinas virtuais
Gerenciamento de PV-7 corrigir de maneira As atualizações do 3.0.0

postura e rápida e automática sistema nos
vulnerabilidades as vulnerabilidades conjuntos de
de software dimensionamento de
máquinas virtuais
devem ser instaladas
Gerenciamento de PV-7 corrigir de maneira As atualizações do 3.0.0

postura e rápida e automática sistema devem ser
vulnerabilidades as vulnerabilidades instaladas em suas
de software máquinas
Segurança de ponto ES-2 Usar software A solução de 3.0.0

de extremidade antimalware proteção de ponto
moderno gerenciado de extremidade deve
centralmente ser instalada nos
conjuntos de
dimensionamento de
máquinas virtuais
VERSÃ O DA
Segurança de ponto ES-2 Usar software Monitorar o 3.0.0

de extremidade antimalware Endpoint Protection
moderno gerenciado ausente na Central
centralmente de Segurança do
Azure
Segurança de ponto ES-2 Usar software O Microsoft 1.1.1

de extremidade antimalware Defender Exploit
moderno gerenciado Guard deve estar
centralmente habilitado nos
computadores
Segurança de ponto ES-3 garantir que o A solução de 3.0.0

de extremidade software antimalware proteção de ponto
e as assinaturas de extremidade deve
sejam atualizados ser instalada nos
conjuntos de
dimensionamento de
máquinas virtuais
Segurança de ponto ES-3 garantir que o Monitorar o 3.0.0

de extremidade software antimalware Endpoint Protection
e as assinaturas ausente na Central
sejam atualizados de Segurança do
Azure
Backup e BR-1 Garantir backups O Backup do Azure 1.0.1

recuperação automatizados deve ser habilitado
regulares para máquinas
virtuais
Backup e BR-2 Criptografar dados O Backup do Azure 1.0.1

recuperação de backup deve ser habilitado
para máquinas
virtuais
Azure Security Benchmark v1

Security Benchmark.
VERSÃ O DA
VERSÃ O DA
Segurança de rede 1,1 proteger recursos As recomendações 3.0.0

usando grupos de da proteção de rede
segurança de rede ou adaptável devem ser
o Firewall do Azure aplicadas nas
em sua Rede Virtual máquinas virtuais
para a Internet
Segurança de rede 1,1 proteger recursos As máquinas virtuais 3.0.0

usando grupos de para a Internet
segurança de rede ou devem ser protegidas
o Firewall do Azure com grupos de
em sua Rede Virtual segurança de rede
Segurança de rede 1,1 proteger recursos O encaminhamento 3.0.0

usando grupos de IP na máquina virtual
segurança de rede ou deve ser desabilitado
o Firewall do Azure
em sua Rede Virtual
Segurança de rede 1,1 proteger recursos As portas de 3.0.0

usando grupos de gerenciamento de
segurança de rede ou máquinas virtuais
o Firewall do Azure devem ser protegidas
em sua Rede Virtual com o controle de
time
Segurança de rede 1,1 proteger recursos Portas de 3.0.0

usando grupos de gerenciamento
segurança de rede ou devem ser fechadas
o Firewall do Azure nas máquinas
em sua Rede Virtual virtuais
Segurança de rede 1.4 rejeitar comunicações As recomendações 3.0.0

com endereços IP da proteção de rede
maliciosos adaptável devem ser
conhecidos aplicadas nas
máquinas virtuais
para a Internet
Segurança de rede 1.4 rejeitar comunicações As portas de 3.0.0

com endereços IP gerenciamento de
maliciosos máquinas virtuais
conhecidos devem ser protegidas
com o controle de
time
Segurança de rede 1.11 usar ferramentas Adicionar identidade 1.0.0

automatizadas para gerenciada atribuída
monitorar as ao sistema para
configurações de habilitar atribuições
recursos de rede e de Configuração de
detectar alterações Convidado em
máquinas virtuais
sem identidades
VERSÃ O DA
Segurança de rede 1.11 usar ferramentas Adicionar uma 1.0.0

automatizadas para identidade
monitorar as gerenciada atribuída
configurações de ao sistema para
recursos de rede e habilitar atribuições
detectar alterações de Configuração de
Convidado em VMs
com uma identidade
atribuída ao usuário
Segurança de rede 1.11 usar ferramentas Implantar a extensão 1.0.0

automatizadas para de Configuração de
monitorar as Convidado do
configurações de Windows para
recursos de rede e habilitar atribuições
detectar alterações de Configuração de
Convidado em VMs
do Windows
Segurança de rede 1.11 usar ferramentas Os computadores 2.0.0

automatizadas para Windows devem
monitorar as atender aos
configurações de requisitos de
recursos de rede e 'Modelos
detectar alterações Administrativos –
Rede'

configurações de requisitos de 'Opções
recursos de rede e de Segurança –
detectar alterações Servidor de Rede da
Microsoft'

detectar alterações Acesso à Rede'

detectar alterações Segurança de Rede'
Registro em log e 2.2 configurar o Auditar os 1.0.0

monitoramento gerenciamento computadores
central de log de Windows nos quais o
segurança agente do Log
Analytics não esteja
conectado conforme
o esperado
VERSÃ O DA
Registro em log e 2.2 configurar o O agente do Log 1.0.0

monitoramento gerenciamento Analytics deve ser
central de log de instalado nos
segurança Conjuntos de
Dimensionamento de
Máquinas Virtuais
Registro em log e 2.2 configurar o O agente do Log 1.0.0

monitoramento gerenciamento Analytics deve ser
central de log de instalado nas
segurança máquinas virtuais
Registro em log e 2.3 habilitar o registro os logs de recurso 2.0.1

monitoramento em log de auditoria nos Conjuntos de
para recursos do Dimensionamento de
Azure Máquinas Virtuais
devem ser
habilitados
Registro em log e 2.4 coletar logs de Auditar os 1.0.0

monitoramento segurança de computadores
sistemas operacionais Windows nos quais o
agente do Log
Analytics não esteja
conectado conforme
o esperado
Registro em log e 2.4 coletar logs de O agente do Log 1.0.0

monitoramento segurança de Analytics deve ser
sistemas operacionais instalado nos
Conjuntos de
Dimensionamento de
Máquinas Virtuais
Registro em log e 2.4 coletar logs de O agente do Log 1.0.0

monitoramento segurança de Analytics deve ser
sistemas operacionais instalado nas
máquinas virtuais
Registro em log e 2.8 centralizar o registro A solução de 3.0.0

monitoramento em log de proteção de ponto
antimalware de extremidade deve
ser instalada nos
conjuntos de
dimensionamento de
máquinas virtuais
Registro em log e 2.8 centralizar o registro O Microsoft 1.0.0

monitoramento em log de Antimalware para o
antimalware Azure deve ser
configurado para
atualizar
automaticamente as
assinaturas de
proteção
VERSÃ O DA
Registro em log e 2.8 centralizar o registro Monitorar o 3.0.0

monitoramento em log de Endpoint Protection
antimalware ausente na Central
de Segurança do
Azure
Identidade e controle 3.3 usar contas Auditar 1.0.0

de acesso administrativas computadores
dedicadas Windows que não
têm membros
especificados no
Grupo de
administradores
Identidade e controle 3.3 usar contas Auditar os 1.0.0

dedicadas Windows que têm
contas extras no
Grupo de
administradores
Identidade e controle 3.3 usar contas Auditar 1.0.0

dedicadas Windows que têm os
membros
especificados no
Grupo de
administradores
Proteção de dados 4.8 criptografar A criptografia de 2.0.0

informações disco deve ser
confidenciais em aplicada em
repouso Máquinas virtuais
Proteção de dados 4.8 criptografar Os discos 1.0.0

informações desconectados
confidenciais em devem ser
repouso criptografados
Gerenciamento de 5.1 executar ferramentas Uma solução de 3.0.0

vulnerabilidades automatizadas de avaliação de
verificação de vulnerabilidade deve
vulnerabilidade ser habilitada nas
máquinas virtuais
Gerenciamento de 5.2 implantar solução As atualizações do 3.0.0

vulnerabilidades automatizada de sistema nos
gerenciamento de conjuntos de
patch de sistema dimensionamento de
operacional máquinas virtuais
VERSÃ O DA
Gerenciamento de 5.2 implantar solução As atualizações do 3.0.0

vulnerabilidades automatizada de sistema devem ser
gerenciamento de instaladas em suas
patch de sistema máquinas
operacional
Gerenciamento de 5.5 usar um processo de As vulnerabilidades 3.0.0

vulnerabilidades avaliação de risco nas configurações de
para priorizar a segurança do
correção das contêiner devem ser
vulnerabilidades corrigidas
descobertas

vulnerabilidades avaliação de risco da configuração de
para priorizar a segurança nas
correção das máquinas devem ser
vulnerabilidades corrigidas
descobertas

vulnerabilidades avaliação de risco da configuração de
para priorizar a segurança nos
correção das conjuntos de
vulnerabilidades dimensionamento de
descobertas máquinas virtuais
Inventário e 6,8 usar somente Os controles de 3.0.0

gerenciamento de aplicativos aprovados aplicativos adaptáveis
ativos para definir
aplicativos seguros
devem estar
habilitados nos
computadores
Inventário e 6.9 usar somente As máquinas virtuais 1.0.0

gerenciamento de serviços do Azure devem ser migradas
ativos aprovados para os novos
recursos do Azure
Resource Manager
Inventário e 6.10 implementar lista de Os controles de 3.0.0

gerenciamento de aplicativos aprovados aplicativos adaptáveis
ativos para definir
aplicativos seguros
devem estar
habilitados nos
computadores
Configuração segura 7.4 manter configurações As vulnerabilidades 3.0.0

seguras de sistema nas configurações de
operacional segurança do
contêiner devem ser
corrigidas
VERSÃ O DA

seguras de sistema da configuração de
operacional segurança nas
máquinas devem ser
corrigidas

seguras de sistema da configuração de
operacional segurança nos
conjuntos de
dimensionamento de
máquinas virtuais
Configuração segura 7.10 implementar As vulnerabilidades 3.0.0

monitoramento nas configurações de
automatizado de segurança do
configuração para contêiner devem ser
sistemas operacionais corrigidas

monitoramento da configuração de
automatizado de segurança nas
configuração para máquinas devem ser
sistemas operacionais corrigidas

monitoramento da configuração de
automatizado de segurança nos
configuração para conjuntos de
sistemas operacionais dimensionamento de
máquinas virtuais
Defesa contra 8.1 usar software A solução de 3.0.0

malwares antimalware proteção de ponto
gerenciado de extremidade deve
centralmente ser instalada nos
conjuntos de
dimensionamento de
máquinas virtuais
Defesa contra 8.1 usar software Monitorar o 3.0.0

malwares antimalware Endpoint Protection
gerenciado ausente na Central
centralmente de Segurança do
Azure
Defesa contra 8.3 garantir que o O Microsoft 1.0.0

malwares software antimalware Antimalware para o
e as assinaturas Azure deve ser
sejam atualizados configurado para
atualizar
automaticamente as
assinaturas de
proteção
VERSÃ O DA
Recuperação de 9.1 garantir backups O Backup do Azure 1.0.1

dados automatizados deve ser habilitado
regulares para máquinas
virtuais
Recuperação de 9.2 realizar backups O Backup do Azure 1.0.1

dados completos do deve ser habilitado
sistema e fazer para máquinas
backup das chaves virtuais
gerenciadas pelo
cliente
CIS Microsoft Azure Foundations Benchmark

mapeadas para esse padrão de conformidade, confira Conformidade regulatória do Azure Policy – CIS Microsoft
Azure Foundations Benchmark 1.1.0. Para saber mais sobre esse padrão de conformidade, confira CIS Microsoft
Azure Foundations Benchmark.
VERSÃ O DA
Central de Segurança 2.3 Garantir que a As atualizações do 3.0.0

configuração padrão sistema devem ser
da política do ASC instaladas em suas
"Monitorar máquinas
Atualizações do
Sistema" não esteja
"Desabilitada"
Central de Segurança 2.4 Garantir que a As vulnerabilidades 3.0.0

configuração padrão da configuração de
da política do ASC segurança nas
"Monitorar máquinas devem ser
Vulnerabilidades do corrigidas
SO" não esteja
"Desabilitada"
Central de Segurança 2.5 Garantir que a Monitorar o 3.0.0

configuração padrão Endpoint Protection
da política do ASC ausente na Central
"Monitorar a de Segurança do
Proteção do Ponto Azure
de Extremidade" não
esteja "Desabilitada"
Central de Segurança 2.6 Garantir que a A criptografia de 2.0.0

configuração padrão disco deve ser
da política do ASC aplicada em
"Monitorar Máquinas virtuais
Criptografia de Disco"
não esteja
"Desabilitada"
VERSÃ O DA
Central de Segurança 2.7 Garantir que a As recomendações 3.0.0

configuração de da proteção de rede
política padrão do adaptável devem ser
ASC "Monitorar aplicadas nas
Grupos de Segurança máquinas virtuais
de Rede" não esteja para a Internet
"Desabilitada"
Central de Segurança 2,9 Garantir que a As máquinas virtuais 3.0.0

configuração de para a Internet
política padrão do devem ser protegidas
ASC "Habilitar com grupos de
Monitoramento de segurança de rede
NGFW (Firewall de
Próxima Geração)"
não esteja
"Desabilitada"
Central de Segurança 2.10 Garantir que a Uma solução de 3.0.0

configuração padrão avaliação de
da política do ASC vulnerabilidade deve
"Monitorar Avaliação ser habilitada nas
de Vulnerabilidade" máquinas virtuais
não esteja
"Desabilitada"
Central de Segurança 2.12 Garantir que a As portas de 3.0.0

configuração padrão gerenciamento de
da política do ASC máquinas virtuais
"Monitorar o Acesso devem ser protegidas
à Rede JIT" não esteja com o controle de
"Desabilitada" acesso à rede just-in-
time
Central de Segurança 2,13 Garantir que a Os controles de 3.0.0

configuração padrão aplicativos adaptáveis
da política do ASC para definir
"Monitorar a Inclusão aplicativos seguros
de Aplicativos devem estar
Adaptáveis à Lista de habilitados nos
Permissões" não computadores
esteja "Desabilitada"
Máquinas Virtuais 7.1 Garantir que o 'Disco A criptografia de 2.0.0

do SO' seja disco deve ser
criptografado aplicada em
Máquinas virtuais
Máquinas Virtuais 7.2 Garantir que os A criptografia de 2.0.0

'Discos de dados' disco deve ser
sejam criptografados aplicada em
Máquinas virtuais
Máquinas Virtuais 7.3 Garantir que os Os discos 1.0.0

'Discos não desconectados
anexados' sejam devem ser
criptografados criptografados
VERSÃ O DA
Máquinas Virtuais 7.4 Garantir que apenas Somente as 1.0.0

as extensões extensões aprovadas
aprovadas sejam da VM devem ser
instaladas instaladas
Máquinas Virtuais 7.5 Garantir que os As atualizações do 3.0.0

Patches de SO mais sistema devem ser
recentes para todas instaladas em suas
as máquinas virtuais máquinas
sejam aplicados
Máquinas Virtuais 7.6 Garantir que a Monitorar o 3.0.0

proteção de ponto Endpoint Protection
de extremidade para ausente na Central
todas as máquinas de Segurança do
virtuais esteja Azure
instalada
CMMC nível 3
mapeadas para esse padrão de conformidade, confira Conformidade regulatória do Azure Policy – CMMC nível
3. Para saber mais sobre esse padrão de conformidade, confira Cybersecurity Maturity Model Certification
(CMMC).
VERSÃ O DA
Controle de acesso AC.1.001 Limitar o acesso do Adicionar identidade 1.0.0

sistema de gerenciada atribuída
informações a ao sistema para
usuários autorizados, habilitar atribuições
processos que atuam de Configuração de
em nome de usuários Convidado em
autorizados e máquinas virtuais
dispositivos sem identidades
(incluindo outros
sistemas de
informações).
VERSÃ O DA
Controle de acesso AC.1.001 Limitar o acesso do Adicionar uma 1.0.0

sistema de identidade
informações a gerenciada atribuída
usuários autorizados, ao sistema para
processos que atuam habilitar atribuições
em nome de usuários de Configuração de
autorizados e Convidado em VMs
dispositivos com uma identidade
(incluindo outros atribuída ao usuário
sistemas de
informações).
Controle de acesso AC.1.001 Limitar o acesso do Auditar os 1.0.0

sistema de computadores Linux
informações a que permitem
usuários autorizados, conexões remotas de
processos que atuam contas sem senhas
em nome de usuários
autorizados e
dispositivos
(incluindo outros
sistemas de
informações).
Controle de acesso AC.1.001 Limitar o acesso do Implantar a extensão 1.0.0

sistema de de Configuração de
informações a Convidado do
usuários autorizados, Windows para
autorizados e Convidado em VMs
dispositivos do Windows
(incluindo outros
sistemas de
informações).
Controle de acesso AC.1.001 Limitar o acesso do As portas de 3.0.0

sistema de gerenciamento de
informações a máquinas virtuais
usuários autorizados, devem ser protegidas
processos que atuam com o controle de
em nome de usuários acesso à rede just-in-
autorizados e time
dispositivos
(incluindo outros
sistemas de
informações).
VERSÃ O DA
Controle de acesso AC.1.001 Limitar o acesso do Os computadores 2.0.0

sistema de Windows devem
informações a atender aos
usuários autorizados, requisitos de 'Opções
processos que atuam de Segurança –
em nome de usuários Acesso à Rede'
autorizados e
dispositivos
(incluindo outros
sistemas de
informações).

informações a atender aos
usuários autorizados, requisitos de 'Opções
processos que atuam de Segurança –
em nome de usuários Segurança de Rede'
autorizados e
dispositivos
(incluindo outros
sistemas de
informações).
Controle de acesso AC.1.002 Limitar o acesso do Auditar os 1.0.0

sistema de computadores Linux
informações aos que permitem
tipos de transações e conexões remotas de
funções que os contas sem senhas
usuários autorizados
têm permissão para
executar.
Controle de acesso AC.1.002 Limitar o acesso do As portas de 3.0.0

sistema de gerenciamento de
informações aos máquinas virtuais
tipos de transações e devem ser protegidas
funções que os com o controle de
usuários autorizados acesso à rede just-in-
têm permissão para time
executar.

informações aos atender aos
tipos de transações e requisitos de 'Opções
funções que os de Segurança –
usuários autorizados Acesso à Rede'
executar.
VERSÃ O DA
Controle de acesso AC.1.002 Limitar o acesso do Os servidores Web 2.0.0

sistema de do Windows devem
informações aos ser configurados para
tipos de transações e usar protocolos de
funções que os comunicação segura
usuários autorizados
executar.
Controle de acesso AC.1.003 Verificar e As recomendações 3.0.0

controlar/limitar as da proteção de rede
conexões e o uso de adaptável devem ser
sistemas de aplicadas nas
informações máquinas virtuais
externos. para a Internet
Controle de acesso AC.1.003 Verificar e As máquinas virtuais 3.0.0

controlar/limitar as para a Internet
conexões e o uso de devem ser protegidas
sistemas de com grupos de
informações segurança de rede
externos.
Controle de acesso AC.2.007 Empregar o princípio As portas de 3.0.0

de privilégios gerenciamento de
mínimos, incluindo máquinas virtuais
para funções de devem ser protegidas
segurança específicas com o controle de
e contas acesso à rede just-in-
privilegiadas. time
Controle de acesso AC.2.008 Usar contas ou Os computadores 2.0.0

funções sem Windows devem
privilégios ao acessar atender aos
funções que não são requisitos de 'Opções
de segurança. de Segurança –
Controle de Conta de
Usuário'
Controle de acesso AC.2.008 Usar contas ou Os computadores 2.0.0

funções sem Windows devem
privilégios ao acessar atender aos
funções que não são requisitos de
de segurança. 'Atribuição de
Direitos do Usuário'
Controle de acesso AC.2.013 Monitore e controle Adicionar identidade 1.0.0

sessões de acesso gerenciada atribuída
remoto. ao sistema para
habilitar atribuições
de Configuração de
Convidado em
máquinas virtuais
sem identidades
VERSÃ O DA
Controle de acesso AC.2.013 Monitore e controle Adicionar uma 1.0.0

sessões de acesso identidade
remoto. gerenciada atribuída
ao sistema para
Convidado em VMs
com uma identidade
Controle de acesso AC.2.013 Monitore e controle Auditar os 1.0.0

sessões de acesso computadores Linux
remoto. que permitem
conexões remotas de
contas sem senhas
Controle de acesso AC.2.013 Monitore e controle Implantar a extensão 1.0.0

sessões de acesso de Configuração de
remoto. Convidado do
Windows para
Convidado em VMs
do Windows
Controle de acesso AC.2.013 Monitore e controle As portas de 3.0.0

sessões de acesso gerenciamento de
remoto. máquinas virtuais
com o controle de
time
Controle de acesso AC.2.013 Monitore e controle Os computadores 2.0.0

sessões de acesso Windows devem
remoto. atender aos
requisitos de 'Opções
de Segurança –
Segurança de Rede'
Controle de acesso AC.2.016 Controle o fluxo de As recomendações 3.0.0

CUI de acordo com da proteção de rede
autorizações adaptável devem ser
aprovadas. aplicadas nas
máquinas virtuais
para a Internet
Controle de acesso AC.2.016 Controle o fluxo de As máquinas virtuais 3.0.0

CUI de acordo com para a Internet
autorizações devem ser protegidas
aprovadas. com grupos de
segurança de rede
VERSÃ O DA
Controle de acesso AC.2.016 Controle o fluxo de Os computadores 2.0.0

CUI de acordo com Windows devem
autorizações atender aos
aprovadas. requisitos de 'Opções
de Segurança –
Acesso à Rede'
Controle de acesso AC.3.017 Separe as tarefas de Auditar 1.0.0

indivíduos para computadores
reduzir o risco de Windows que não
atividades maliciosas têm membros
sem colusão. especificados no
Grupo de
administradores
Controle de acesso AC.3.017 Separe as tarefas de Auditar 1.0.0

reduzir o risco de Windows que têm os
atividades maliciosas membros
Grupo de
administradores
Controle de acesso AC.3.018 Impedir que usuários Os computadores 2.0.0

sem privilégios Windows devem
executem funções atender aos
privilegiadas e requisitos de
capturem a execução 'Políticas de Auditoria
dessas funções em do Sistema – Uso de
logs de auditoria. Privilégios'
Controle de acesso AC.3.021 Autorizar a execução Adicionar identidade 1.0.0

remota de comandos gerenciada atribuída
privilegiados e acesso ao sistema para
remoto a habilitar atribuições
informações de Configuração de
relevantes à Convidado em
segurança. máquinas virtuais
sem identidades
Controle de acesso AC.3.021 Autorizar a execução Adicionar uma 1.0.0

remota de comandos identidade
privilegiados e acesso gerenciada atribuída
remoto a ao sistema para
informações habilitar atribuições
relevantes à de Configuração de
segurança. Convidado em VMs
com uma identidade
VERSÃ O DA
Controle de acesso AC.3.021 Autorizar a execução Implantar a extensão 1.0.0

remota de comandos de Configuração de
privilegiados e acesso Convidado do Linux
remoto a para habilitar
informações atribuições de
relevantes à Configuração de
do Linux
Controle de acesso AC.3.021 Autorizar a execução Implantar a extensão 1.0.0

remota de comandos de Configuração de
privilegiados e acesso Convidado do
remoto a Windows para
informações habilitar atribuições
relevantes à de Configuração de
do Windows
Controle de acesso AC.3.021 Autorizar a execução A extensão de 1.0.1

remota de comandos Configuração de
privilegiados e acesso Convidado deve ser
remoto a instalada nos seus
informações computadores
relevantes à
segurança.
Controle de acesso AC.3.021 Autorizar a execução A extensão de 1.0.1

remota de comandos Configuração de
privilegiados e acesso Convidado das
remoto a máquinas virtuais
informações deve ser implantada
relevantes à com a identidade
segurança. gerenciada atribuída
ao sistema
Controle de acesso AC.3.021 Autorizar a execução Os computadores 2.0.0

remota de comandos Windows devem
privilegiados e acesso atender aos
remoto a requisitos de 'Opções
informações de Segurança –
relevantes à Controle de Conta de
segurança. Usuário'
Controle de acesso AC.3.021 Autorizar a execução Os computadores 2.0.0

remota de comandos Windows devem
privilegiados e acesso atender aos
remoto a requisitos de
informações 'Atribuição de
relevantes à Direitos do Usuário'
segurança.
VERSÃ O DA
Auditoria e AU.2.041 Verificar se as ações [Versão prévia]: 1.0.0 – versão prévia

Contabilidade de usuários Auditar a
individuais do implantação do
sistema podem ser Agente do Log
rastreadas Analytics – imagem
exclusivamente para de VM (sistema
esses usuários, para operacional) não
que eles possam ser listada
responsabilizados
pelas respectivas
ações.
Auditoria e AU.2.041 Verificar se as ações Auditar a 1.0.1

Contabilidade de usuários implantação do
individuais do agente do Log
sistema podem ser Analytics em
rastreadas Conjuntos de
exclusivamente para Dimensionamento de
esses usuários, para Máquinas Virtuais –
que eles possam ser imagem de VM
responsabilizados (sistema operacional)
pelas respectivas não listada
ações.
Auditoria e AU.2.041 Verificar se as ações Auditar o workspace 1.0.1

Contabilidade de usuários do Log Analytics para
individuais do a VM – Relatar
sistema podem ser incompatibilidade
rastreadas
exclusivamente para
esses usuários, para
que eles possam ser
responsabilizados
pelas respectivas
ações.
Auditoria e AU.2.041 Verificar se as ações O agente do Log 1.0.0

Contabilidade de usuários Analytics deve ser
individuais do instalado nos
sistema podem ser Conjuntos de
rastreadas Dimensionamento de
exclusivamente para Máquinas Virtuais
que eles possam ser
responsabilizados
pelas respectivas
ações.
VERSÃ O DA
Auditoria e AU.2.041 Verificar se as ações O agente do Log 1.0.0

individuais do instalado nas
sistema podem ser máquinas virtuais
rastreadas
exclusivamente para
que eles possam ser
responsabilizados
pelas respectivas
ações.
Auditoria e AU.2.042 Crie e retenha [Versão prévia]: 1.0.0 – versão prévia

Contabilidade registros e logs de Auditar a
auditoria do sistema implantação do
na extensão Agente do Log
necessária para Analytics – imagem
habilitar o de VM (sistema
monitoramento, a operacional) não
análise, a listada
investigação e a
emissão de relatórios
de atividades ilegais
ou não autorizadas
do sistema.
Auditoria e AU.2.042 Crie e retenha Auditar a 1.0.1

Contabilidade registros e logs de implantação do
auditoria do sistema agente do Log
na extensão Analytics em
necessária para Conjuntos de
habilitar o Dimensionamento de
monitoramento, a Máquinas Virtuais –
análise, a imagem de VM
investigação e a (sistema operacional)
emissão de relatórios não listada
ou não autorizadas
do sistema.
Auditoria e AU.2.042 Crie e retenha Auditar o workspace 1.0.1

Contabilidade registros e logs de do Log Analytics para
auditoria do sistema a VM – Relatar
na extensão incompatibilidade
necessária para
habilitar o
monitoramento, a
análise, a
investigação e a
ou não autorizadas
do sistema.
VERSÃ O DA
Auditoria e AU.2.042 Crie e retenha O agente do Log 1.0.0

Contabilidade registros e logs de Analytics deve ser
auditoria do sistema instalado nos
na extensão Conjuntos de
necessária para Dimensionamento de
habilitar o Máquinas Virtuais
monitoramento, a
análise, a
investigação e a
ou não autorizadas
do sistema.
Auditoria e AU.2.042 Crie e retenha O agente do Log 1.0.0

auditoria do sistema instalado nas
na extensão máquinas virtuais
necessária para
habilitar o
monitoramento, a
análise, a
investigação e a
ou não autorizadas
do sistema.
Auditoria e AU.2.043 Fornecer uma Auditar os 1.0.0

Contabilidade funcionalidade do computadores
sistema que compara Windows que não
e sincroniza os estão definidos para
relógios internos do o fuso horário
sistema com uma especificado
fonte autoritativa
para gerar carimbos
de data/hora para
registros de
auditoria.
Auditoria e AU.3.046 Alerta no caso de [Versão prévia]: 1.0.0 – versão prévia

Contabilidade uma falha de Auditar a
processo de log de implantação do
auditoria. Agente do Log
Analytics – imagem
de VM (sistema
operacional) não
listada
VERSÃ O DA
Auditoria e AU.3.046 Alerta no caso de Auditar a 1.0.1

Contabilidade uma falha de implantação do
processo de log de agente do Log
auditoria. Analytics em
Conjuntos de
Dimensionamento de
Máquinas Virtuais –
imagem de VM
(sistema operacional)
não listada
Auditoria e AU.3.046 Alerta no caso de Auditar o workspace 1.0.1

Contabilidade uma falha de do Log Analytics para
processo de log de a VM – Relatar
auditoria. incompatibilidade
Auditoria e AU.3.048 Coletar informações [Versão prévia]: 1.0.0 – versão prévia

Contabilidade de auditoria (por Auditar a
exemplo, logs) em implantação do
um ou mais Agente do Log
repositórios centrais. Analytics – imagem
de VM (sistema
operacional) não
listada
Auditoria e AU.3.048 Coletar informações Auditar a 1.0.1

Contabilidade de auditoria (por implantação do
exemplo, logs) em agente do Log
um ou mais Analytics em
repositórios centrais. Conjuntos de
Dimensionamento de
imagem de VM
não listada
Auditoria e AU.3.048 Coletar informações Auditar o workspace 1.0.1

Contabilidade de auditoria (por do Log Analytics para
exemplo, logs) em a VM – Relatar
um ou mais incompatibilidade
repositórios centrais.
Auditoria e AU.3.048 Coletar informações O agente do Log 1.0.0

Contabilidade de auditoria (por Analytics deve ser
exemplo, logs) em instalado nos
um ou mais Conjuntos de
repositórios centrais. Dimensionamento de
Máquinas Virtuais
Auditoria e AU.3.048 Coletar informações O agente do Log 1.0.0

Contabilidade de auditoria (por Analytics deve ser
exemplo, logs) em instalado nas
um ou mais máquinas virtuais
repositórios centrais.
VERSÃ O DA
Avaliação de CA.2.158 Avaliar Uma solução de 3.0.0

segurança periodicamente os avaliação de
controles de vulnerabilidade deve
segurança em ser habilitada nas
sistemas máquinas virtuais
organizacionais para
determinar se os
controles estão em
vigor em seus
aplicativos.
Avaliação de CA.2.158 Avaliar Os controles de 3.0.0

segurança periodicamente os aplicativos adaptáveis
controles de para definir
segurança em aplicativos seguros
sistemas devem estar
organizacionais para habilitados nos
determinar se os computadores
controles estão em
vigor em seus
aplicativos.
Avaliação de CA.2.158 Avaliar As regras da lista de 3.0.0

segurança periodicamente os permissões na
controles de política de controles
segurança em de aplicativos
sistemas adaptáveis devem ser
organizacionais para atualizadas
determinar se os
controles estão em
vigor em seus
aplicativos.
Avaliação de CA.2.158 Avaliar A solução de 3.0.0

segurança periodicamente os proteção de ponto
controles de de extremidade deve
segurança em ser instalada nos
sistemas conjuntos de
organizacionais para dimensionamento de
determinar se os máquinas virtuais
controles estão em
vigor em seus
aplicativos.
Avaliação de CA.2.158 Avaliar Monitorar o 3.0.0

segurança periodicamente os Endpoint Protection
controles de ausente na Central
segurança em de Segurança do
sistemas Azure
organizacionais para
determinar se os
controles estão em
vigor em seus
aplicativos.
VERSÃ O DA
Avaliação de CA.3.161 Monitorar controles Uma solução de 3.0.0

segurança de segurança avaliação de
continuamente para vulnerabilidade deve
garantir sua eficácia ser habilitada nas
contínua. máquinas virtuais
Avaliação de CA.3.161 Monitorar controles Os controles de 3.0.0

segurança de segurança aplicativos adaptáveis
continuamente para para definir
garantir sua eficácia aplicativos seguros
contínua. devem estar
habilitados nos
computadores
Avaliação de CA.3.161 Monitorar controles As regras da lista de 3.0.0

segurança de segurança permissões na
continuamente para política de controles
garantir sua eficácia de aplicativos
contínua. adaptáveis devem ser
atualizadas
Avaliação de CA.3.161 Monitorar controles A solução de 3.0.0

segurança de segurança proteção de ponto
continuamente para de extremidade deve
garantir sua eficácia ser instalada nos
contínua. conjuntos de
dimensionamento de
máquinas virtuais
Avaliação de CA.3.161 Monitorar controles Monitorar o 3.0.0

segurança de segurança Endpoint Protection
continuamente para ausente na Central
garantir sua eficácia de Segurança do
contínua. Azure
Gerenciamento de CM.2.061 Estabelecer e manter Os controles de 3.0.0

configuração configurações de aplicativos adaptáveis
linha de base e para definir
inventários dos aplicativos seguros
sistemas devem estar
organizacionais habilitados nos
(incluindo hardware, computadores
software, firmware e
documentação)
durante os
respectivos ciclos de
vida de
desenvolvimento do
sistema.
VERSÃ O DA
Gerenciamento de CM.2.061 Estabelecer e manter Os computadores 1.1.0 – versão prévia

configuração configurações de Linux devem atender
linha de base e aos requisitos da
inventários dos linha de base de
sistemas segurança do Azure
organizacionais
(incluindo hardware,
software, firmware e
documentação)
durante os
respectivos ciclos de
vida de
desenvolvimento do
sistema.
Gerenciamento de CM.2.062 Empregar o princípio Os computadores 2.0.0

configuração da funcionalidade Windows devem
mínima configurando atender aos
sistemas requisitos de
organizacionais para 'Políticas de Auditoria
fornecer apenas do Sistema – Uso de
recursos essenciais. Privilégios'
Gerenciamento de CM.2.063 Controle e monitore Os controles de 3.0.0

configuração software instalado aplicativos adaptáveis
pelo usuário. para definir
aplicativos seguros
devem estar
habilitados nos
computadores
Gerenciamento de CM.2.063 Controle e monitore As regras da lista de 3.0.0

configuração software instalado permissões na
pelo usuário. política de controles
de aplicativos
adaptáveis devem ser
atualizadas
Gerenciamento de CM.2.063 Controle e monitore Os computadores 2.0.0

configuração software instalado Windows devem
pelo usuário. atender aos
de Segurança –
Usuário'
Gerenciamento de CM.2.064 Estabelecer e impor Todas as portas de 3.0.0

configuração as definições de rede devem ser
configuração de restritas nos grupos
segurança para de segurança de rede
produtos de associados à sua
tecnologia da máquina virtual
informação
empregadas em
sistemas
organizacionais.
VERSÃ O DA
Gerenciamento de CM.2.064 Estabelecer e impor Os computadores 2.0.0

configuração as definições de Windows devem
configuração de atender aos
segurança para requisitos de 'Opções
produtos de de Segurança –
tecnologia da Segurança de Rede'
informação
empregadas em
sistemas
organizacionais.
Gerenciamento de CM.2.065 Acompanhar, Os computadores 2.0.0

configuração examinar, aprovar ou Windows devem
desaprovar e atender aos
registrar alterações requisitos de
em sistemas 'Políticas de Auditoria
organizacionais. do Sistema –
Alteração de Política'
Gerenciamento de CM.3.068 Restrinja, desabilite Os controles de 3.0.0

configuração ou impeça o uso de aplicativos adaptáveis
programas, funções, para definir
portas, protocolos e aplicativos seguros
serviços não devem estar
essenciais. habilitados nos
computadores
Gerenciamento de CM.3.068 Restrinja, desabilite As recomendações 3.0.0

configuração ou impeça o uso de da proteção de rede
programas, funções, adaptável devem ser
portas, protocolos e aplicadas nas
serviços não máquinas virtuais
essenciais. para a Internet
Gerenciamento de CM.3.068 Restrinja, desabilite Todas as portas de 3.0.0

configuração ou impeça o uso de rede devem ser
programas, funções, restritas nos grupos
portas, protocolos e de segurança de rede
serviços não associados à sua
essenciais. máquina virtual
Gerenciamento de CM.3.068 Restrinja, desabilite As regras da lista de 3.0.0

configuração ou impeça o uso de permissões na
programas, funções, política de controles
portas, protocolos e de aplicativos
serviços não adaptáveis devem ser
essenciais. atualizadas
Gerenciamento de CM.3.068 Restrinja, desabilite As máquinas virtuais 3.0.0

configuração ou impeça o uso de para a Internet
programas, funções, devem ser protegidas
portas, protocolos e com grupos de
serviços não segurança de rede
essenciais.
VERSÃ O DA
Gerenciamento de CM.3.068 Restrinja, desabilite As portas de 3.0.0

configuração ou impeça o uso de gerenciamento de
programas, funções, máquinas virtuais
portas, protocolos e devem ser protegidas
serviços não com o controle de
essenciais. acesso à rede just-in-
time
Gerenciamento de CM.3.068 Restrinja, desabilite Máquinas virtuais 3.0.0

configuração ou impeça o uso de não voltadas para a
programas, funções, Internet devem ser
portas, protocolos e protegidas com
serviços não grupos de segurança
essenciais. de rede
Gerenciamento de CM.3.069 Aplique a política de Os controles de 3.0.0

configuração negar por exceção aplicativos adaptáveis
(lista de bloqueios) para definir
para evitar o uso de aplicativos seguros
software não devem estar
autorizado ou a habilitados nos
política de negar computadores
tudo, permitir por
exceção (lista de
permissões) para
permitir a realização
de software
autorizado.
Identificação e IA.1.077 Autenticar (ou Adicionar identidade 1.0.0

Autenticação verificar) as gerenciada atribuída
identidades de ao sistema para
usuários, processos habilitar atribuições
ou dispositivos como de Configuração de
um pré-requisito Convidado em
para permitir o máquinas virtuais
acesso a sistemas de sem identidades
informações
organizacionais.
Identificação e IA.1.077 Autenticar (ou Adicionar uma 1.0.0

Autenticação verificar) as identidade
identidades de gerenciada atribuída
usuários, processos ao sistema para
ou dispositivos como habilitar atribuições
um pré-requisito de Configuração de
para permitir o Convidado em VMs
acesso a sistemas de com uma identidade
informações atribuída ao usuário
organizacionais.
VERSÃ O DA
Identificação e IA.1.077 Autenticar (ou Auditar os 1.0.0

Autenticação verificar) as computadores Linux
identidades de que não têm as
usuários, processos permissões de
ou dispositivos como arquivo de senha
um pré-requisito definidas como 0644
para permitir o
acesso a sistemas de
informações
organizacionais.
Identificação e IA.1.077 Autenticar (ou Auditar os 1.0.0

identidades de que têm contas sem
usuários, processos senhas
ou dispositivos como
um pré-requisito
para permitir o
informações
organizacionais.
Identificação e IA.1.077 Autenticar (ou Implantar a extensão 1.0.0

Autenticação verificar) as de Configuração de
identidades de Convidado do
usuários, processos Windows para
acesso a sistemas de do Windows
informações
organizacionais.
Identificação e IA.1.077 Autenticar (ou Os computadores 2.0.0

Autenticação verificar) as Windows devem
identidades de atender aos
usuários, processos requisitos de 'Opções
ou dispositivos como de Segurança –
um pré-requisito Segurança de Rede'
para permitir o
informações
organizacionais.
Identificação e IA.2.078 Imponha uma Adicionar identidade 1.0.0

Autenticação complexidade mínima gerenciada atribuída
de senha e uma ao sistema para
alteração de habilitar atribuições
caracteres quando de Configuração de
senhas forem criadas. Convidado em
máquinas virtuais
sem identidades
VERSÃ O DA
Identificação e IA.2.078 Imponha uma Adicionar uma 1.0.0

Autenticação complexidade mínima identidade
de senha e uma gerenciada atribuída
alteração de ao sistema para
caracteres quando habilitar atribuições
senhas forem criadas. de Configuração de
Convidado em VMs
com uma identidade
Identificação e IA.2.078 Imponha uma Auditar os 1.0.0

Autenticação complexidade mínima computadores Linux
de senha e uma que têm contas sem
alteração de senhas
caracteres quando
senhas forem criadas.

Autenticação complexidade mínima computadores
de senha e uma Windows que não
alteração de têm a configuração
caracteres quando de complexidade de
senhas forem criadas. senha habilitada

alteração de restringem o
caracteres quando tamanho mínimo da
senhas forem criadas. senha a 14 caracteres
Identificação e IA.2.078 Imponha uma Implantar a extensão 1.0.0

Autenticação complexidade mínima de Configuração de
de senha e uma Convidado do
alteração de Windows para
Convidado em VMs
do Windows
Identificação e IA.2.078 Imponha uma Os computadores 2.0.0

Autenticação complexidade mínima Windows devem
de senha e uma atender aos
alteração de requisitos de 'Opções
caracteres quando de Segurança –
senhas forem criadas. Segurança de Rede'
Identificação e IA.2.079 Proíba a reutilização Adicionar identidade 1.0.0

Autenticação de senhas por um gerenciada atribuída
número especificado ao sistema para
de gerações. habilitar atribuições
Convidado em
máquinas virtuais
sem identidades
VERSÃ O DA
Identificação e IA.2.079 Proíba a reutilização Adicionar uma 1.0.0

Autenticação de senhas por um identidade
número especificado gerenciada atribuída
de gerações. ao sistema para
Convidado em VMs
com uma identidade
Identificação e IA.2.079 Proíba a reutilização Auditar os 1.0.0

Autenticação de senhas por um computadores
número especificado Windows que podem
de gerações. reutilizar as 24
senhas anteriores
Identificação e IA.2.079 Proíba a reutilização Implantar a extensão 1.0.0

Autenticação de senhas por um de Configuração de
número especificado Convidado do
de gerações. Windows para
Convidado em VMs
do Windows
Identificação e IA.2.079 Proíba a reutilização Os computadores 2.0.0

Autenticação de senhas por um Windows devem
número especificado atender aos
de gerações. requisitos de 'Opções
de Segurança –
Segurança de Rede'
Identificação e IA.2.081 Armazene e Adicionar identidade 1.0.0

Autenticação transmita apenas gerenciada atribuída
senhas protegidas ao sistema para
criptograficamente. habilitar atribuições
Convidado em
máquinas virtuais
sem identidades
Identificação e IA.2.081 Armazene e Adicionar uma 1.0.0

Autenticação transmita apenas identidade
senhas protegidas gerenciada atribuída
criptograficamente. ao sistema para
Convidado em VMs
com uma identidade
Identificação e IA.2.081 Armazene e Auditar os 1.0.0

Autenticação transmita apenas computadores
senhas protegidas Windows que não
criptograficamente. armazenam senhas
usando a criptografia
reversível
VERSÃ O DA
Identificação e IA.2.081 Armazene e Implantar a extensão 1.0.0

Autenticação transmita apenas de Configuração de
senhas protegidas Convidado do
criptograficamente. Windows para
Convidado em VMs
do Windows
Identificação e IA.2.081 Armazene e Os computadores 2.0.0

Autenticação transmita apenas Windows devem
senhas protegidas atender aos
criptograficamente. requisitos de 'Opções
de Segurança –
Segurança de Rede'
Identificação e IA.3.084 Empregar Os servidores Web 2.0.0

Autenticação mecanismos de do Windows devem
autenticação ser configurados para
resistente à repetição usar protocolos de
para acesso à rede comunicação segura
para contas com e
sem privilégios.
Resposta a incidentes IR.2.093 Detectar e relatar Monitorar o 3.0.0

eventos. Endpoint Protection
ausente na Central
de Segurança do
Azure
Recuperação RE.2.137 Executar e testar Auditar máquinas 1.0.0

back-ups de dados virtuais sem a
regularmente. recuperação de
desastre configurada
Recuperação RE.2.137 Executar e testar O Backup do Azure 1.0.1

back-ups de dados deve ser habilitado
regularmente. para máquinas
virtuais
Recuperação RE.3.139 Executar Auditar máquinas 1.0.0

regularmente virtuais sem a
backups de dados recuperação de
completos, desastre configurada
abrangentes e
resilientes conforme
definido pela
organização.
Recuperação RE.3.139 Executar O Backup do Azure 1.0.1

regularmente deve ser habilitado
backups de dados para máquinas
completos, virtuais
abrangentes e
resilientes conforme
definido pela
organização.
VERSÃ O DA
Avaliação de risco RM.2.141 Avaliar Uma solução de 3.0.0

periodicamente o avaliação de
risco para operações vulnerabilidade deve
organizacionais ser habilitada nas
(incluindo missão, máquinas virtuais
funções, imagem ou
reputação), ativos
organizacionais e
indivíduos
resultantes da
operação de sistemas
organizacionais e do
processamento, do
armazenamento ou
da transmissão de
CUI associada.
Avaliação de risco RM.2.142 Verifique se há Uma solução de 3.0.0

vulnerabilidades em avaliação de
sistemas vulnerabilidade deve
organizacionais e ser habilitada nas
aplicativos máquinas virtuais
periodicamente e
quando novas
vulnerabilidades que
afetam esses
sistemas e aplicativos
são identificadas.
Avaliação de risco RM.2.143 Corrigir Uma solução de 3.0.0

vulnerabilidades de avaliação de
acordo com as vulnerabilidade deve
avaliações de risco. ser habilitada nas
máquinas virtuais
Avaliação de risco RM.2.143 Corrigir As vulnerabilidades 3.0.0

vulnerabilidades de nas configurações de
acordo com as segurança do
avaliações de risco. contêiner devem ser
corrigidas

vulnerabilidades de da configuração de
acordo com as segurança nas
avaliações de risco. máquinas devem ser
corrigidas
VERSÃ O DA

vulnerabilidades de da configuração de
acordo com as segurança nos
avaliações de risco. conjuntos de
dimensionamento de
máquinas virtuais
Proteção do Sistema SC.1.175 Monitore, controle e As recomendações 3.0.0

e das Comunicações proteja as da proteção de rede
comunicações (ou adaptável devem ser
seja, informações aplicadas nas
transmitidas ou máquinas virtuais
recebidas por para a Internet
sistemas
organizacionais) nos
limites externos e os
principais limites
internos dos sistemas
organizacionais.
Proteção do Sistema SC.1.175 Monitore, controle e Todas as portas de 3.0.0

e das Comunicações proteja as rede devem ser
comunicações (ou restritas nos grupos
seja, informações de segurança de rede
transmitidas ou associados à sua
recebidas por máquina virtual
sistemas
principais limites
organizacionais.
Proteção do Sistema SC.1.175 Monitore, controle e As máquinas virtuais 3.0.0

e das Comunicações proteja as para a Internet
comunicações (ou devem ser protegidas
seja, informações com grupos de
transmitidas ou segurança de rede
recebidas por
sistemas
principais limites
organizacionais.
VERSÃ O DA
Proteção do Sistema SC.1.175 Monitore, controle e As portas de 3.0.0

e das Comunicações proteja as gerenciamento de
comunicações (ou máquinas virtuais
seja, informações devem ser protegidas
transmitidas ou com o controle de
recebidas por acesso à rede just-in-
sistemas time
principais limites
organizacionais.
Proteção do Sistema SC.1.175 Monitore, controle e Máquinas virtuais 3.0.0

e das Comunicações proteja as não voltadas para a
comunicações (ou Internet devem ser
seja, informações protegidas com
transmitidas ou grupos de segurança
recebidas por de rede
sistemas
principais limites
organizacionais.
Proteção do Sistema SC.1.175 Monitore, controle e Os computadores 2.0.0

e das Comunicações proteja as Windows devem
comunicações (ou atender aos
seja, informações requisitos de 'Opções
transmitidas ou de Segurança –
recebidas por Acesso à Rede'
sistemas
principais limites
organizacionais.
Proteção do Sistema SC.1.175 Monitore, controle e Os computadores 2.0.0

e das Comunicações proteja as Windows devem
comunicações (ou atender aos
seja, informações requisitos de 'Opções
transmitidas ou de Segurança –
recebidas por Segurança de Rede'
sistemas
principais limites
organizacionais.
VERSÃ O DA
Proteção do Sistema SC.1.175 Monitore, controle e Os servidores Web 2.0.0

e das Comunicações proteja as do Windows devem
comunicações (ou ser configurados para
seja, informações usar protocolos de
transmitidas ou comunicação segura
recebidas por
sistemas
principais limites
organizacionais.
Proteção do Sistema SC.1.176 Implemente sub- As recomendações 3.0.0

e das Comunicações redes para da proteção de rede
componentes do adaptável devem ser
sistema publicamente aplicadas nas
acessíveis que máquinas virtuais
estejam fisicamente para a Internet
ou logicamente
separados de redes
internas.
Proteção do Sistema SC.1.176 Implemente sub- Todas as portas de 3.0.0

e das Comunicações redes para rede devem ser
componentes do restritas nos grupos
sistema publicamente de segurança de rede
acessíveis que associados à sua
estejam fisicamente máquina virtual
ou logicamente
separados de redes
internas.
Proteção do Sistema SC.1.176 Implemente sub- As máquinas virtuais 3.0.0

e das Comunicações redes para para a Internet
componentes do devem ser protegidas
sistema publicamente com grupos de
acessíveis que segurança de rede
estejam fisicamente
ou logicamente
separados de redes
internas.
Proteção do Sistema SC.2.179 Use sessões As portas de 3.0.0

e das Comunicações criptografadas para o gerenciamento de
gerenciamento de máquinas virtuais
dispositivos de rede. devem ser protegidas
com o controle de
time
Proteção do Sistema SC.3.177 Empregar criptografia Auditar os 1.0.0

e das Comunicações validada por FIPS computadores
quando usada para Windows que não
proteger a armazenam senhas
confidencialidade da usando a criptografia
CUI. reversível
VERSÃ O DA
Proteção do Sistema SC.3.177 Empregar criptografia A criptografia de 2.0.0

e das Comunicações validada por FIPS disco deve ser
quando usada para aplicada em
proteger a Máquinas virtuais
confidencialidade da
CUI.
Proteção do Sistema SC.3.177 Empregar criptografia Os discos 1.0.0

e das Comunicações validada por FIPS desconectados
quando usada para devem ser
proteger a criptografados
confidencialidade da
CUI.
Proteção do Sistema SC.3.181 Separar a Auditar os 1.0.0

e das Comunicações funcionalidade do computadores
usuário da Windows que têm
funcionalidade de contas extras no
gerenciamento do Grupo de
sistema. administradores
Proteção do Sistema SC.3.181 Separar a Auditar 1.0.0

e das Comunicações funcionalidade do computadores
usuário da Windows que têm os
funcionalidade de membros
gerenciamento do especificados no
sistema. Grupo de
administradores
Proteção do Sistema SC.3.183 Negar o tráfego de As recomendações 3.0.0

e das Comunicações comunicações de da proteção de rede
rede por padrão e adaptável devem ser
permitir o tráfego de aplicadas nas
comunicações de máquinas virtuais
rede por exceção (ou para a Internet
seja, negar tudo,
permitir por exceção).
Proteção do Sistema SC.3.183 Negar o tráfego de Todas as portas de 3.0.0

e das Comunicações comunicações de rede devem ser
rede por padrão e restritas nos grupos
permitir o tráfego de de segurança de rede
comunicações de associados à sua
rede por exceção (ou máquina virtual
seja, negar tudo,
Proteção do Sistema SC.3.183 Negar o tráfego de As máquinas virtuais 3.0.0

e das Comunicações comunicações de para a Internet
rede por padrão e devem ser protegidas
permitir o tráfego de com grupos de
comunicações de segurança de rede
rede por exceção (ou
seja, negar tudo,
VERSÃ O DA
Proteção do Sistema SC.3.183 Negar o tráfego de As portas de 3.0.0

e das Comunicações comunicações de gerenciamento de
rede por padrão e máquinas virtuais
permitir o tráfego de devem ser protegidas
comunicações de com o controle de
rede por exceção (ou acesso à rede just-in-
seja, negar tudo, time
Proteção do Sistema SC.3.183 Negar o tráfego de Máquinas virtuais 3.0.0

e das Comunicações comunicações de não voltadas para a
rede por padrão e Internet devem ser
permitir o tráfego de protegidas com
comunicações de grupos de segurança
rede por exceção (ou de rede
seja, negar tudo,
Proteção do Sistema SC.3.183 Negar o tráfego de Os computadores 2.0.0

e das Comunicações comunicações de Windows devem
rede por padrão e atender aos
permitir o tráfego de requisitos de 'Opções
comunicações de de Segurança –
rede por exceção (ou Acesso à Rede'
seja, negar tudo,
Proteção do Sistema SC.3.183 Negar o tráfego de Os computadores 2.0.0

e das Comunicações comunicações de Windows devem
rede por padrão e atender aos
permitir o tráfego de requisitos de 'Opções
comunicações de de Segurança –
rede por exceção (ou Segurança de Rede'
seja, negar tudo,
Proteção do Sistema SC.3.185 Implemente Os servidores Web 2.0.0

e das Comunicações mecanismos do Windows devem
criptográficos para ser configurados para
impedir a divulgação usar protocolos de
não autorizada da comunicação segura
CUI durante a
transmissão, a menos
que ela conte com
proteções físicas
alternativas.
Proteção do Sistema SC.3.190 Proteger a Os servidores Web 2.0.0

e das Comunicações autenticidade das do Windows devem
sessões de ser configurados para
comunicação. usar protocolos de
Proteção do Sistema SC.3.191 Proteja a A criptografia de 2.0.0

e das Comunicações confidencialidade do disco deve ser
CUI em repouso. aplicada em
Máquinas virtuais
VERSÃ O DA
Proteção do Sistema SC.3.191 Proteja a Os discos 1.0.0

e das Comunicações confidencialidade do desconectados
CUI em repouso. devem ser
criptografados
Integridade do SI.1.210 Identificar, relatar e O Microsoft 1.0.0

Sistema e das corrigir falhas em Antimalware para o
Informações informações e Azure deve ser
sistemas de configurado para
informações atualizar
oportunamente. automaticamente as
assinaturas de
proteção
Integridade do SI.1.210 Identificar, relatar e As atualizações do 3.0.0

Sistema e das corrigir falhas em sistema nos
Informações informações e conjuntos de
sistemas de dimensionamento de
informações máquinas virtuais
oportunamente. devem ser instaladas
Integridade do SI.1.210 Identificar, relatar e As atualizações do 3.0.0

Sistema e das corrigir falhas em sistema devem ser
Informações informações e instaladas em suas
sistemas de máquinas
informações
oportunamente.
Integridade do SI.1.210 Identificar, relatar e As vulnerabilidades 3.0.0

Sistema e das corrigir falhas em da configuração de
Informações informações e segurança nas
sistemas de máquinas devem ser
informações corrigidas
oportunamente.
Integridade do SI.1.210 Identificar, relatar e As vulnerabilidades 3.0.0

Sistema e das corrigir falhas em da configuração de
Informações informações e segurança nos
sistemas de conjuntos de
informações dimensionamento de
oportunamente. máquinas virtuais
Integridade do SI.1.211 Fornecer proteção A solução de 3.0.0

Sistema e das contra código mal proteção de ponto
Informações intencionado em de extremidade deve
locais adequados em ser instalada nos
sistemas de conjuntos de
informações dimensionamento de
organizacionais. máquinas virtuais
VERSÃ O DA
Integridade do SI.1.211 Fornecer proteção O Microsoft 1.0.0

Sistema e das contra código mal Antimalware para o
Informações intencionado em Azure deve ser
locais adequados em configurado para
sistemas de atualizar
informações automaticamente as
organizacionais. assinaturas de
proteção
Integridade do SI.1.211 Fornecer proteção A extensão 1.0.0

Sistema e das contra código mal IaaSAntimalware da
Informações intencionado em Microsoft deve ser
locais adequados em implantada em
sistemas de servidores do
informações Windows
organizacionais.
Integridade do SI.1.211 Fornecer proteção Monitorar o 3.0.0

Sistema e das contra código mal Endpoint Protection
Informações intencionado em ausente na Central
locais adequados em de Segurança do
sistemas de Azure
informações
organizacionais.
Integridade do SI.1.212 Atualizar mecanismos O Microsoft 1.0.0

Sistema e das de proteção contra Antimalware para o
Informações código mal Azure deve ser
intencionado quando configurado para
novas versões estão atualizar
disponíveis. automaticamente as
assinaturas de
proteção
Integridade do SI.1.213 Executar verificações O Microsoft 1.0.0

Sistema e das periódicas do sistema Antimalware para o
Informações de informações e Azure deve ser
verificações em configurado para
tempo real de atualizar
arquivos de fontes automaticamente as
externas conforme assinaturas de
arquivos são proteção
baixados, abertos ou
executados.
Integridade do SI.1.213 Executar verificações A extensão 1.0.0

Sistema e das periódicas do sistema IaaSAntimalware da
Informações de informações e Microsoft deve ser
verificações em implantada em
tempo real de servidores do
arquivos de fontes Windows
externas conforme
arquivos são
executados.
VERSÃ O DA
Integridade do SI.1.213 Executar verificações Monitorar o 3.0.0

Sistema e das periódicas do sistema Endpoint Protection
Informações de informações e ausente na Central
verificações em de Segurança do
tempo real de Azure
arquivos de fontes
externas conforme
arquivos são
executados.
HIPAA HITRUST 9.2

mapeadas para esse padrão de conformidade, confira Conformidade Regulatória do Azure Policy – HIPAA
HITRUST 9.2. Para obter mais informações sobre esse padrão de conformidade, confira HIPAA HITRUST 9.2.
VERSÃ O DA
Gerenciamento de 11180.01c3System.6 O acesso a funções As portas de 3.0.0

privilégios – 01.c de gerenciamento ou gerenciamento de
consoles máquinas virtuais
administrativos para devem ser protegidas
sistemas que com o controle de
hospedam sistemas acesso à rede just-in-
virtualizados é time
restrito ao pessoal
com base no
princípio de
privilégios mínimos e
com suporte por
meio de controles
técnicos.
Gerenciamento de 1143.01c1System.12 Os privilégios são Portas de 3.0.0

privilégios 3 – 01.c formalmente gerenciamento
autorizados e devem ser fechadas
controlados, alocados nas máquinas
aos usuários de virtuais
acordo com a
necessidade de uso e
com o evento para a
função deles (por
exemplo, usuário ou
administrador), e
documentados para
cada
produto/elemento do
sistema.
VERSÃ O DA
Gerenciamento de 1148.01c2System.78 A organização Os computadores 2.0.0

privilégios – 01.c restringe o acesso a Windows devem
funções privilegiadas atender aos
e a todas as requisitos de 'Opções
informações de Segurança –
relevantes de Contas'
segurança.
Gerenciamento de 1150.01c2System.10 O sistema de Portas de 3.0.0

privilégios – 01.c controle de acesso gerenciamento
para os componentes devem ser fechadas
do sistema que nas máquinas
armazenam, virtuais
processam ou
transmitem
informações sigilosas
é definido com uma
configuração "negar
tudo" padrão.
Autenticação de 1119.01j2Organizati O equipamento de As portas de 3.0.0

usuário para onal.3 – 01.j rede é verificado gerenciamento de
conexões externas quanto a máquinas virtuais
funcionalidades de devem ser protegidas
conexão discada com o controle de
inesperada. acesso à rede just-in-
time
Autenticação de 1175.01j1Organizati O acesso remoto às As portas de 3.0.0

usuário para onal.8 – 01.j informações gerenciamento de
conexões externas comerciais entre máquinas virtuais
redes públicas só devem ser protegidas
ocorre após a com o controle de
identificação e a acesso à rede just-in-
autenticação bem- time
sucedidas.
Autenticação de 1179.01j3Organizati O sistema de As portas de 3.0.0

usuário para onal.1 – 01.j informações gerenciamento de
conexões externas monitora e controla máquinas virtuais
os métodos de devem ser protegidas
acesso remoto. com o controle de
time
Diagnóstico remoto e 1192.01l1Organizati O acesso ao As portas de 3.0.0

proteção da porta de onal.1 – 01.l equipamento de rede gerenciamento de
configuração está fisicamente máquinas virtuais
protegido. devem ser protegidas
com o controle de
time
VERSÃ O DA
Diagnóstico remoto e 1193.01l2Organizati Os controles para o Portas de 3.0.0

proteção da porta de onal.13 – 01.l acesso às portas de gerenciamento
configuração configuração e devem ser fechadas
diagnóstico incluem nas máquinas
o uso de um virtuais
bloqueio de chave e
a implementação de
procedimentos de
suporte para
controlar o acesso
físico à porta.
Diagnóstico remoto e 1197.01l3Organizati A organização Os controles de 3.0.0

proteção da porta de onal.3 – 01.l desabilita o aplicativos adaptáveis
configuração Bluetooth e os para definir
protocolos de rede aplicativos seguros
ponto a ponto no devem estar
sistema de habilitados nos
informações computadores
considerados
desnecessários ou
não seguros.
Diferenciação em 0805.01m1Organizat Os gateways de As máquinas virtuais 3.0.0

redes ional.12 – 01.m segurança da para a Internet
organização (por devem ser protegidas
exemplo, firewalls) com grupos de
impõem políticas de segurança de rede
segurança e são
configurados para
filtrar o tráfego entre
domínios, bloquear
acesso não
autorizado e são
usados para manter
a diferenciação entre
segmentos de rede
internos com fio,
internos sem fio e
externos (por
exemplo, a Internet),
incluindo DMZs e
imposição de
políticas de controle
de acesso para cada
um dos domínios.
VERSÃ O DA
Diferenciação em 0806.01m2Organizat A rede de As máquinas virtuais 3.0.0

redes ional.12356 – 01.m organizações é lógica para a Internet
e fisicamente devem ser protegidas
segmentada com um com grupos de
perímetro de segurança de rede
segurança definido e
um conjunto
graduado de
controles, incluindo
sub-redes de
componentes do
sistema publicamente
acessíveis que são
logicamente
separados da rede
interna, com base
nos requisitos
organizacionais; e o
tráfego é controlado
com base na
funcionalidade
necessária e na
classificação dos
dados/sistemas com
base em uma
avaliação de risco e
nos respectivos
requisitos de
segurança.
Diferenciação em 0894.01m2Organizat As redes são As máquinas virtuais 3.0.0

redes ional.7 – 01.m separadas das redes para a Internet
de nível de produção devem ser protegidas
durante a migração com grupos de
de servidores físicos, segurança de rede
aplicativos ou dados
para servidores
virtualizados.
Controle de conexão 0809.01n2Organizati O tráfego de rede é As recomendações 3.0.0

de rede onal.1234 – 01.n controlado de acordo da proteção de rede
com a política de adaptável devem ser
controle de acesso da aplicadas nas
organização por meio máquinas virtuais
do firewall e de para a Internet
outras restrições
relacionadas à rede
para cada ponto de
acesso à rede ou
interface gerenciada
do serviço de
telecomunicação
externo.
VERSÃ O DA
Controle de conexão 0809.01n2Organizati O tráfego de rede é As máquinas virtuais 3.0.0

de rede onal.1234 – 01.n controlado de acordo para a Internet
com a política de devem ser protegidas
controle de acesso da com grupos de
organização por meio segurança de rede
do firewall e de
outras restrições
relacionadas à rede
para cada ponto de
acesso à rede ou
interface gerenciada
do serviço de
telecomunicação
externo.
Controle de conexão 0810.01n2Organizati As informações As recomendações 3.0.0

de rede onal.5 – 01.n transmitidas são da proteção de rede
protegidas e, no adaptável devem ser
mínimo, aplicadas nas
criptografadas em máquinas virtuais
redes abertas e para a Internet
públicas.
Controle de conexão 0810.01n2Organizati As informações As máquinas virtuais 3.0.0

de rede onal.5 – 01.n transmitidas são para a Internet
protegidas e, no devem ser protegidas
mínimo, com grupos de
criptografadas em segurança de rede
redes abertas e
públicas.
Controle de conexão 0811.01n2Organizati As exceções à política As recomendações 3.0.0

de rede onal.6 – 01.n de fluxo de tráfego da proteção de rede
são documentadas adaptável devem ser
com uma aplicadas nas
missão/necessidade máquinas virtuais
de suporte, pela para a Internet
duração da exceção,
e examinadas pelo
menos anualmente;
as exceções da
política de fluxo de
tráfego são
removidas quando
não há mais suporte
a uma
missão/necessidade
de negócios explícita.
VERSÃ O DA
Controle de conexão 0811.01n2Organizati As exceções à política As máquinas virtuais 3.0.0

de rede onal.6 – 01.n de fluxo de tráfego para a Internet
são documentadas devem ser protegidas
com uma com grupos de
missão/necessidade segurança de rede
de suporte, pela
duração da exceção,
e examinadas pelo
menos anualmente;
as exceções da
política de fluxo de
tráfego são
removidas quando
não há mais suporte
a uma
missão/necessidade
de negócios explícita.
Controle de conexão 0812.01n2Organizati Dispositivos remotos As recomendações 3.0.0

de rede onal.8 – 01.n que estabelecem da proteção de rede
uma conexão não adaptável devem ser
remota não têm aplicadas nas
permissão para se máquinas virtuais
comunicar com para a Internet
recursos externos
(remotos).
Controle de conexão 0812.01n2Organizati Dispositivos remotos As máquinas virtuais 3.0.0

de rede onal.8 – 01.n que estabelecem para a Internet
uma conexão não devem ser protegidas
remota não têm com grupos de
permissão para se segurança de rede
comunicar com
recursos externos
(remotos).
Controle de conexão 0814.01n1Organizati A capacidade dos As recomendações 3.0.0

de rede onal.12 – 01.n usuários de se da proteção de rede
conectar à rede adaptável devem ser
interna é restrita aplicadas nas
usando uma política máquinas virtuais
de negação por para a Internet
padrão e de
permissão por
exceção em interfaces
gerenciadas de
acordo com a política
de controle de acesso
e os requisitos de
aplicativos clínicos e
de negócios.
VERSÃ O DA
Controle de conexão 0814.01n1Organizati A capacidade dos As máquinas virtuais 3.0.0

de rede onal.12 – 01.n usuários de se para a Internet
conectar à rede devem ser protegidas
interna é restrita com grupos de
usando uma política segurança de rede
de negação por
padrão e de
permissão por
exceção em interfaces
gerenciadas de
acordo com a política
de controle de acesso
e os requisitos de
aplicativos clínicos e
de negócios.
Identificação e 11210.01q2Organiza As assinaturas Auditar 1.0.0

autenticação do tional.10 – 01.q eletrônicas e as computadores
usuário assinaturas Windows que têm os
manuscritas membros
executadas em especificados no
registros eletrônicos Grupo de
devem estar administradores
vinculadas aos
respectivos registros
eletrônicos.
Identificação e 11211.01q2Organiza Os registros Auditar 1.0.0

autenticação do tional.11 – 01.q eletrônicos assinados computadores
usuário devem conter Windows que não
informações têm membros
associadas à especificados no
assinatura em Grupo de
formato legível. administradores
Identificação e 1123.01q1System.2 Os usuários que Auditar os 1.0.0

autenticação do – 01.q executaram funções computadores
usuário privilegiadas (por Windows que têm
exemplo, contas extras no
administração do Grupo de
sistema) usam contas administradores
separadas ao
executar essas
funções privilegiadas.
Identificação e 1125.01q2System.1 Os métodos de Auditar 1.0.0

autenticação do – 01.q autenticação computadores
usuário multifator são usados Windows que têm os
de acordo com a membros
política especificados no
organizacional (por Grupo de
exemplo, para acesso administradores
remoto à rede).
VERSÃ O DA
Identificação e 1127.01q2System.3 Quando tokens são Auditar 1.0.0

autenticação do – 01.q fornecidos para a computadores
usuário autenticação Windows que não
multifator, a têm membros
verificação presencial especificados no
é necessária antes de Grupo de
permitir o acesso. administradores
Log de auditoria 1202.09aa1System.1 Um registro de As atualizações do 3.0.0

– 09.aa auditoria seguro é sistema nos
criado para todas as conjuntos de
atividades no sistema dimensionamento de
(criação, leitura, máquinas virtuais
atualização, exclusão) devem ser instaladas
que envolvem
informações sigilosas.
Log de auditoria 1206.09aa2System.2 A auditoria está os logs de recurso 2.0.1

3 – 09.aa sempre disponível nos Conjuntos de
enquanto o sistema Dimensionamento de
está ativo e rastreia Máquinas Virtuais
os principais eventos, devem ser
o acesso a dados habilitados
com êxito/falha, as
alterações de
configuração de
segurança do
sistema, o uso
privilegiado ou de
utilitário, os alarmes
gerados, a ativação e
a desativação de
sistemas de proteção
(por exemplo, A/V e
IDS), a ativação e a
desativação de
mecanismos de
identificação e
autenticação e a
criação e a exclusão
de objetos no nível
de sistema.
Uso do sistema de 12100.09ab2System. A organização O agente do Log 1.0.0

monitoramento 15 – 09.ab monitora o sistema Analytics deve ser
de informações para instalado nas
identificar máquinas virtuais
irregularidades ou
anomalias que são
indicadores de mau
funcionamento ou
comprometimento
do sistema e ajudam
a confirmar se o
sistema está
funcionando em um
estado ideal,
resiliente e seguro.
VERSÃ O DA
Uso do sistema de 12101.09ab1Organiz A organização O agente do Log 1.0.0

monitoramento ational.3 – 09.ab especifica com que Analytics deve ser
frequência os logs de instalado nos
auditoria são Conjuntos de
examinados, como as Dimensionamento de
revisões são Máquinas Virtuais
documentadas e as
funções e as
responsabilidades
específicas da equipe
que realiza as
revisões, incluindo as
certificações
profissionais ou
outras qualificações
necessárias.
Uso do sistema de 12102.09ab1Organiz A organização deve Auditar os 1.0.0

monitoramento ational.4 – 09.ab testar computadores
periodicamente os Windows nos quais o
processos de agente do Log
monitoramento e Analytics não esteja
detecção, corrigir conectado conforme
deficiências e o esperado
aprimorar os
respectivos
processos.
Uso do sistema de 1215.09ab2System.7 Os sistemas de O agente do Log 1.0.0

monitoramento – 09.ab auditoria e Analytics deve ser
monitoramento instalado nas
empregados pela máquinas virtuais
organização dão
suporte à redução da
auditoria e à geração
de relatórios.
Uso do sistema de 1216.09ab3System.1 Os sistemas O agente do Log 1.0.0

monitoramento 2 – 09.ab automatizados são Analytics deve ser
usados para instalado nos
examinar as Conjuntos de
atividades de Dimensionamento de
monitoramento dos Máquinas Virtuais
sistemas de
segurança (por
exemplo, IPS/IDS) e
os registros do
sistema diariamente
e identificar e
documentar
anomalias.
VERSÃ O DA
Uso do sistema de 1217.09ab3System.3 Os alertas são Auditar os 1.0.0

monitoramento – 09.ab gerados para o computadores
pessoal técnico Windows nos quais o
analisar e investigar agente do Log
uma atividade Analytics não esteja
suspeita ou violações conectado conforme
suspeitas. o esperado
Diferenciação de 1232.09c3Organizati O acesso de Os computadores 2.0.0

tarefas onal.12 – 09.c indivíduos Windows devem
responsáveis por atender aos
administrar os requisitos de
controles de acesso é 'Atribuição de
limitado ao mínimo Direitos do Usuário'
necessário, com base
na função e nas
responsabilidades de
cada usuário, e esses
indivíduos não
podem acessar as
funções de auditoria
relacionadas a esses
controles.
Diferenciação de 1277.09c2Organizati A inicialização de um Os computadores 2.0.0

tarefas onal.4 – 09.c evento é separada da Windows devem
autorização dele para atender aos
reduzir a requisitos de 'Opções
possibilidade de de Segurança –
colusão. Controle de Conta de
Usuário'
VERSÃ O DA
Controles contra 0201.09j1Organizati Antivírus e anti- Os controles de 3.0.0

código mal- onal.124 – 09.j spyware estão aplicativos adaptáveis
intencionado instalados, operando para definir
e atualizados em aplicativos seguros
todos os dispositivos devem estar
de usuário final para habilitados nos
realizar verificações computadores
periódicas dos
sistemas para
identificar e remover
software não
autorizado. Os
ambientes de
servidor para os
quais o
desenvolvedor de
software para
servidores
recomenda
especificamente não
instalar software
antivírus e anti-
spyware com base
em host podem
atender ao requisito
por meio de uma
solução NBMD
(detecção de malware
baseada em rede).
Controles contra 0201.09j1Organizati Antivírus e anti- Implantar a extensão 1.0.0

código mal- onal.124 – 09.j spyware estão padrão antimalware
intencionado instalados, operando de IaaS da Microsoft
e atualizados em para Windows Server
todos os dispositivos
de usuário final para
realizar verificações
periódicas dos
sistemas para
software não
autorizado. Os
ambientes de
servidor para os
quais o
desenvolvedor de
software para
servidores
recomenda
instalar software
antivírus e anti-
spyware com base
em host podem
por meio de uma
solução NBMD
baseada em rede).
VERSÃ O DA
Controles contra 0201.09j1Organizati Antivírus e anti- A solução de 3.0.0

código mal- onal.124 – 09.j spyware estão proteção de ponto
intencionado instalados, operando de extremidade deve
e atualizados em ser instalada nos
todos os dispositivos conjuntos de
de usuário final para dimensionamento de
realizar verificações máquinas virtuais
periódicas dos
sistemas para
software não
autorizado. Os
ambientes de
servidor para os
quais o
desenvolvedor de
software para
servidores
recomenda
instalar software
antivírus e anti-
spyware com base
em host podem
por meio de uma
solução NBMD
baseada em rede).
Controles contra 0201.09j1Organizati Antivírus e anti- O Microsoft 1.0.0

código mal- onal.124 – 09.j spyware estão Antimalware para o
intencionado instalados, operando Azure deve ser
e atualizados em configurado para
todos os dispositivos atualizar
de usuário final para automaticamente as
realizar verificações assinaturas de
periódicas dos proteção
sistemas para
software não
autorizado. Os
ambientes de
servidor para os
quais o
desenvolvedor de
software para
servidores
recomenda
instalar software
antivírus e anti-
spyware com base
em host podem
por meio de uma
solução NBMD
baseada em rede).
VERSÃ O DA
Controles contra 0201.09j1Organizati Antivírus e anti- Monitorar o 3.0.0

código mal- onal.124 – 09.j spyware estão Endpoint Protection
intencionado instalados, operando ausente na Central
e atualizados em de Segurança do
todos os dispositivos Azure
periódicas dos
sistemas para
software não
autorizado. Os
ambientes de
servidor para os
quais o
desenvolvedor de
software para
servidores
recomenda
instalar software
antivírus e anti-
spyware com base
em host podem
por meio de uma
solução NBMD
baseada em rede).
Controles contra 0201.09j1Organizati Antivírus e anti- As atualizações do 3.0.0

código mal- onal.124 – 09.j spyware estão sistema devem ser
intencionado instalados, operando instaladas em suas
e atualizados em máquinas
todos os dispositivos
periódicas dos
sistemas para
software não
autorizado. Os
ambientes de
servidor para os
quais o
desenvolvedor de
software para
servidores
recomenda
instalar software
antivírus e anti-
spyware com base
em host podem
por meio de uma
solução NBMD
baseada em rede).
VERSÃ O DA
Backup 1620.09l1Organizati Quando o serviço de O Backup do Azure 1.0.1

onal.8 – 09.l backup é fornecido deve ser habilitado
por terceiros, o SLA para máquinas
inclui as proteções virtuais
detalhadas para
controlar a
confidencialidade, a
integridade e a
disponibilidade das
informações de
backup.
Backup 1625.09l3Organizati Três (3) gerações de O Backup do Azure 1.0.1

onal.34 – 09.l backups (completo, deve ser habilitado
além de todos os para máquinas
backups incrementais virtuais
ou diferenciais
relacionados) são
armazenados fora do
site, e os backups no
site e fora dele são
registrados com
nome, data, hora e
ação.
Backup 1699.09l1Organizati As funções e as O Backup do Azure 1.0.1

onal.10 – 09.l responsabilidades deve ser habilitado
dos membros da para máquinas
força de trabalho no virtuais
processo de backup
de dados são
identificadas e
comunicadas à força
de trabalho; em
particular, os
usuários BYOD (Traga
seu próprio
dispositivo) devem
executar backups de
dados
organizacionais e/ou
do cliente nos
próprios dispositivos.
VERSÃ O DA
Controles de rede 0858.09m1Organizat A organização Todas as portas de 3.0.0

ional.4 – 09.m monitora todo o rede devem ser
acesso sem fio restritas nos grupos
autorizado e não de segurança de rede
autorizado ao associados à sua
sistema de máquina virtual
informações e proíbe
a instalação de WAPs
(pontos de acesso
sem fio), a menos
que explicitamente
autorizado por
escrito pelo CIO ou
pelo representante
designado dele.
Controles de rede 0858.09m1Organizat A organização As portas de 3.0.0

ional.4 – 09.m monitora todo o gerenciamento de
acesso sem fio máquinas virtuais
autorizado e não devem ser protegidas
autorizado ao com o controle de
sistema de acesso à rede just-in-
informações e proíbe time
(pontos de acesso
sem fio), a menos
que explicitamente
autorizado por
escrito pelo CIO ou
pelo representante
designado dele.
Controles de rede 0858.09m1Organizat A organização Os computadores 2.0.0

ional.4 – 09.m monitora todo o Windows devem
acesso sem fio atender aos
autorizado e não requisitos de
autorizado ao 'Propriedades do
sistema de Firewall do Windows'
informações e proíbe
(pontos de acesso
sem fio), a menos
que explicitamente
autorizado por
escrito pelo CIO ou
pelo representante
designado dele.
VERSÃ O DA
Controles de rede 0859.09m1Organizat A organização As recomendações 3.0.0

ional.78 – 09.m garante a segurança da proteção de rede
das informações nas adaptável devem ser
redes, a aplicadas nas
disponibilidade dos máquinas virtuais
serviços de rede e para a Internet
dos serviços de
informações usando
a rede e a proteção
dos serviços
conectados contra o
acesso não
autorizado.
Controles de rede 0861.09m2Organizat Para identificar e Os computadores 2.0.0

ional.67 – 09.m autenticar Windows devem
dispositivos em redes atender aos
locais e/ou de longa requisitos de 'Opções
distância, incluindo de Segurança –
redes sem fio, o Acesso à Rede'
sistema de
informações usa uma
(i) solução de
informações
conhecidas
compartilhadas ou (ii)
uma solução de
autenticação
organizacional, cuja
seleção e força exatas
dependem da
categorização de
segurança do sistema
de informações.
Segurança de 0835.09n1Organizati Os serviços O agente de coleta 1.0.1 – versão prévia

Serviços de Rede onal.1 – 09.n acordados fornecidos dos dados de tráfego
por um de rede deve ser
provedor/gerente de instalado nas
serviços de rede são máquinas virtuais do
formalmente Windows
gerenciados e
monitorados para
garantir que sejam
fornecidos com
segurança.
Segurança de 0835.09n1Organizati Os serviços As máquinas virtuais 1.0.0

Serviços de Rede onal.1 – 09.n acordados fornecidos devem ser migradas
por um para os novos
provedor/gerente de recursos do Azure
serviços de rede são Resource Manager
formalmente
gerenciados e
monitorados para
garantir que sejam
fornecidos com
segurança.
VERSÃ O DA
Segurança de 0836.09.n2Organizat A organização O agente de coleta 1.0.1 – versão prévia

Serviços de Rede ional.1 – 09.n autoriza e de dados do tráfego
documenta de rede deve ser
formalmente as instalado nas
características de máquinas virtuais do
cada conexão em um Linux
sistema de
informações para
outros sistemas de
informações fora da
organização.
Segurança de 0885.09n2Organizati A organização O agente de coleta 1.0.1 – versão prévia

Serviços de Rede onal.3 – 09.n examina e atualiza os de dados do tráfego
contratos de de rede deve ser
segurança de instalado nas
interconexão máquinas virtuais do
continuamente Linux
verificando a
imposição de
requisitos de
segurança.
Segurança de 0887.09n2Organizati A organização exige O agente de coleta 1.0.1 – versão prévia

Serviços de Rede onal.5 – 09.n provedores de dos dados de tráfego
serviços de rede deve ser
externos/terceirizado instalado nas
s para identificar as máquinas virtuais do
funções, as portas e Windows
os protocolos
específicos usados na
provisão dos serviços
externos/terceirizado
s.
Gerenciamento de 0302.09o2Organizati A organização A criptografia de 2.0.0

mídia removível onal.1 – 09.o protege e controla a disco deve ser
mídia que contém aplicada em
informações Máquinas virtuais
confidenciais durante
o transporte fora de
áreas controladas.
Gerenciamento de 0303.09o2Organizati Mídia digital e não Os discos 1.0.0

mídia removível onal.2 – 09.o digital que exige o desconectados
uso restrito e as devem ser
garantias específicas criptografados
usadas para restringir
o uso delas são
identificadas.
VERSÃ O DA
Transações online 0945.09y1Organizati Os protocolos Auditar os 1.0.1

onal.3 – 09.y usados para computadores
comunicação entre Windows que não
todas as partes contêm os
envolvidas são certificados
protegidos por meio especificados na Raiz
de técnicas de Confiável
criptografia (por
exemplo, SSL).
Controle de software 0605.10h1System.12 Somente os As vulnerabilidades 3.0.0

operacional – 10.h administradores da configuração de
autorizados têm segurança nas
permissão para máquinas devem ser
implementar corrigidas
atualizações
aprovadas em
programas de
software, aplicativos
e bibliotecas de
programas, com base
nos requisitos de
negócios e nas
implicações de
segurança da versão.
Controle de software 0605.10h1System.12 Somente os Os computadores 2.0.0

operacional – 10.h administradores Windows devem
autorizados têm atender aos
permissão para requisitos de 'Opções
implementar de Segurança –
atualizações Auditoria'
aprovadas em
programas de
e bibliotecas de
programas, com base
nos requisitos de
negócios e nas
implicações de
Controle de software 0605.10h1System.12 Somente os Os computadores 2.0.0

operacional – 10.h administradores Windows devem
autorizados têm atender aos
permissão para requisitos de
implementar 'Políticas de Auditoria
atualizações do Sistema –
aprovadas em Gerenciamento de
programas de Contas'
e bibliotecas de
programas, com base
nos requisitos de
negócios e nas
implicações de
VERSÃ O DA
Controle de software 0606.10h2System.1 Os aplicativos e os As vulnerabilidades 3.0.0

operacional – 10.h sistemas operacionais nas configurações de
são testados com segurança do
êxito quanto à contêiner devem ser
usabilidade, à corrigidas
segurança e ao
impacto antes da
produção.
Controle de software 0607.10h2System.23 A organização usa o Os controles de 3.0.0

operacional – 10.h programa de aplicativos adaptáveis
controle de para definir
configuração dela aplicativos seguros
para manter o devem estar
controle de todo o habilitados nos
software computadores
implementado e a
documentação do
sistema dele e
versões anteriores de
arquivo do software
implementado e da
documentação do
sistema associada.
Controle de software 0607.10h2System.23 A organização usa o As vulnerabilidades 3.0.0

operacional – 10.h programa de da configuração de
controle de segurança nos
configuração dela conjuntos de
para manter o dimensionamento de
controle de todo o máquinas virtuais
software devem ser corrigidas
implementado e a
documentação do
sistema dele e
versões anteriores de
arquivo do software
implementado e da
documentação do
sistema associada.
VERSÃ O DA
Procedimentos de 0635.10k1Organizati Os gerentes Os computadores 2.0.0

controle de onal.12 – 10.k responsáveis por Windows devem
alterações sistemas de atender aos
aplicativos também requisitos de
são responsáveis 'Políticas de Auditoria
pelo controle estrito do Sistema –
(segurança) do Acompanhamento
ambiente de suporte Detalhado'
ou projeto e
garantem que todas
as alterações do
sistema propostas
foram examinadas
para verificar se elas
não comprometem a
segurança do sistema
ou do ambiente
operacional.
Procedimentos de 0636.10k2Organizati A organização Os computadores 2.0.0

controle de onal.1 – 10.k aborda formalmente Windows devem
alterações a finalidade, o atender aos
escopo, as funções, requisitos de
as responsabilidades, 'Políticas de Auditoria
o compromisso de do Sistema –
gerenciamento, a Acompanhamento
coordenação entre as Detalhado'
entidades
organizacionais e a
conformidade do
gerenciamento de
configuração (por
exemplo, por meio de
políticas, padrões,
processos).

controle de onal.2 – 10.k desenvolveu, Windows devem
alterações documentou e atender aos
implementou um requisitos de
plano de 'Políticas de Auditoria
gerenciamento de do Sistema –
configuração para o Acompanhamento
sistema de Detalhado'
informações.
Procedimentos de 0638.10k2Organizati As alterações são Os computadores 2.0.0

controle de onal.34569 – 10.k formalmente Windows devem
alterações controladas, atender aos
documentadas e requisitos de
impostas a fim de 'Políticas de Auditoria
minimizar situações do Sistema –
de sistemas de Acompanhamento
informação Detalhado'
corrompidos.
VERSÃ O DA
Procedimentos de 0639.10k2Organizati As listas de Os computadores 2.0.0

controle de onal.78 – 10.k verificação de Windows devem
alterações instalação e as atender aos
verificações de requisitos de
vulnerabilidade são 'Políticas de Auditoria
usadas para validar a do Sistema –
configuração de Acompanhamento
servidores, estações Detalhado'
de trabalho,
dispositivos e
aparelhos e garantir
que a configuração
atenda aos padrões
mínimos.
Procedimentos de 0640.10k2Organizati Quando o Os computadores 2.0.0

controle de onal.1012 – 10.k desenvolvimento é Windows devem
alterações terceirizado, os atender aos
procedimentos de requisitos de
controle de 'Políticas de Auditoria
alterações usados do Sistema –
para lidar com a Acompanhamento
segurança são Detalhado'
incluídos nos
contratos e,
especificamente,
exigem que o
desenvolvedor
acompanhe as falhas
de segurança e a
resolução das falhas
dentro do sistema,
do componente ou
do serviço e relate as
descobertas à equipe
ou às funções
definidas pela
organização.
Procedimentos de 0641.10k2Organizati A organização não Os computadores 2.0.0

controle de onal.11 – 10.k usa atualizações Windows devem
alterações automatizadas em atender aos
sistemas críticos. requisitos de
'Políticas de Auditoria
do Sistema –
Acompanhamento
Detalhado'
VERSÃ O DA

controle de onal.12 – 10.k desenvolve, Windows devem
alterações documenta e atender aos
mantém sob controle requisitos de
uma configuração de 'Políticas de Auditoria
linha de base atual do Sistema –
do sistema de Acompanhamento
informações, além de Detalhado'
examinar e atualizar a
linha de base,
conforme necessário.
Procedimentos de 0643.10k3Organizati A organização (i) Os computadores 2.0.0

controle de onal.3 – 10.k estabelece e Windows devem
alterações documenta atender aos
definições de requisitos de
configuração 'Políticas de Auditoria
obrigatórias para do Sistema –
produtos de Acompanhamento
tecnologia da Detalhado'
informação
empregados no
sistema de
informações usando
as linhas de base de
configuração de
segurança mais
recentes; (ii)
identifica, documenta
e aprova exceções
das definições de
configuração
estabelecidas
obrigatórias para
componentes
individuais com base
em requisitos
operacionais
explícitos; e (iii)
monitora e controla
as alterações nas
definições de
configuração de
acordo com as
políticas e os
procedimentos
organizacionais.
VERSÃ O DA

controle de onal.4 – 10.k emprega Windows devem
alterações mecanismos atender aos
automatizados para requisitos de
(i) gerenciar, aplicar e 'Políticas de Auditoria
verificar de modo do Sistema –
central as definições Acompanhamento
de configuração; (ii) Detalhado'
responder a
alterações não
autorizadas nas
definições de
configuração
relacionadas à
segurança da rede e
do sistema; e (iii)
impor restrições de
acesso e auditoria
das ações de
imposição.
Controle de 0709.10m1Organizat As vulnerabilidades Uma solução de 3.0.0

vulnerabilidades ional.1 – 10.m técnicas são avaliação de
técnicas identificadas, vulnerabilidade deve
avaliadas quanto aos ser habilitada nas
riscos e corrigidas em máquinas virtuais
tempo hábil.
Controle de 0709.10m1Organizat As vulnerabilidades As vulnerabilidades 3.0.0

vulnerabilidades ional.1 – 10.m técnicas são nas configurações de
técnicas identificadas, segurança do
avaliadas quanto aos contêiner devem ser
riscos e corrigidas em corrigidas
tempo hábil.

vulnerabilidades ional.1 – 10.m técnicas são da configuração de
técnicas identificadas, segurança nas
avaliadas quanto aos máquinas devem ser
riscos e corrigidas em corrigidas
tempo hábil.

vulnerabilidades ional.1 – 10.m técnicas são da configuração de
técnicas identificadas, segurança nos
avaliadas quanto aos conjuntos de
riscos e corrigidas em dimensionamento de
tempo hábil. máquinas virtuais
Controle de 0709.10m1Organizat As vulnerabilidades Os computadores 2.0.0

vulnerabilidades ional.1 – 10.m técnicas são Windows devem
técnicas identificadas, atender aos
avaliadas quanto aos requisitos de 'Opções
riscos e corrigidas em de Segurança –
tempo hábil. Servidor de Rede da
Microsoft'
VERSÃ O DA
Controle de 0711.10m2Organizat Um programa de Uma solução de 3.0.0

vulnerabilidades ional.23 – 10.m gerenciamento de avaliação de
técnicas vulnerabilidades vulnerabilidade deve
técnicas está em ser habilitada nas
vigor para monitorar, máquinas virtuais
avaliar, classificar e
corrigir as
vulnerabilidades
identificadas nos
sistemas.
Controle de 0713.10m2Organizat Os patches são As vulnerabilidades 3.0.0

vulnerabilidades ional.5 – 10.m testados e avaliados da configuração de
técnicas antes de serem segurança nas
instalados. máquinas devem ser
corrigidas
Controle de 0714.10m2Organizat O programa de As vulnerabilidades 3.0.0

vulnerabilidades ional.7 – 10.m gerenciamento de da configuração de
técnicas vulnerabilidades segurança nos
técnicas é avaliado conjuntos de
trimestralmente. dimensionamento de
máquinas virtuais
Controle de 0715.10m2Organizat Os sistemas são As vulnerabilidades 3.0.0

vulnerabilidades ional.8 – 10.m protegidos de nas configurações de
técnicas maneira adequada segurança do
(por exemplo, contêiner devem ser
configurados apenas corrigidas
com serviços, portas
e protocolos seguros
e necessários
habilitados).
Controle de 0717.10m3Organizat As ferramentas de As vulnerabilidades 3.0.0

vulnerabilidades ional.2 – 10.m verificação de da configuração de
técnicas vulnerabilidade segurança nos
incluem a capacidade conjuntos de
de atualizar dimensionamento de
imediatamente as máquinas virtuais
vulnerabilidades do devem ser corrigidas
sistema de
informações
verificadas.
VERSÃ O DA
Controle de 0718.10m3Organizat A organização As vulnerabilidades 3.0.0

vulnerabilidades ional.34 – 10.m examina se há da configuração de
técnicas vulnerabilidades no segurança nas
sistema de máquinas devem ser
informações e nos corrigidas
aplicativos
hospedados para
determinar o estado
da correção de falhas
mensalmente
(automaticamente) e
novamente (manual
ou automaticamente)
quando novas
potencialmente
afetam os sistemas e
os ambientes em
rede são identificadas
e relatadas.
Continuidade dos 1634.12b1Organizati A organização Auditar máquinas 1.0.0

negócios e avaliação onal.1 – 12.b identifica os virtuais sem a
de riscos processos de recuperação de
negócios críticos que desastre configurada
exigem continuidade
dos negócios.
Continuidade dos 1637.12b2Organizati A análise de impacto Os computadores 2.0.0

negócios e avaliação onal.2 – 12.b nos negócios é usada Windows devem
de riscos para avaliar as atender aos
consequências de requisitos de 'Opções
desastres, falhas de de Segurança –
segurança, perda de Console de
serviço e recuperação'
disponibilidade do
serviço.
VERSÃ O DA
Continuidade dos 1638.12b2Organizati As avaliações de risco Auditar máquinas 1.0.0

negócios e avaliação onal.345 – 12.b de continuidade dos virtuais sem a
de riscos negócios (i) são recuperação de
realizadas desastre configurada
anualmente com
envolvimento
completo de
proprietários de
recursos e processos
de negócios; (ii)
consideram todos os
processos de
negócios e não são
limitadas aos ativos
de informações, mas
inclui os resultados
específicos à
segurança da
informação; e (iii)
identificam,
quantificam e
priorizam riscos com
relação aos principais
objetivos de negócios
e critérios relevantes
à organização,
incluindo recursos
críticos, impactos de
interrupções, tempos
de interrupção
permitidos e
prioridades de
recuperação.
ISO 27001:2013
mapeadas para esse padrão de conformidade, confira Conformidade regulatória do Azure Policy – ISO
27001:2013. Para obter mais informações sobre esse padrão de conformidade, confira ISO 27001:2013.
VERSÃ O DA
Controle de acesso 9.1.2 Acesso a redes e Adicionar identidade 1.0.0

serviços de rede gerenciada atribuída
ao sistema para
Convidado em
máquinas virtuais
sem identidades
VERSÃ O DA
Controle de acesso 9.1.2 Acesso a redes e Adicionar uma 1.0.0

serviços de rede identidade
gerenciada atribuída
ao sistema para
Convidado em VMs
com uma identidade
Controle de acesso 9.1.2 Acesso a redes e Auditar os 1.0.0

serviços de rede computadores Linux
que permitem
contas sem senhas
Controle de acesso 9.1.2 Acesso a redes e Auditar os 1.0.0

serviços de rede computadores Linux
que têm contas sem
senhas
Controle de acesso 9.1.2 Acesso a redes e Auditar VMs que não 1.0.0
serviços de rede usam discos
gerenciados
Controle de acesso 9.1.2 Acesso a redes e Implantar a extensão 1.0.0

serviços de rede de Configuração de
Convidado do Linux
para habilitar
atribuições de
Configuração de
Convidado em VMs
do Linux
Controle de acesso 9.1.2 Acesso a redes e As máquinas virtuais 1.0.0

serviços de rede devem ser migradas
para os novos
recursos do Azure
Resource Manager
Controle de acesso 9.2.4 Gerenciamento de Adicionar identidade 1.0.0

informações de gerenciada atribuída
autenticação secretas ao sistema para
de usuários habilitar atribuições
Convidado em
máquinas virtuais
sem identidades
VERSÃ O DA
Controle de acesso 9.2.4 Gerenciamento de Adicionar uma 1.0.0

informações de identidade
autenticação secretas gerenciada atribuída
de usuários ao sistema para
Convidado em VMs
com uma identidade
Controle de acesso 9.2.4 Gerenciamento de Auditar os 1.0.0

informações de computadores Linux
autenticação secretas que não têm as
de usuários permissões de
arquivo de senha
definidas como 0644
Controle de acesso 9.2.4 Gerenciamento de Implantar a extensão 1.0.0

informações de de Configuração de
autenticação secretas Convidado do Linux
de usuários para habilitar
atribuições de
Configuração de
Convidado em VMs
do Linux
Controle de acesso 9.4.3 Sistema de Adicionar identidade 1.0.0

gerenciamento de gerenciada atribuída
senhas ao sistema para
Convidado em
máquinas virtuais
sem identidades
Controle de acesso 9.4.3 Sistema de Adicionar uma 1.0.0

gerenciamento de identidade
senhas gerenciada atribuída
ao sistema para
Convidado em VMs
com uma identidade
Controle de acesso 9.4.3 Sistema de Auditar os 1.0.0

gerenciamento de computadores
senhas Windows que podem
reutilizar as 24
senhas anteriores

senhas Windows que não
têm uma duração
máxima da senha de
70 dias
VERSÃ O DA

têm uma duração
mínima da senha de
1 dia

têm a configuração
de complexidade de
senha habilitada

restringem o
tamanho mínimo da
senha a 14 caracteres
Controle de acesso 9.4.3 Sistema de Implantar a extensão 1.0.0

gerenciamento de de Configuração de
senhas Convidado do
Windows para
Convidado em VMs
do Windows
Criptografia 10.1.1 Política sobre o uso Adicionar identidade 1.0.0

de controles de gerenciada atribuída
criptografia ao sistema para
Convidado em
máquinas virtuais
sem identidades
Criptografia 10.1.1 Política sobre o uso Adicionar uma 1.0.0

de controles de identidade
criptografia gerenciada atribuída
ao sistema para
Convidado em VMs
com uma identidade
Criptografia 10.1.1 Política sobre o uso Auditar os 1.0.0

de controles de computadores
criptografia Windows que não
armazenam senhas
reversível
VERSÃ O DA
Criptografia 10.1.1 Política sobre o uso Implantar a extensão 1.0.0

de controles de de Configuração de
criptografia Convidado do
Windows para
Convidado em VMs
do Windows
Criptografia 10.1.1 Política sobre o uso A criptografia de 2.0.0

de controles de disco deve ser
criptografia aplicada em
Máquinas virtuais
Segurança de 12.4.1 Log de eventos [Versão prévia]: 1.0.0 – versão prévia

operações Auditar a
implantação do
Agente do Log
de VM (sistema
operacional) não
listada
Segurança de 12.4.1 Log de eventos Auditar a 1.0.1

operações implantação do
Dependency Agent –
imagem de VM
não listada

Dependency Agent
em conjuntos de
dimensionamento de
máquinas virtuais –
imagem de VM
não listada

agente do Log
Analytics em
Conjuntos de
Dimensionamento de
imagem de VM
não listada
VERSÃ O DA
Segurança de 12.4.3 Logs de [Versão prévia]: 1.0.0 – versão prévia

operações administrador e Auditar a
operador implantação do
Agente do Log
de VM (sistema
operacional) não
listada
Segurança de 12.4.3 Logs de Auditar a 1.0.1

operações administrador e implantação do
operador Dependency Agent –
imagem de VM
não listada

operador Dependency Agent
em conjuntos de
dimensionamento de
imagem de VM
não listada

operador agente do Log
Analytics em
Conjuntos de
Dimensionamento de
imagem de VM
não listada
Segurança de 12.4.4 Sincronização de [Versão prévia]: 1.0.0 – versão prévia

operações relógio Auditar a
implantação do
Agente do Log
de VM (sistema
operacional) não
listada
Segurança de 12.4.4 Sincronização de Auditar a 1.0.1

operações relógio implantação do
Dependency Agent –
imagem de VM
não listada
VERSÃ O DA

Dependency Agent
em conjuntos de
dimensionamento de
imagem de VM
não listada

agente do Log
Analytics em
Conjuntos de
Dimensionamento de
imagem de VM
não listada
Segurança de 12.5.1 Instalação do Os controles de 3.0.0

operações software de sistemas aplicativos adaptáveis
operacionais para definir
aplicativos seguros
devem estar
habilitados nos
computadores
Segurança de 12.6.1 Gerenciamento de Uma solução de 3.0.0

operações vulnerabilidades avaliação de
técnicas vulnerabilidade deve
ser habilitada nas
máquinas virtuais
Segurança de 12.6.1 Gerenciamento de Monitorar o 3.0.0

operações vulnerabilidades Endpoint Protection
técnicas ausente na Central
de Segurança do
Azure
Segurança de 12.6.1 Gerenciamento de As atualizações do 3.0.0

operações vulnerabilidades sistema devem ser
técnicas instaladas em suas
máquinas
Segurança de 12.6.1 Gerenciamento de As vulnerabilidades 3.0.0

operações vulnerabilidades da configuração de
técnicas segurança nas
máquinas devem ser
corrigidas
VERSÃ O DA
Segurança de 12.6.2 Restrições de Os controles de 3.0.0

operações instalação de aplicativos adaptáveis
software para definir
aplicativos seguros
devem estar
habilitados nos
computadores
Segurança de 13.1.1 Controles de rede Todas as portas de 3.0.0

comunicações rede devem ser
restritas nos grupos
de segurança de rede
associados à sua
máquina virtual
ISM da Nova Zelândia

Para examinar como os internos do Azure Policy disponíveis para todos os serviços do Azure são mapeados
para esse padrão de conformidade, confira Conformidade regulatória do Azure Policy – Manual de segurança da
informação da Nova Zelândia. Para obter mais informações sobre esse padrão de conformidade, confira Manual
de segurança da informação da Nova Zelândia.
VERSÃ O DA
Monitoramento de ISM-3 6.2.5 Realização de Uma solução de 3.0.0

segurança da avaliações de avaliação de
informação vulnerabilidade vulnerabilidade deve
ser habilitada nas
máquinas virtuais
Monitoramento de ISM-3 6.2.5 Realização de As vulnerabilidades 3.0.0

segurança da avaliações de nas configurações de
informação vulnerabilidade segurança do
contêiner devem ser
corrigidas

segurança da avaliações de da configuração de
informação vulnerabilidade segurança nas
máquinas devem ser
corrigidas

segurança da avaliações de da configuração de
informação vulnerabilidade segurança nos
conjuntos de
dimensionamento de
máquinas virtuais
VERSÃ O DA
Segurança do PRS-5 12.4.4 Aplicação de As atualizações do 3.0.0

produto patches para sistema nos
correção de conjuntos de
vulnerabilidades em dimensionamento de
produtos máquinas virtuais
Segurança do PRS-5 12.4.4 Aplicação de As atualizações do 3.0.0

produto patches para sistema devem ser
correção de instaladas em suas
vulnerabilidades em máquinas
produtos
Segurança de SS-2 14.1.9 Manutenção Implantar o 1.3.0

software de SOEs protegidos Dependency Agent
em conjuntos de
dimensionamento de
Windows
Segurança de SS-2 14.1.9 Manutenção A solução de 3.0.0

software de SOEs protegidos proteção de ponto
de extremidade deve
ser instalada nos
conjuntos de
dimensionamento de
máquinas virtuais
Segurança de SS-2 14.1.9 Manutenção A extensão 1.0.0

software de SOEs protegidos IaaSAntimalware da
Microsoft deve ser
implantada em
servidores do
Windows
Segurança de SS-2 14.1.9 Manutenção Monitorar o 3.0.0

software de SOEs protegidos Endpoint Protection
ausente na Central
de Segurança do
Azure
Segurança de SS-4 14.2.4 Inclusão de Os controles de 3.0.0

software aplicativos em listas aplicativos adaptáveis
de permitidos para definir
aplicativos seguros
devem estar
habilitados nos
computadores
Controle de acesso e AC-2 16.1.32 Identificação Auditar os 1.0.0

senhas de usuário do computadores Linux
sistema que permitem
contas sem senhas
VERSÃ O DA

senhas de usuário do computadores Linux
sistema que têm contas sem
senhas
Controle de acesso e AC-2 16.1.32 Identificação Auditar 1.0.0

senhas de usuário do computadores
sistema Windows que não
têm membros
especificados no
Grupo de
administradores

sistema Windows que têm
contas extras no
Grupo de
administradores
Controle de acesso e AC-2 16.1.32 Identificação Auditar 1.0.0

sistema Windows que têm os
membros
especificados no
Grupo de
administradores
Controle de acesso e AC-2 16.1.32 Identificação Implantar o 1.3.0

senhas de usuário do Dependency Agent
sistema nas máquinas
virtuais do Windows
Controle de acesso e AC-2 16.1.32 Identificação Implantar a extensão 1.0.0

senhas de usuário do de Configuração de
sistema Convidado do Linux
para habilitar
atribuições de
Configuração de
Convidado em VMs
do Linux
Controle de acesso e AC-2 16.1.32 Identificação Implantar a extensão 1.0.0

senhas de usuário do de Configuração de
sistema Convidado do
Windows para
Convidado em VMs
do Windows
Controle de acesso e AC-4 16.1.40 Política de Implantar o 1.3.0

senhas seleção de senha Dependency Agent
nas máquinas
virtuais do Windows
VERSÃ O DA
Controle de acesso e AC-4 16.1.40 Política de Os computadores 2.0.0

senhas seleção de senha Windows devem
atender aos
requisitos de
'Configurações de
Segurança – Políticas
de Conta'
Controle de acesso e AC-5 16.1.46 Suspensão Implantar o 1.3.0

senhas do acesso Dependency Agent
nas máquinas
virtuais do Windows
Controle de acesso e AC-7 16.2.5 Proteção de As portas de 3.0.0

senhas informações gerenciamento de
compartimentalizada máquinas virtuais
s em sistemas devem ser protegidas
com o controle de
time
Controle de acesso e AC-9 16.3.5 Uso de contas Auditar 1.0.0

senhas com privilégios computadores
Windows que não
têm membros
especificados no
Grupo de
administradores
Controle de acesso e AC-9 16.3.5 Uso de contas Auditar os 1.0.0

Windows que têm
contas extras no
Grupo de
administradores
Controle de acesso e AC-9 16.3.5 Uso de contas Auditar 1.0.0

Windows que têm os
membros
especificados no
Grupo de
administradores
Controle de acesso e AC-9 16.3.5 Uso de contas Implantar o 1.3.0

senhas com privilégios Dependency Agent
nas máquinas
virtuais do Windows
Controle de acesso e AC-9 16.3.5 Uso de contas Implantar a extensão 1.0.0

senhas com privilégios de Configuração de
Convidado do
Windows para
Convidado em VMs
do Windows
VERSÃ O DA
Controle de acesso e AC-14 16.6.7 Conteúdo de [Versão prévia]: 1.0.0 – versão prévia
senhas logs de Auditar a
gerenciamento do implantação do
sistema Agente do Log
de VM (sistema
operacional) não
listada
Controle de acesso e AC-14 16.6.7 Conteúdo de Auditar a 1.0.1

senhas logs de implantação do
gerenciamento do agente do Log
sistema Analytics em
Conjuntos de
Dimensionamento de
imagem de VM
não listada
Controle de acesso e AC-14 16.6.7 Conteúdo de Auditar o workspace 1.0.1

senhas logs de do Log Analytics para
gerenciamento do a VM – Relatar
sistema incompatibilidade
Criptografia CR-2 17.1.46 Redução dos A criptografia de 2.0.0

requisitos de disco deve ser
armazenamento e de aplicada em
transferência física Máquinas virtuais
Criptografia CR-6 17.4.16 Uso do Implantar a extensão 1.0.0

protocolo TLS de Configuração de
Convidado do
Windows para
Convidado em VMs
do Windows
Criptografia CR-6 17.4.16 Uso do Os servidores Web 2.0.0

protocolo TLS do Windows devem
ser configurados para
usar protocolos de
VERSÃ O DA
Segurança de rede NS-2 18.1.13 Limitação de As recomendações 3.0.0

acesso à rede da proteção de rede
adaptável devem ser
aplicadas nas
máquinas virtuais
para a Internet
Segurança de rede NS-2 18.1.13 Limitação de As máquinas virtuais 3.0.0

acesso à rede para a Internet
com grupos de
segurança de rede
Gerenciamento de DM-4 20.3.10 Verificações Implantar o 1.3.0

dados antivírus Dependency Agent
em conjuntos de
dimensionamento de
Windows
Gerenciamento de DM-4 20.3.10 Verificações A solução de 3.0.0

dados antivírus proteção de ponto
de extremidade deve
ser instalada nos
conjuntos de
dimensionamento de
máquinas virtuais
Gerenciamento de DM-4 20.3.10 Verificações Monitorar o 3.0.0

dados antivírus Endpoint Protection
ausente na Central
de Segurança do
Azure
Gerenciamento de DM-4 20.3.10 Verificações O Microsoft 1.1.1

dados antivírus Defender Exploit
Guard deve estar
habilitado nos
computadores
Gerenciamento de DM-6 20.4.4 Arquivos de A criptografia de 2.0.0

dados banco de dados disco deve ser
aplicada em
Máquinas virtuais
Gerenciamento de DM-6 20.4.4 Arquivos de Os servidores Web 2.0.0

dados banco de dados do Windows devem
ser configurados para
usar protocolos de
Segurança de ESS-3 22.1.26 Backup, Auditar máquinas 1.0.0

sistemas corporativos arquivamento de virtuais sem a
recuperação e recuperação de
remanência de dados desastre configurada
NIST SP 800-171 R2
mapeadas para esse padrão de conformidade, confira Conformidade regulatória do Azure Policy – NIST SP 800-
171 R2. Para obter mais informações sobre esse padrão de conformidade, confira NIST SP 800-171 R2.
VERSÃ O DA
Controle de acesso 3.1.1 Limite o acesso do Adicionar identidade 1.0.0

sistema a usuários gerenciada atribuída
autorizados, ao sistema para
autorizados e Convidado em
dispositivos máquinas virtuais
(incluindo outros sem identidades
sistemas).
Controle de acesso 3.1.1 Limite o acesso do Adicionar uma 1.0.0

sistema a usuários identidade
autorizados, gerenciada atribuída
processos que atuam ao sistema para
em nome de usuários habilitar atribuições
autorizados e de Configuração de
dispositivos Convidado em VMs
(incluindo outros com uma identidade
sistemas). atribuída ao usuário
Controle de acesso 3.1.1 Limite o acesso do Auditar os 1.0.0

sistema a usuários computadores Linux
autorizados, que permitem
processos que atuam conexões remotas de
em nome de usuários contas sem senhas
autorizados e
dispositivos
(incluindo outros
sistemas).
Controle de acesso 3.1.1 Limite o acesso do Implantar a extensão 1.0.0

sistema a usuários de Configuração de
autorizados, Convidado do
processos que atuam Windows para
em nome de usuários habilitar atribuições
autorizados e de Configuração de
dispositivos Convidado em VMs
(incluindo outros do Windows
sistemas).
Controle de acesso 3.1.1 Limite o acesso do Os computadores 2.0.0

sistema a usuários Windows devem
autorizados, atender aos
processos que atuam requisitos de 'Opções
em nome de usuários de Segurança –
autorizados e Segurança de Rede'
dispositivos
(incluindo outros
sistemas).
VERSÃ O DA
Controle de acesso 3.1.4 Separe as tarefas de Auditar 1.0.0

reduzir o risco de Windows que não
atividades maliciosas têm membros
Grupo de
administradores
Controle de acesso 3.1.4 Separe as tarefas de Auditar 1.0.0

reduzir o risco de Windows que têm os
atividades maliciosas membros
Grupo de
administradores
Controle de acesso 3.1.12 Monitore e controle Adicionar identidade 1.0.0

sessões de acesso gerenciada atribuída
remoto. ao sistema para
Convidado em
máquinas virtuais
sem identidades
Controle de acesso 3.1.12 Monitore e controle Adicionar uma 1.0.0

sessões de acesso identidade
remoto. gerenciada atribuída
ao sistema para
Convidado em VMs
com uma identidade
Controle de acesso 3.1.12 Monitore e controle Auditar os 1.0.0

sessões de acesso computadores Linux
remoto. que permitem
contas sem senhas
Controle de acesso 3.1.12 Monitore e controle Implantar a extensão 1.0.0

sessões de acesso de Configuração de
remoto. Convidado do
Windows para
Convidado em VMs
do Windows
Controle de acesso 3.1.12 Monitore e controle Os computadores 2.0.0

sessões de acesso Windows devem
remoto. atender aos
de Segurança –
Segurança de Rede'
VERSÃ O DA
Auditoria e 3.3.1 Crie e retenha [Versão prévia]: 1.0.0 – versão prévia

Contabilidade registros e logs de Auditar a
auditoria do sistema implantação do
na extensão Agente do Log
necessária para Analytics – imagem
habilitar o de VM (sistema
monitoramento, a operacional) não
análise, a listada
investigação e a
ou não autorizadas
do sistema.
Auditoria e 3.3.1 Crie e retenha Auditar a 1.0.1

Contabilidade registros e logs de implantação do
auditoria do sistema agente do Log
na extensão Analytics em
necessária para Conjuntos de
habilitar o Dimensionamento de
monitoramento, a Máquinas Virtuais –
análise, a imagem de VM
investigação e a (sistema operacional)
emissão de relatórios não listada
ou não autorizadas
do sistema.
Auditoria e 3.3.1 Crie e retenha Auditar o workspace 1.0.1

Contabilidade registros e logs de do Log Analytics para
auditoria do sistema a VM – Relatar
na extensão incompatibilidade
necessária para
habilitar o
monitoramento, a
análise, a
investigação e a
ou não autorizadas
do sistema.
Auditoria e 3.3.1 Crie e retenha O agente do Log 1.0.0

auditoria do sistema instalado nos
na extensão Conjuntos de
necessária para Dimensionamento de
habilitar o Máquinas Virtuais
monitoramento, a
análise, a
investigação e a
ou não autorizadas
do sistema.
VERSÃ O DA
Auditoria e 3.3.1 Crie e retenha O agente do Log 1.0.0

auditoria do sistema instalado nas
na extensão máquinas virtuais
necessária para
habilitar o
monitoramento, a
análise, a
investigação e a
ou não autorizadas
do sistema.
Auditoria e 3.3.2 Verifique se as ações [Versão prévia]: 1.0.0 – versão prévia

Contabilidade de usuários Auditar a
individuais do implantação do
sistema podem ser Agente do Log
rastreadas Analytics – imagem
exclusivamente para de VM (sistema
esses usuários, para operacional) não
que eles possam ser listada
responsabilizados
pelas respectivas
ações.
Auditoria e 3.3.2 Verifique se as ações Auditar a 1.0.1

Contabilidade de usuários implantação do
individuais do agente do Log
sistema podem ser Analytics em
rastreadas Conjuntos de
exclusivamente para Dimensionamento de
esses usuários, para Máquinas Virtuais –
que eles possam ser imagem de VM
responsabilizados (sistema operacional)
pelas respectivas não listada
ações.
Auditoria e 3.3.2 Verifique se as ações Auditar o workspace 1.0.1

Contabilidade de usuários do Log Analytics para
individuais do a VM – Relatar
sistema podem ser incompatibilidade
rastreadas
exclusivamente para
que eles possam ser
responsabilizados
pelas respectivas
ações.
VERSÃ O DA
Auditoria e 3.3.2 Verifique se as ações O agente do Log 1.0.0

individuais do instalado nos
sistema podem ser Conjuntos de
rastreadas Dimensionamento de
exclusivamente para Máquinas Virtuais
que eles possam ser
responsabilizados
pelas respectivas
ações.
Auditoria e 3.3.2 Verifique se as ações O agente do Log 1.0.0

individuais do instalado nas
sistema podem ser máquinas virtuais
rastreadas
exclusivamente para
que eles possam ser
responsabilizados
pelas respectivas
ações.
Gerenciamento de 3.4.7 Restrinja, desabilite Os controles de 3.0.0

configuração ou impeça o uso de aplicativos adaptáveis
programas, funções, para definir
portas, protocolos e aplicativos seguros
serviços não devem estar
essenciais. habilitados nos
computadores
Gerenciamento de 3.4.8 Aplique a política de Os controles de 3.0.0

configuração negar por exceção aplicativos adaptáveis
(lista de bloqueios) para definir
para evitar o uso de aplicativos seguros
software não devem estar
autorizado ou a habilitados nos
política de negar computadores
tudo, permitir por
exceção (lista de
permissões) para
permitir a realização
de software
autorizado.
Gerenciamento de 3.4.9 Controle e monitore Os controles de 3.0.0

configuração software instalado aplicativos adaptáveis
pelo usuário. para definir
aplicativos seguros
devem estar
habilitados nos
computadores
VERSÃ O DA
Identificação e 3.5.2 Autenticar (ou Adicionar identidade 1.0.0

Autenticação verificar) as gerenciada atribuída
identidades de ao sistema para
usuários, processos habilitar atribuições
ou dispositivos como de Configuração de
um pré-requisito Convidado em
para permitir o máquinas virtuais
acesso a sistemas sem identidades
organizacionais.
Identificação e 3.5.2 Autenticar (ou Adicionar uma 1.0.0

Autenticação verificar) as identidade
identidades de gerenciada atribuída
usuários, processos ao sistema para
acesso a sistemas com uma identidade
organizacionais. atribuída ao usuário
Identificação e 3.5.2 Autenticar (ou Auditar os 1.0.0

identidades de que têm contas sem
usuários, processos senhas
ou dispositivos como
um pré-requisito
para permitir o
acesso a sistemas
organizacionais.
Identificação e 3.5.2 Autenticar (ou Implantar a extensão 1.0.0

Autenticação verificar) as de Configuração de
identidades de Convidado do
usuários, processos Windows para
acesso a sistemas do Windows
organizacionais.
Identificação e 3.5.2 Autenticar (ou Os computadores 2.0.0

Autenticação verificar) as Windows devem
identidades de atender aos
usuários, processos requisitos de 'Opções
ou dispositivos como de Segurança –
um pré-requisito Segurança de Rede'
para permitir o
acesso a sistemas
organizacionais.
VERSÃ O DA
Identificação e 3.5.7 Imponha uma Adicionar identidade 1.0.0

Autenticação complexidade mínima gerenciada atribuída
de senha e uma ao sistema para
alteração de habilitar atribuições
caracteres quando de Configuração de
senhas forem criadas. Convidado em
máquinas virtuais
sem identidades
Identificação e 3.5.7 Imponha uma Adicionar uma 1.0.0

Autenticação complexidade mínima identidade
de senha e uma gerenciada atribuída
alteração de ao sistema para
Convidado em VMs
com uma identidade
Identificação e 3.5.7 Imponha uma Auditar os 1.0.0

Autenticação complexidade mínima computadores Linux
de senha e uma que têm contas sem
alteração de senhas
caracteres quando
senhas forem criadas.

alteração de têm a configuração
caracteres quando de complexidade de
senhas forem criadas. senha habilitada

alteração de restringem o
caracteres quando tamanho mínimo da
senhas forem criadas. senha a 14 caracteres
Identificação e 3.5.7 Imponha uma Implantar a extensão 1.0.0

Autenticação complexidade mínima de Configuração de
de senha e uma Convidado do
alteração de Windows para
Convidado em VMs
do Windows
Identificação e 3.5.7 Imponha uma Os computadores 2.0.0

Autenticação complexidade mínima Windows devem
de senha e uma atender aos
alteração de requisitos de 'Opções
caracteres quando de Segurança –
senhas forem criadas. Segurança de Rede'
VERSÃ O DA
Identificação e 3.5.8 Proíba a reutilização Adicionar identidade 1.0.0

Autenticação de senhas por um gerenciada atribuída
número especificado ao sistema para
de gerações. habilitar atribuições
Convidado em
máquinas virtuais
sem identidades
Identificação e 3.5.8 Proíba a reutilização Adicionar uma 1.0.0

Autenticação de senhas por um identidade
número especificado gerenciada atribuída
de gerações. ao sistema para
Convidado em VMs
com uma identidade
Identificação e 3.5.8 Proíba a reutilização Auditar os 1.0.0

Autenticação de senhas por um computadores
número especificado Windows que podem
de gerações. reutilizar as 24
senhas anteriores
Identificação e 3.5.8 Proíba a reutilização Implantar a extensão 1.0.0

Autenticação de senhas por um de Configuração de
número especificado Convidado do
de gerações. Windows para
Convidado em VMs
do Windows
Identificação e 3.5.8 Proíba a reutilização Os computadores 2.0.0

Autenticação de senhas por um Windows devem
número especificado atender aos
de gerações. requisitos de 'Opções
de Segurança –
Segurança de Rede'
Identificação e 3.5.10 Armazene e Adicionar identidade 1.0.0

Autenticação transmita apenas gerenciada atribuída
senhas protegidas ao sistema para
criptograficamente. habilitar atribuições
Convidado em
máquinas virtuais
sem identidades
VERSÃ O DA
Identificação e 3.5.10 Armazene e Adicionar uma 1.0.0

Autenticação transmita apenas identidade
senhas protegidas gerenciada atribuída
criptograficamente. ao sistema para
Convidado em VMs
com uma identidade
Identificação e 3.5.10 Armazene e Auditar os 1.0.0

Autenticação transmita apenas computadores Linux
senhas protegidas que não têm as
criptograficamente. permissões de
arquivo de senha
definidas como 0644
Identificação e 3.5.10 Armazene e Auditar os 1.0.0

Autenticação transmita apenas computadores
senhas protegidas Windows que não
criptograficamente. armazenam senhas
reversível
Identificação e 3.5.10 Armazene e Implantar a extensão 1.0.0

Autenticação transmita apenas de Configuração de
senhas protegidas Convidado do
criptograficamente. Windows para
Convidado em VMs
do Windows
Identificação e 3.5.10 Armazene e Os computadores 2.0.0

Autenticação transmita apenas Windows devem
senhas protegidas atender aos
criptograficamente. requisitos de 'Opções
de Segurança –
Segurança de Rede'
Avaliação de risco 3.11.2 Verifique se há Uma solução de 3.0.0

vulnerabilidades em avaliação de
sistemas vulnerabilidade deve
organizacionais e ser habilitada nas
aplicativos máquinas virtuais
periodicamente e
quando novas
afetam esses
são identificadas.
VERSÃ O DA
Avaliação de risco 3.11.2 Verifique se há As vulnerabilidades 3.0.0

vulnerabilidades em nas configurações de
sistemas segurança do
organizacionais e contêiner devem ser
aplicativos corrigidas
periodicamente e
quando novas
afetam esses
são identificadas.

vulnerabilidades em da configuração de
sistemas segurança nas
organizacionais e máquinas devem ser
aplicativos corrigidas
periodicamente e
quando novas
afetam esses
são identificadas.

vulnerabilidades em da configuração de
sistemas segurança nos
organizacionais e conjuntos de
aplicativos dimensionamento de
periodicamente e máquinas virtuais
quando novas devem ser corrigidas
afetam esses
são identificadas.
Proteção do Sistema 3.13.1 Monitore, controle e As recomendações 3.0.0

e das Comunicações proteja as da proteção de rede
comunicações (ou adaptável devem ser
seja, informações aplicadas nas
transmitidas ou máquinas virtuais
recebidas por para a Internet
sistemas
principais limites
organizacionais.
VERSÃ O DA
Proteção do Sistema 3.13.1 Monitore, controle e Todas as portas de 3.0.0

e das Comunicações proteja as rede devem ser
comunicações (ou restritas nos grupos
seja, informações de segurança de rede
transmitidas ou associados à sua
recebidas por máquina virtual
sistemas
principais limites
organizacionais.
Proteção do Sistema 3.13.1 Monitore, controle e Os servidores Web 2.0.0

e das Comunicações proteja as do Windows devem
comunicações (ou ser configurados para
seja, informações usar protocolos de
transmitidas ou comunicação segura
recebidas por
sistemas
principais limites
organizacionais.
Proteção do Sistema 3.13.5 Implemente sub- As recomendações 3.0.0

e das Comunicações redes para da proteção de rede
componentes do adaptável devem ser
sistema publicamente aplicadas nas
acessíveis que máquinas virtuais
estejam fisicamente para a Internet
ou logicamente
separados de redes
internas.
Proteção do Sistema 3.13.5 Implemente sub- Todas as portas de 3.0.0

e das Comunicações redes para rede devem ser
componentes do restritas nos grupos
sistema publicamente de segurança de rede
acessíveis que associados à sua
estejam fisicamente máquina virtual
ou logicamente
separados de redes
internas.
Proteção do Sistema 3.13.5 Implemente sub- As máquinas virtuais 3.0.0

e das Comunicações redes para para a Internet
componentes do devem ser protegidas
sistema publicamente com grupos de
acessíveis que segurança de rede
estejam fisicamente
ou logicamente
separados de redes
internas.
VERSÃ O DA
Proteção do Sistema 3.13.8 Implemente Os servidores Web 2.0.0

e das Comunicações mecanismos do Windows devem
criptográficos para ser configurados para
impedir a divulgação usar protocolos de
não autorizada da comunicação segura
CUI durante a
transmissão, a menos
que ela conte com
proteções físicas
alternativas.
Proteção do Sistema 3.13.16 Proteja a A criptografia de 2.0.0

e das Comunicações confidencialidade do disco deve ser
CUI em repouso. aplicada em
Máquinas virtuais
Integridade do 3.14.1 Identifique, relate e Uma solução de 3.0.0

Sistema e das corrija falhas do avaliação de
Informações sistema vulnerabilidade deve
oportunamente. ser habilitada nas
máquinas virtuais
Integridade do 3.14.1 Identifique, relate e As atualizações do 3.0.0

Sistema e das corrija falhas do sistema nos
Informações sistema conjuntos de
oportunamente. dimensionamento de
máquinas virtuais
Integridade do 3.14.1 Identifique, relate e As atualizações do 3.0.0

Sistema e das corrija falhas do sistema devem ser
Informações sistema instaladas em suas
oportunamente. máquinas
Integridade do 3.14.1 Identifique, relate e As vulnerabilidades 3.0.0

Sistema e das corrija falhas do da configuração de
Informações sistema segurança nas
oportunamente. máquinas devem ser
corrigidas
Integridade do 3.14.1 Identifique, relate e As vulnerabilidades 3.0.0

Sistema e das corrija falhas do da configuração de
Informações sistema segurança nos
oportunamente. conjuntos de
dimensionamento de
máquinas virtuais
Integridade do 3.14.2 Fornecer proteção A solução de 3.0.0

Sistema e das contra código mal- proteção de ponto
Informações intencionado em de extremidade deve
locais designados em ser instalada nos
sistemas conjuntos de
organizacionais. dimensionamento de
máquinas virtuais
VERSÃ O DA
Integridade do 3.14.2 Fornecer proteção A extensão 1.0.0

Sistema e das contra código mal- IaaSAntimalware da
Informações intencionado em Microsoft deve ser
locais designados em implantada em
sistemas servidores do
organizacionais. Windows
Integridade do 3.14.2 Fornecer proteção Monitorar o 3.0.0

Sistema e das contra código mal- Endpoint Protection
Informações intencionado em ausente na Central
locais designados em de Segurança do
sistemas Azure
organizacionais.
NIST SP 800-53 R4
mapeadas para esse padrão de conformidade, confira Conformidade regulatória do Azure Policy – NIST SP 800-
53 R4. Para obter mais informações sobre esse padrão de conformidade, confira NIST SP 800-53 R4.
VERSÃ O DA
Controle de acesso AC-2 (12) Gerenciamento de As portas de 3.0.0

conta | gerenciamento de
Monitoramento de máquinas virtuais
conta/Uso atípico devem ser protegidas
com o controle de
time
Controle de acesso AC-5 Separação de funções Auditar 1.0.0

computadores
Windows que não
têm membros
especificados no
Grupo de
administradores
Controle de acesso AC-5 Separação de funções Auditar 1.0.0

computadores
Windows que têm os
membros
especificados no
Grupo de
administradores
Controle de acesso AC-6 (7) Privilégios mínimos | Auditar 1.0.0

Revisão de privilégios computadores
do usuário Windows que não
têm membros
especificados no
Grupo de
administradores
VERSÃ O DA
Controle de acesso AC-6 (7) Privilégios mínimos | Auditar 1.0.0

Revisão de privilégios computadores
do usuário Windows que têm os
membros
especificados no
Grupo de
administradores
Controle de acesso AC-17 (1) Acesso remoto | Adicionar identidade 1.0.0

Controle/monitoram gerenciada atribuída
ento automatizado ao sistema para
Convidado em
máquinas virtuais
sem identidades
Controle de acesso AC-17 (1) Acesso remoto | Adicionar uma 1.0.0

Controle/monitoram identidade
ento automatizado gerenciada atribuída
ao sistema para
Convidado em VMs
com uma identidade
Controle de acesso AC-17 (1) Acesso remoto | Auditar os 1.0.0

Controle/monitoram computadores Linux
ento automatizado que permitem
contas sem senhas
Controle de acesso AC-17 (1) Acesso remoto | Implantar a extensão 1.0.0

Controle/monitoram de Configuração de
ento automatizado Convidado do Linux
para habilitar
atribuições de
Configuração de
Convidado em VMs
do Linux
Controle de acesso AC-17 (1) Acesso remoto | Implantar a extensão 1.0.0

Controle/monitoram de Configuração de
ento automatizado Convidado do
Windows para
Convidado em VMs
do Windows
VERSÃ O DA
Auditoria e AU-3 (2) Conteúdo de [Versão prévia]: 1.0.0 – versão prévia

Contabilidade registros de auditoria Auditar a
| Gerenciamento implantação do
centralizado do Agente do Log
conteúdo do registro Analytics – imagem
de auditoria de VM (sistema
planejada operacional) não
listada
Auditoria e AU-3 (2) Conteúdo de Auditar a 1.0.1

Contabilidade registros de auditoria implantação do
| Gerenciamento agente do Log
centralizado do Analytics em
conteúdo do registro Conjuntos de
de auditoria Dimensionamento de
planejada Máquinas Virtuais –
imagem de VM
não listada
Auditoria e AU-3 (2) Conteúdo de Auditar o workspace 1.0.1

Contabilidade registros de auditoria do Log Analytics para
| Gerenciamento a VM – Relatar
centralizado do incompatibilidade
conteúdo do registro
de auditoria
planejada
Auditoria e AU-6 (4) Revisão, análise e [Versão prévia]: 1.0.0 – versão prévia
Contabilidade relatório de auditoria Auditar a
| Revisão e análise implantação do
central Agente do Log
de VM (sistema
operacional) não
listada
Auditoria e AU-6 (4) Revisão, análise e Auditar a 1.0.1

Contabilidade relatório de auditoria implantação do
| Revisão e análise agente do Log
central Analytics em
Conjuntos de
Dimensionamento de
imagem de VM
não listada
Auditoria e AU-6 (4) Revisão, análise e Auditar o workspace 1.0.1

Contabilidade relatório de auditoria do Log Analytics para
| Revisão e análise a VM – Relatar
central incompatibilidade
VERSÃ O DA
Auditoria e AU-12 Geração de auditoria [Versão prévia]: 1.0.0 – versão prévia

Contabilidade Auditar a
implantação do
Agente do Log
de VM (sistema
operacional) não
listada
Auditoria e AU-12 Geração de auditoria Auditar a 1.0.1

Contabilidade implantação do
agente do Log
Analytics em
Conjuntos de
Dimensionamento de
imagem de VM
não listada
Auditoria e AU-12 Geração de auditoria Auditar o workspace 1.0.1

Contabilidade do Log Analytics para
a VM – Relatar
incompatibilidade
Gerenciamento de CM-7 (2) Funcionalidade Os controles de 3.0.0

configuração mínima | Impedir a aplicativos adaptáveis
execução do para definir
programa aplicativos seguros
devem estar
habilitados nos
computadores
Gerenciamento de CM-7 (5) Funcionalidade Os controles de 3.0.0

configuração mínima | Software aplicativos adaptáveis
autorizado/Inclusão para definir
na lista de aplicativos seguros
permissões devem estar
habilitados nos
computadores
Gerenciamento de CM-11 Software Instalado Os controles de 3.0.0

configuração pelo Usuário aplicativos adaptáveis
para definir
aplicativos seguros
devem estar
habilitados nos
computadores
Planejamento de CP-7 Site de Auditar máquinas 1.0.0

Contingência processamento virtuais sem a
alternativo recuperação de
desastre configurada
VERSÃ O DA
Identificação e IA-5 Gerenciamento de Adicionar identidade 1.0.0

Autenticação autenticador gerenciada atribuída
ao sistema para
Convidado em
máquinas virtuais
sem identidades
Identificação e IA-5 Gerenciamento de Adicionar uma 1.0.0

Autenticação autenticador identidade
gerenciada atribuída
ao sistema para
Convidado em VMs
com uma identidade
Identificação e IA-5 Gerenciamento de Auditar os 1.0.0

Autenticação autenticador computadores Linux
que não têm as
permissões de
arquivo de senha
definidas como 0644

Autenticação autenticador computadores Linux
que têm contas sem
senhas

Autenticação autenticador computadores
Windows que não
armazenam senhas
reversível
Identificação e IA-5 Gerenciamento de Implantar a extensão 1.0.0

Autenticação autenticador de Configuração de
Convidado do Linux
para habilitar
atribuições de
Configuração de
Convidado em VMs
do Linux
Identificação e IA-5 Gerenciamento de Implantar a extensão 1.0.0

Autenticação autenticador de Configuração de
Convidado do
Windows para
Convidado em VMs
do Windows
VERSÃ O DA
Identificação e IA-5 (1) Gerenciamento do Adicionar identidade 1.0.0

Autenticação Authenticator | gerenciada atribuída
Autenticação ao sistema para
baseada em senha habilitar atribuições
Convidado em
máquinas virtuais
sem identidades
Identificação e IA-5 (1) Gerenciamento do Adicionar uma 1.0.0

Autenticação Authenticator | identidade
Autenticação gerenciada atribuída
baseada em senha ao sistema para
Convidado em VMs
com uma identidade
Identificação e IA-5 (1) Gerenciamento do Auditar os 1.0.0

Autenticação Authenticator | computadores
Autenticação Windows que podem
baseada em senha reutilizar as 24
senhas anteriores

Autenticação Windows que não
baseada em senha têm uma duração
máxima da senha de
70 dias

baseada em senha têm uma duração
mínima da senha de
1 dia

baseada em senha têm a configuração
de complexidade de
senha habilitada

baseada em senha restringem o
tamanho mínimo da
senha a 14 caracteres
VERSÃ O DA

baseada em senha armazenam senhas
reversível
Identificação e IA-5 (1) Gerenciamento do Implantar a extensão 1.0.0

Autenticação Authenticator | de Configuração de
Autenticação Convidado do Linux
baseada em senha para habilitar
atribuições de
Configuração de
Convidado em VMs
do Linux
Identificação e IA-5 (1) Gerenciamento do Implantar a extensão 1.0.0

Autenticação Authenticator | de Configuração de
Autenticação Convidado do
baseada em senha Windows para
Convidado em VMs
do Windows
Avaliação de risco RA-5 Verificação de Uma solução de 3.0.0

vulnerabilidade avaliação de
vulnerabilidade deve
ser habilitada nas
máquinas virtuais
Avaliação de risco RA-5 Verificação de As vulnerabilidades 3.0.0

vulnerabilidade da configuração de
segurança nas
máquinas devem ser
corrigidas
Avaliação de risco RA-5 Verificação de As vulnerabilidades 3.0.0

vulnerabilidade da configuração de
segurança nos
conjuntos de
dimensionamento de
máquinas virtuais
Proteção do Sistema SC-7 Proteção de limite As recomendações 3.0.0

e das Comunicações da proteção de rede
adaptável devem ser
aplicadas nas
máquinas virtuais
para a Internet
VERSÃ O DA
Proteção do Sistema SC-7 Proteção de limite Todas as portas de 3.0.0

e das Comunicações rede devem ser
restritas nos grupos
de segurança de rede
associados à sua
máquina virtual
Proteção do Sistema SC-7 (3) Proteção de limite | As portas de 3.0.0

e das Comunicações Pontos de acesso gerenciamento de
máquinas virtuais
com o controle de
time
Proteção do Sistema SC-7 (4) Proteção de limite | As portas de 3.0.0

e das Comunicações Serviços de gerenciamento de
telecomunicações máquinas virtuais
externas devem ser protegidas
com o controle de
time
Proteção do Sistema SC-8 (1) Confidencialidade e Os servidores Web 2.0.0

e das Comunicações integridade de do Windows devem
transmissão | ser configurados para
Proteção física usar protocolos de
criptográfica ou comunicação segura
alternativa
Proteção do Sistema SC-28 (1) Proteção de A criptografia de 2.0.0

e das Comunicações informações em disco deve ser
repouso | Proteção aplicada em
de criptografia Máquinas virtuais
Integridade do SI-2 Correção de falhas Uma solução de 3.0.0

Sistema e das avaliação de
Informações vulnerabilidade deve
ser habilitada nas
máquinas virtuais
Integridade do SI-2 Correção de falhas As atualizações do 3.0.0

Sistema e das sistema nos
Informações conjuntos de
dimensionamento de
máquinas virtuais
Integridade do SI-2 Correção de falhas As atualizações do 3.0.0

Sistema e das sistema devem ser
Informações instaladas em suas
máquinas
VERSÃ O DA
Integridade do SI-2 Correção de falhas As vulnerabilidades 3.0.0

Sistema e das da configuração de
Informações segurança nas
máquinas devem ser
corrigidas
Integridade do SI-2 Correção de falhas As vulnerabilidades 3.0.0

Sistema e das da configuração de
Informações segurança nos
conjuntos de
dimensionamento de
máquinas virtuais
Integridade do SI-3 Proteção contra A solução de 3.0.0

Sistema e das código mal- proteção de ponto
Informações intencionado de extremidade deve
ser instalada nos
conjuntos de
dimensionamento de
máquinas virtuais
Integridade do SI-3 Proteção contra Monitorar o 3.0.0

Sistema e das código mal- Endpoint Protection
Informações intencionado ausente na Central
de Segurança do
Azure
Integridade do SI-3 (1) Proteção contra A solução de 3.0.0

Sistema e das código mal- proteção de ponto
Informações intencionado | de extremidade deve
Gerenciamento ser instalada nos
central conjuntos de
dimensionamento de
máquinas virtuais
Integridade do SI-3 (1) Proteção contra Monitorar o 3.0.0

Sistema e das código mal- Endpoint Protection
Informações intencionado | ausente na Central
Gerenciamento de Segurança do
central Azure
Integridade do SI-4 Monitoramento do [Versão prévia]: 1.0.0 – versão prévia

Sistema e das sistema de Auditar a
Informações informações implantação do
Agente do Log
de VM (sistema
operacional) não
listada
VERSÃ O DA
Integridade do SI-4 Monitoramento do Auditar a 1.0.1

Sistema e das sistema de implantação do
Informações informações agente do Log
Analytics em
Conjuntos de
Dimensionamento de
imagem de VM
não listada
Integridade do SI-4 Monitoramento do Auditar o workspace 1.0.1

Sistema e das sistema de do Log Analytics para
Informações informações a VM – Relatar
incompatibilidade
Próximas etapas
Saiba mais sobre a Conformidade Regulatória do Azure Policy.
Definições internas do Azure Policy para máquinas
virtuais do Microsoft Azure
Esta página é um índice de definições de políticas internas do Azure Policy para as Máquinas Virtuais do Azure.
Para obter políticas internas adicionais do Azure Policy para outros serviços, confira Definições internas do
Azure Policy.
O nome de cada definição de política interna leva à definição da política no portal do Azure. Use o link na coluna
Versão para ver a origem no repositório GitHub do Azure Policy.
Microsoft.Compute
NOME VERSÃ O
( PO RTA L DO A ZURE ) DESC RIÇ Ã O EF EITO ( S) ( GIT HUB)
[Versão Prévia Privada do [Versão Prévia Privada do modify 1.0.0 – versão prévia
ASC] Implantar – Configurar ASC] Configure a identidade
a identidade gerenciada gerenciada atribuída ao
atribuída ao sistema para sistema para máquinas
habilitar atribuições do virtuais hospedadas no
Azure Monitor nas VMs Azure com suporte do
Azure Monitor que não têm
uma identidade gerenciada
atribuída ao sistema. Uma
identidade gerenciada
atribuída ao sistema é um
pré-requisito para todas as
atribuições do Azure
Monitor e precisa ser
adicionada a computadores
antes de usar alguma
extensão do Azure Monitor.
As máquinas virtuais de
destino devem estar em um
local com suporte.
[Versão prévia]: Auditar a Máquinas virtuais de auditIfNotExists 1.0.0 – versão prévia

implantação do Agente do relatórios como não
Log Analytics – imagem de compatível se a imagem de
VM (sistema operacional) máquina virtual (SO) não
não listada estiver na lista definida e o
agente não estiver
instalado. A lista de
imagens do sistema
operacional será atualizada
ao longo do tempo
conforme atualização do
suporte.
NOME VERSÃ O
DESC RIÇ Ã O EF EITO ( S)
Uma solução de avaliação Audita as máquinas virtuais AuditIfNotExists, 3.0.0

de vulnerabilidade deve ser para detectar se elas estão desabilitado
habilitada nas máquinas executando uma solução de
virtuais avaliação de vulnerabilidade
compatível. Um
componente principal de
cada programa de
segurança e risco
cibernético é a identificação
e a análise das
vulnerabilidades. O tipo de
preço padrão da Central de
Segurança do Azure inclui a
verificação de
vulnerabilidade para as
máquinas virtuais sem
custo adicional. Além disso,
a Central de Segurança
pode implantar essa
ferramenta
automaticamente para
você.
Os controles de aplicativos Permita que os controles de AuditIfNotExists, 3.0.0

adaptáveis para definir aplicativos definam a lista desabilitado
aplicativos seguros devem de aplicativos considerados
estar habilitados nos seguros em execução nos
computadores seus computadores e
alertem você quando
outros aplicativos forem
executados. Isso ajuda a
proteger seus
computadores contra
malware. Para simplificar o
processo de configuração e
manutenção de suas regras,
a Central de Segurança usa
o machine learning para
analisar os aplicativos em
execução em cada
computador e sugerir a lista
de aplicativos considerados
seguros.
As recomendações da A Central de Segurança do AuditIfNotExists, 3.0.0

proteção de rede adaptável Azure analisa os padrões de desabilitado
devem ser aplicadas nas tráfego das máquinas
máquinas virtuais para a virtuais para a Internet e
Internet fornece recomendações de
regra do Grupo de
Segurança de Rede que
reduzem a possível
superfície de ataque
NOME VERSÃ O
Adicionar identidade Essa política adiciona uma modify 1.0.0

gerenciada atribuída ao identidade gerenciada
sistema para habilitar atribuída ao sistema a
atribuições de Configuração máquinas virtuais
de Convidado em máquinas hospedadas no Azure com
virtuais sem identidades suporte da Configuração de
Convidado, mas que não
têm identidades
gerenciadas. Uma
identidade gerenciada
atribuída ao sistema é um
pré-requisito para todas as
atribuições de Configuração
de Convidado e deve ser
adicionada a computadores
antes de usar definições de
política da Configuração de
Convidado. Para obter mais
informações sobre a
Configuração de
Convidado, acesse
https://aka.ms/gcpol.
Adicionar uma identidade Essa política adiciona uma modify 1.0.0

gerenciada atribuída ao identidade gerenciada
sistema para habilitar atribuída ao sistema a
atribuições de Configuração máquinas virtuais
de Convidado em VMs com hospedadas no Azure com
uma identidade atribuída ao suporte da Configuração de
usuário Convidado e tem pelo
menos uma identidade
atribuída ao usuário, mas
não tem uma identidade
gerenciada atribuída ao
sistema. Uma identidade
gerenciada atribuída ao
sistema é um pré-requisito
para todas as atribuições de
Configuração de Convidado
e deve ser adicionada a
computadores antes de
usar definições de política
da Configuração de
Convidado. Para obter mais
Configuração de
Convidado, acesse
NOME VERSÃ O
Todas as portas de rede A Central de Segurança do AuditIfNotExists, 3.0.0

devem ser restritas nos Azure identificou algumas desabilitado
grupos de segurança de das regras de entrada de
rede associados à sua seus grupos de segurança
máquina virtual de rede como permissivas
demais. As regras de
entrada não devem permitir
o acesso por meio de
intervalos "Qualquer" ou
"Internet". Isso tem o
potencial de tornar seus
recursos alvos de invasores.
SKUs de tamanho de Esta política permite Negar 1.0.1

máquina virtual permitidos especificar um conjunto de
SKUs de tamanho de
máquina virtual que sua
organização pode implantar.
As regras da lista de Monitore as alterações no AuditIfNotExists, 3.0.0

permissões na política de comportamento dos desabilitado
controles de aplicativos grupos de computadores
adaptáveis devem ser configurados para auditoria
atualizadas pelos controles de
aplicativos adaptáveis da
Central de Segurança do
Azure. A Central de
Segurança usa o machine
learning para analisar os
processos em execução em
seus computadores e
sugerir uma lista de
aplicativos considerados
seguros. Eles são
apresentados como
aplicativos recomendados
para permitir as políticas de
controle de aplicativos
adaptáveis.
Auditar a implantação do Máquinas virtuais de auditIfNotExists 1.0.1

Dependency Agent – relatórios como não
imagem de VM (sistema compatível se a imagem de
operacional) não listada máquina virtual (SO) não
estiver na lista definida e o
agente não estiver
imagens do sistema
ao longo do tempo
suporte.
NOME VERSÃ O
Auditar a implantação do Relata os conjuntos de auditIfNotExists 1.0.1

Dependency Agent em dimensionamento de
conjuntos de máquinas virtuais do Azure
dimensionamento de como fora de conformidade
máquinas virtuais – imagem se a imagem da VM
de VM (sistema (sistema operacional) não
operacional) não listada está na lista definida e o
agente não está instalado.
A lista de imagens do
sistema operacional será
atualizada ao longo do
tempo conforme
atualização do suporte.
Auditar os computadores Requer que os pré- AuditIfNotExists, 1.0.0

Linux que permitem requisitos sejam desabilitado
conexões remotas de implantados no escopo de
contas sem senhas atribuição de política. Para
obter detalhes, visite
https://aka.ms/gcpol. Os
computadores não estarão
em conformidade se forem
computadores Linux que
permitem conexões
remotas de contas sem
senhas

Linux que não têm as requisitos sejam desabilitado
permissões de arquivo de implantados no escopo de
senha definidas como 0644 atribuição de política. Para
não têm as permissões de
arquivo de senha definidas
como 0644
Auditar os computadores Requer que os pré- auditIfNotExists 3.0.0

Linux que não têm os requisitos sejam
aplicativos especificados implantados no escopo de
instalados atribuição de política. Para
em conformidade se o
recurso Chef InSpec indicar
que um ou mais dos
pacotes fornecidos pelo
parâmetro não estão
instalados.
NOME VERSÃ O

Linux que têm contas sem requisitos sejam desabilitado
senhas implantados no escopo de
atribuição de política. Para
permitem contas sem
senhas

Linux que têm os aplicativos requisitos sejam
especificados instalados implantados no escopo de
recurso Chef InSpec indicar
que um ou mais dos
pacotes fornecidos pelo
parâmetro estão instalados.
Auditar a implantação do Relata os conjuntos de auditIfNotExists 1.0.1

agente do Log Analytics em dimensionamento de
Conjuntos de máquinas virtuais do Azure
Dimensionamento de como fora de conformidade
Máquinas Virtuais – se a imagem da VM
imagem de VM (sistema (sistema operacional) não
operacional) não listada está na lista definida e o
agente não está instalado.
A lista de imagens do
sistema operacional será
atualizada ao longo do
tempo conforme
atualização do suporte.
Auditar o workspace do Log Relata as VMs como sem auditoria 1.0.1

Analytics para a VM – conformidade se elas não
Relatar incompatibilidade estão registrando no log do
workspace do Log Analytics
especificado na atribuição
de política ou de iniciativa.
Auditar máquinas virtuais Audite máquinas virtuais auditIfNotExists 1.0.0

sem a recuperação de sem a recuperação de
desastre configurada desastre configurada. Para
saber mais sobre
recuperação de desastre,
acesse https://aka.ms/asr-
doc.
Auditar VMs que não usam Essa política audita VMs auditoria 1.0.0
discos gerenciados que não usam discos
gerenciados
NOME VERSÃ O
Auditar computadores Requer que os pré- auditIfNotExists 1.0.0

Windows que não têm requisitos sejam
membros especificados no implantados no escopo de
Grupo de administradores atribuição de política. Para
Grupo de administradores
local não contiver um ou
mais membros listados no
parâmetro de política.
Auditar a conectividade de Requer que os pré- auditIfNotExists 1.0.0

rede de computadores requisitos sejam
Windows implantados no escopo de
em conformidade se um
status de conexão de rede
para um IP e a porta TCP
não corresponderem ao

Windows nos quais a requisitos sejam
configuração DSC não está implantados no escopo de
em conformidade atribuição de política. Para
comando Get-
DSCConfigurationStatus do
Windows PowerShell
retornar que a configuração
DSC do computador não
está em conformidade.

Windows nos quais o requisitos sejam
agente do Log Analytics implantados no escopo de
não esteja conectado atribuição de política. Para
conforme o esperado obter detalhes, visite
agente não estiver instalado
e nem se ele estiver
instalado, mas o objeto
COM
AgentConfigManager.Mgmt
SvcCfg retornar que ele está
registrado em um
workspace diferente da ID
especificada no parâmetro
de política.
NOME VERSÃ O

Windows nos quais os requisitos sejam
serviços especificados não implantados no escopo de
estão instalados e 'Em atribuição de política. Para
execução' obter detalhes, visite
resultado do comando Get-
Service do Windows
PowerShell não incluir o
nome do serviço com o
status correspondente,
conforme especificado pelo

Windows nos quais o requisitos sejam
Console Serial do Windows implantados no escopo de
não está habilitado atribuição de política. Para
computador não tiver o
software do Console Serial
instalado ou se o número
da porta do EMS ou a taxa
de transmissão não
estiverem configurados com
os mesmos valores que os
dos parâmetros da política.

Windows que podem requisitos sejam desabilitado
reutilizar as 24 senhas implantados no escopo de
anteriores atribuição de política. Para
computadores Windows
que permitem a reutilização
das 24 senhas anteriores

Windows que não requisitos sejam
ingressaram no domínio implantados no escopo de
especificado atribuição de política. Para
em conformidade se o valor
da propriedade de Domínio
na classe WMI
win32_computersystem não
corresponder ao valor no
NOME VERSÃ O

Windows que não estão requisitos sejam
definidos para o fuso implantados no escopo de
horário especificado atribuição de política. Para
em conformidade se o valor
da propriedade
StandardName na classe
WMI Win32_TimeZone não
corresponder ao fuso
horário selecionado para o

Windows que contêm requisitos sejam
certificados que expiram implantados no escopo de
dentro do número de dias atribuição de política. Para
especificado obter detalhes, visite
em conformidade se os
certificados no repositório
especificado tiverem uma
data de validade fora do
intervalo para o número de
dias fornecido como
parâmetro. A política
também fornece a opção de
verificar apenas certificados
específicos ou excluir
certificados específicos e se
certificados expirados serão
relatados.

Windows que não contêm requisitos sejam
os certificados especificados implantados no escopo de
na Raiz Confiável atribuição de política. Para
repositório de certificados
Raiz Confiável do
computador
(Cert:\LocalMachine\Root)
não contiver um ou mais
certificados listados pelo
NOME VERSÃ O

Windows que não têm uma requisitos sejam desabilitado
duração máxima da senha implantados no escopo de
de 70 dias atribuição de política. Para
que não têm uma duração
máxima da senha de 70
dias

Windows que não têm uma requisitos sejam desabilitado
duração mínima da senha implantados no escopo de
de 1 dia atribuição de política. Para
que não têm uma duração
mínima de senha de 1 dia

Windows que não têm a requisitos sejam desabilitado
configuração de implantados no escopo de
complexidade de senha atribuição de política. Para
habilitada obter detalhes, visite
que não têm a configuração
de complexidade de senha
habilitada
Faça auditoria dos Requer que os pré- AuditIfNotExists, 1.0.0

computadores Windows requisitos sejam desabilitado
que não têm a política de implantados no escopo de
execução do Windows atribuição de política. Para
PowerShell especificada obter detalhes, visite
comando Get-
ExecutionPolicy do Windows
PowerShell retornar um
valor diferente do que foi
selecionado no parâmetro
de política.
NOME VERSÃ O
Faça auditoria dos Requer que os pré- AuditIfNotExists, 1.0.0

computadores Windows requisitos sejam desabilitado
que não têm os módulos implantados no escopo de
do Windows PowerShell atribuição de política. Para
especificados instalados obter detalhes, visite
em conformidade se um
módulo não estiver
disponível em um local
especificado pela variável de
ambiente PSModulePath.

Windows que não requisitos sejam desabilitado
restringem o tamanho implantados no escopo de
mínimo da senha a 14 atribuição de política. Para
caracteres obter detalhes, visite
que não restringem o
tamanho mínimo da senha
a 14 caracteres

Windows que não requisitos sejam desabilitado
armazenam senhas usando implantados no escopo de
a criptografia reversível atribuição de política. Para
que não armazenam senhas
reversível
NOME VERSÃ O

Windows que não têm os requisitos sejam
nome do aplicativo não for
encontrado em nenhum
dos seguintes caminhos do
Registro:
HKLM:SOFTWARE\Microsoft
\Windows\CurrentVersion\
Uninstall,
HKLM:SOFTWARE\Wow643
2node\Microsoft\Windows\
CurrentVersion\Uninstall,
HKCU:Software\Microsoft\
Windows\CurrentVersion\U
ninstall.

Windows que têm contas requisitos sejam
extras no Grupo de implantados no escopo de
administradores atribuição de política. Para
local contiver membros que
não estejam listados no

Windows que não foram requisitos sejam
reiniciados dentro do implantados no escopo de
número de dias especificado atribuição de política. Para
em conformidade se a
propriedade WMI
LastBootUpTime na classe
Win32_Operatingsystem
estiver fora do intervalo de
dias fornecido pelo
NOME VERSÃ O

Windows que têm os requisitos sejam
nome do aplicativo for
encontrado em algum dos
seguintes caminhos do
Registro:
HKLM:SOFTWARE\Microsoft
\Windows\CurrentVersion\
Uninstall,
HKLM:SOFTWARE\Wow643
2node\Microsoft\Windows\
CurrentVersion\Uninstall,
HKCU:Software\Microsoft\
Windows\CurrentVersion\U
ninstall.

Windows que têm os requisitos sejam
membros especificados no implantados no escopo de
Grupo de administradores atribuição de política. Para
local contiver um ou mais
membros listados no
Auditar as VMs do Requer que os pré- auditIfNotExists 1.0.0

Windows com uma requisitos sejam
reinicialização pendente implantados no escopo de
computador tiver uma
reinicialização pendente por
qualquer um dos seguintes
motivos: serviço baseado
em componentes, Windows
Update, renomeação de
arquivo pendente,
renomeação de
computador pendente,
reinicialização pendente do
Configuration Manager.
Cada detecção tem um
caminho do Registro
exclusivo.
NOME VERSÃ O
A autenticação para Embora o SSH em si forneça AuditIfNotExists, 2.0.1

computadores Linux deve uma conexão criptografada, desabilitado
exigir chaves SSH usar senhas com SSH ainda
deixa a VM vulnerável a
ataques de força bruta. A
opção mais segura para
autenticação em uma
máquina virtual Linux do
Azure por SSH é com um
par de chaves pública-
privada, também conhecido
como chaves SSH. Saiba
mais:
https://docs.microsoft.com/
azure/virtual-
machines/linux/create-ssh-
keys-detailed.
O Backup do Azure deve Garanta a proteção de suas AuditIfNotExists, 1.0.1

ser habilitado para Máquinas Virtuais do Azure desabilitado
máquinas virtuais habilitando o Backup do
Azure. O Backup do Azure é
uma solução de proteção
de dados segura e
econômica para o Azure.
Configurar o backup em Impor o backup a todas as deployIfNotExists 1.0.0 – versão prévia

VMs com uma marca máquinas virtuais
especificada para um novo implantando um cofre dos
cofre dos Serviços de Serviços de Recuperação na
Recuperação com uma mesma localização e no
política padrão mesmo grupo de recursos
da máquina virtual. É útil
fazer isso quando diferentes
equipes de aplicativo na sua
organização recebem
grupos de recursos
separados e precisam
gerenciar restaurações e
backups próprios.
Opcionalmente, você pode
incluir máquinas virtuais
que contenham uma marca
especificada para controlar
o escopo da atribuição.
Confira
https://aka.ms/AzureVMAp
pCentricBackupIncludeTag
NOME VERSÃ O
Configurar o backup em Imponha o backup a todas deployIfNotExists, 1.0.0 – versão prévia

VMs com uma marca as máquinas virtuais auditIfNotExists,
especificada para um cofre fazendo backup delas em desabilitado
dos Serviços de um cofre central dos
Recuperação existente na Serviços de Recuperação
mesma localização existente na mesma
localização e assinatura da
máquina virtual. É útil fazer
isso quando há uma equipe
central na sua organização
que gerencia os backups de
todos os recursos em uma
assinatura. Opcionalmente,
você pode incluir máquinas
virtuais que contenham
uma marca especificada
para controlar o escopo da
atribuição. Confira
https://aka.ms/AzureVMCe
ntralBackupIncludeTag
Configurar o backup em Impor o backup a todas as deployIfNotExists 1.0.0 – versão prévia

VMs sem uma marca máquinas virtuais
especificada para um novo implantando um cofre dos
cofre dos Serviços de Serviços de Recuperação na
Recuperação com uma mesma localização e no
política padrão mesmo grupo de recursos
da máquina virtual. É útil
fazer isso quando diferentes
equipes de aplicativo na sua
organização recebem
grupos de recursos
separados e precisam
gerenciar restaurações e
backups próprios.
Opcionalmente, você pode
excluir máquinas virtuais
que contenham uma marca
especificada para controlar
o escopo da atribuição.
Confira
https://aka.ms/AzureVMAp
pCentricBackupExcludeTag
NOME VERSÃ O
Configurar o backup em Imponha o backup a todas deployIfNotExists, 1.1.0

VMs sem uma marca as máquinas virtuais auditIfNotExists,
especificada para um cofre fazendo backup delas em desabilitado
dos Serviços de um cofre central dos
Recuperação existente na Serviços de Recuperação
mesma localização existente na mesma
localização e assinatura da
máquina virtual. É útil fazer
isso quando há uma equipe
central na sua organização
que gerencia os backups de
todos os recursos em uma
assinatura. Opcionalmente,
você pode excluir máquinas
virtuais que contenham
uma marca especificada
para controlar o escopo da
atribuição. Confira
https://aka.ms/AzureVMCe
ntralBackupExcludeTag
Configurar o fuso horário Esta política cria uma deployIfNotExists 1.1.0

nos computadores atribuição de Configuração
Windows. de Convidado para definir o
fuso horário especificado
nas máquinas virtuais do
Windows.
Implantar – Configurar a As máquinas virtuais sem deployIfNotExists 1.0.0

recuperação de desastre em configurações de
máquinas virtuais recuperação de desastre
habilitando a replicação são vulneráveis a
interrupções. Se a máquina
virtual ainda não tivesse a
recuperação de desastre
configurada, isso iniciaria a
mesma coisa habilitando a
replicação usando
configurações predefinidas
para facilitar a continuidade
dos negócios. Para saber
mais sobre recuperação de
desastre, acesse
https://aka.ms/asr-doc.
Implantar – Configurar o Configure o agente do deployIfNotExists 1.0.0 – versão prévia

agente do Azure Monitor Azure Monitor do Linux
do Linux para habilitar para máquinas virtuais do
atribuições do Azure Linux hospedadas no Azure
Monitor em máquinas que são compatíveis com o
virtuais do Linux Azure Monitor. O agente do
Azure Monitor coleta
eventos da máquina virtual
que podem ser usados para
fornecer recomendações. As
máquinas virtuais de
local com suporte.
NOME VERSÃ O
Implantar – Configurar Configure computadores deployIfNotExists 1.0.0 – versão prévia

computadores Linux para Linux para instalar
instalar automaticamente o automaticamente o agente
agente de Segurança do de Segurança do Azure. A
Azure Central de Segurança coleta
eventos do agente e os usa
para fornecer alertas de
segurança e tarefas de
proteção personalizadas
(recomendações). Crie um
grupo de recursos e um
na mesma região que a do
computador para
armazenar os registros de
auditoria. As máquinas
virtuais de destino devem
estar em um local com
suporte.
Implantar – Configurar o Configure o agente do deployIfNotExists 1.0.0 – versão prévia

agente do Azure Monitor Azure Monitor do Windows
do Windows para habilitar para máquinas virtuais do
atribuições do Azure Windows hospedadas no
Monitor em máquinas Azure que são compatíveis
virtuais do Windows com o Azure Monitor. O
agente do Azure Monitor
coleta eventos da máquina
virtual que podem ser
usados para fornecer
recomendações. As
máquinas virtuais de
local com suporte.
Implantar – Configurar Configure computadores deployIfNotExists 1.0.0 – versão prévia

computadores Windows Windows para instalar
para instalar automaticamente o agente
automaticamente o agente de Segurança do Azure. A
de Segurança do Azure Central de Segurança coleta
eventos do agente e os usa
para fornecer alertas de
segurança e tarefas de
proteção personalizadas
(recomendações). Crie um
grupo de recursos e um
na mesma região que a do
computador para
armazenar os registros de
auditoria. As máquinas
virtuais de destino devem
estar em um local com
suporte.
NOME VERSÃ O
Implantar a extensão Essa política implanta uma deployIfNotExists 1.0.0

padrão antimalware de IaaS extensão IaaSAntimalware
da Microsoft para Windows da Microsoft com uma
Server configuração padrão
quando uma VM não está
configurada com a extensão
antimalware.
Implantar o Dependency Implantar o Dependency deployIfNotExists 1.3.0

Agent em conjuntos de Agent nos conjuntos de
dimensionamento de dimensionamento de
máquinas virtuais do Linux máquinas virtuais do Linux
se a imagem da VM
(sistema operacional) estiver
na lista definida e o agente
não estiver instalado.
Observação: se o conjunto
de dimensionamento
upgradePolicy for definido
como Manual, você
precisará aplicar a extensão
a todas as máquinas
virtuais no conjunto
chamando a atualização
nelas. Na CLI, isso seria az
vmss update-instances.
Implantar o Dependency Implante o Dependency deployIfNotExists 1.3.0

Agent nas máquinas Agent nas máquinas
virtuais do Linux virtuais do Linux se a
Imagem de VM (SO) estiver
Implantar o Dependency Implantar o Dependency deployIfNotExists 1.3.0

Agent em conjuntos de Agent em conjuntos de
máquinas virtuais do máquinas virtuais do
Windows Windows se a imagem da
VM (sistema operacional)
agente não estiver
imagens do sistema
ao longo do tempo
suporte. Observação: se o
conjunto de
dimensionamento
como Manual, você
a todas as máquinas
virtuais no conjunto
chamando a atualização
nelas. Na CLI, isso seria az
vmss update-instances.
NOME VERSÃ O
Implantar o Dependency Implante o Dependency deployIfNotExists 1.3.0

Agent nas máquinas Agent nas máquinas
virtuais do Windows virtuais do Windows se a
Imagem de VM (SO) estiver
não estiver instalado. A lista
de imagens do sistema
ao longo do tempo
suporte.
Implantar o agente do Log Implantar o agente do Log deployIfNotExists 2.0.0

Analytics em conjuntos de Analytics em conjuntos de
máquinas virtuais do Linux máquinas virtuais do Linux
se a imagem da VM
(sistema operacional) estiver
Observação: se o conjunto
de dimensionamento
como Manual, você
para todas as VMs no
conjunto ao chamar o
upgrade nelas. Na CLI, isso
seria az vmss update-
instances.

Analytics para VMs do Analytics para VMs do
Linux Linux, se a imagem de VM
(SO) estiver na lista definida
e o agente não estiver
instalado.
NOME VERSÃ O

Analytics em conjuntos de Analytics em conjuntos de
máquinas virtuais do máquinas virtuais do
Windows Windows se a imagem da
VM (sistema operacional)
agente não estiver
imagens do sistema
ao longo do tempo
suporte. Observação: se o
conjunto de
dimensionamento
como Manual, você
para todas as VMs no
conjunto ao chamar o
upgrade nelas. Na CLI, isso
seria az vmss update-
instances.

Analytics para VMs do Analytics para as máquinas
Windows virtuais do Windows se a
imagem de máquina virtual
(SO) estiver na lista definida
e o agente não estiver
imagens do sistema
ao longo do tempo
suporte.
Implantar a extensão de Essa política implanta a deployIfNotExists 1.0.0

Configuração de Convidado extensão de Configuração
do Linux para habilitar de Convidado do Linux em
atribuições de Configuração máquinas virtuais do Linux
de Convidado em VMs do hospedadas no Azure com
Linux suporte da Configuração de
Convidado. A extensão de
do Linux é um pré-requisito
para todas as atribuições da
do Linux e deve ser
implantada em
usar qualquer definição de
política de Configuração de
Convidado do Linux. Para
obter mais informações
sobre a Configuração de
Convidado, acesse
NOME VERSÃ O
Implantar a extensão de Essa política implanta a deployIfNotExists 1.0.0

Configuração de Convidado extensão de Configuração
do Windows para habilitar de Convidado do Windows
atribuições de Configuração em máquinas virtuais do
de Convidado em VMs do Windows hospedadas no
Windows Azure com suporte da
Configuração de
Convidado. A extensão de
do Windows é um pré-
requisito para todas as
atribuições da Configuração
de Convidado do Windows
e deve ser implantada em
usar qualquer definição de
política de Configuração de
Convidado do Windows.
Para obter mais
Configuração de
Convidado, acesse
A criptografia de disco deve As máquinas virtuais sem AuditIfNotExists, 2.0.0

ser aplicada em Máquinas uma criptografia de disco desabilitado
virtuais habilitada serão
monitoradas pela Central
de Segurança do Azure
como recomendações.
Habilitar o O Autogerenciamento deployIfNotExists 1.0.0

Autogerenciamento – registra, configura e
Práticas recomendadas para monitora máquinas virtuais
máquinas virtuais do Azure com serviços de práticas
recomendadas da VM do
Azure. Use esta política para
aplicar o
Autogerenciamento ao
escopo selecionado.
A solução de proteção de Faça a auditoria da AuditIfNotExists, 3.0.0

ponto de extremidade deve existência de uma solução desabilitado
ser instalada nos conjuntos de proteção de ponto de
de dimensionamento de extremidade e da sua
máquinas virtuais integridade nos seus
conjuntos de
dimensionamento de
máquinas virtuais, para
protegê-los contra ameaças
e vulnerabilidades.
NOME VERSÃ O
A extensão de Configuração Para garantir configurações AuditIfNotExists, 1.0.1

de Convidado deve ser seguras de configurações desabilitado
instalada nos seus no convidado de seu
computadores computador, instale a
extensão de Configuração
de Convidado. As
configurações no convidado
que a extensão monitora
incluem a configuração do
sistema operacional, a
configuração ou a presença
do aplicativo e as
configurações do ambiente.
Depois de instaladas, as
políticas no convidado
estarão disponíveis, como
'O Windows Exploit Guard
deve estar habilitado'. Saiba
mais em
As máquinas virtuais para a Proteja suas máquinas AuditIfNotExists, 3.0.0

Internet devem ser virtuais contra possíveis desabilitado
protegidas com grupos de ameaças, restringindo o
segurança de rede acesso a elas com um NSG
(grupo de segurança de
rede). Saiba mais sobre
como controlar o tráfego
com NSGs em
https://aka.ms/nsg-doc
O encaminhamento IP na A habilitação do AuditIfNotExists, 3.0.0

máquina virtual deve ser encaminhamento de IP na desabilitado
desabilitado NIC de uma máquina
virtual permite que o
computador receba o
tráfego endereçado a
outros destinos. O
encaminhamento de IP
raramente é necessário (por
exemplo, ao usar a VM
como uma solução de
virtualização de rede) e,
portanto, isso deve ser
examinado pela equipe de
segurança de rede.
Os computadores Linux Requer que os pré- AuditIfNotExists, 1.1.0 – versão prévia

devem atender aos requisitos sejam desabilitado
requisitos da linha de base implantados no escopo de
de segurança do Azure atribuição de política. Para
em conformidade se os
computadores Linux
atendem aos requisitos de
linha de base de segurança
do Azure
NOME VERSÃ O
Os problemas de A Central de Segurança usa AuditIfNotExists, 1.0.0

integridade do agente do o agente do Log Analytics, desabilitado
Log Analytics devem ser anteriormente conhecido
resolvidos nos como MMA (Microsoft
computadores Monitoring Agent). Para
que suas máquinas virtuais
sejam monitoradas com
êxito, você precisa verificar
se o agente está instalado
nas máquinas virtuais e se
ele coleta corretamente os
eventos de segurança para
o workspace configurado.
O agente do Log Analytics Esta política auditará VMs AuditIfNotExists, 1.0.0

deve ser instalado na (máquinas virtuais) do desabilitado
máquina virtual para o Windows/Linux se não
monitoramento da Central estiver instalado o agente
de Segurança do Azure do Log Analytics que a
Central de Segurança usa
para monitorar
vulnerabilidades e ameaças
à segurança
O agente do Log Analytics A Central de Segurança AuditIfNotExists, 1.0.0

deve ser instalado em seus coleta dados de suas VMs desabilitado
conjuntos de (máquinas virtuais) do
dimensionamento de Azure a fim de monitorar as
máquinas virtuais para o vulnerabilidades e ameaças
monitoramento da Central à segurança.
As portas de O possível acesso JIT (Just AuditIfNotExists, 3.0.0

gerenciamento de In Time) da rede será desabilitado
máquinas virtuais devem monitorado pela Central de
ser protegidas com o Segurança do Azure como
controle de acesso à rede recomendação
just-in-time
Portas de gerenciamento As portas abertas de AuditIfNotExists, 3.0.0

devem ser fechadas nas gerenciamento remoto desabilitado
máquinas virtuais estão expondo sua VM a
um alto nível de risco de
ataques baseados na
Internet. Estes ataques
tentam obter credenciais
por força bruta para obter
acesso de administrador à
máquina.
O Microsoft Antimalware Essa política audita AuditIfNotExists, 1.0.0

para o Azure deve ser qualquer máquina virtual desabilitado
configurado para atualizar do Windows não
automaticamente as configurada com a
assinaturas de proteção atualização automática das
assinaturas de proteção
Microsoft Antimalware.
NOME VERSÃ O
A extensão IaaSAntimalware Essa política audita AuditIfNotExists, 1.0.0

da Microsoft deve ser qualquer VM de servidor desabilitado
implantada em servidores do Windows sem a
do Windows extensão IaaSAntimalware
da Microsoft implantada.
Monitorar o Endpoint Servidores sem um agente AuditIfNotExists, 3.0.0

Protection ausente na do Endpoint Protection desabilitado
Central de Segurança do instalado serão
Azure monitorados pela Central
como recomendações
O agente de coleta de A Central de Segurança usa AuditIfNotExists, 1.0.1 – versão prévia

dados do tráfego de rede o Microsoft Dependency desabilitado
deve ser instalado nas Agent para coletar dados
máquinas virtuais do Linux de tráfego de rede de suas
máquinas virtuais do Azure
para habilitar recursos
avançados de proteção de
rede, como visualização de
tráfego no mapa de rede,
recomendações de proteção
de rede e ameaças de rede
específicas.
O agente de coleta dos A Central de Segurança usa AuditIfNotExists, 1.0.1 – versão prévia
dados de tráfego de rede o Microsoft Dependency desabilitado
deve ser instalado nas Agent para coletar dados
máquinas virtuais do de tráfego de rede de suas
Windows máquinas virtuais do Azure
para habilitar recursos
avançados de proteção de
rede, como visualização de
tráfego no mapa de rede,
recomendações de proteção
de rede e ameaças de rede
específicas.
Máquinas virtuais não Proteja suas máquinas AuditIfNotExists, 3.0.0

voltadas para a Internet virtuais não voltadas para a desabilitado
devem ser protegidas com Internet contra possíveis
grupos de segurança de ameaças, restringindo o
rede acesso com um NSG (grupo
de segurança de rede).
Saiba mais sobre como
controlar o tráfego com
NSGs em
Somente as extensões Essa política rege as Audit, Deny, desabilitado 1.0.0

aprovadas da VM devem extensões da máquina
ser instaladas virtual que não foram
aprovadas.
NOME VERSÃ O
Exigir a aplicação Essa política impõe a deny 1.0.0

automática de patch da habilitação do patch
imagem do sistema automático da imagem do
operacional em Conjuntos sistema operacional nos
de Dimensionamento de Conjuntos de
Máquinas Virtuais Dimensionamento de
Máquinas Virtuais para que
as máquinas virtuais
estejam sempre protegidas
por meio da aplicação
segura dos patches de
segurança mais recentes
mensalmente.
Os logs de recursos em Recomenda-se habilitar os AuditIfNotExists, 2.0.1

conjuntos de Logs para que a trilha de desabilitado
dimensionamento de atividades possa ser
máquinas virtuais devem recriada quando
ser habilitados investigações forem
necessárias no caso de um
incidente ou um
comprometimento.
As atualizações do sistema Faça uma auditoria para AuditIfNotExists, 3.0.0

nos conjuntos de verificar se faltam desabilitado
dimensionamento de atualizações de segurança
máquinas virtuais devem do sistema e atualizações
ser instaladas críticas que devem ser
instaladas para garantir que
os seus conjuntos de
dimensionamento de
máquinas virtuais Windows
e Linux estejam seguros.
As atualizações do sistema A falta de atualizações do AuditIfNotExists, 3.0.0

devem ser instaladas em sistema de segurança em desabilitado
suas máquinas seus servidores será
monitorada pela Central de
Segurança do Azure como
recomendações
O agente do Log Analytics Essa política audita os AuditIfNotExists, 1.0.0

deve ser instalado nos Conjuntos de desabilitado
Conjuntos de Dimensionamento de
Dimensionamento de Máquinas Virtuais do
Máquinas Virtuais Windows ou do Linux nos
quais o agente do Log
Analytics não está instalado.
O agente do Log Analytics Essa política audita as AuditIfNotExists, 1.0.0

deve ser instalado nas máquinas virtuais do desabilitado
máquinas virtuais Windows ou do Linux nas
quais o agente do Log
Analytics não está instalado.
NOME VERSÃ O
Os discos desconectados Essa política audita Audit, desabilitado 1.0.0

devem ser criptografados qualquer disco
desconectado sem a
criptografia habilitada.
As máquinas virtuais devem Use o novo Azure Resource Audit, Deny, desabilitado 1.0.0
ser migradas para os novos Manager para suas
recursos do Azure Resource máquinas virtuais a fim de
Manager fornecer melhorias de
segurança como: RBAC
(controle de acesso) mais
forte, melhor auditoria,
implantação e governança
baseadas no Azure
Resource Manager, acesso a
identidades gerenciadas,
acesso ao cofre de chaves
para segredos, autenticação
baseada no Azure AD e
suporte para marcas e
grupos de recursos visando
facilitar o gerenciamento da
segurança
A extensão de Configuração A extensão de configuração AuditIfNotExists, 1.0.1

de Convidado das de convidado exige uma desabilitado
máquinas virtuais deve ser identidade gerenciada
implantada com a atribuída ao sistema. As
identidade gerenciada máquinas virtuais do Azure
atribuída ao sistema no escopo desta política
não estarão em
conformidade quando
tiverem a extensão de
instalada, mas não tiverem
uma identidade gerenciada
atribuída ao sistema. Saiba
mais em
https://aka.ms/gcpol
As vulnerabilidades nas Audite vulnerabilidades na AuditIfNotExists, 3.0.0

configurações de segurança configuração de segurança desabilitado
do contêiner devem ser em computadores com o
corrigidas Docker instalado e exiba
como recomendações na
Azure.
As vulnerabilidades da Os servidores que não AuditIfNotExists, 3.0.0

configuração de segurança atenderem à linha de base desabilitado
nas máquinas devem ser configurada serão
corrigidas monitorados pela Central
NOME VERSÃ O
As vulnerabilidades da Faça a auditoria das AuditIfNotExists, 3.0.0

configuração de segurança vulnerabilidades do SO nos desabilitado
nos conjuntos de seus conjuntos de
máquinas virtuais devem máquinas virtuais para
ser corrigidas protegê-los contra ataques.
As vulnerabilidades nos A avaliação de AuditIfNotExists, 1.0.0

servidores SQL no vulnerabilidade do SQL desabilitado
computador devem ser verifica a presença de
corrigidas eventuais vulnerabilidades
de segurança em seu banco
de dados e expõe quaisquer
desvios das práticas
recomendadas como
configurações incorretas,
permissões excessivas e
dados confidenciais
desprotegidos. Resolver as
vulnerabilidades
encontradas pode melhorar
muito a postura de
segurança de seu banco de
dados.
O Microsoft Defender O Microsoft Defender AuditIfNotExists, 1.1.1

Exploit Guard deve estar Exploit Guard usa o agente desabilitado
habilitado nos de Configuração de
computadores Convidado do Azure Policy.
O Exploit Guard tem quatro
componentes que foram
projetados para bloquear
dispositivos contra uma
ampla variedade de vetores
de ataque e
comportamentos de
bloqueio comumente
usados em ataques de
malware, permitindo que as
empresas encontrem um
equilíbrio entre os
requisitos de produtividade
e o risco de segurança
enfrentados (somente
Windows).
NOME VERSÃ O
Os computadores Windows Os computadores Windows AuditIfNotExists, 2.0.0

devem atender aos devem ter as configurações desabilitado
requisitos de 'Modelos de Política de Grupo
Administrativos – Painel de especificadas na categoria
Controle' 'Modelos Administrativos –
Painel de Controle' para
personalização de entrada e
prevenção de habilitação de
telas de bloqueio. Essa
política requer que os pré-
requisitos de Configuração
de Convidado tenham sido
implantados no escopo de

Administrativos – MSS especificadas na categoria
(Herdado)' 'Modelos Administrativos –
MSS (Herdado)' para logon
automático, proteção de
tela, comportamento de
rede, DLL segura e log de
eventos. Essa política requer
que os pré-requisitos de
tenham sido implantados
no escopo de atribuição de
política. Para obter detalhes,
visite https://aka.ms/gcpol.

Administrativos – Rede' especificadas na categoria
'Modelos Administrativos –
Rede' para logons de
convidado, conexões
simultâneas, ponte de rede,
ICS e resolução de nomes
multicast. Essa política
requer que os pré-
NOME VERSÃ O

Administrativos – Sistema' especificadas na categoria
'Modelos Administrativos –
Sistema' para as
configurações que
controlam a experiência
administrativa e a
Assistência Remota. Essa

requisitos de 'Opções de da Política de Grupo
Segurança – Contas' especificadas na categoria
'Opções de Segurança –
Contas' para limitar o uso
da conta local de senhas em
branco e o status da conta
convidado. Essa política
requer que os pré-

requisitos de 'Opções de de Política de Grupo
Segurança – Auditoria' especificadas na categoria
Auditoria' para impor a
subcategoria da política de
auditoria e o desligamento
se não for possível registrar
em log as auditorias de
segurança. Essa política
requer que os pré-
NOME VERSÃ O

Segurança – Dispositivos' especificadas na categoria
Dispositivos' para
desencaixar sem fazer
logon, instalar drivers de
impressão e formatar/ejetar
mídia. Essa política requer

Segurança – Logon especificadas na categoria
Interativo' 'Opções de Segurança –
Logon Interativo' para exibir
o nome do último usuário e
exigir Ctrl-Alt-Del. Essa

Segurança – Cliente de Rede especificadas na categoria
da Microsoft' 'Opções de Segurança –
Cliente de Rede da
Microsoft' para o
cliente/servidor de rede da
Microsoft e o SMB v1. Essa
NOME VERSÃ O

Segurança – Servidor de especificadas na categoria
Rede da Microsoft' 'Opções de Segurança –
Servidor de Rede da
Microsoft' para desabilitar o
servidor SMB v1. Essa

Segurança – Acesso à Rede' especificadas na categoria
Acesso à Rede' para incluir o
acesso a usuários
anônimos, contas locais e
acesso remoto ao Registro.
Essa política requer que os
pré-requisitos de

Segurança – Segurança de especificadas na categoria
Rede' 'Opções de Segurança –
Segurança de Rede' para
incluir o comportamento do
Sistema Local, PKU2U, LAN
Manager, cliente LDAP e
NTLM SSP. Essa política
requer que os pré-
NOME VERSÃ O

Segurança – Console de especificadas na categoria
recuperação' 'Opções de Segurança –
Console de recuperação'
para permitir a cópia de
disquete e o acesso a todas
as unidades e pastas. Essa

Segurança – Desligamento' especificadas na categoria
Desligamento' para permitir
o desligamento sem fazer
logon e limpar o arquivo de
paginação de memória
virtual. Essa política requer

Segurança – Objetos do especificadas na categoria
sistema' 'Opções de Segurança –
Objetos do sistema' para
não diferenciação de
maiúsculas e minúsculas
para subsistemas que não
são Windows e permissões
de objetos internos do
sistema. Essa política requer
NOME VERSÃ O

Segurança – Configurações especificadas na categoria
do sistema' 'Opções de Segurança –
Configurações do sistema'
para regras de certificado
em executáveis para a
política SRP e subsistemas
opcionais. Essa política
requer que os pré-

Segurança – Controle de especificadas na categoria
Conta de Usuário' 'Opções de Segurança –
Usuário' para o modo de
administradores, o
comportamento da
solicitação de elevação e a
virtualização de falhas de
gravação de arquivo e no
Registro. Essa política
requer que os pré-

requisitos de 'Configurações de Política de Grupo
de Segurança – Políticas de especificadas na categoria
Conta' 'Configurações de
Segurança – Políticas de
Conta' para histórico de
senha, idade, comprimento,
complexidade e
armazenamento de senhas
usando criptografia
reversível. Essa política
requer que os pré-
NOME VERSÃ O

requisitos de 'Políticas de de Política de Grupo
Auditoria do Sistema – especificadas na categoria
Logon da Conta' 'Políticas de Auditoria do
Sistema – Logon da Conta'
para auditoria da validação
de credenciais e outros
eventos de logon de conta.
pré-requisitos de

Gerenciamento de Contas' 'Políticas de Auditoria do
Sistema – Gerenciamento
de Contas' para auditoria
de aplicativo, segurança e
gerenciamento do grupo de
usuários e outros eventos
de gerenciamento. Essa

Acompanhamento 'Políticas de Auditoria do
Detalhado' Sistema –
Acompanhamento
Detalhado' para auditoria
de DPAPI,
criação/encerramento de
processos, eventos RPC e
atividade PNP. Essa política
requer que os pré-
NOME VERSÃ O

Logon/Logoff' 'Políticas de Auditoria do
Sistema – Logon-logoff'
para auditoria de IPSec,
política de rede,
declarações, bloqueio de
conta, associação de grupo
e eventos de logon/logoff.
pré-requisitos de

Acesso de Objeto' 'Políticas de Auditoria do
Sistema – Acesso a Objeto'
para auditoria de arquivo,
Registro, SAM,
armazenamento, filtragem,
kernel e outros tipos de
sistema. Essa política requer

Alteração de Política' 'Políticas de Auditoria do
Sistema – Alteração de
Política' para auditoria de
alterações em políticas de
auditoria do sistema. Essa
NOME VERSÃ O

Auditoria do Sistema – Uso especificadas na categoria
de Privilégios' 'Políticas de Auditoria do
Sistema – Uso de
Privilégios' para auditoria
do uso não confidencial e
outro uso de privilégio. Essa

Sistema' 'Políticas de Auditoria do
Sistema – Sistema' para
auditoria de driver IPsec,
integridade do sistema,
extensão do sistema,
alteração de estado e
outros eventos do sistema.
pré-requisitos de

requisitos de 'Atribuição de de Política de Grupo
Direitos do Usuário' especificadas na categoria
'Atribuição de Direitos do
Usuário' para permitir o
logon local, o RDP, o acesso
na rede e muitas outras
atividades do usuário. Essa
NOME VERSÃ O

requisitos de 'Componentes de Política de Grupo
do Windows' especificadas na categoria
'Componentes do Windows'
para autenticação básica,
tráfego não criptografado,
contas Microsoft,
telemetria, Cortana e
outros comportamentos do
Windows. Essa política
requer que os pré-

requisitos de 'Propriedades de Política de Grupo
do Firewall do Windows' especificadas na categoria
'Propriedades do Firewall do
Windows' para estado do
firewall, conexões,
gerenciamento de regras e
notificações. Essa política
requer que os pré-
Os computadores Windows Requer que os pré- AuditIfNotExists, 1.0.0 – versão prévia

devem atender aos requisitos sejam desabilitado
requisitos da linha de base implantados no escopo de
da Central de Segurança do atribuição de política. Para
Azure obter detalhes, visite
em conformidade se não
estiverem configurados
corretamente para uma das
recomendações na linha de
base da Central de
Segurança do Azure.
NOME VERSÃ O
Os servidores Web do Para proteger a privacidade AuditIfNotExists, 2.0.0

Windows devem ser das informações desabilitado
configurados para usar comunicadas pela Internet,
protocolos de comunicação seus servidores Web devem
segura usar a versão mais recente
do protocolo de criptografia
padrão do setor, o
protocolo TLS. O TLS
protege as comunicações
em uma rede usando
certificados de segurança
para criptografar uma
conexão entre
computadores. O TLS 1.3 é
mais rápido e seguro do
que as versões anteriores:
TLS 1.0 a 1.2 e SSL 2-3, que
são considerados
protocolos herdados.
NOME VERSÃ O
Os modelos do Construtor Faça auditoria dos modelos Audit, desabilitado 1.0.1

de Imagens de VM devem do Construtor de Imagens
usar o link privado de VM que não têm uma
rede virtual configurada.
Quando uma rede virtual
não está configurada, um IP
público é criado e usado, o
que pode expor
diretamente os recursos à
Internet e aumentar a
possível superfície de
ataque.
Microsoft.ClassicCompute
NOME VERSÃ O
NOME VERSÃ O
Uma solução de avaliação Audita as máquinas virtuais AuditIfNotExists, 3.0.0

de vulnerabilidade deve ser para detectar se elas estão desabilitado
habilitada nas máquinas executando uma solução de
virtuais avaliação de vulnerabilidade
compatível. Um
componente principal de
cada programa de
segurança e risco
cibernético é a identificação
e a análise das
vulnerabilidades. O tipo de
preço padrão da Central de
Segurança do Azure inclui a
verificação de
vulnerabilidade para as
máquinas virtuais sem
custo adicional. Além disso,
a Central de Segurança
pode implantar essa
ferramenta
automaticamente para
você.
Os controles de aplicativos Permita que os controles de AuditIfNotExists, 3.0.0

adaptáveis para definir aplicativos definam a lista desabilitado
aplicativos seguros devem de aplicativos considerados
estar habilitados nos seguros em execução nos
computadores seus computadores e
alertem você quando
outros aplicativos forem
executados. Isso ajuda a
proteger seus
computadores contra
malware. Para simplificar o
processo de configuração e
manutenção de suas regras,
a Central de Segurança usa
o machine learning para
analisar os aplicativos em
execução em cada
computador e sugerir a lista
de aplicativos considerados
seguros.
Todas as portas de rede A Central de Segurança do AuditIfNotExists, 3.0.0

devem ser restritas nos Azure identificou algumas desabilitado
grupos de segurança de das regras de entrada de
rede associados à sua seus grupos de segurança
máquina virtual de rede como permissivas
demais. As regras de
entrada não devem permitir
o acesso por meio de
intervalos "Qualquer" ou
"Internet". Isso tem o
potencial de tornar seus
recursos alvos de invasores.
NOME VERSÃ O
As regras da lista de Monitore as alterações no AuditIfNotExists, 3.0.0

permissões na política de comportamento dos desabilitado
controles de aplicativos grupos de computadores
adaptáveis devem ser configurados para auditoria
atualizadas pelos controles de
aplicativos adaptáveis da
Azure. A Central de
Segurança usa o machine
learning para analisar os
processos em execução em
seus computadores e
sugerir uma lista de
aplicativos considerados
seguros. Eles são
apresentados como
aplicativos recomendados
para permitir as políticas de
controle de aplicativos
adaptáveis.
Auditar máquinas virtuais Audite máquinas virtuais auditIfNotExists 1.0.0

sem a recuperação de sem a recuperação de
desastre configurada desastre configurada. Para
saber mais sobre
recuperação de desastre,
acesse https://aka.ms/asr-
doc.
A criptografia de disco deve As máquinas virtuais sem AuditIfNotExists, 2.0.0

ser aplicada em Máquinas uma criptografia de disco desabilitado
virtuais habilitada serão
monitoradas pela Central
como recomendações.
As máquinas virtuais para a Proteja suas máquinas AuditIfNotExists, 3.0.0

Internet devem ser virtuais contra possíveis desabilitado
protegidas com grupos de ameaças, restringindo o
segurança de rede acesso a elas com um NSG
(grupo de segurança de
rede). Saiba mais sobre
como controlar o tráfego
com NSGs em
NOME VERSÃ O
O encaminhamento IP na A habilitação do AuditIfNotExists, 3.0.0

máquina virtual deve ser encaminhamento de IP na desabilitado
desabilitado NIC de uma máquina
virtual permite que o
computador receba o
tráfego endereçado a
outros destinos. O
encaminhamento de IP
raramente é necessário (por
exemplo, ao usar a VM
como uma solução de
virtualização de rede) e,
portanto, isso deve ser
examinado pela equipe de
segurança de rede.
Os problemas de A Central de Segurança usa AuditIfNotExists, 1.0.0

integridade do agente do o agente do Log Analytics, desabilitado
Log Analytics devem ser anteriormente conhecido
resolvidos nos como MMA (Microsoft
computadores Monitoring Agent). Para
que suas máquinas virtuais
sejam monitoradas com
êxito, você precisa verificar
se o agente está instalado
nas máquinas virtuais e se
ele coleta corretamente os
eventos de segurança para
o workspace configurado.
O agente do Log Analytics Esta política auditará VMs AuditIfNotExists, 1.0.0

deve ser instalado na (máquinas virtuais) do desabilitado
máquina virtual para o Windows/Linux se não
monitoramento da Central estiver instalado o agente
de Segurança do Azure do Log Analytics que a
Central de Segurança usa
para monitorar
vulnerabilidades e ameaças
à segurança
Portas de gerenciamento As portas abertas de AuditIfNotExists, 3.0.0

devem ser fechadas nas gerenciamento remoto desabilitado
máquinas virtuais estão expondo sua VM a
um alto nível de risco de
ataques baseados na
Internet. Estes ataques
tentam obter credenciais
por força bruta para obter
acesso de administrador à
máquina.
Monitorar o Endpoint Servidores sem um agente AuditIfNotExists, 3.0.0

Protection ausente na do Endpoint Protection desabilitado
Central de Segurança do instalado serão
Azure monitorados pela Central
NOME VERSÃ O
Máquinas virtuais não Proteja suas máquinas AuditIfNotExists, 3.0.0

voltadas para a Internet virtuais não voltadas para a desabilitado
devem ser protegidas com Internet contra possíveis
grupos de segurança de ameaças, restringindo o
rede acesso com um NSG (grupo
de segurança de rede).
Saiba mais sobre como
controlar o tráfego com
NSGs em
A versão do sistema Manter o SO (sistema AuditIfNotExists, 1.0.0

operacional deve ser a mais operacional) na versão mais desabilitado
atualizada para as suas recente com suporte para
funções do serviço de as funções do serviço de
nuvem nuvem aprimora a postura
de segurança do sistema.
As atualizações do sistema A falta de atualizações do AuditIfNotExists, 3.0.0

devem ser instaladas em sistema de segurança em desabilitado
suas máquinas seus servidores será
monitorada pela Central de
Segurança do Azure como
recomendações
As máquinas virtuais devem Use o novo Azure Resource Audit, Deny, desabilitado 1.0.0
ser migradas para os novos Manager para suas
recursos do Azure Resource máquinas virtuais a fim de
Manager fornecer melhorias de
segurança como: RBAC
(controle de acesso) mais
forte, melhor auditoria,
implantação e governança
baseadas no Azure
Resource Manager, acesso a
identidades gerenciadas,
acesso ao cofre de chaves
para segredos, autenticação
baseada no Azure AD e
suporte para marcas e
grupos de recursos visando
facilitar o gerenciamento da
segurança
As vulnerabilidades nas Audite vulnerabilidades na AuditIfNotExists, 3.0.0

configurações de segurança configuração de segurança desabilitado
do contêiner devem ser em computadores com o
corrigidas Docker instalado e exiba
como recomendações na
Azure.
As vulnerabilidades da Os servidores que não AuditIfNotExists, 3.0.0

configuração de segurança atenderem à linha de base desabilitado
nas máquinas devem ser configurada serão
corrigidas monitorados pela Central
Próximas etapas
Revise a estrutura de definição do Azure Policy.
Revisar Compreendendo os efeitos da política.
Aplicar políticas a VMs Linux com o Azure Resource
Manager
Usando políticas, uma organização pode impor várias convenções e regras em toda a empresa. A imposição do
comportamento desejado pode ajudar a reduzir o risco e contribui para o sucesso da organização. Neste artigo,
descrevemos como você pode usar as políticas do Azure Resource Manager para definir o comportamento
desejado das Máquinas Virtuais de sua organização.
Para obter uma introdução às políticas, consulte O que é o Azure Policy?.
Máquinas virtuais permitidas

Para garantir que as máquinas virtuais de sua organização são compatíveis com um aplicativo, você pode
restringir os sistemas operacionais permitidos. No exemplo de política a seguir, você permite que apenas
Máquinas Virtuais Ubuntu 14.04.2-LTS sejam criadas.
{
"if": {
"allOf": [
{
"field": "type",
"in": [
"Microsoft.Compute/disks",
"Microsoft.Compute/virtualMachines",
"Microsoft.Compute/VirtualMachineScaleSets"
]
},
{
"not": {
"allOf": [
{
"field": "Microsoft.Compute/imagePublisher",
"in": [
"Canonical"
]
},
{
"field": "Microsoft.Compute/imageOffer",
"in": [
"UbuntuServer"
]
},
{
"field": "Microsoft.Compute/imageSku",
"in": [
"14.04.2-LTS"
]
},
{
"field": "Microsoft.Compute/imageVersion",
"in": [
"latest"
]
}
]
}
}
]
},
"then": {
"effect": "deny"
}
}
Use um curinga para modificar a política anterior a fim de permitir qualquer imagem do Ubuntu LTS:
{
"field": "Microsoft.Compute/virtualMachines/imageSku",
"like": "*LTS"
}
Para obter informações sobre campos de política, consulte Aliases de política.
Discos gerenciados
Para exigir o uso de discos gerenciados, use a seguinte política:
{
"if": {
"anyOf": [
{
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "Microsoft.Compute/virtualMachines/osDisk.uri",
"exists": true
}
]
},
{
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/VirtualMachineScaleSets"
},
{
"anyOf": [
{
"field": "Microsoft.Compute/VirtualMachineScaleSets/osDisk.vhdContainers",
"exists": true
},
{
"field": "Microsoft.Compute/VirtualMachineScaleSets/osdisk.imageUrl",
"exists": true
}
]
}
]
}
]
},
"then": {
"effect": "deny"
}
}
Imagens de máquinas virtuais

Por motivos de segurança, você pode exigir que apenas imagens personalizadas aprovadas sejam implantadas
em seu ambiente. Você pode especificar o grupo de recursos que contém as imagens aprovadas ou as imagens
aprovadas específicas.
O exemplo a seguir exige imagens de um grupo de recursos aprovado:
{
"if": {
"allOf": [
{
"field": "type",
"in": [
]
},
{
"not": {
"field": "Microsoft.Compute/imageId",
"contains": "resourceGroups/CustomImage"
}
}
]
},
"then": {
"effect": "deny"
}
}
O exemplo a seguir especifica as IDs de imagem aprovadas:
{
"in": ["{imageId1}","{imageId2}"]
}
Extensões de Máquina Virtual

Talvez você queira proibir o uso de determinados tipos de extensões. Por exemplo, uma extensão pode não ser
compatível com determinadas imagens de máquina virtual personalizadas. O exemplo a seguir mostra como
bloquear uma extensão específica. Ele usa o publicador e o tipo para determinar qual extensão será bloqueada.
{
"if": {
"allOf": [
{
"field": "type",
},
{
},
{
"equals": "{extension-type}"
}
]
},
"then": {
"effect": "deny"
}
}
Próximas etapas
Depois de definir uma regra de política (conforme mostrado nos exemplos anteriores), você precisará criar a
definição de política e atribuí-la a um escopo. O escopo pode ser uma assinatura, grupo de recursos ou
recurso. Para atribuir políticas, consulte Usar o portal do Azure para atribuir e gerenciar políticas de recursos,
Usar o PowerShell para atribuir políticas ou Usar a CLI do Azure para atribuir políticas.
Para obter uma introdução às políticas de recursos, consulte O que é o Azure Policy?.
Para obter orientação sobre como as empresas podem usar o Resource Manager para gerenciar assinaturas
de forma eficaz, consulte Azure enterprise scaffold – controle de assinatura prescritivas.
Aplicar políticas a VMs Windows com o Azure
Resource Manager
Usando políticas, uma organização pode impor várias convenções e regras em toda a empresa. A imposição do
comportamento desejado pode ajudar a reduzir o risco e contribui para o sucesso da organização. Neste artigo,
descrevemos como você pode usar as políticas do Azure Resource Manager para definir o comportamento
desejado das Máquinas Virtuais de sua organização.
Para obter uma introdução às políticas, consulte O que é o Azure Policy?.
Máquinas virtuais permitidas

Para garantir que as máquinas virtuais de sua organização são compatíveis com um aplicativo, você pode
restringir os sistemas operacionais permitidos. No seguinte exemplo de política, você permite que apenas
Máquinas Virtuais Windows Server 2012 R2 Datacenter sejam criadas:
{
"if": {
"allOf": [
{
"field": "type",
"in": [
]
},
{
"not": {
"allOf": [
{
"field": "Microsoft.Compute/imagePublisher",
"in": [
"MicrosoftWindowsServer"
]
},
{
"field": "Microsoft.Compute/imageOffer",
"in": [
"WindowsServer"
]
},
{
"in": [
"2012-R2-Datacenter"
]
},
{
"field": "Microsoft.Compute/imageVersion",
"in": [
"latest"
]
}
]
}
}
]
},
"then": {
"effect": "deny"
}
}
Use um curinga para modificar a política anterior a fim de permitir qualquer imagem do Windows Server
Datacenter:
{
"like": "*Datacenter"
}
Use anyOf para modificar a política anterior para permitir qualquer Windows Server 2012 R2 Datacenter ou
uma imagem superior:
{
"anyOf": [
{
"like": "2012-R2-Datacenter*"
},
{
"like": "2016-Datacenter*"
}
]
}
Para obter informações sobre campos de política, consulte Aliases de política.
Discos gerenciados
Para exigir o uso de discos gerenciados, use a seguinte política:
{
"if": {
"anyOf": [
{
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "Microsoft.Compute/virtualMachines/osDisk.uri",
"exists": true
}
]
},
{
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/VirtualMachineScaleSets"
},
{
"anyOf": [
{
"field": "Microsoft.Compute/VirtualMachineScaleSets/osDisk.vhdContainers",
"exists": true
},
{
"field": "Microsoft.Compute/VirtualMachineScaleSets/osdisk.imageUrl",
"exists": true
}
]
}
]
}
]
},
"then": {
"effect": "deny"
}
}
Imagens de máquinas virtuais

Por motivos de segurança, você pode exigir que apenas imagens personalizadas aprovadas sejam implantadas
em seu ambiente. Você pode especificar o grupo de recursos que contém as imagens aprovadas ou as imagens
aprovadas específicas.
O exemplo a seguir exige imagens de um grupo de recursos aprovado:
{
"if": {
"allOf": [
{
"field": "type",
"in": [
]
},
{
"not": {
"contains": "resourceGroups/CustomImage"
}
}
]
},
"then": {
"effect": "deny"
}
}
O exemplo a seguir especifica as IDs de imagem aprovadas:
{
"in": ["{imageId1}","{imageId2}"]
}
Extensões de Máquina Virtual

Talvez você queira proibir o uso de determinados tipos de extensões. Por exemplo, uma extensão pode não ser
compatível com determinadas imagens de máquina virtual personalizadas. O exemplo a seguir mostra como
bloquear uma extensão específica. Ele usa o publicador e o tipo para determinar qual extensão será bloqueada.
{
"if": {
"allOf": [
{
"field": "type",
},
{
},
{
"equals": "{extension-type}"
}
]
},
"then": {
"effect": "deny"
}
}
Benefício de Uso do Azure Híbrido

Quando você tiver uma licença local, poderá salvar a taxa de licença em suas máquinas virtuais. Quando você
não tiver a licença, deverá proibir a opção. A seguinte política proíbe o uso do Benefício de Uso do Azure Híbrido
(AHUB):
{
"if": {
"allOf": [
{
"field": "type",
"in":[ "Microsoft.Compute/virtualMachines","Microsoft.Compute/VirtualMachineScaleSets"]
},
{
"field": "Microsoft.Compute/licenseType",
"exists": true
}
]
},
"then": {
"effect": "deny"
}
}
Próximas etapas
Depois de definir uma regra de política (conforme mostrado nos exemplos anteriores), você precisará criar a
definição de política e atribuí-la a um escopo. O escopo pode ser uma assinatura, grupo de recursos ou
recurso. Para atribuir políticas, consulte Usar o portal do Azure para atribuir e gerenciar políticas de recursos,
Usar o PowerShell para atribuir políticas ou Usar a CLI do Azure para atribuir políticas.
Para obter uma introdução às políticas de recursos, consulte O que é o Azure Policy?.
Para obter orientação sobre como as empresas podem usar o Resource Manager para gerenciar assinaturas
de forma eficaz, consulte Azure enterprise scaffold – controle de assinatura prescritivas.
O que é o Azure Bastion?
O Azure Bastion é um serviço que ao ser implantado permite que você se conecte a uma máquina virtual
usando seu navegador e o portal do Azure. O serviço do Azure Bastion é um serviço PaaS totalmente
gerenciado por plataforma que pode ser provisionado dentro de sua rede virtual. Ele fornece uma conectividade
RDP/SSH segura e contínua para suas máquinas virtuais diretamente do portal do Azure via TLS. Ao se conectar
por meio do Azure Bastion, suas máquinas virtuais não precisarão de um endereço IP público, nem de um
agente e tampouco de um software cliente especial.
O Bastion fornece conectividade segura de RDP e SSH a todas as VMs na rede virtual em que ele é
provisionado. O uso do Azure Bastion protege suas máquinas virtuais contra a exposição das portas RDP/SSH
ao mundo externo, fornecendo acesso seguro usando o RDP/o SSH.
Arquitetura
A implantação do Azure Bastion é feita por rede virtual, não por assinatura/conta ou máquina virtual. Após você
provisionar um serviço do Azure Bastion em sua rede virtual, a experiência de RDP/SSH é disponibilizada para
todas as suas VMs na mesma rede virtual.
RDP e SSH são alguns dos meios fundamentais pelos quais você pode se conectar às suas cargas de trabalho
em execução no Azure. A exposição de portas RDP/SSH pela Internet não é desejada e é vista como uma
superfície de ameaça significativa. Isso costuma ocorrer devido a vulnerabilidades de protocolo. Para conter essa
superfície de ameaça, você pode implantar hosts de bastiões (também conhecidos como jump-servers) no lado
público de sua rede de perímetro. Os servidores de hosts de bastião são projetados e configurados para resistir
a ataques. Os servidores de bastião também fornecem conectividade RDP e SSH às cargas de trabalho situadas
atrás do bastião, bem como dentro da rede.
Esta figura mostra a arquitetura de uma implantação do Azure Bastion. Neste diagrama:
O bastion host é implantado na rede virtual que contém a sub-rede AzureBastionSubnet que tem um prefixo
mínimo /27.
O usuário se conecta ao portal do Azure usando qualquer navegador HTML5.
O usuário seleciona a máquina virtual a qual se conectar.
Com um único clique, a sessão RDP/SSH é aberta no navegador.
Nenhum IP público é necessário na VM do Azure.
Principais recursos
Os seguintes recursos estão disponíveis:
RDP e SSH diretamente no por tal do Azure: Você pode obter acesso direto à sessão RDP e SSH no
portal do Azure usando uma experiência perfeita de único clique.
Sessão remota sobre TLS e passagem de firewall para RDP/SSH: O Azure Bastion usa um cliente
Web baseado em HTML5 que é automaticamente transmitido para o dispositivo local, de modo que você
obtenha a sessão RDP/SSH via TLS na porta 443, permitindo atravessar firewalls corporativos com
segurança.
Não é necessário IP público na VM do Azure: O Azure Bastion abre a conexão RDP/SSH com sua
máquina virtual do Azure usando IP privado em sua VM. Você não precisa de um IP público na sua máquina
virtual.
Sem problemas de gerenciamento de NSGs: O Azure Bastion é um serviço PaaS de plataforma
totalmente gerenciado do Azure que é protegido internamente para fornecer conectividade RDP/SSH segura.
Não é preciso aplicar qualquer NSG na sub-rede do Azure Bastion. Como o Azure Bastion se conecta às suas
máquinas virtuais por IP privado, você pode configurar seus NSGs para permitir somente o RDP/SSH do
Azure Bastion. Isso acaba com o trabalho de gerenciar NSGs cada vez que você precisa se conectar com
segurança às suas máquinas virtuais.
Proteção contra a varredura de por ta: Como você não precisa expor suas máquinas virtuais à Internet
pública, suas VMs são protegidas contra a varredura de portas por usuários invasores e mal-intencionados
localizados fora de sua rede virtual.
Protege contra explorações de dia zero. Proteção em um único lugar : o Azure Bastion é um serviço
de PaaS totalmente gerenciado por plataforma. Como ele reside no perímetro de sua rede virtual, você não
precisa se preocupar em proteger cada uma das máquinas virtuais da sua rede virtual. A plataforma Azure
oferece proteção contra explorações de dia zero, mantendo o Azure Bastion protegido e sempre atualizado
para você.
Novidades
Assine o RSS feed e veja as atualizações mais recentes dos recursos do Azure Bastion na página Atualizações do
Azure.
Preciso de um IP público em minha máquina virtual para me conectar via Azure Bastion?
Não. Ao conectar-se a uma VM usando o Azure Bastion, não é preciso um IP público na máquina virtual do
Azure a que você está se conectando. O serviço do Bastion abrirá o RDP/SSH/sessão/conexão para sua máquina
virtual usando o IP privado da máquina virtual, dentro de sua rede virtual.
Há suporte para o IPv6?
No momento, não há suporte para o IPv6. O Azure Bastion só dá suporte ao IPv4.
Eu preciso de um cliente de RDP ou SSH?
Não. Você não precisa de um cliente de RDP ou SSH para acessar o RDP/SSH para sua máquina virtual do Azure
no portal do Azure. Use o portal do Azure para ter acesso de RDP/SSH à sua máquina virtual diretamente no
navegador.
Eu preciso ter um agente em execução na máquina virtual do Azure?
Não. Não é necessário instalar um agente ou um software no navegador ou na máquina virtual do Azure. O
serviço do Bastion é sem agente e não requer software adicional para RDP/SSH.
Com quantas sessões de RDP e SSH simultâneas cada Azure Bastion é compatível?
RDP e SSH são protocolos baseados em uso. O alto uso de sessões fará com que o bastion host seja compatível
com um número total de sessões menor. Os números abaixo presumem fluxos de trabalho normais do dia a dia.
REC URSO L IM IT E
Conexões RDP simultâneas 25*
Conexões SSH simultâneas 50**
*Pode variar devido a outras sessões RDP em andamento ou a outras sessões SSH em andamento.
**Poderá variar se houver conexões RDP ou uso de outras sessões SSH em andamento.
Quais recursos são compatíveis em uma sessão RDP?
Neste momento, apenas o recurso de copiar/colar texto é compatível. Recursos como cópia de arquivo não são
compatíveis. Fique à vontade para compartilhar seus comentários sobre novos recursos na página Comentários
sobre o Azure Bastion.
A proteção do Bastion funciona com VMs ingressadas na extensão da VM do AADJ?
Esse recurso não funciona com máquinas virtuais ingressadas na extensão da VM do AADJ usando usuários do
Azure AD. Para obter mais informações, confira VMs do Microsoft Azure e Azure AD.
Quais navegadores são compatíveis?
Use o navegador Microsoft Edge ou o Google Chrome no Windows. Para o Apple Mac, use o navegador Google
Chrome. O Microsoft Edge Chromium também é compatível com o Windows e o Mac, respectivamente.
Onde o Azure Bastion armazena dados do cliente?
O Azure Bastion não move nem armazena dados do cliente fora da região em que está implantado.
É necessário ter alguma função para acessar uma máquina virtual?
Para fazer uma conexão, são necessárias as seguintes funções:
Função de leitor na máquina virtual
Função de leitor na placa de interface de rede com endereço IP privado da máquina virtual
Função de leitor no recurso do Azure Bastion
Quais são os preços?
Para saber mais, confira a página de preço.
O Azure Bastion exige uma CAL para Serviços de Área de Trabalho Remota para fins administrativos em VMs
hospedadas no Azure?
Não, o acesso às VMs do Windows Server pelo Azure Bastion não exige uma CAL para Serviços de Área de
Trabalho Remota quando usado exclusivamente para fins administrativos.
Quais layouts de teclado têm suporte durante a sessão remota do Bastion?
Atualmente, o Azure Bastion dá suporte ao layout de teclado QWERTY em inglês dentro da VM. Estamos
trabalhando para dar suporte a layouts de teclado de outras localidades.
As sub-redes do Azure Bastion tem suporte para UDR (roteamento definido pelo usuário )?
Não. As sub-redes do Azure Bastion não tem suporte para UDR.
Para cenários que incluem o Azure Bastion e o Firewall do Azure ou a NVA (solução de virtualização de rede) na
mesma rede virtual, você não precisa forçar o tráfego de uma sub-rede do Azure Bastion para o Firewall do
Azure, pois a comunicação entre o Azure Bastion e suas VMs é privada. Para saber mais, confira Acessar VMs
por trás do Firewall do Azure com o Bastion.
Por que recebo a mensagem de erro "Sua sessão expirou" antes de iniciar a sessão do Bastion?
Uma sessão deve ser iniciada somente por meio do portal do Azure. Entre no portal do Azure e inicie sua sessão
novamente. Se você acessar a URL diretamente em outra guia ou sessão do navegador, esse erro será esperado.
Ele ajuda a garantir que sua sessão seja mais segura e que ela possa ser acessada somente por meio do portal
do Azure.
Como faço para lidar com falhas de implantação?
Examine todas as mensagens de erro e gere uma solicitação de suporte no portal do Azure conforme
necessário. As falhas de implantação podem resultar de Limites, cotas e restrições de assinatura do Azure.
Especificamente, os clientes podem encontrar um limite no número de endereços IP públicos permitidos por
assinatura que causam falha na implantação do Azure Bastion.
Como incorporo o Azure Bastion em meu plano de Recuperação de Desastre?
O Azure Bastion é implantado em VNets ou VNets emparelhadas e está associado a uma região do Azure. Você
é responsável por implantar o Azure Bastion em uma VNet do site de DR (Recuperação de Desastre). No caso de
uma falha de região do Azure, execute uma operação de failover para suas VMs na região de DR. Em seguida,
use o host do Azure Bastion que é implantado na região de DR para se conectar às VMs que agora estão
implantadas.
Próximas etapas
Tutorial: como criar um host do Azure Bastion e se conectar a uma VM do Windows.
Saiba mais sobre alguns dos outros principais recursos de rede do Azure.
Criar um host de bastiões do Azure usando Azure
PowerShell
Este artigo mostra como criar um host de bastiões do Azure usando o PowerShell. Depois de provisionar o
serviço de bastiões do Azure em sua rede virtual, a experiência ininterrupta de RDP/SSH estará disponível para
todas as VMs na mesma rede virtual. A implantação do Azure Bastion é feita por rede virtual, não por
assinatura/conta ou máquina virtual.
Opcionalmente, você pode criar um host de bastiões do Azure usando o portal do Azure.
Pré-requisitos
Verifique se você tem uma assinatura do Azure. Se ainda não tiver uma assinatura do Azure, você poderá ativar
os Benefícios do assinante do MSDN ou inscrever-se para obter uma conta gratuita.
Este artigo usa cmdlets do PowerShell. Para executar os cmdlets, você pode usar o Azure Cloud Shell. O Azure
Cloud Shell é um shell interativo grátis que pode ser usado para executar as etapas neste artigo. Ele tem
ferramentas do Azure instaladas e configuradas para usar com sua conta.
Você também pode instalar e executar os cmdlets Azure PowerShell localmente no seu computador. Os cmdlets
do PowerShell são atualizados com frequência. Se você não tiver instalado a versão mais recente, os valores
especificados nas instruções poderão falhar. Para localizar as versões do Azure PowerShell instaladas no seu
computador, use o Get-Module -ListAvailable Az cmdlet. Para instalar ou atualizar o, consulte instalar o Azure
PowerShell Module.
Criar um bastion host

Esta seção ajuda você a criar um novo recurso de bastiões do Azure usando o Azure PowerShell.
1. Crie uma rede virtual e uma sub-rede de bastiões do Azure. Você deve criar a sub-rede de bastiões do
Azure usando o valor de nome AzureBastionSubnet . Esse valor permite que o Azure saiba em qual
sub-rede os recursos do Bastion serão implantados. Isso é diferente de uma sub-rede de gateway. Você
deve usar uma sub-rede de pelo menos/27 ou uma sub-rede maior (/27,/26 e assim por diante). Crie o
AzureBastionSubnet sem nenhuma tabela ou delegação de rota. Se você usar grupos de segurança de
rede no AzureBastionSubnet , consulte o artigo trabalhar com NSGs .
$subnetName = "AzureBastionSubnet"
$subnet = New-AzVirtualNetworkSubnetConfig -Name $subnetName -AddressPrefix 10.0.0.0/24
$vnet = New-AzVirtualNetwork -Name "myVnet" -ResourceGroupName "myBastionRG" -Location "westeurope" -
AddressPrefix 10.0.0.0/16 -Subnet $subnet
2. Crie um endereço IP público para a bastiões do Azure. O IP público é o endereço IP público no qual o
recurso de bastiões em que o RDP/SSH será acessado (pela porta 443). O endereço IP público precisa
estar na mesma região que o recurso do Bastion que você está criando.
$publicip = New-AzPublicIpAddress -ResourceGroupName "myBastionRG" -name "myPublicIP" -location
"westeurope" -AllocationMethod Static -Sku Standard
3. Crie um novo recurso de bastiões do Azure no AzureBastionSubnet de sua rede virtual. Leva cerca de 5
minutos para que o recurso de bastiões seja criado e implantado.
$bastion = New-AzBastion -ResourceGroupName "myBastionRG" -Name "myBastion" -PublicIpAddress

$publicip -VirtualNetwork $vnet
Próximas etapas
Leia as perguntas frequentes sobre bastiões para obter informações adicionais.
Para usar grupos de segurança de rede com a sub-rede do Azure Bastion, confira Trabalhar com NSGs.
Criar um host de bastiões do Azure usando CLI do
Azure
Este artigo mostra como criar um host de bastiões do Azure usando CLI do Azure. Depois de provisionar o
serviço de bastiões do Azure em sua rede virtual, a experiência ininterrupta de RDP/SSH estará disponível para
todas as VMs na mesma rede virtual. A implantação do Azure Bastion é feita por rede virtual, não por
assinatura/conta ou máquina virtual.
Opcionalmente, você pode criar um host de bastiões do Azure usando o portal do Azureou usando Azure
PowerShell.
Pré-requisitos
Verifique se você tem uma assinatura do Azure. Se ainda não tiver uma assinatura do Azure, você poderá ativar
os Benefícios do assinante do MSDN ou inscrever-se para obter uma conta gratuita.
Este artigo usa o CLI do Azure. Para executar comandos, você pode usar Azure Cloud Shell. O Azure Cloud Shell
é um shell interativo grátis que pode ser usado para executar as etapas neste artigo. Ele tem ferramentas do
Azure instaladas e configuradas para usar com sua conta.
também pode iniciar Cloud Shell em uma guia separada do navegador acessando https://shell.azure.com e
alternando o menu suspenso no canto esquerdo para refletir o bash ou o PowerShell. Selecione Copiar para
copiar os blocos de código, cole o código no Cloud Shell e depois pressione Enter para executá-lo.
Criar um bastion host

Esta seção ajuda você a criar um novo recurso de bastiões do Azure usando o CLI do Azure.
NOTE
Conforme mostrado nos exemplos, use o --location parâmetro com --resource-group para cada comando para
garantir que os recursos sejam implantados juntos.
1. Crie uma rede virtual e uma sub-rede de bastiões do Azure. Você deve criar a sub-rede de bastiões do
Azure usando o valor de nome AzureBastionSubnet . Esse valor permite que o Azure saiba em qual
sub-rede os recursos do Bastion serão implantados. Isso é diferente de uma sub-rede de gateway. Você
deve usar uma sub-rede de pelo menos/27 ou uma sub-rede maior (/27,/26 e assim por diante). Crie o
AzureBastionSubnet sem nenhuma tabela ou delegação de rota. Se você usar grupos de segurança de
rede no AzureBastionSubnet , consulte o artigo trabalhar com NSGs .
az network vnet create --resource-group MyResourceGroup --name MyVnet --address-prefix 10.0.0.0/16 --

subnet-name AzureBastionSubnet --subnet-prefix 10.0.0.0/24 --location northeurope
2. Crie um endereço IP público para a bastiões do Azure. O IP público é o endereço IP público no qual o
recurso de bastiões em que o RDP/SSH será acessado (pela porta 443). O endereço IP público precisa
estar na mesma região que o recurso do Bastion que você está criando.
az network public-ip create --resource-group MyResourceGroup --name MyIp --sku Standard --location
northeurope
3. Crie um novo recurso de bastiões do Azure no AzureBastionSubnet de sua rede virtual. Leva cerca de 5
minutos para que o recurso de bastiões seja criado e implantado.
az network bastion create --name MyBastion --public-ip-address MyIp --resource-group MyResourceGroup

--vnet-name MyVnet --location northeurope
Próximas etapas
Leia as perguntas frequentes sobre bastiões para obter informações adicionais.
Para usar grupos de segurança de rede com a sub-rede do Azure Bastion, confira Trabalhar com NSGs.
Conectar-se usando SSH em uma máquina virtual
Linux usando a bastiões do Azure
Este artigo mostra como fazer SSH de forma segura e direta para suas VMs do Linux em uma rede virtual do
Azure. Você pode se conectar a uma VM diretamente do portal do Azure. Ao usar a bastiões do Azure, as VMs
não exigem um cliente, agente ou software adicional. Para obter mais informações sobre a bastiões do Azure,
consulte a visão geral.
Você pode usar a bastiões do Azure para se conectar a uma máquina virtual Linux usando SSH. Você pode usar
o nome de usuário/senha e as chaves SSH para autenticação. Você pode se conectar à sua VM com chaves SSH
usando:
Uma chave privada que você insere manualmente
Um arquivo que contém as informações de chave privada
A chave privada SSH deve estar em um formato que comece com "-----BEGIN RSA PRIVATE KEY-----" e termine
com "-----END RSA PRIVATE KEY-----" .
Pré-requisitos
Verifique se você configurou um host de bastiões do Azure para a rede virtual na qual a VM reside. Para obter
mais informações, consulte criar um host de bastiões do Azure. Depois que o serviço de bastiões for
provisionado e implantado em sua rede virtual, você poderá usá-lo para se conectar a qualquer VM nessa rede
virtual.
Quando você usa a bastiões para se conectar, ele pressupõe que você está usando o RDP para se conectar a uma
VM do Windows e o SSH para se conectar às suas VMs do Linux. Para obter informações sobre como se
conectar a uma VM do Windows, consulte conectar-se a uma VM-Windows.
Funções necessárias
Para fazer uma conexão, são necessárias as seguintes funções:
Função de leitor na máquina virtual
Função de leitor na placa de interface de rede com endereço IP privado da máquina virtual
Função de leitor no recurso do Azure Bastion
Portas
Para se conectar à VM do Linux via SSH, você deve ter as seguintes portas abertas em sua VM:
Porta de entrada: SSH (22)
Conectar: usando nome de usuário e senha

1. Abra o Portal do Azure. Navegue até a máquina virtual à qual você deseja se conectar e clique em
conectar e selecione bastiões na lista suspensa.
2. Depois de selecionar a bastiões, clique em usar bastiões . Se você não provisionar a bastiões para a rede
virtual, consulte Configurar a bastiões.
3. Na página conectar usando a bastiões do Azure , insira o nome de usuário e a senha .
4. Selecione conectar para conectar-se à VM.
Conectar: Insira manualmente uma chave privada

3. Na página conectar usando a bastiões do Azure , insira o nome de usuário e a chave privada
SSH .
4. Insira sua chave privada na chave privada SSH da área de texto (ou cole-a diretamente).
5. Selecione conectar para conectar-se à VM.
Conectar: usando um arquivo de chave privada

3. Na página conectar usando a bastiões do Azure , insira o nome de usuário e a chave privada
SSH do arquivo local .
4. Procure o arquivo e selecione abrir .

5. Selecione conectar para conectar-se à VM. Depois de clicar em conectar, o SSH para essa máquina
virtual será aberto diretamente no portal do Azure. Essa conexão é sobre o HTML5 usando a porta 443
no serviço de bastiões por meio do IP privado de sua máquina virtual.
Conectar: usando uma chave privada armazenada em Azure Key Vault

NOTE
A atualização do portal para este recurso está sendo distribuída no momento para regiões.
3. Na página conectar usando a bastiões do Azure , insira o nome de usuário e selecione chave
privada SSH em Azure Key Vault .
4. Selecione a lista suspensa Azure Key Vault e selecione o recurso no qual você armazenou a chave
privada SSH. Se você não configurou um recurso de Azure Key Vault, consulte criar um cofre de chaves e
armazenar sua chave privada SSH como o valor de um novo segredo de Key Vault.
Verifique se você tem a lista e obtenha acesso aos segredos armazenados no recurso de Key Vault. Para
atribuir e modificar políticas de acesso para o recurso Key Vault, consulte atribuir uma política de acesso
Key Vault.
5. Selecione o Azure Key Vault lista suspensa segredo e selecione o segredo de Key Vault que contém o
valor da chave privada SSH.
6. Selecione conectar para conectar-se à VM. Depois de clicar em conectar , o ssh para essa máquina
virtual será aberto diretamente no portal do Azure. Essa conexão é sobre o HTML5 usando a porta 443
no serviço de bastiões por meio do IP privado de sua máquina virtual.
Próximas etapas
Para obter mais informações sobre a bastiões do Azure, consulte as perguntas frequentes sobre bastiões.
Conectar-se a uma máquina virtual do Windows
usando a bastiões do Azure
Usando a bastiões do Azure, você pode se conectar de forma segura e direta às suas máquinas virtuais por SSL
diretamente no portal do Azure. Quando você usa a bastiões do Azure, suas VMs não exigem um cliente, agente
ou software adicional. Este artigo mostra como se conectar às suas VMs do Windows. Para obter informações
sobre como se conectar a uma VM do Linux, consulte conectar-se a uma VM do Linux.
A bastiões do Azure fornece conectividade segura para todas as VMs na rede virtual em que ela é provisionada.
O uso do Azure Bastion protege suas máquinas virtuais contra a exposição das portas RDP/SSH ao mundo
externo, fornecendo acesso seguro usando o RDP/o SSH. Para obter mais informações, consulte o que é a
bastiões do Azure?.
Pré-requisitos
Antes de começar, verifique se você atende aos seguintes critérios:
Uma VNet com o host de bastiões já está instalada.
Verifique se você configurou um host de bastiões do Azure para a rede virtual na qual a VM está
localizada. Depois que o serviço de bastiões for provisionado e implantado em sua rede virtual, você
poderá usá-lo para se conectar a qualquer VM na rede virtual. Para configurar um host de bastiões do
Azure, consulte criar um host de bastiões.
Uma máquina virtual do Windows na rede virtual.
As seguintes funções obrigatórias:
A função de leitor na máquina virtual.
A função de leitor na placa de interface de rede com endereço IP privado da máquina virtual.
Função de leitor no recurso do Azure Bastion.
Portas: Para se conectar à VM do Windows, você precisará abrir as seguintes portas nela:
Portas de entrada: RDP (3389)
Conectar
1. Abra o Portal do Azure. Navegue até a máquina virtual à qual você deseja se conectar e selecione
Conectar . Selecione Bastion no menu suspenso.
2. Depois de selecionar o Bastion no menu suspenso, uma barra lateral será exibida com três guias: RDP,
SSH e Bastion. Como o Bastion foi provisionado para a rede virtual, a guia Bastion está ativa por padrão.
Selecione Usar Bastion .
3. Na página Conectar-se usando o Azure Bastion , insira o nome de usuário e a senha para sua
máquina virtual e selecione Conectar .
4. A conexão RDP com essa máquina virtual via Bastion será aberta diretamente no portal do Azure (via
HTML5) usando a porta 443 e o serviço Bastion.
Próximas etapas
Leia as perguntas frequentes do Bastion.
O que é o RBAC do Azure (controle de acesso
baseado em função do Azure)?
O gerenciamento de acesso para recursos de nuvem é uma função crítica para qualquer organização que esteja
usando a nuvem. O RBAC do Azure (controle de acesso baseado em funções do Azure) ajuda a gerenciar quem
tem acesso aos recursos do Azure, o que pode fazer com esses recursos e a quais áreas tem acesso.
O RBAC do Azure é um sistema de autorização baseado no Azure Resource Manager que fornece
gerenciamento de acesso refinado dos recursos do Azure.
Este vídeo fornece uma visão geral rápida do RBAC do Azure.
O que posso fazer com o RBAC do Azure?

Aqui estão alguns exemplos do que você pode fazer com o RBAC do Azure:
Permitir que um usuário gerencie máquinas virtuais em uma assinatura e outro usuário gerencie redes
virtuais
Permitir que um grupo de DBA gerencie bancos de dados SQL em uma assinatura
Permitir que um usuário gerencie todos os recursos em um grupo de recursos, como máquinas virtuais, sites
e sub-redes
Permitir que um aplicativo acesse todos os recursos em um grupo de recursos
Como o RBAC do Azure funciona

A maneira de controlar o acesso aos recursos usando o RBAC do Azure é atribuir funções do Azure. Esse é um
conceito fundamental que deve ser entendido: como as permissões são aplicadas. Uma atribuição de função
consiste em três elementos: entidade de segurança, definição de função e escopo.
Entidade de segurança
Uma entidade de segurança é um objeto que representa um usuário, grupo, entidade de serviço ou uma
identidade gerenciada que está solicitando acesso aos recursos do Azure. Você pode atribuir uma função a
qualquer uma dessas entidades de segurança.
Definição de função
Uma definição de função é um conjunto de permissões. Normalmente ela é chamada apenas de função. Uma
definição de função lista as operações que podem ser executadas, como leitura, gravação e exclusão. Funções
podem ser de alto nível, como proprietário, ou específicas, como leitor de máquina virtual.
O Azure inclui várias funções internas que você pode usar. Por exemplo, a função Colaborador de Máquina
Virtual permite que um usuário crie e gerencie máquinas virtuais. Se as funções internas não atenderem às
necessidades específicas de sua organização, você poderá criar funções personalizadas do Azure próprias.
Este vídeo fornece uma visão geral rápida das funções internas e das funções personalizadas.
O Azure tem operações de dados que permitem a você conceder acesso a dados em um objeto. Por exemplo, se
um usuário tem acesso de leitura de dados para uma conta de armazenamento, eles podem ler blobs ou
mensagens dentro dessa conta de armazenamento.
Para saber mais, veja Noções básicas sobre definições de função do Azure.
Escopo
Escopo é o conjunto de recursos ao qual o acesso se aplica. Quando você atribui uma função, você pode limitar
ainda mais as ações permitidas definindo um escopo. Isso será útil se você quiser tornar alguém um
colaborador do site, mas apenas para um grupo de recursos.
No Azure, você pode especificar um escopo em quatro níveis: grupo de gerenciamento, assinatura, grupo de
recursos ou recurso. Os escopos são estruturados em uma relação pai-filho. Você pode atribuir funções em
qualquer um desses níveis de escopo.
Para obter mais informações sobre escopo, confira Noções básicas de escopo.
Atribuições de função
Uma atribuição de função é o processo de associar uma definição de função a um usuário, grupo, entidade de
serviço ou identidade gerenciada em um escopo específico com a finalidade de conceder acesso. O acesso é
concedido criando uma atribuição de função, e é revogado removendo uma atribuição de função.
O diagrama a seguir mostra um exemplo de uma atribuição de função. Neste exemplo, o grupo de Marketing foi
atribuído à função Colaborador para o grupo de recursos vendas farmacêuticas. Isso significa que os usuários
do grupo de Marketing podem criar ou gerenciar qualquer recurso do Azure no grupo de recursos de vendas do
setor farmacêutico. Os usuários de Marketing não possuem acesso a recursos fora do grupo de recursos de
vendas do setor farmacêutico, a menos que sejam parte de outra atribuição de função.
Você pode atribuir funções usando o portal do Azure, a CLI do Azure, o Azure PowerShell, SDKs do Azure ou
APIs REST.
Para obter mais informações, confira Etapas para atribuir uma função do Azure.
Atribuições de função múltiplas

O que acontece se você tem várias atribuições de função sobrepostas? O RBAC do Azure é um modelo aditivo e,
portanto, suas permissões efetivas são a soma das atribuições de função. Considere o exemplo a seguir em que
um usuário recebe a função Colaborador no escopo da assinatura e a função Leitor em um grupo de recursos. A
soma das permissões de Colaborador e das permissões de Leitor é, efetivamente, a função Colaborador para o
grupo de recursos. Portanto, nesse caso, a atribuição de função Leitor não tem nenhum impacto.
Negar atribuições
Anteriormente, o RBAC do Azure era um modelo somente de permissão, sem negação, mas agora ele é
compatível com atribuições de negações, com limitações. Semelhante a uma atribuição de função, uma
atribuição de negação anexa um conjunto de ações de negação a um usuário, grupo, entidade de serviço ou
identidade gerenciada em um escopo específico com o objetivo de negar acesso. Uma atribuição de função
define um conjunto de ações que são permitidas, enquanto uma atribuição de negação define um conjunto de
ações que não são permitidas. Em outras palavras, as atribuições de negação impedem que os usuários
executem ações especificadas, mesmo quando uma atribuição de função lhes concede acesso. As atribuições de
negação têm precedência sobre as atribuições de função.
Para obter mais informações, confira Compreender atribuições de negação do Azure.
Como o RBAC do Azure determina se um usuário tem acesso a um

recurso
Veja a seguir as etapas gerais que o RBAC do Azure usa para determinar se você tem acesso a um recurso no
plano de gerenciamento. Convém entender isso quando você está tentando solucionar problemas de acesso.
1. Um usuário (ou uma entidade de serviço) adquire um token do Azure Resource Manager.
O token inclui as associações a um grupo do usuário (incluindo associações de grupo transitivas).
2. O usuário faz uma chamada à API REST para o Azure Resource Manager com o token anexado.
3. O Azure Resource Manager recupera todas as atribuições de função e as atribuições de negação que se
aplicam ao recurso no qual a ação está sendo realizada.
4. O Azure Resource Manager restringe as atribuições de função que se aplicam a esse usuário ou ao seu
grupo e determina as funções que o usuário tem para este recurso.
5. O Azure Resource Manager determina se a ação na chamada à API está incluída nas funções que o
usuário tem para este recurso.
6. Se o usuário não tem uma função com a ação no escopo solicitado, o acesso não é concedido. Caso
contrário, o Azure Resource Manager verifica se uma atribuição de negação se aplica.
7. Se houver uma atribuição de negação aplicável, o acesso será bloqueado. Caso contrário, o acesso será
permitido.
Requisitos de licença
O uso desse recurso é gratuito e está incluído em sua assinatura do Azure.
Próximas etapas
Atribuir funções do Azure usando o portal do Azure
Entender as diferentes funções
Cloud Adoption Framework: Gerenciamento de acesso aos recursos no Azure
Como configurar o Key Vault para máquinas virtuais
com a CLI do Azure
Na pilha do Azure Resource Manager, os segredos/certificados são modelados como recursos que são
fornecidos pelo Key Vault. Para saber mais sobre o Cofre de Chaves do Azure, consulte O que é o Cofre de
Chaves do Azure? Para que o Key Vault seja usado com VMs do Azure Resource Manager, a propriedade
EnabledForDeployment no Key Vault deverá ser definida como true. Este artigo mostra como configurar o Key
Vault para uso com VMs (máquinas virtuais) do Azure usando a CLI do Azure.
Para realizar essas etapas, é preciso ter a CLI do Azure mais recente instalada e conectada a uma conta do Azure
usando az login.

Crie um Key Vault e atribua a política de implantação com az keyvault create. O exemplo a seguir cria um Key
Vault chamado myKeyVault no grupo de recursos myResourceGroup :
az keyvault create -l westus -n myKeyVault -g myResourceGroup --enabled-for-deployment true
Atualizar um Key Vault para uso com VMs

Defina a política de implantação em um Key Vault existente com az keyvault update. O exemplo a seguir atualiza
o cofre de chaves chamado myKeyVault no grupo de recursos myResourceGroup :
az keyvault update -n myKeyVault -g myResourceGroup --set properties.enabledForDeployment=true
Usar modelos para configurar o Cofre de Chaves

Ao usar um modelo, você precisa definir a propriedade enabledForDeployment como true para o recurso do
Key Vault da seguinte forma:
{
"type": "Microsoft.KeyVault/vaults",
"name": "ContosoKeyVault",
"apiVersion": "2015-06-01",
"location": "<location-of-key-vault>",
"properties": {
"enabledForDeployment": "true",
....
....
}
}
Próximas etapas
Para obter outras opções que você pode definir ao criar um Key Vault usando modelos, consulte Create a key
vault (Criar um Key Vault).
Configurar Key Vault para máquinas virtuais usando
Azure PowerShell
NOTE
O Azure tem dois modelos de implantação diferentes que você pode usar para criar e trabalhar com recursos: Azure
Resource Manager e clássico. Este artigo abordará o uso do modelo de implantação do Resource Manager.
Recomendamos usar o modelo de implantação do Resource Manager para executar novas implantações em vez do
modelo clássico de implantação.
Na pilha do Azure Resource Manager, os certificados/segredos são modelados como recursos que são
fornecidos pelo provedor de recursos do Cofre de Chaves. Para saber mais sobre o Cofre de Chaves, consulte O
que é o Cofre de Chaves do Azure?
NOTE
1. Para que um Cofre de Chaves seja usado com máquinas virtuais do Azure Resource Manager, a propriedade
EnabledForDeployment no Cofre de Chaves deverá ser definida como true. Você pode fazer isso em vários clientes.
2. O Cofre de Chaves precisa ser criado na mesma assinatura e na mesma localização que a Máquina Virtual.
Usar o PowerShell para configurar o Cofre de Chaves

Para criar um key vault usando o PowerShell, consulte Definir e recuperar um segredo do Azure Key Vault
Para novos cofres de chaves, você pode usar este cmdlet do PowerShell:
New-AzKeyVault -VaultName 'ContosoKeyVault' -ResourceGroupName 'ContosoResourceGroup' -Location 'East Asia'

-EnabledForDeployment
Para cofres de chaves existentes, você pode usar este cmdlet do PowerShell:
Set-AzKeyVaultAccessPolicy -VaultName 'ContosoKeyVault' -EnabledForDeployment
Usar a CLI para configurar o Cofre de Chaves

Para criar um cofre de chaves usando a CLI (interface de linha de comando), consulte Gerenciar Cofre da Chave
usando a CLI.
Para a CLI, você precisa criar o cofre de chaves antes de atribuir a política de implantação. Faça isso usando este
comando:
az keyvault create --name "ContosoKeyVault" --resource-group "ContosoResourceGroup" --location "EastAsia"
Em seguida, para habilitar Key Vault para uso com a implantação de modelo, execute o seguinte comando:
az keyvault update --name "ContosoKeyVault" --resource-group "ContosoResourceGroup" --enabled-for-deployment
"true"
Usar modelos para configurar o Cofre de Chaves

Ao usar um modelo, você precisa definir a propriedade enabledForDeployment como true para o recurso de
Cofre de Chaves.
{
"type": "Microsoft.KeyVault/vaults",
"name": "ContosoKeyVault",
"apiVersion": "2015-06-01",
"location": "<location-of-key-vault>",
"properties": {
"enabledForDeployment": "true",
....
....
}
}
Para obter outras opções que você pode configurar ao criar um cofre de chaves usando modelos, consulte criar
um cofre de chaves.
Diretrizes para mitigar vulnerabilidades de canal
lateral de execução especulativa
Última atualização do documento : 12 de novembro de 2019 10:00 am PST.

A divulgação de uma nova classe de vulnerabilidades de CPU conhecida como ataques de canal paralelo de
execução especulativa resultou em várias perguntas dos clientes que queriam mais esclarecimentos sobre o
assunto.
A Microsoft implantou atenuações em todos os nossos serviços de nuvem. A infraestrutura que executa o Azure
e isola as cargas de trabalho do cliente entre elas está protegida. Isso significa que um invasor potencial que usa
a mesma infraestrutura não pode atacar seu aplicativo usando essas vulnerabilidades.
O Azure usa a manutenção da preservação da memória sempre que possível, para minimizar o impacto para o
cliente e eliminar a necessidade de reinicializações. O Azure continuará utilizando esses métodos ao fazer
atualizações em todo o sistema do host e proteger nossos clientes.
Mais informações sobre como a segurança é integrada em todos os aspectos do Azure estão disponíveis no site
Documentação de segurança do Azure.
NOTE
Desde a primeira publicação deste documento, foram divulgadas várias variantes dessa classe de vulnerabilidade. A
Microsoft continua investindo intensamente na proteção de nossos clientes e no fornecimento de diretrizes. Esta página
será atualizada conforme continuamos liberando correções adicionais.
Em 12 de novembro de 2019, a Intel publicou um aviso técnico sobre a vulnerabilidade da Intel® extensões de
sincronização transacional (Intel® TSX) Transaction assíncrona (TAA) que é atribuída CVE-2019-11135. Essa
vulnerabilidade afeta os processadores Intel® Core® e Intel® Xeon®. O Microsoft Azure lançou atualizações do
sistema operacional e está implantando o novo microcódigo, pois ele é disponibilizado pela Intel, em toda a frota para
proteger nossos clientes contra essas novas vulnerabilidades. O Azure está trabalhando de forma minuciosa com a Intel
para testar e validar o novo microcódigo antes do lançamento oficial na plataforma.
Os clientes que executam código não confiável dentro de sua VM precisam tomar medidas para proteger
contra essas vulnerabilidades lendo abaixo as orientações adicionais sobre todas as vulnerabilidades de canal lateral de
execução especulativa (Microsoft Advisors avçd 180002, 180018e 190013).
Outros clientes devem avaliar essas vulnerabilidades de uma perspectiva de defesa profunda e considerar as implicações
de segurança e desempenho de sua configuração escolhida.
Mantendo seus sistemas operacionais atualizados

Embora uma atualização do sistema operacional não seja necessária para isolar os aplicativos em execução no
Azure de outros clientes do Azure, é sempre uma melhor prática manter o software atualizado. Os últimos
Pacotes Cumulativos de Atualizações de Segurança para o Windows contêm mitigações de várias
vulnerabilidades de canal paralelo de execução especulativa. Da mesma forma, as distribuições Linux liberaram
várias atualizações para resolver essas vulnerabilidades. Aqui estão nossas ações recomendadas para atualizar
seu sistema operacional:
O F ERTA A Ç Ã O REC O M EN DA DA
Serviços de nuvem do Azure Habilite a atualização automática ou verifique se você está

executando o SO convidado mais recente.
Máquinas Virtuais do Linux do Azure Instale atualizações do provedor do sistema operacional.

Para obter mais informações, confira Linux mais adiante
neste documento.
Máquinas Virtuais do Windows do Azure Instale o pacote cumulativo de atualizações de segurança

mais recente.
Outros Serviços de PaaS do Azure Não é necessária nenhuma ação para clientes que usam
esses serviços. O Azure mantém automaticamente suas
versões de Sistema Operacional atualizadas.
Orientações adicionais se você estiver executando código não

confiável
Os clientes que permitem que usuários não confiáveis executem um código arbitrário podem desejar
implementar alguns recursos de segurança adicionais nas Máquinas Virtuais do Azure ou nos Serviços de
Nuvem. Esses recursos protegem contra vetores de divulgação dentro do processo descritos por várias
vulnerabilidades de execução especulativa.
Cenários de exemplo em que os recursos de segurança adicionais são recomendados:
Você permite que um código não confiável seja executado em sua VM.
Por exemplo, você permite que um de seus clientes carregue um binário ou um script que você, em
seguida, executa no aplicativo.
Você permite que os usuários não confiáveis façam logon em sua VM usando contas com baixos privilégios.
Por exemplo, você permite que um usuário com poucos privilégios faça logon em uma de suas VMs
usando a área de trabalho remota ou o SSH.
Você permite que usuários não confiáveis acessem máquinas virtuais implementadas por meio da
virtualização aninhada.
Por exemplo, você controla o host Hyper-V, mas aloca as VMs a usuários não confiáveis.
Os clientes que não implementam um cenário que envolva um código não confiável não precisam habilitar
esses recursos de segurança adicionais.
Habilitando a segurança adicional

Você pode habilitar recursos de segurança adicionais dentro de sua VM ou serviço de nuvem se você estiver
executando código não confiável. Em paralelo, verifique se o sistema operacional está atualizado para habilitar
recursos de segurança dentro de sua VM ou serviço de nuvem
Windows
O sistema operacional de destino precisa estar atualizado para habilitar esses recursos de segurança adicionais.
Embora várias mitigações de ataques de canal paralelo de execução especulativa estejam habilitadas por
padrão, os recursos adicionais descritos aqui precisam ser habilitados manualmente e podem causar um
impacto no desempenho.
Etapa 1: desabilitar o hyper threading na VM -os clientes que executam código não confiável em uma VM
Hyper-threaded precisarão desabilitar o Hyper-Threading ou mover para um tamanho de VM não Hyper-thread.
Referencie este documento para obter uma lista de tamanhos de VM Hyper-threaded (em que a taxa de vCPU
para Core é 2:1). Para verificar se sua VM tem o hyperthreading habilitado, consulte o script abaixo usando a
linha de comando do Windows de dentro da VM.
Digite wmic para inserir a interface interativa. Em seguida, digite o seguinte para exibir a quantidade de
processadores físicos e lógicos na VM.
CPU Get NumberOfCores,NumberOfLogicalProcessors /Format:List
Se o número de processadores lógicos for maior que processadores físicos (núcleos), o hyperthreading será
habilitado. Se você estiver executando uma VM Hyper-threaded, entre em contato com o suporte do Azure para
obter o hyperthreading desabilitado. Depois que o hyperthreading estiver desabilitado, o supor te exigirá uma
reinicialização completa da VM . Consulte a contagem de núcleos para entender por que sua contagem de
núcleos de VM diminuiu.
Etapa 2 : em paralelo à etapa 1, siga as instruções em KB4072698 para verificar se as proteções estão
habilitadas usando o módulo SpeculationControl PowerShell.
NOTE
Se você já baixou este módulo, precisará instalar a versão mais recente.
A saída do script do PowerShell deve ter os valores abaixo para validar as proteções habilitadas contra essas
vulnerabilidades:
Windows OS support for branch target injection mitigation is enabled: True

Windows OS support for kernel VA shadow is enabled: True
Windows OS support for speculative store bypass disable is enabled system-wide: False
Windows OS support for L1 terminal fault mitigation is enabled: True
Windows OS support for MDS mitigation is enabled: True
Windows OS support for TAA mitigation is enabled: True
Se a saída for mostrada MDS mitigation is enabled: False , entre em contato com o suporte do Azure para
obter as opções de mitigação disponíveis.
Etapa 3 : para habilitar o suporte do sistema operacional de KVAS (sombra de endereço virtual) de kernel e BTI
(injeção de destino de Branch), siga as instruções em KB4072698 para habilitar as proteções usando as
Session Manager chaves do registro. Uma reinicialização é necessária.
Etapa 4 : para implantações que estão usando a virtualização aninhada (apenas D3 e E3): essas instruções se
aplicam dentro da VM que você está usando como um host Hyper-V.
1. Siga as instruções em KB4072698 para habilitar as proteções usando as MinVmVersionForCpuBasedMitigations
chaves do registro.
2. Defina o tipo de Agendador do hipervisor como seguindo Core as instruções aqui.
Linux
A habilitação do conjunto de recursos de segurança adicionais internamente exige que o sistema operacional de
destino esteja totalmente atualizado. Algumas mitigações serão habilitadas por padrão. A seção a seguir
descreve os recursos que estão desativados por padrão e/ou que são dependentes de suporte de hardware
(microcódigo). A habilitação desses recursos pode causar um impacto no desempenho. Referencie a
documentação do provedor do sistema operacional para obter mais instruções
Etapa 1: desabilitar o hyper threading na VM -os clientes que executam código não confiável em uma VM
Hyper-threaded precisarão desabilitar o Hyper-Threading ou mover para uma VM não Hyper-thread. Referencie
este documento para obter uma lista de tamanhos de VM Hyper-threaded (em que a taxa de vCPU para Core é
2:1). Para verificar se você está executando uma VM Hyper-threaded, execute o lscpu comando na VM Linux.
Se, o hyperthreading foi Thread(s) per core = 2 habilitado.
Se, o hyperthreading foi Thread(s) per core = 1 desabilitado.
Exemplo de saída para uma VM com o hyperthreading habilitado:
CPU Architecture: x86_64

CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Se você estiver executando uma VM Hyper-threaded, entre em contato com o suporte do Azure para obter o
hyperthreading desabilitado. Depois que o hyperthreading estiver desabilitado, o supor te exigirá uma
reinicialização completa da VM . Consulte a contagem de núcleos para entender por que sua contagem de
núcleos de VM diminuiu.
Etapa 2 : para mitigar qualquer uma das vulnerabilidades de canal lateral de execução especulativa abaixo,
consulte a documentação do provedor do sistema operacional:
Red Hat e CentOS
SUSE
Ubuntu
Contagem de núcleos
Quando uma VM Hyper-threaded é criada, o Azure aloca 2 threads por núcleo – eles são chamados de vCPUs.
Quando o hyperthreading está desabilitado, o Azure remove um thread e superfícies de núcleos de thread único
(núcleos físicos). A taxa de vCPU para CPU é 2:1, assim, depois que o hyperthreading estiver desabilitado, a
contagem de CPU na VM parecerá ter diminuído pela metade. Por exemplo, uma VM D8_v3 é uma VM Hyper-
thread executada em 8 vCPUs (2 threads por núcleos x 4 núcleos). Quando o hyperthreading estiver
desabilitado, as CPUs serão descartadas para quatro núcleos físicos com 1 thread por núcleo.
Próximas etapas
Este artigo fornece orientação para os ataques de canal lateral de execução especulativo abaixo que afetam
muitos processadores modernos:
Meltdown Spectre:
CVE-2017-5715 – injeção de destino de ramificação (BTI)
CVE-2017-5754-isolamento de tabela de página de kernel (KPTI)
CVE-2018-3639 – bypass de armazenamento especulativo (KPTI)
CVE-2019-1125 – informações de kernel do Windows – variante da variante de Spectre 1
Falha de terminal L1 (L1TF):
CVE-2018-3615-extensões do Intel software Guard (Intel SGX)
CVE-2018-3620-sistemas operacionais (SO) e modo de gerenciamento do sistema (SMM)
CVE-2018-3646 – afeta Virtual Machine Manager (VMM)
Amostragem de dados de microarquitetura:
CVE-2019-11091-microarquitetura dados de amostragem de memória não cache (MDSUM)
CVE-2018-12126-MSBDS (amostragem de dados de buffer de armazenamento de microarquitetura)
CVE-2018-12127-microarquitetura carregar dados de porta (MLPDS)
CVE-2018-12130-microarquitetura de amostragem de dados de buffer de preenchimento (MFBDS)
Anulação assíncrona da transação de extensões de sincronização transacional (Intel® TSX):
CVE-2019-11135 – anulação assíncrona da transação TSX (TAA)
Ingressar uma máquina virtual Red Hat Enterprise
Linux em um domínio Azure Active Directory
Domain Services gerenciado
Para permitir que os usuários entrem em máquinas virtuais (VMs) no Azure usando um único conjunto de
credenciais, você pode ingressar VMs em um domínio gerenciado Azure Active Directory Domain Services (AD
DS do Azure). Quando você une uma VM a um domínio gerenciado AD DS do Azure, as contas de usuário e as
credenciais do domínio podem ser usadas para entrar e gerenciar servidores. As associações de grupo do
domínio gerenciado também são aplicadas para permitir que você controle o acesso a arquivos ou serviços na
VM.
Este artigo mostra como unir uma VM Red Hat Enterprise Linux (RHEL) a um domínio gerenciado.
Pré-requisitos
Para concluir este tutorial, você precisará dos seguintes recursos e privilégios:
Uma assinatura ativa do Azure.
Caso não tenha uma assinatura do Azure, crie uma conta.
Um locatário do Azure Active Directory associado com a assinatura, sincronizado com um diretório local ou
somente em nuvem.
Se necessário, crie um locatário do Azure Active Directory ou associe uma assinatura do Azure à sua
conta.
Um domínio gerenciado do Azure Active Directory Domain Services habilitado e configurado no locatário do
Azure AD.
Se necessário, o primeiro tutorial cria e configura um domínio gerenciado do Azure Active Directory
Domain Services.
Uma conta de usuário que é parte do domínio gerenciado.
Criar e conectar-se a uma VM do RHEL Linux

Se você tiver uma VM do Linux RHEL existente no Azure, conecte-se a ela usando o SSH e continue na próxima
etapa para começar a configurar a VM.
Se você precisar criar uma VM do RHEL Linux ou desejar criar uma VM de teste para uso com este artigo, você
pode usar um dos seguintes métodos:
Azure portal
CLI do Azure
PowerShell do Azure
Ao criar a VM, preste atenção às configurações de rede virtual para garantir que a VM possa se comunicar com
o domínio gerenciado:
Implante a VM na mesma rede virtual, ou emparelhada, na qual você habilitou Azure AD Domain Services.
Implante a VM em uma sub-rede diferente da Azure AD Domain Services domínio gerenciado.
Depois que a VM for implantada, siga as etapas para se conectar à VM usando SSH.
Configurar o arquivo de hosts
Para certificar-se de que o nome do host da VM esteja configurado corretamente para o domínio gerenciado,
edite o arquivo /etc/hosts e defina o nome do host:
sudo vi /etc/hosts
No arquivo hosts , atualize o endereço localhost . No exemplo a seguir:

aaddscontoso.com é o nome de domínio DNS do seu domínio gerenciado.
RHEL é o nome do host da sua VM RHEL que você está unindo ao domínio gerenciado.
Atualize esses nomes com seus próprios valores:
127.0.0.1 rhel rhel.aaddscontoso.com
Quando terminar, salve e saia do arquivo de hosts usando o :wq comando do editor.
Instalar os pacotes necessários

A VM precisa de alguns pacotes adicionais para unir a VM ao domínio gerenciado. Para instalar e configurar
esses pacotes, atualize e instale as ferramentas de ingresso no domínio usando o yum . Há algumas diferenças
entre o RHEL 7. x e o RHEL 6. x, portanto, use os comandos apropriados para sua versão do distribuição nas
seções restantes deste artigo.
RHEL 7
sudo yum install realmd sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools
RHEL 6
sudo yum install adcli sssd authconfig krb5-workstation
Ingressar VM no domínio gerenciado

Agora que os pacotes necessários estão instalados na VM, ingresse a VM no domínio gerenciado. Novamente,
use as etapas apropriadas para sua versão distribuição do RHEL.
RHEL 7
1. Use o realm discover comando para descobrir o domínio gerenciado. O exemplo a seguir descobre o
realm AADDSCONTOSO.com. Especifique seu próprio nome de domínio gerenciado em letras
MAIÚSCULAs:
sudo realm discover AADDSCONTOSO.COM
Se o realm discover comando não conseguir localizar seu domínio gerenciado, examine as seguintes
etapas de solução de problemas:
Verifique se o domínio está acessível da VM. Tente ping aaddscontoso.com ver se uma resposta
positiva é retornada.
Verifique se a VM está implantada na mesma rede virtual, ou emparelhada, na qual o domínio
gerenciado está disponível.
Confirme se as configurações do servidor DNS para a rede virtual foram atualizadas para apontar
para os controladores de domínio do domínio gerenciado.
2. Agora, inicialize o Kerberos usando o kinit comando. Especifique um usuário que faça parte do
domínio gerenciado. Se necessário, adicione uma conta de usuário a um grupo no Azure ad.
Novamente, o nome de domínio gerenciado deve ser inserido em letras MAIÚSCULAs. No exemplo a
seguir, a conta denominada contosoadmin@aaddscontoso.com é usada para inicializar o Kerberos. Insira sua
própria conta de usuário que faça parte do domínio gerenciado:
kinit contosoadmin@AADDSCONTOSO.COM
3. Por fim, ingresse a VM no domínio gerenciado usando o realm join comando. Use a mesma conta de
usuário que faz parte do domínio gerenciado que você especificou no comando anterior kinit , como
contosoadmin@AADDSCONTOSO.COM :
sudo realm join --verbose AADDSCONTOSO.COM -U 'contosoadmin@AADDSCONTOSO.COM'
Leva alguns minutos para unir a VM ao domínio gerenciado. A saída de exemplo a seguir mostra que a VM
ingressou com êxito no domínio gerenciado:
Successfully enrolled machine in realm
RHEL 6
1. Use o adcli info comando para descobrir o domínio gerenciado. O exemplo a seguir descobre o realm
ADDDSCONTOSO.com. Especifique seu próprio nome de domínio gerenciado em letras MAIÚSCULAs:
sudo adcli info aaddscontoso.com
Se o adcli info comando não conseguir localizar seu domínio gerenciado, examine as seguintes etapas
de solução de problemas:
2. Primeiro, ingresse no domínio usando o adcli join comando. esse comando também cria o keytab para
autenticar o computador. Use uma conta de usuário que faça parte do domínio gerenciado.
sudo adcli join aaddscontoso.com -U contosoadmin
3. Agora, configure o /ect/krb5.conf e crie os /etc/sssd/sssd.conf arquivos para usar o aaddscontoso.com

domínio Active Directory. Certifique-se de que AADDSCONTOSO.COM o seja substituído pelo seu próprio
nome de domínio:
Abra o /ect/krb5.conf arquivo com um editor:
sudo vi /etc/krb5.conf
Atualize o krb5.conf arquivo para corresponder ao seguinte exemplo:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = AADDSCONTOSO.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
AADDSCONTOSO.COM = {
kdc = AADDSCONTOSO.COM
admin_server = AADDSCONTOSO.COM
}
[domain_realm]
.AADDSCONTOSO.COM = AADDSCONTOSO.COM
AADDSCONTOSO.COM = AADDSCONTOSO.COM
Crie o /etc/sssd/sssd.conf arquivo:
sudo vi /etc/sssd/sssd.conf
Atualize o sssd.conf arquivo para corresponder ao seguinte exemplo:
[sssd]
services = nss, pam, ssh, autofs
config_file_version = 2
domains = AADDSCONTOSO.COM
[domain/AADDSCONTOSO.COM]
id_provider = ad
4. Verifique se /etc/sssd/sssd.conf as permissões são 600 e pertencem ao usuário raiz:
sudo chmod 600 /etc/sssd/sssd.conf

sudo chown root:root /etc/sssd/sssd.conf
5. Use authconfig para instruir a VM sobre a integração do Linux com o AD:
sudo authconfig --enablesssd --enablesssdauth --update
6. Inicie e habilite o serviço SSSD:
sudo service sssd start

sudo chkconfig sssd on
Se sua VM não puder concluir com êxito o processo de ingresso no domínio, verifique se o grupo de segurança
de rede da VM permite o tráfego de saída do Kerberos na porta TCP + UDP 464 para a sub-rede da rede virtual
para o domínio gerenciado.
Agora, verifique se você pode consultar informações do AD do usuário usando getent
sudo getent passwd contosoadmin
Permitir autenticação de senha para SSH

Por padrão, os usuários só podem entrar em uma VM usando a autenticação baseada em chave pública SSH.
Falha na autenticação baseada em senha. Quando você ingressa a VM em um domínio gerenciado, essas contas
de domínio precisam usar a autenticação baseada em senha. Atualize a configuração de SSH para permitir a
autenticação baseada em senha da seguinte maneira.
1. Abra o arquivo sshd_conf com um editor:
sudo vi /etc/ssh/sshd_config
2. Atualize a linha de PasswordAuthentication para Sim:
Quando terminar, salve e saia do arquivo de sshd_conf usando o :wq comando do editor.
3. Para aplicar as alterações e permitir que os usuários entrem usando uma senha, reinicie o serviço SSH
para a versão distribuição do RHEL:
RHEL 7
sudo systemctl restart sshd
RHEL 6
sudo service sshd restart
Conceder os privilégios sudo de grupo 'Administradores de

controlador de domínio do AAD'
Para conceder aos membros do grupo de Administradores do AAD DC privilégios administrativos na VM RHEL,
você adiciona uma entrada ao /etc/sudoers. Depois de adicionados, os membros do grupo de Administradores
do AAD DC podem usar o sudo comando na VM do RHEL.
1. Abra o arquivo do sudoers para edição:
sudo visudo
2. Adicione a seguinte entrada ao final do arquivo /etc/sudoers . O grupo de Administradores do AAD DC

contém espaço em branco no nome, portanto, inclua o caractere de escape de barra invertida no nome
do grupo. Adicione seu próprio nome de domínio, como aaddscontoso.com:
# Add 'AAD DC Administrators' group members as admins.
%AAD\ DC\ Administrators@aaddscontoso.com ALL=(ALL) NOPASSWD:ALL
Quando terminar, salve e saia do editor usando o :wq comando do editor.
Entrar na VM usando uma conta de domínio

Para verificar se a VM ingressou com êxito no domínio gerenciado, inicie uma nova conexão SSH usando uma
conta de usuário de domínio. Confirme se um diretório base foi criado e se a associação de grupo do domínio
foi aplicada.
1. Crie uma nova conexão SSH no console do. Use uma conta de domínio que pertença ao domínio
gerenciado usando o ssh -l comando, como contosoadmin@aaddscontoso.com e, em seguida, insira o
endereço da VM, como RHEL.aaddscontoso.com. Se você usar o Azure Cloud Shell, use o endereço IP
público da VM em vez do nome DNS interno.
ssh -l contosoadmin@AADDSCONTOSO.com rhel.aaddscontoso.com
2. Quando você se conectou com êxito à VM, verifique se o diretório base foi inicializado corretamente:
pwd
Você deve estar no diretório /Home com seu próprio diretório que corresponda à conta de usuário.
3. Agora, verifique se as associações de grupo estão sendo resolvidas corretamente:
id
Você deve ver as associações de grupo do domínio gerenciado.

4. Se você entrou na VM como um membro do grupo de Administradores do controlador de domínio do
AAD , verifique se você pode usar corretamente o sudo comando:
sudo yum update
Próximas etapas
Se você tiver problemas para conectar a VM ao domínio gerenciado ou entrar com uma conta de domínio,
consulte Solucionando problemas de ingresso no domínio.
Unir uma máquina virtual CentOS Linux a um Azure
Active Directory Domain Services domínio
gerenciado
VM.
Este artigo mostra como unir uma VM do CentOS Linux a um domínio gerenciado.
Pré-requisitos
somente em nuvem.
conta.
Azure AD.
Domain Services.
Uma conta de usuário que faz parte do domínio gerenciado.
Criar e conectar-se a uma VM CentOS Linux

Se você tiver uma VM CentOS Linux existente no Azure, conecte-se a ela usando o SSH e continue na próxima
Se você precisar criar uma VM CentOS Linux ou desejar criar uma VM de teste para uso com este artigo, você
pode usar um dos seguintes métodos:
Azure portal
CLI do Azure
PowerShell do Azure
Implante a VM em uma sub-rede diferente do seu domínio gerenciado.
sudo vi /etc/hosts

CentOS é o nome do host da sua VM CentOS que você está unindo ao domínio gerenciado.
127.0.0.1 centos.aaddscontoso.com centos

esses pacotes, atualize e instale as ferramentas de ingresso no domínio usando yum :
sudo yum install realmd sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools

Agora que os pacotes necessários estão instalados na VM, ingresse a VM no domínio gerenciado.
MAIÚSCULAs:
kinit contosoadmin@AADDSCONTOSO.COM
sudo realm join --verbose AADDSCONTOSO.COM -U 'contosoadmin@AADDSCONTOSO.COM'

3. Para aplicar as alterações e permitir que os usuários entrem usando uma senha, reinicie o serviço SSH:
sudo systemctl restart sshd
Conceder os privilégios sudo de grupo 'Administradores de

controlador de domínio do AAD'
Para conceder aos membros do grupo de Administradores do AAD DC privilégios administrativos na VM
CentOS, você adiciona uma entrada ao /etc/sudoers. Depois de adicionados, os membros do grupo de
Administradores do AAD DC podem usar o sudo comando na VM CentOS.
sudo visudo
2. Adicione a seguinte entrada ao final do arquivo /etc/sudoers . O grupo de Administradores do AAD DC
contém espaço em branco no nome, portanto, inclua o caractere de escape de barra invertida no nome
do grupo. Adicione seu próprio nome de domínio, como aaddscontoso.com:

%AAD\ DC\ Administrators@aaddscontoso.com ALL=(ALL) NOPASSWD:ALL
Quando terminar, salve e saia do editor usando o :wq comando do editor.

foi aplicada.
endereço da VM, como CentOS.aaddscontoso.com. Se você usar o Azure Cloud Shell, use o endereço IP
ssh -l contosoadmin@AADDSCONTOSO.com centos.aaddscontoso.com
pwd
id

sudo yum update
Próximas etapas
Ingressar uma máquina virtual Ubuntu Linux em um
domínio Azure Active Directory Domain Services
gerenciado
VM.
Este artigo mostra como unir uma VM Ubuntu Linux a um domínio gerenciado.
Pré-requisitos
somente em nuvem.
conta.
Azure AD.
Domain Services.
Uma conta de usuário que é parte do domínio gerenciado.
Criar e conectar-se a uma VM Ubuntu Linux

Se você tiver uma VM Ubuntu Linux existente no Azure, conecte-se a ela usando o SSH e continue na próxima
Se você precisar criar uma VM Ubuntu Linux ou desejar criar uma VM de teste para uso com este artigo, poderá
usar um dos seguintes métodos:
Azure portal
CLI do Azure
PowerShell do Azure
Implante a VM em uma sub-rede diferente da Azure AD Domain Services domínio gerenciado.
sudo vi /etc/hosts

o Ubuntu é o nome do host da sua VM do Ubuntu que você está unindo ao domínio gerenciado.
127.0.0.1 ubuntu.aaddscontoso.com ubuntu

esses pacotes, atualize e instale as ferramentas de ingresso no domínio usando o apt-get
Durante a instalação do Kerberos, o pacote krb5-User solicita o nome do realm em letras maiúsculas. Por
exemplo, se o nome do seu domínio gerenciado for aaddscontoso.com, insira AADDSCONTOSO.com como o
realm. A instalação grava as [realm] [domain_realm] seções e no arquivo de configuração /etc/krb5.conf .
Certifique-se de especificar o realm em letras MAIÚSCULAs:
sudo apt-get update

sudo apt-get install krb5-user samba sssd sssd-tools libnss-sss libpam-sss ntp ntpdate realmd adcli
Configurar protocolo NTP (NTP)

Para que a comunicação de domínio funcione corretamente, a data e hora da sua VM do Ubuntu devem
sincronizar com o domínio gerenciado. Adicione o nome de host NTP do seu domínio gerenciado ao arquivo
/etc/ntp.conf .
1. Abra o arquivo NTP. conf com um editor:
sudo vi /etc/ntp.conf
2. No arquivo NTP. conf , crie uma linha para adicionar o nome DNS do seu domínio gerenciado. No
exemplo a seguir, uma entrada para aaddscontoso.com é adicionada. Use seu próprio nome DNS:
server aaddscontoso.com
Quando terminar, salve e saia do arquivo NTP. conf usando o :wq comando do editor.
3. Para certificar-se de que a VM está sincronizada com o domínio gerenciado, as seguintes etapas são
necessárias:
Parar o servidor NTP
Atualizar a data e a hora do domínio gerenciado
Iniciar o serviço NTP
Execute os comandos a seguir para concluir essas etapas. Use seu próprio nome DNS com o ntpdate
comando:
sudo systemctl stop ntp

sudo ntpdate aaddscontoso.com
sudo systemctl start ntp

Agora que os pacotes necessários estão instalados na VM e o NTP está configurado, ingresse a VM no domínio
gerenciado.
MAIÚSCULAs:
kinit -V contosoadmin@AADDSCONTOSO.COM
sudo realm join --verbose AADDSCONTOSO.COM -U 'contosoadmin@AADDSCONTOSO.COM' --install=/
Se você recebeu o erro falha de GSS não especificada. O código secundário pode fornecer mais informações
(servidor não encontrado no banco de dados Kerberos), abra o arquivo /etc/krb5.conf e adicione o seguinte
código na [libdefaults] seção e tente novamente:
rdns=false
Atualizar a configuração do SSSD

Um dos pacotes instalados em uma etapa anterior era para o daemon dos serviços de segurança do sistema
(SSSD). Quando um usuário tenta entrar em uma VM usando credenciais de domínio, o SSSD transmite a
solicitação para um provedor de autenticação. Nesse cenário, o SSSD usa o Azure AD DS para autenticar a
solicitação.
1. Abra o arquivo SSSD. conf com um editor:
sudo vi /etc/sssd/sssd.conf
2. Comente a linha para use_fully_qualified_names da seguinte maneira:
# use_fully_qualified_names = True
Quando terminar, salve e saia do arquivo SSSD. conf usando o :wq comando do editor.
3. Para aplicar a alteração, reinicie o serviço SSSD:
sudo systemctl restart sssd
Definir configurações de conta de usuário e grupo

Com a VM ingressada no domínio gerenciado e configurada para autenticação, há algumas opções de
configuração de usuário a serem concluídas. Essas alterações de configuração incluem a permissão de
autenticação baseada em senha e a criação automática de diretórios base na VM local quando os usuários do
domínio entram pela primeira vez.
3. Para aplicar as alterações e permitir que os usuários entrem usando uma senha, reinicie o serviço SSH:
sudo systemctl restart ssh
Configurar a criação automática do diretório base

Para habilitar a criação automática do diretório base quando um usuário entrar pela primeira vez, conclua as
seguintes etapas:
1. Abra o arquivo /etc/pam.d/common-Session em um editor:
sudo vi /etc/pam.d/common-session
2. Adicione a seguinte linha a este arquivo abaixo da linha session optional pam_sss.so :
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
Quando terminar, salve e saia do arquivo de sessão comum usando o :wq comando do editor.
Conceder os privilégios sudo de grupo 'Administradores de controlador de domínio do AAD'
Para conceder aos membros do grupo de Administradores do AAD DC privilégios administrativos na VM do
Ubuntu, você adiciona uma entrada ao /etc/sudoers. Depois de adicionados, os membros do grupo de
Administradores do AAD DC podem usar o sudo comando na VM do Ubuntu.
sudo visudo
2. Adicione a seguinte entrada ao final do arquivo /etc/sudoers :

%AAD\ DC\ Administrators ALL=(ALL) NOPASSWD:ALL
Quando terminar, salve e saia do editor usando o Ctrl-X comando.

foi aplicada.
endereço da VM, como Ubuntu.aaddscontoso.com. Se você usar o Azure Cloud Shell, use o endereço IP
ssh -l contosoadmin@AADDSCONTOSO.com ubuntu.aaddscontoso.com
pwd
id

sudo apt-get update
Próximas etapas
Configurar identidades gerenciadas para recursos
do Azure em uma VM usando o portal do Azure
Identidades gerenciadas para recursos do Azure é um recurso do Azure Active Directory. Cada um dos serviços
do Azure que dão suporte a identidades gerenciadas para recursos do Azure está sujeito à própria linha do
tempo. Não deixe de examinar o status de disponibilidade das identidades gerenciadas do seu recurso e os
problemas conhecidos antes de começar.
As identidades gerenciadas dos recursos do Azure fornecem aos serviços do Azure uma identidade gerenciada
automaticamente no Azure Active Directory. Você pode usar essa identidade para autenticar em qualquer
serviço que dá suporte à autenticação do Azure AD, incluindo o Key Vault, sem ter as credenciais no seu código.
Neste artigo, você aprende como habilitar e desabilitar identidades gerenciadas atribuídas ao usuário e ao
sistema para uma VM (Máquina Virtual) do Azure, usando o portal do Azure.
Pré-requisitos
Se você não estiver familiarizado com identidades gerenciadas para recursos do Azure, confira a seção de
visão geral.
Se você ainda não tiver uma conta do Azure, inscreva-se em uma conta gratuita antes de continuar.
Identidade gerenciada atribuída pelo sistema

Nesta seção, você aprende como habilitar e desabilitar a identidade gerenciada atribuída ao sistema para VM
usando o portal do Azure.
Habilitar identidade gerenciada atribuída ao sistema durante a criação de uma VM
Para habilitar a identidade gerenciada atribuída pelo sistema em uma VM durante sua criação, sua conta precisa
da atribuição de função Colaboração da Máquina Virtual. Nenhuma atribuição adicional de função de diretório
do Azure Active Directory é necessária.
Na guia Gerenciamento da seção Identidade , mude Identidade do ser viço gerenciado para Em .
Consulte os seguintes Inícios Rápidos para criar uma VM:
Criar uma máquina virtual do Windows com o Portal do Azure
Habilitar a identidade gerenciada atribuída ao sistema em uma VM existente
Para habilitar a identidade gerenciada atribuída ao sistema em uma VM que foi originalmente provisionada sem
ela, a conta precisará da atribuição de função Colaborador da Máquina Virtual. Nenhuma atribuição adicional de
função de diretório do Azure Active Directory é necessária.
1. Entre no portal do Azure usando uma conta associada à assinatura do Azure que contenha a VM.
2. Navegue até a Máquina Virtual desejada e selecione Identidade .
3. Em Sistema atribuído , Status , selecione Ativado e, em seguida, clique em Salvar :
Remover identidade gerenciada atribuída ao sistema de uma VM

Para remover a identidade gerenciada atribuída pelo sistema de uma VM, sua conta precisa da atribuição de
função Atribuída do Virtual Machine. Nenhuma atribuição adicional de função de diretório do Azure Active
Directory é necessária.
Se você tiver uma Máquina Virtual que não precisa mais de identidade gerenciada atribuída ao sistema:
2. Navegue até a Máquina Virtual desejada e selecione Identidade .
3. Em Sistema atribuído , Status , selecione Desativado e, em seguida, clique em Salvar :
Identidade gerenciada atribuída pelo usuário

Nesta seção, você aprende como adicionar e remover uma identidade gerenciada atribuída ao usuário de uma
VM usando o portal do Azure.
Atribuir uma identidade atribuída ao usuário durante a criação de uma VM
Para atribuir uma identidade atribuída pelo usuário a uma VM, sua conta precisa das atribuições de função
Contribuidor de Máquina Virtual e Operador de Identidade Gerenciada. Nenhuma atribuição adicional de
Atualmente, o portal do Azure não dá suporte à atribuição de uma identidade gerenciada atribuída ao usuário
durante a criação de uma VM. Em vez disso, consulte um dos seguintes artigos de Início Rápido de criação de
VM para primeiro criar uma VM e, em seguida, vá para a próxima seção para obter detalhes sobre como atribuir
uma identidade gerenciada atribuída ao usuário à VM:
Criar uma máquina virtual do Windows com o Portal do Azure
Atribuir uma identidade gerenciada atribuída ao usuário a uma VM existente
2. Navegue até a VM desejada e clique em Identidade , Usuário atribuído e, em seguida, +Adicionar .
3. Clique na identidade atribuída ao usuário que você quer adicionar à VM e, em seguida, clique em
Adicionar .
Remover uma identidade gerenciada atribuída ao usuário de uma VM

Para remover uma identidade atribuída pelo usuário de uma VM, sua conta precisa da atribuição de função
Atribuído do Virtual Machine. Nenhuma atribuição adicional de função de diretório do Azure Active Directory é
necessária.
2. Navegue até a VM desejada e clique em Identidade , Usuário atribuído , clique no nome da identidade
gerenciada atribuída ao usuário que deseja excluir e, em seguida, clique em Remover (clique em Sim no
painel de confirmação).
Próximas etapas
Usando o portal do Azure, conceda acesso de identidade gerenciada de uma VM do Azure a outro recurso do
Azure.
do Azure em uma VM do Azure usando a CLI do
Azure
Neste artigo, usando a CLI do Azure, você aprenderá como executar as seguintes identidades gerenciadas para
operações de recursos do Azure em uma VM do Azure:
Habilitar e desabilitar a identidade gerenciada atribuída pelo sistema em uma VM do Azure
Adicionar e remover uma identidade gerenciada atribuída pelo usuário em uma VM do Azure
Pré-requisitos
Se você não estiver familiarizado com as identidades gerenciadas dos recursos do Azure, confira O que são
as identidades gerenciadas dos recursos do Azure?. Para saber mais sobre tipos de identidade gerenciada
atribuída pelo sistema e pelo usuário, confira Tipos de identidade gerenciada.


Nesta seção, você aprenderá como habilitar e desabilitar a identidade gerenciada atribuída ao sistema em uma
VM do Azure usando a CLI do Azure.
Ativar identidade gerenciada atribuída pelo sistema durante a criação de uma VM do Azure
Para criar uma VM do Azure com a identidade gerenciada atribuída ao sistema habilitada, a conta precisará da
atribuição de função Colaborador da Máquina Virtual. Nenhuma atribuição adicional de função de diretório do
Azure Active Directory é necessária.
1. Criar um grupo de recursos para contenção e implantação de VM e seus recursos relacionados usando az
group create. Ignore esta etapa, se você já tiver o grupo de recursos que deseja usar:
2. Crie uma VM usando az vm create. O exemplo a seguir cria uma VM nomeada myVM com uma
identidade gerenciada atribuída ao sistema, conforme solicitado pelo parâmetro --assign-identity . Os
parâmetros --admin-username e --admin-password especificam o nome de usuário e a senha do usuário
administrativo para a entrada na máquina virtual. Atualize esses valores como adequado ao seu
ambiente:
az vm create --resource-group myResourceGroup --name myVM --image win2016datacenter --generate-ssh-

keys --assign-identity --admin-username azureuser --admin-password myPassword12
Habilitar identidade gerenciada atribuída ao sistema em uma VM do Azure existente

Para habilitar a identidade gerenciada atribuída pelo sistema em uma VM, sua conta precisa da atribuição de
função Colaboração da Máquina Virtual. Nenhuma atribuição adicional de função de diretório do Azure Active
1. Se você estiver usando a CLI do Azure em um console local, primeiro entre no Azure usando o logon az.
Use uma conta que esteja associada com uma assinatura do Azure que contenha uma VM.
az login
2. Use az vm identity assign com identity assign para habilitar a identidade atribuída ao sistema para
uma VM existente:
az vm identity assign -g myResourceGroup -n myVm
Desabilitar uma identidade atribuída ao sistema de uma VM do Azure

Para desabilitar a identidade gerenciada atribuída ao sistema em uma VM, a conta precisará da atribuição de
função Colaborador da Máquina Virtual. Nenhuma atribuição adicional de função de diretório do Azure Active
Se você tiver uma Máquina Virtual que não precisa mais da identidade atribuída ao sistema, mas ainda precisar
de identidades atribuídas ao usuário, use o comando a seguir:
az vm update -n myVM -g myResourceGroup --set identity.type='UserAssigned'
Se você tiver uma máquina virtual que não precisa mais da identidade atribuída ao sistema e não tiver
identidades atribuídas ao usuário, use o comando a seguir:
NOTE
O valor none diferencia maiúsculas de minúsculas. Deve estar em letras minúsculas.
az vm update -n myVM -g myResourceGroup --set identity.type="none"

Nesta seção, você aprenderá como adicionar e remover uma identidade gerenciada atribuída ao usuário de uma
VM do Azure usando a CLI do Azure. Se você criar sua identidade gerenciada atribuída ao usuário em um RG
diferente da VM. Você precisará usar a URL da sua identidade gerenciada para atribuí-la à VM. ou seja, --
identities
"/subscriptions//resourcegroups//providers/Microsoft.ManagedIdentity/userAssignedIdentities/<NOME_DA_ID
_ATRIBUÍDA_AO_USUÁRIO>"
Atribuir uma identidade gerenciada atribuída pelo usuário durante a criação de uma VM do Azure
Para atribuir uma identidade atribuída pelo usuário a uma VM durante sua criação, sua conta precisa das
atribuições de função Contribuinte virtual e Operador de identidade gerenciada. Nenhuma atribuição adicional
de função de diretório do Azure Active Directory é necessária.
1. Se você já tiver um grupo de recursos e quiser usá-lo, ignore esta etapa. Crie um grupo de recursos para
independência e implantação da identidade gerenciada atribuída ao usuário, usando az group create .
Substitua os valores de parâmetro <RESOURCE GROUP> e <LOCATION> pelos seus próprios valores. :
az group create --name <RESOURCE GROUP> --location <LOCATION>
2. Crie uma identidade gerenciada atribuída ao usuário usando az identity create. O parâmetro -g
especifica o grupo de recursos em que a identidade gerenciada atribuída pelo usuário é criada e o
parâmetro -n especifica o nome.
IMPORTANT
Ao criar identidades atribuídas pelo usuário, somente caracteres alfanuméricos (0-9, a-z, A-Z), o sublinhado (_) e o
hífen (-) são compatíveis. Além disso, o nome deve ter no mínimo 3 caracteres e até 128 caracteres para que a
atribuição à VM/VMSS funcione corretamente. Procure novamente por atualizações. Para mais informações,
consulte Perguntas frequentes e problemas conhecidos
az identity create -g myResourceGroup -n myUserAssignedIdentity
A resposta contém detalhes para a identidade gerenciada atribuída ao usuário criada, semelhante à
seguinte. O valor da ID do recurso atribuído à identidade gerenciada atribuída ao usuário será usado na
etapa a seguir.
{
"clientId": "73444643-8088-4d70-9532-c3a0fdc190fz",
"clientSecretUrl": "https://control-westcentralus.identity.azure.net/subscriptions/<SUBSCRIPTON
ID>/resourcegroups/<RESOURCE
GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<myUserAssignedIdentity>/credential
s?tid=5678&oid=9012&aid=73444643-8088-4d70-9532-c3a0fdc190fz",
"id": "/subscriptions/<SUBSCRIPTON ID>/resourcegroups/<RESOURCE
GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<USER ASSIGNED IDENTITY NAME>",
"location": "westcentralus",
"name": "<USER ASSIGNED IDENTITY NAME>",
"principalId": "e5fdfdc1-ed84-4d48-8551-fe9fb9dedfll",
"resourceGroup": "<RESOURCE GROUP>",
"tags": {},
"tenantId": "733a8f0e-ec41-4e69-8ad8-971fc4b533bl",
"type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}
3. Crie uma VM usando az vm create. O exemplo a seguir cria uma VM associada à nova identidade
atribuída ao usuário, conforme especificado pelo parâmetro --assign-identity . Substitua os valores dos
parâmetros <RESOURCE GROUP> , <VM NAME> , <USER NAME> , <PASSWORD> e <USER ASSIGNED IDENTITY NAME>
pelos seus próprios valores.
az vm create --resource-group <RESOURCE GROUP> --name <VM NAME> --image UbuntuLTS --admin-username
<USER NAME> --admin-password <PASSWORD> --assign-identity <USER ASSIGNED IDENTITY NAME>
Atribuir uma identidade gerenciada usuário atribuído a uma VM existente do Azure

1. Crie uma identidade atribuída pelo usuário usando az identity create. O parâmetro -g especifica o grupo
de recursos em que a identidade atribuída ao usuário é criada e o parâmetro -n especifica o nome.
Substitua os valores de parâmetro <RESOURCE GROUP> e <USER ASSIGNED IDENTITY NAME> pelos seus
próprios valores:
IMPORTANT
Atualmente, não há suporte para criação de identidades gerenciadas atribuídas ao usuário com caracteres
especiais (ou seja, sublinhado) no nome. Use caracteres alfanuméricos. Procure novamente por atualizações. Para
obter mais informações, consulte Perguntas frequentes e problemas conhecidos
az identity create -g <RESOURCE GROUP> -n <USER ASSIGNED IDENTITY NAME>
A resposta contém detalhes para a identidade gerenciada atribuída ao usuário criada, semelhante à
seguinte.
{
"clientId": "73444643-8088-4d70-9532-c3a0fdc190fz",
"clientSecretUrl": "https://control-westcentralus.identity.azure.net/subscriptions/<SUBSCRIPTON
ID>/resourcegroups/<RESOURCE GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<USER
ASSIGNED IDENTITY NAME>/credentials?tid=5678&oid=9012&aid=73444643-8088-4d70-9532-c3a0fdc190fz",
"id": "/subscriptions/<SUBSCRIPTON ID>/resourcegroups/<RESOURCE
GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<USER ASSIGNED IDENTITY NAME>",
"location": "westcentralus",
"name": "<USER ASSIGNED IDENTITY NAME>",
"principalId": "e5fdfdc1-ed84-4d48-8551-fe9fb9dedfll",
"resourceGroup": "<RESOURCE GROUP>",
"tags": {},
"tenantId": "733a8f0e-ec41-4e69-8ad8-971fc4b533bl",
"type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}
2. Atribua a identidade atribuída ao usuário à VM usando az vm identity assign. Substitua os valores de

parâmetro <RESOURCE GROUP> e <VM NAME> pelos seus próprios valores. O <USER ASSIGNED IDENTITY NAME>
é a propriedade name do recurso de identidade gerenciada atribuída ao usuário, conforme criado na
etapa anterior. Se você criar sua identidade gerenciada atribuída ao usuário em um RG diferente da VM.
Você precisará usar a URL da sua identidade gerenciada.
az vm identity assign -g <RESOURCE GROUP> -n <VM NAME> --identities <USER ASSIGNED IDENTITY>
Remover uma identidade gerenciada atribuída pelo usuário de uma VM do Azure

Para remover uma identidade atribuída ao usuário a uma VM, a conta precisará da atribuição de função
Colaborador da Máquina Virtual.
Se essa for a única identidade gerenciada atribuída ao usuário atribuída à máquina virtual, UserAssigned será
removido do valor do tipo de identidade. Substitua os valores de parâmetro <RESOURCE GROUP> e <VM NAME>
pelos seus próprios valores. O <USER ASSIGNED IDENTITY> será a propriedade name da identidade atribuída ao
usuário, que pode ser localizada na seção de identidade da máquina virtual usando az vm identity show :
az vm identity remove -g <RESOURCE GROUP> -n <VM NAME> --identities <USER ASSIGNED IDENTITY>
Se a VM não tiver uma identidade gerenciada atribuída ao sistema e você quiser remover todas as identidades
atribuídas ao usuário, use o comando a seguir:
NOTE
O valor none diferencia maiúsculas de minúsculas. Deve estar em letras minúsculas.
az vm update -n myVM -g myResourceGroup --set identity.type="none" identity.userAssignedIdentities=null
Se a VM tiver identidades atribuídas ao sistema e atribuídas ao usuário, você poderá remover todas as
identidades atribuídas ao usuário, alternando para usar somente atribuídas ao sistema. Use o seguinte
comando:
az vm update -n myVM -g myResourceGroup --set identity.type='SystemAssigned'

identity.userAssignedIdentities=null
Próximas etapas
Para os guias de início rápido completos sobre VM do Azure, consulte:
Crie máquinas virtuais Windows com o CLI
Crie máquinas virtuais Linux com o CLI
do Azure em uma VM do Azure usando PowerShell
Neste artigo, usando o PowerShell, você aprenderá como executar as seguintes identidades gerenciadas para
operações de recursos do Azure em uma VM do Azure.
NOTE
Este artigo foi atualizado para usar o módulo Az PowerShell do Azure. O módulo Az PowerShell é o módulo do PowerShell
recomendado para interagir com o Azure. Para começar a usar o módulo do Az PowerShell, confira Instalar o Azure
PowerShell. Para saber como migrar para o módulo Az PowerShell, confira Migrar o Azure PowerShell do AzureRM para o
Az.
Pré-requisitos
Se você não estiver familiarizado com identidades gerenciadas para recursos do Azure, confira a seção de
visão geral. Revise a diferença entre uma identidade gerenciada atribuída ao sistema e atribuída
ao usuário .
Para executar os scripts de exemplo, você tem duas opções:
Use o Azure Cloud Shell, que você pode abrir usando o botão Experimentar no canto superior direito
dos blocos de código.
Execute os scripts localmente instalando a versão mais recente do Azure PowerShell e, em seguida,
entre no Azure usando Connect-AzAccount .

Nesta seção, você aprenderá como habilitar e desabilitar a identidade gerenciada atribuída ao sistema usando o
Azure PowerShell.
1. Consulte um dos guias de início rápido de VM do Azure a seguir, concluindo apenas as seções
necessárias ("Entrar no Azure", "Criar o grupo de recursos", "Criar grupo de rede", "Criar a máquina
virtual").
Quando você chegar à seção "Criar a VM", faça uma pequena modificação na sintaxe do cmdlet New-
AzVMConfig. Certifique-se de adicionar um parâmetro -IdentityType SystemAssigned para provisionar a
VM com a identidade atribuída ao sistema habilitada, por exemplo:
$vmConfig = New-AzVMConfig -VMName myVM -IdentityType SystemAssigned ...
Criar uma máquina virtual do Windows usando o PowerShell

Crie uma Máquina Virtual do Linux usando o PowerShell
Habilitar identidade gerenciada atribuída ao sistema em uma VM do Azure existente
1. Recupere as propriedades da VM usando o cmdlet Get-AzVM . Em seguida, para habilitar uma identidade
gerenciada atribuída ao sistema, use a opção -IdentityType no cmdlet Update-AzVM:

Update-AzVM -ResourceGroupName myResourceGroup -VM $vm -IdentityType SystemAssigned
Adicionar uma identidade atribuída pelo sistema de uma VM a um grupo

Depois de habilitar a identidade atribuída pelo sistema em uma VM, você pode adicioná-la a um grupo. O
procedimento a seguir adiciona uma identidade atribuída pelo sistema de uma VM a um grupo.
1. Recupere e tome nota do ObjectID (conforme especificado no campo Id dos valores retornados) da
entidade de serviço da VM:
Get-AzADServicePrincipal -displayname "myVM"
2. Recupere e tome nota do ObjectID (conforme especificado no campo Id dos valores retornados) do
grupo:
Get-AzADGroup -searchstring "myGroup"
3. Adicionar a entidade de serviço da VM ao grupo:
Add-AzureADGroupMember -ObjectId "<objectID of group>" -RefObjectId "<object id of VM service

principal>"
Desativar identidade gerenciada atribuída pelo sistema de uma VM do

Azure
Se você tiver uma máquina virtual que não precise mais da identidade gerenciada atribuída ao sistema, mas
ainda precisar de identidades gerenciadas atribuídas ao usuário, use o seguinte cmdlet:
1. Recupere as propriedades da VM usando o cmdlet Get-AzVM e defina o parâmetro -IdentityType como
UserAssigned :
Update-AzVm -ResourceGroupName myResourceGroup -VM $vm -IdentityType "UserAssigned"
Se você tiver uma máquina virtual que não precise mais da identidade gerenciada atribuída ao sistema e não
tiver identidades gerenciadas atribuídas ao usuário, use os comandos a seguir:

Update-AzVm -ResourceGroupName myResourceGroup -VM $vm -IdentityType None

Nesta seção, você aprenderá como adicionar e remover uma identidade atribuída ao usuário de uma VM
usando Azure PowerShell.
Atribuir uma identidade gerenciada atribuída ao usuário a uma VM durante a criação
1. Consulte um dos guias de início rápido de VM do Azure a seguir, concluindo apenas as seções
necessárias ("Entrar no Azure", "Criar o grupo de recursos", "Criar grupo de rede", "Criar a máquina
virtual").
Quando você chegar à seção "Criar a VM", faça uma pequena modificação na New-AzVMConfig sintaxe do
cmdlet. Adicione os parâmetros -IdentityType UserAssigned e -IdentityID para provisionar a VM com
uma identidade atribuída ao usuário. Substitua <VM NAME> , <SUBSCRIPTION ID> , <RESROURCE GROUP> , e
<USER ASSIGNED IDENTITY NAME> pelos seus próprios valores. Por exemplo:
$vmConfig = New-AzVMConfig -VMName <VM NAME> -IdentityType UserAssigned -IdentityID

"/subscriptions/<SUBSCRIPTION ID>/resourcegroups/<RESROURCE
GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<USER ASSIGNED IDENTITY NAME>..."
Criar uma máquina virtual do Windows usando o PowerShell

Crie uma Máquina Virtual do Linux usando o PowerShell
1. Crie uma identidade gerenciada atribuída ao usuário, usando o cmdlet New-AzUserAssignedIdentity.
Observe o Id na saída porque isso será necessário na próxima etapa.
IMPORTANT
A criação de identidades gerenciadas atribuídas ao usuário dá suporte apenas a caracteres alfanuméricos,
sublinhado e hífen (0-9 ou a-z ou A-Z, _ ou -). Além disso, o nome deve ter um limite de 3 a 128 caracteres para
que a atribuição a VM/VMSS funcione corretamente. Para mais informações, consulte Perguntas frequentes e
problemas conhecidos
New-AzUserAssignedIdentity -ResourceGroupName <RESOURCEGROUP> -Name <USER ASSIGNED IDENTITY NAME>

2. Recupere as propriedades da VM usando o cmdlet Get-AzVM . Em seguida, para atribuir uma identidade
gerenciada atribuída ao usuário à VM do Azure, use a opção -IdentityType e -IdentityID no cmdlet
Update-AzVM. O valor para o -IdentityId parâmetro é o Id você anotou na etapa anterior. Substitua, , , e
pelos seus próprios valores.
WARNING
Para manter qualquer identidades gerenciadas anteriormente atribuído ao usuário atribuídas à VM, consulte o
Identity propriedade do objeto da VM (por exemplo, $vm.Identity ). Se qualquer usuário atribuído
identidades gerenciadas são retornadas, incluí-los no comando a seguir, juntamente com o novo usuário atribuído
a identidade gerenciada que você deseja atribuir à VM.
$vm = Get-AzVM -ResourceGroupName <RESOURCE GROUP> -Name <VM NAME>

Update-AzVM -ResourceGroupName <RESOURCE GROUP> -VM $vm -IdentityType UserAssigned -IdentityID
"/subscriptions/<SUBSCRIPTION ID>/resourcegroups/<RESROURCE
GROUP>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<USER ASSIGNED IDENTITY NAME>"

Se a VM tiver várias identidades gerenciadas atribuídas ao usuário, será possível remover todas, exceto a última,
usando os seguintes comandos. Substitua os valores de parâmetro <RESOURCE GROUP> e <VM NAME> pelos seus
próprios valores. O <USER ASSIGNED IDENTITY NAME> é a propriedade do nome da identidade gerenciada atribuída
ao usuário, que deve permanecer na VM. Essas informações podem ser encontradas ao consultar o Identity
propriedade do objeto da VM. Por exemplo $vm.Identity :
$vm = Get-AzVm -ResourceGroupName myResourceGroup -Name myVm

Update-AzVm -ResourceGroupName myResourceGroup -VirtualMachine $vm -IdentityType UserAssigned -IdentityID
<USER ASSIGNED IDENTITY NAME>
Se a VM não tiver uma identidade gerenciada atribuída ao sistema e você quiser remover todas as identidades
gerenciadas atribuídas ao usuário, use o comando a seguir:

Update-AzVm -ResourceGroupName myResourceGroup -VM $vm -IdentityType None
Se a VM tiver ambas as identidades gerenciadas atribuídas ao sistema e atribuídas ao usuário, será possível
remover todas as identidades gerenciadas atribuídas ao usuário, alternando para usar apenas as identidades
gerenciadas atribuídas ao sistema.

Update-AzVm -ResourceGroupName myResourceGroup -VirtualMachine $vm -IdentityType "SystemAssigned"
Próximas etapas
Para os guias de início rápido completos sobre VM do Azure, consulte:
Aprenda rapidamente a criar máquinas virtuais Windows com o PowerShell
Aprenda rapidamente a criar máquinas virtuais Linux com o PowerShell
do Azure em uma VM do Azure usando modelos
Neste artigo, usando o modelo de implantação do Azure Resource Manager, você aprende como executar as
seguintes identidades gerenciadas para operações de recursos do Azure em uma VM do Azure:
Pré-requisitos
Se você não estiver familiarizado com o uso do modelo de implantação do Azure Resource Manager, confira
a seção de visão geral. Revise a diferença entre uma identidade gerenciada atribuída ao sistema e
atribuída ao usuário .

Assim como com o Portal do Azure e o script, os modelos do Azure Resource Manager permitem implantar
recursos novos ou modificados definidos por um grupo de recursos do Azure. Há várias opções disponíveis
para a edição e a implantação do modelo, tanto locais quanto baseadas em portal, incluindo:
Usar um modelo personalizado do Azure Marketplace, que permite a criação de um modelo do zero ou usar
como base um modelo comum existente ou um modelo de início rápido.
Derivar de um grupo de recursos existente, exportando um modelo da implantação original ou do estado
atual da implantação.
Usar um editor JSON local (por exemplo, VS Code), depois carregar e implantar usando o PowerShell ou a
CLI.
Usar o projeto do Grupo de Recursos do Azure do Visual Studio para criar e implantar um modelo.
Independentemente da opção escolhido, a sintaxe do modelo será a mesma durante a implantação inicial e a
reimplantação. Habilitar uma identidade gerenciada atribuída ao usuário ou ao sistema em uma VM nova ou
existente é feita da mesma maneira. Além disso, por padrão, o Azure Resource Manager faz uma atualização
incremental para implantações.

Nesta seção, você habilitará e desabilitará uma identidade gerenciada atribuída ao sistema usando um modelo
Habilitar identidade gerenciada atribuída ao sistema durante a criação de uma VM do Azure ou em uma VM
existente
Para habilitar a identidade gerenciada atribuída pelo sistema em uma VM, sua conta precisa da atribuição de
função Colaboração da Máquina Virtual. Nenhuma atribuição adicional de função de diretório do Azure Active
1. Se você entrar no Azure localmente ou por meio do portal do Azure, use uma conta que esteja associada
com a assinatura do Azure que contenha a máquina virtual.
2. Para habilitar a identidade gerenciada atribuída ao sistema, carregue o modelo em um editor, localize o
recurso Microsoft.Compute/virtualMachines de interesse dentro da seção resources e adicione a
propriedade "identity" no mesmo nível que a propriedade
"type": "Microsoft.Compute/virtualMachines" . Use a seguinte sintaxe:
"identity": {
"type": "SystemAssigned"
},
3. Quando você terminar, as seguintes seções deverão ser adicionadas à seção resource do modelo e ela
será semelhante à seguinte:
"resources": [
{
//other resource provider properties...
"apiVersion": "2018-06-01",
"identity": {
"type": "SystemAssigned",
},
},
//The following appears only if you provisioned the optional VM extension (to be deprecated)
{
"name": "[concat(variables('vmName'),'/ManagedIdentityExtensionForWindows')]",
"apiVersion": "2018-06-01",
"dependsOn": [
],
"properties": {
"publisher": "Microsoft.ManagedIdentity",
"type": "ManagedIdentityExtensionForWindows",
"settings": {
"port": 50342
}
}
}
]
Atribuir uma função à identidade gerenciada atribuída ao sistema da VM

Após habilitar a identidade atribuída ao sistema na VM, é recomendável conceder uma função a ela, como o
acesso de Leitor ao grupo de recursos no qual foi criado.
Para atribuir uma função à identidade atribuída pelo sistema da sua VM, sua conta precisa da atribuição de
função Administrador de acesso do usuário.
2. Carregue o modelo em um editor e adicione as informações a seguir para conceder o acesso de Leitor
na VM ao grupo de recursos no qual ela foi criada. A estrutura do modelo pode variar conforme o editor e
o modelo de implantação escolhido.
Na seção parameters , adicione o seguinte:
"builtInRoleType": {
"type": "string",
"defaultValue": "Reader"
},
"rbacGuid": {
"type": "string"
}
Na seção variables , adicione o seguinte:
"Reader": "[concat('/subscriptions/', subscription().subscriptionId,

'/providers/Microsoft.Authorization/roleDefinitions/', 'acdd72a7-3385-48ef-bd42-f606fba81ae7')]"
Na seção resources , adicione o seguinte:
{
"apiVersion": "2017-09-01",
"type": "Microsoft.Authorization/roleAssignments",
"name": "[parameters('rbacGuid')]",
"properties": {
"roleDefinitionId": "[variables(parameters('builtInRoleType'))]",
"principalId": "[reference(variables('vmResourceId'), '2017-12-01',
'Full').identity.principalId]",
"scope": "[resourceGroup().id]"
},
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"
]
}
Desabilitar uma identidade gerenciada atribuída ao sistema de uma VM do Azure

Para remover a identidade gerenciada atribuída pelo sistema de uma VM, sua conta precisa da atribuição de
função Atribuída do Virtual Machine. Nenhuma atribuição adicional de função de diretório do Azure Active
2. Carregue o modelo em um editor e localize o recurso Microsoft.Compute/virtualMachines de interesse na
seção resources . Se você tiver uma VM que tenha apenas a identidade gerenciada atribuída ao sistema,
poderá desabilitá-la alterando o tipo de identidade para None .
Microsoft.Compute/vir tualMachines API versão 2018-06-01
Se a VM tiver identidades gerenciadas atribuídas ao usuário e ao sistema, remova SystemAssigned do
tipo de identidade e mantenha UserAssigned junto com os valores de dicionário userAssignedIdentities .
Se apiVersionfor 2017-12-01 e a VM tiver identidades gerenciadas ao sistema e ao usuário, remova
SystemAssigned do tipo de identidade e mantenha UserAssigned junto com a matriz identityIds das
identidades gerenciadas atribuídas ao usuário.
O seguinte exemplo mostra como remover uma identidade gerenciada atribuída ao sistema de uma VM sem
identidades gerenciadas atribuídas ao usuário:
{
"apiVersion": "2018-06-01",
"identity": {
"type": "None"
}
}

Nesta seção, você atribui uma identidade gerenciada atribuída ao usuário a uma VM do Azure usando o modelo
NOTE
Para criar uma identidade gerenciada atribuída ao usuário usando um modelo do Azure Resource Manager, consulte Criar
uma identidade gerenciada atribuída ao usuário.
Atribuir uma identidade gerenciada atribuída ao usuário a uma VM do Azure

1. No elemento resources , adicione a seguinte entrada para atribuir uma identidade gerenciada atribuída
ao usuário à VM. Certifique-se de substituir <USERASSIGNEDIDENTITY> pelo nome da identidade gerenciada
atribuída ao usuário que você criou.
Se apiVersion for 2018-06-01 , as identidades gerenciadas atribuídas ao usuário serão armazenadas no
formato de dicionário userAssignedIdentities e o valor <USERASSIGNEDIDENTITYNAME> deverá ser
armazenado em uma variável definida na seção variables do modelo.
{
"apiVersion": "2018-06-01",
"identity": {
"type": "userAssigned",
"
[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',variables('<USERASSIGNEDIDENTITYNAME>
'))]": {}
}
}
}

Se apiVersion for 2017-12-01 , as identidades gerenciadas atribuídas ao usuário serão armazenadas na
matriz identityIds e o valor <USERASSIGNEDIDENTITYNAME> deverá ser armazenado em uma variável
definida na seção variables do modelo.
{
"apiVersion": "2017-12-01",
"identity": {
"identityIds": [
"
'))]"
]
}
}
2. Quando você terminar, as seguintes seções deverão ser adicionadas à seção resource do modelo e ela
será semelhante à seguinte:
"resources": [
{
"apiVersion": "2018-06-01",
"identity": {
"
'))]": {}
}
}
},
{
"dependsOn": [
],
"properties": {
"settings": {
"port": 50342
}
}
}
]

"resources": [
{
"apiVersion": "2017-12-01",
"identity": {
"identityIds": [
"
'))]"
]
}
},
{
"dependsOn": [
],
"properties": {
"settings": {
"port": 50342
}
}
}
]

Para remover uma identidade atribuída pelo usuário de uma VM, sua conta precisa da atribuição de função
Atribuído do Virtual Machine. Nenhuma atribuição adicional de função de diretório do Azure Active Directory é
necessária.
2. Carregue o modelo em um editor e localize o recurso Microsoft.Compute/virtualMachines de interesse na
seção resources . Se você tiver uma VM que tenha apenas a identidade gerenciada atribuída ao usuário,
será possível desabilitá-la alterando o tipo de identidade para None .
O exemplo a seguir mostra como remover todas as identidades gerenciadas atribuídas ao usuário de
uma VM sem identidades gerenciadas atribuídas ao sistema:
{
"apiVersion": "2018-06-01",
"identity": {
"type": "None"
},
}

Para remover uma identidade gerenciada atribuída ao usuário único de uma VM, remova-a do dicionário
useraAssignedIdentities .
Caso você tenha uma identidade gerenciada atribuída ao sistema, mantenha a identidade com o valor
type no valor identity .

Para remover uma identidade gerenciada atribuída ao usuário único de uma VM, remova-a da matriz
identityIds .
Caso você tenha uma identidade gerenciada atribuída ao sistema, mantenha a identidade com o valor
type no valor identity .
Próximas etapas
Identidades gerenciadas para visão geral dos recursos do Azure.
do Azure em uma VM do Azure usando chamadas
da API REST
As identidades gerenciadas para recursos do Azure fornecem aos serviços do Azure uma identidade do sistema
gerenciada automaticamente no Azure Active Directory. Você pode usar essa identidade para autenticar em
qualquer serviço que dá suporte à autenticação do Azure AD, incluindo o Key Vault, sem ter as credenciais no
seu código.
Neste artigo, usando CURL para fazer chamadas para o ponto de extremidade REST do Azure Resource
Manager, você aprenderá como executar as seguintes identidades gerenciadas para operações de recursos do
Azure em uma VM do Azure:
Habilitar e desabilitar a identidade gerenciada atribuída pelo sistema em uma VM do Azure
Adicionar e remover uma identidade gerenciada atribuída pelo usuário em uma VM do Azure
Pré-requisitos
Se você não estiver familiarizado com as identidades gerenciadas dos recursos do Azure, confira O que são
as identidades gerenciadas dos recursos do Azure?. Para saber mais sobre tipos de identidade gerenciada
atribuída pelo sistema e pelo usuário, confira Tipos de identidade gerenciada.


Nesta seção, você aprenderá como habilitar e desabilitar a identidade gerenciada atribuída pelo sistema em
uma VM do Azure usando CURL para fazer chamadas para o ponto de extremidade REST do Azure Resource
Manager.
1. Criar um grupo de recursos para contenção e implantação de VM e seus recursos relacionados usando az
group create. Ignore esta etapa, se você já tiver o grupo de recursos que deseja usar:
2. Crie um adaptador de rede para a VM:
az network nic create -g myResourceGroup --vnet-name myVnet --subnet mySubnet -n myNic
3. Recupere um token de acesso do portador, que você usará na próxima etapa no cabeçalho Autorização
para criar sua VM com uma identidade gerenciada atribuída pelo sistema.
4. Com o Azure Cloud Shell, crie uma VM usando o CURL para chamar o ponto de extremidade REST do
Azure Resource Manager. O exemplo a seguir cria uma VM denominada myVM com uma identidade
gerenciada designada pelo sistema, conforme identificada no corpo da solicitação pelo valor
"identity":{"type":"SystemAssigned"} . Substitua <ACCESS TOKEN> pelo valor recebido na etapa anterior
quando você solicitou um token de acesso de portador e o valor de <SUBSCRIPTION ID> apropriado para
seu ambiente.
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01' -X PUT -d '{"location":"westus","name":"myVM","identity":
{"type":"SystemAssigned"},"properties":{"hardwareProfile":
{"vmSize":"Standard_D2_v2"},"storageProfile":{"imageReference":{"sku":"2016-
Datacenter","publisher":"MicrosoftWindowsServer","version":"latest","offer":"WindowsServer"},"osDisk"
:{"caching":"ReadWrite","managedDisk":
{"storageAccountType":"Standard_LRS"},"name":"myVM3osdisk","createOption":"FromImage"},"dataDisks":
[{"diskSizeGB":1023,"createOption":"Empty","lun":0},
{"diskSizeGB":1023,"createOption":"Empty","lun":1}]},"osProfile":
{"adminUsername":"azureuser","computerName":"myVM","adminPassword":"<SECURE PASSWORD
STRING>"},"networkProfile":{"networkInterfaces":[{"id":"/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/myNic","properties":
{"primary":true}}]}}}' -H "Content-Type: application/json" -H "Authorization: Bearer <ACCESS TOKEN>"
PUT https://management.azure.com/subscriptions/<SUBSCRIPTION
06-01 HTTP/1.1
Cabeçalhos de solicitação
Content-Type Obrigatórios. Defina como application/json .
Autorização Obrigatórios. Defina como um Bearer token de acesso

válido.
Corpo da solicitação
{
"location":"westus",
"name":"myVM",
"identity":{
"type":"SystemAssigned"
},
"properties":{
"hardwareProfile":{
"vmSize":"Standard_D2_v2"
},
"storageProfile":{
"imageReference":{
"sku":"2016-Datacenter",
"publisher":"MicrosoftWindowsServer",
"version":"latest",
"offer":"WindowsServer"
},
"osDisk":{
"caching":"ReadWrite",
"managedDisk":{
"storageAccountType":"Standard_LRS"
},
"name":"myVM3osdisk",
"createOption":"FromImage"
},
"dataDisks":[
{
"diskSizeGB":1023,
"createOption":"Empty",
"lun":0
},
{
"diskSizeGB":1023,
"lun":1
}
]
},
"osProfile":{
"adminUsername":"azureuser",
"computerName":"myVM",
"adminPassword":"myPassword12"
},
"networkProfile":{
"networkInterfaces":[
{
"id":"/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/myNic",
"properties":{
"primary":true
}
}
]
}
}
}
Ativar identidade atribuída pelo sistema em uma VM do Azure existente

2. Use o seguinte comando CURL para chamar o terminal REST do Azure Resource Manager para ativar a
identidade gerenciada atribuída pelo sistema em sua VM, conforme identificado no corpo da solicitação
pelo valor {"identity":{"type":"SystemAssigned"} para uma VM denominada myVM. Substitua
<ACCESS TOKEN> pelo valor recebido na etapa anterior quando você solicitou um token de acesso de
portador e o valor de <SUBSCRIPTION ID> apropriado para seu ambiente.
IMPORTANT
Para garantir que você não exclua nenhuma identidade gerenciada atribuída pelo usuário que esteja atribuída à
VM, é necessário listar as identidades gerenciadas atribuídas pelo usuário usando este comando CURL:
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION ID>/resourceGroups/<RESOURCE
GROUP>/providers/Microsoft.Compute/virtualMachines/<VM NAME>?api-version=2018-06-01' -H
"Authorization: Bearer <ACCESS TOKEN>"
. Se você tiver identidades gerenciadas atribuídas pelo usuário e atribuídas à VM, conforme identificado no valor
identity na resposta, pule para a etapa 3, que mostra como manter as identidades gerenciadas atribuídas pelo
usuário ao ativar a identidade gerenciada atribuída pelo sistema na sua VM.
06-01' -X PATCH -d '{"identity":{"type":"SystemAssigned"}}' -H "Content-Type: application/json" -H
"Authorization:Bearer <ACCESS TOKEN>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
06-01 HTTP/1.1

válido.
{
"identity":{
}
}
3. Para habilitar a identidade gerenciada atribuída pelo sistema em uma VM com identidades gerenciadas
atribuídas pelo usuário existentes, você precisa adicionar SystemAssigned ao type valor.
Por exemplo, se sua VM tiver as identidades gerenciadas atribuídas pelo usuário ID1 e ID2 atribuídas a
ela e você quiser adicionar a identidade gerenciada atribuída pelo sistema à VM, use a seguinte chamada
CURL. Substitua <ACCESS TOKEN> e <SUBSCRIPTION ID> pelos valores apropriados para seu ambiente.
A versão da API armazena identidades gerenciadas designadas pelo usuário no valor
2018-06-01
userAssignedIdentities em um formato de dicionário, em oposição ao valor identityIds em um
formato de matriz usado na versão da API 2017-12-01 .
API DE 2018 VERSÃO-06-01
06-01' -X PATCH -d '{"identity":{"type":"SystemAssigned, UserAssigned", "userAssignedIdentities":
{"/subscriptions/<<SUBSCRIPTION
ID>>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1":
{},"/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID2":
{}}}}' -H "Content-Type: application/json" -H "Authorization:Bearer <ACCESS TOKEN>"
06-01 HTTP/1.1

válido.
{
"identity":{
"type":"SystemAssigned, UserAssigned",
"userAssignedIdentities":{
"/subscriptions/<<SUBSCRIPTION
ID>>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1":{
},
"/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID2":{
}
}
}
}
VERSÃO DA API 2017-12-01
12-01' -X PATCH -d '{"identity":{"type":"SystemAssigned, UserAssigned", "identityIds":
["/subscriptions/<<SUBSCRIPTION
ID>>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1","
/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID2"]}}
' -H "Content-Type: application/json" -H "Authorization:Bearer <ACCESS TOKEN>"
12-01 HTTP/1.1

válido.
{
"identity":{
"identityIds":[
"/subscriptions/<<SUBSCRIPTION
ID>>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1",
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID2"
]
}
}
Desativar identidade gerenciada atribuída pelo sistema de uma VM do Azure

2. Atualize a VM usando CURL para chamar o ponto de extremidade REST do Azure Resource Manager para
desabilitar a identidade gerenciada atribuída pelo sistema. O exemplo a seguir desativa a identidade
gerenciada designada pelo sistema conforme identificada no corpo da solicitação pelo valor
{"identity":{"type":"None"}} de uma VM denominada myVM. Substitua <ACCESS TOKEN> pelo valor
recebido na etapa anterior quando você solicitou um token de acesso de portador e o valor de
<SUBSCRIPTION ID> apropriado para seu ambiente.
IMPORTANT
Para garantir que você não exclua nenhuma identidade gerenciada atribuída pelo usuário que esteja atribuída à
VM, é necessário listar as identidades gerenciadas atribuídas pelo usuário usando este comando CURL:
. Se você tiver identidades gerenciadas atribuídas pelo usuário e atribuídas à VM, conforme identificado no valor
identity na resposta, vá para a etapa 3, que mostra como manter as identidades gerenciadas atribuídas pelo
usuário e desabilitar a identidade gerenciada atribuída pelo sistema na sua VM.
06-01' -X PATCH -d '{"identity":{"type":"None"}}' -H "Content-Type: application/json" -H
06-01 HTTP/1.1

válido.
{
"identity":{
"type":"None"
}
}
Para remover a identidade gerenciada atribuída pelo sistema de uma máquina virtual que tenha
identidades gerenciadas designadas pelo usuário, remova SystemAssigned do valor
{"identity":{"type:" "}} e mantenha o valor UserAssigned e os valores do dicionário
userAssignedIdentities se você estiver usando Versão da API 2018-06-01 . Se você estiver usando a
versão da API 2017-12-01 ou anterior, mantenha o array identityIds .

Nesta seção, você aprenderá a adicionar e remover a identidade gerenciada atribuída pelo usuário em uma VM
do Azure usando CURL para fazer chamadas para o ponto de extremidade REST do Azure Resource Manager.
Atribuir uma identidade gerenciada atribuída pelo usuário durante a criação de uma VM do Azure
2. Crie um adaptador de rede para a VM:
az network nic create -g myResourceGroup --vnet-name myVnet --subnet mySubnet -n myNic
4. Crie uma identidade gerenciada atribuída pelo usuário usando as instruções encontradas aqui: Crie uma
5. Crie uma VM usando o CURL para chamar o ponto de extremidade REST do Azure Resource Manager. O
exemplo a seguir cria uma VM denominada myVM no grupo de recursos myResourceGroup com uma
identidade gerenciada designada pelo usuário ID1 , conforme identificado no corpo da solicitação pelo
valor "identity":{"type":"UserAssigned"} . Substitua <ACCESS TOKEN> pelo valor recebido na etapa
anterior quando você solicitou um token de acesso de portador e o valor de <SUBSCRIPTION ID>
apropriado para seu ambiente.
06-01' -X PUT -d '{"location":"westus","name":"myVM","identity":{"type":"UserAssigned","identityIds":
["/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1"]},
"properties":{"hardwareProfile":{"vmSize":"Standard_D2_v2"},"storageProfile":{"imageReference":
{"sku":"2016-
{"adminUsername":"azureuser","computerName":"myVM","adminPassword":"myPassword12"},"networkProfile":
{"networkInterfaces":[{"id":"/subscriptions/<SUBSCRIPTION
06-01 HTTP/1.1

válido.
{
"name":"myVM",
"identity":{
"type":"UserAssigned",
"identityIds":[
]
},
"properties":{
"hardwareProfile":{
},
"storageProfile":{
"imageReference":{
"version":"latest",
},
"osDisk":{
"managedDisk":{
},
},
"dataDisks":[
{
"diskSizeGB":1023,
"lun":0
},
{
"diskSizeGB":1023,
"lun":1
}
]
},
"osProfile":{
},
"networkProfile":{
{
"properties":{
"primary":true
}
}
]
}
}
}

12-01' -X PUT -d '{"location":"westus","name":"myVM","identity":{"type":"UserAssigned","identityIds":
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1"]},
"properties":{"hardwareProfile":{"vmSize":"Standard_D2_v2"},"storageProfile":{"imageReference":
{"sku":"2016-
{"adminUsername":"azureuser","computerName":"myVM","adminPassword":"myPassword12"},"networkProfile":
{"networkInterfaces":[{"id":"/subscriptions/<SUBSCRIPTION
12-01 HTTP/1.1

válido.
{
"name":"myVM",
"identity":{
"identityIds":[
]
},
"properties":{
"hardwareProfile":{
},
"storageProfile":{
"imageReference":{
"version":"latest",
},
"osDisk":{
"managedDisk":{
},
},
"dataDisks":[
{
"diskSizeGB":1023,
"lun":0
},
{
"diskSizeGB":1023,
"lun":1
}
]
},
"osProfile":{
},
"networkProfile":{
{
"properties":{
"primary":true
}
}
]
}
}
}

2. Crie uma identidade gerenciada atribuída pelo usuário usando as instruções encontradas aqui, Crie uma
3. Para garantir que você não exclua as identidades gerenciadas atribuídas pelo usuário ou pelo sistema
atribuídas à VM, é necessário listar os tipos de identidade atribuídos à VM usando o seguinte comando
CURL. Se houver identidades gerenciadas atribuídas ao conjunto de dimensionamento de máquinas
virtuais, elas serão listadas no valor identity .

GET https://management.azure.com/subscriptions/<SUBSCRIPTION ID>/resourceGroups/<RESOURCE

GROUP>/providers/Microsoft.Compute/virtualMachines/<VM NAME>?api-version=2018-06-01 HTTP/1.1

válido.
Se você tiver qualquer usuário ou identidades gerenciadas atribuídas pelo sistema atribuídas à VM,
conforme identificado no valor identity na resposta, vá para a etapa 5 que mostra como manter a
identidade gerenciada atribuída pelo sistema ao adicionar um gerenciado atribuído pelo usuário
identidade na sua VM.
4. Se você não tiver nenhuma identidade gerenciada atribuída pelo usuário atribuída à sua VM, use o
seguinte comando CURL para chamar o ponto de extremidade REST do Azure Resource Manager para
atribuir a primeira identidade gerenciada atribuída pelo usuário à VM.
O exemplo a seguir atribui uma identidade gerenciada designada pelo usuário, ID1 , a uma VM
denominada myVM no grupo de recursos myResourceGroup. Substitua <ACCESS TOKEN> pelo valor
recebido na etapa anterior quando você solicitou um token de acesso de portador e o valor de
<SUBSCRIPTION ID> apropriado para seu ambiente.
06-01' -X PATCH -d '{"identity":{"type":"UserAssigned", "userAssignedIdentities":
{"/subscriptions/<SUBSCRIPTION
06-01 HTTP/1.1

válido.
{
"identity":{
}
}
}
}
12-01' -X PATCH -d '{"identity":{"type":"userAssigned", "identityIds":["/subscriptions/<SUBSCRIPTION
12-01 HTTP/1.1

válido.
{
"identity":{
"type":"userAssigned",
"identityIds":[
]
}
}
5. Se você tiver uma identidade gerenciada designada pelo usuário ou designada pelo sistema atribuída à
sua VM:
Adicionar a identidade atribuída pelo usuário gerenciada para o userAssignedIdentities valor do
dicionário.
Por exemplo, se você tiver uma identidade gerenciada atribuída pelo sistema e a identidade gerenciada
atribuída pelo usuário ID1 atualmente atribuída à sua VM e quiser adicionar a identidade gerenciada
atribuída pelo usuário ID2 a ela:
{},"/subscriptions/<SUBSCRIPTION
06-01 HTTP/1.1

válido.
{
"identity":{
},
}
}
}
}

Reter as identidades gerenciadas atribuídas pelo usuário que você gostaria de manter no valor da matriz
identityIds ao adicionar a nova identidade gerenciada atribuída pelo usuário.
Por exemplo, se você tiver uma identidade gerenciada atribuída pelo sistema e a identidade gerenciada
atribuída pelo usuário ID1 atualmente atribuída à sua VM e quiser adicionar a identidade gerenciada
atribuída pelo usuário ID2 a ela:
12-01' -X PATCH -d '{"identity":{"type":"SystemAssigned,UserAssigned", "identityIds":
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1","/
subscriptions/<SUBSCRIPTION
12-01 HTTP/1.1

válido.
{
"identity":{
"type":"SystemAssigned,UserAssigned",
"identityIds":[
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1",
]
}
}

2. Para garantir que você não exclua nenhuma identidade gerenciada atribuída pelo usuário que gostaria de
manter atribuída à VM ou remover a identidade gerenciada atribuída pelo sistema, é necessário listar as
identidades gerenciadas usando o seguinte comando CURL:
GET https://management.azure.com/subscriptions/<SUBSCRIPTION ID>/resourceGroups/<RESOURCE

GROUP>/providers/Microsoft.Compute/virtualMachines/<VM NAME>?api-version=2018-06-01 HTTP/1.1

válido.
Se houver identidades gerenciadas atribuídas à VM, elas serão listadas na resposta no valor identity .
Por exemplo, se você tiver identidades gerenciadas atribuídas pelo usuário ID1 e ID2 atribuídas à sua
VM, e só quiser manter ID1 atribuída e manter a identidade atribuída pelo sistema:
Adicionar null para o usuário atribuído gerenciado identidade que você deseja remover:
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID2":nu
ll}}}' -H "Content-Type: application/json" -H "Authorization:Bearer <ACCESS TOKEN>"
06-01 HTTP/1.1

válido.
{
"identity":{
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID2":nu
ll
}
}
}

Reter apenas as identidades gerenciadas atribuídas pelo usuário que você gostaria de manter na matriz
identityIds :
12-01' -X PATCH -d '{"identity":{"type":"SystemAssigned, UserAssigned", "identityIds":
12-01 HTTP/1.1

válido.
{
"identity":{
"identityIds":[
]
}
}
Se sua VM tiver identidades gerenciadas atribuídas pelo sistema e atribuídas pelo usuário, você poderá remover
todas as identidades gerenciadas atribuídas pelo usuário alternando para usar somente a identidade gerenciada
atribuída pelo sistema usando o seguinte comando:
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-06-01'
-X PATCH -d '{"identity":{"type":"SystemAssigned"}}' -H "Content-Type: application/json" -H
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-06-01
HTTP/1.1

válido.
{
"identity":{
}
}
Se sua VM tiver somente identidades gerenciadas atribuídas pelo usuário e você quiser removê-las, use o
seguinte comando:
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-06-01'
-X PATCH -d '{"identity":{"type":"None"}}' -H "Content-Type: application/json" -H Authorization:"Bearer
<ACCESS TOKEN>"
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-06-01
HTTP/1.1

válido.
{
"identity":{
"type":"None"
}
}
Próximas etapas
Para obter informações sobre como criar, listar ou excluir identidades gerenciadas atribuídas pelo usuário
usando o REST, consulte:
Criar, listar ou excluir identidades gerenciadas atribuídas pelo usuário usando chamadas da API REST
Configurar uma VM com identidades gerenciadas
para recursos do Azure usando um SDK do Azure
automaticamente no AD (Azure Active Directory). Você pode usar essa identidade para autenticar em qualquer
Neste artigo, você aprende como habilitar e remover identidades gerenciadas para recursos do Azure para uma
VM do Azure usando um SDK do Azure.
Pré-requisitos
Se você não estiver familiarizado com as identidades gerenciadas para funcionalidades de recursos do Azure,
veja esta visão geral. Caso você ainda não tenha uma conta do Azure, inscreva-se em uma conta gratuita
antes de continuar.
SDKs do Azure com identidades gerenciadas para suporte a recursos

do Azure
O Azure dá suporte a várias plataformas de programação por meio de uma série de SDKs do Azure. Vários deles
foram atualizados para dar suporte a identidades gerenciadas para recursos do Azure e fornecer exemplos
correspondentes para demonstrar o uso. Esta lista é atualizada conforme suporte adicional é adicionado:
. A M O ST RA
.NET Gerenciar recursos de uma VM habilitada com identidades

gerenciadas para recursos do Azure habilitados
Java Gerenciar o armazenamento de uma VM habilitada com

identidades gerenciadas para recursos do Azure
Node.js Criar uma VM com identidade gerenciada atribuída ao

sistema habilitada
Python Criar uma VM com identidade gerenciada atribuída ao

sistema habilitada
Ruby Criar uma VM do Azure com uma identidade atribuída ao

sistema habilitada
Próximas etapas
Consulte os artigos relacionados em Configurar identidade para uma VM do Azure , para saber como
também é possível usar o portal do Azure, o PowerShell, a CLI e os modelos de recursos.
Versão prévia: faça logon em uma máquina virtual
Linux no Azure usando Azure Active Directory
autenticação
Para melhorar a segurança das VMs (máquinas virtuais) do Linux no Azure, você pode fazer a integração com a
autenticação do AD (Azure Active Directory). Ao usar a autenticação do Azure AD para VMs do Linux, você
controla e impõe de forma central as políticas que permitem ou negam acesso às VMs. Este artigo mostra como
criar e configurar uma VM do Linux para usar a autenticação do Azure AD.
IMPORTANT
A autenticação Azure Active Directory está atualmente em visualização pública. Essa versão prévia é fornecida sem um
Versões Prévias do Microsoft Azure. Use esse recurso em uma máquina virtual de teste que você pretende descartar após
o teste.
Há muitos benefícios de usar a autenticação do Azure AD para fazer logon em VMs do Linux no Azure, como:
Segurança aprimorada:
Você pode usar suas credenciais corporativas do AD para fazer logon em VMs do Linux no Azure. Não
é necessário criar contas de administrador local e gerenciar o tempo de vida da credencial.
Dependendo menos da contas de administrador local, você não precisa se preocupar com a perda ou
o roubo de credenciais, credenciais fracas configuradas pelos usuários, etc.
As políticas de complexidade e de tempo de vida de senha configuradas para o diretório do Azure AD
também ajudam a proteger as VMs do Linux.
Para proteger ainda mais o logon nas máquinas virtuais do Azure, você pode configurar a
autenticação multifator.
A capacidade de fazer logon em VMs do Linux com Azure Active Directory também funciona para
clientes que usam os Serviços de Federação.
Colaboração direta: Com o controle de acesso baseado em função do Azure (RBAC do Azure), você
pode especificar quem pode entrar em uma determinada VM como um usuário comum ou com
privilégios de administrador. Quando os usuários ingressam ou deixam sua equipe, você pode atualizar a
política RBAC do Azure para a VM para conceder acesso conforme apropriado. Essa experiência é muito
mais simples do que ter que limpar as VMs para remover as chaves públicas SSH desnecessárias.
Quando os funcionários saem da organização e a conta de usuário é desabilitada ou removida do Azure
AD, eles deixam de ter acesso aos recursos.
Regiões do Azure e distribuições do Linux com suporte

No momento, há suporte para as seguintes distribuições do Linux durante a versão prévia desse recurso:
CentOS CentOS 6, CentOS 7

Debian Debian 9
openSUSE openSUSE Leap 42.3
RedHat Enterprise Linux RHEL 6, RHEL 7
SUSE Linux Enterprise Server SLES 12
Ubuntu Server Ubuntu 14.04 LTS, Ubuntu Server 16.04 e Ubuntu Server
18.04
No momento, há suporte para as seguintes regiões do Azure durante a versão prévia desse recurso:
Todas as regiões globais do Azure
IMPORTANT
Para usar esse recurso de versão prévia, somente implante uma distribuição do Linux com suporte em uma região do
Azure com suporte. Não há suporte para o recurso no Azure Governamental nem nas nuvens soberanas.
Não há suporte para usar essa extensão nos clusters do AKS (serviço kubernetes do Azure). Para obter mais informações,
consulte políticas de suporte para AKs.
Se optar por instalar e usar a CLI localmente, este tutorial exigirá que você esteja executando a CLI do Azure
Requisitos de rede
Para habilitar a autenticação do Azure AD para suas VMs do Linux no Azure, você precisa garantir que sua
configuração de rede de VMs permita o acesso de saída aos seguintes pontos de extremidade pela porta TCP
443:
https://login.microsoftonline.com
https://login.windows.net
https: / /Device.login.microsoftonline.com
https: / /Pas.Windows.net
https://management.azure.com
https: / /Packages.Microsoft.com
NOTE
Atualmente, os grupos de segurança de rede do Azure não podem ser configurados para VMs habilitadas com a
Criar uma máquina virtual do Linux

Crie um grupo de recursos com az group create e, em seguida, crie uma VM com az vm create usando uma
distribuição com suporte em uma região com suporte. O exemplo a seguir implanta uma VM denominada
myVM que usa o Ubuntu 16.04 LTS em um grupo de recursos denominado myResourceGroup na região
southcentralus. Nos exemplos a seguir, você pode fornecer seu próprio grupo de recursos e seus próprios
nomes de VM, conforme o necessário.
az group create --name myResourceGroup --location southcentralus
az vm create \
--name myVM \
--image UbuntuLTS \
--generate-ssh-keys
A criação da VM e dos recursos de suporte demora alguns minutos.
Instalar a extensão da VM de logon do Azure AD

NOTE
Se estiver implantando essa extensão em uma VM criada anteriormente, verifique se a máquina tem pelo menos 1GB de
memória alocada. caso contrário, a extensão falhará na instalação
Para fazer logon em uma VM do Linux com credenciais do Azure AD, instale a extensão de VM de logon Azure
Active Directory. As extensões de VM são pequenos aplicativos que fornecem tarefas de configuração e
automação pós-implantação nas máquinas virtuais do Azure. Use az vm extension set para instalar a extensão
AADLoginForLinux na VM denominada myVM no grupo de recursos myResourceGroup:
--publisher Microsoft.Azure.ActiveDirectory.LinuxSSH \
--name AADLoginForLinux \
--vm-name myVM
O provisioningState de Succeeded é mostrado depois que a extensão é instalada com êxito na VM. A VM precisa
de um agente de VM em execução para instalar a extensão. Para obter mais informações, consulte visão geral do
agente de VM.
Configurar atribuições de função para a VM

A política do Azure RBAC (controle de acesso baseado em função) determina quem pode fazer logon na VM.
Duas funções do Azure são usadas para autorizar o logon da VM:
Logon de administrador da máquina vir tual : os usuários com essa função atribuída podem fazer logon
em uma máquina virtual do Azure com privilégios de usuário de administrador do Windows ou raiz do
Linux.
Logon de usuário da máquina vir tual : os usuários com essa função atribuído podem fazer logon uma
máquina virtual do Azure com privilégios de usuários regulares.
NOTE
Para permitir que um usuário faça logon na VM por SSH, você precisa atribuir a função Logon de Administrador da
Máquina Virtual ou Logon de Usuário da Máquina Virtual. As funções de logon de administrador de máquina virtual e de
usuário de máquina virtual usam dataactions e, portanto, não podem ser atribuídas no escopo do grupo de
gerenciamento. Atualmente, essas funções só podem ser atribuídas na assinatura, no grupo de recursos ou no escopo do
recurso. Um usuário do Azure com a função Proprietário ou Colaborador atribuída para uma VM não tem
automaticamente privilégios para fazer logon na VM por SSH.
O exemplo a seguir usa az role assignment create para atribuir a função Logon de Administrador da Máquina
Virtual para a VM ao usuário atual do Azure. O nome de usuário da conta do Azure ativa é obtido com az
account show e o escopo é definido para a VM criada na etapa anterior com az vm show. O escopo também
pode ser atribuído em um nível de assinatura ou grupo de recursos, e as permissões normais de herança do
RBAC do Azure se aplicam. Para obter mais informações, consulte RBAC do Azure
username=$(az account show --query user.name --output tsv)

vm=$(az vm show --resource-group myResourceGroup --name myVM --query id -o tsv)

--role "Virtual Machine Administrator Login" \
--assignee $username \
--scope $vm
NOTE
Se o domínio do AAD e o domínio do nome de usuário de logon não corresponderem, especifique a ID de objeto da
conta de usuário com --assignee-object-id, não apenas o nome de usuário de --assignee. É possível obter a ID de objeto
para a conta de usuário com az ad user list.
Para obter mais informações sobre como usar o RBAC do Azure para gerenciar o acesso aos recursos de sua
assinatura do Azure, consulte usando o CLI do Azure, portal do Azureou Azure PowerShell.
Usando o acesso condicional

Você pode impor políticas de acesso condicional, como a autenticação multifator ou a verificação de risco de
entrada do usuário antes de autorizar o acesso às VMs do Linux no Azure que estão habilitadas com o logon do
Azure AD. Para aplicar a política de acesso condicional, você deve selecionar o aplicativo "entrada de VM do
Azure Linux" na opção de atribuição de aplicativos ou ações de nuvem e, em seguida, usar o risco de entrada
como uma condição e/ou exigir a autenticação multifator como um controle de acesso de concessão.
WARNING
A autenticação multifator habilitada/imposta por usuário do Azure AD não tem suporte para entrada de VM.
Fazer logon na máquina virtual do Linux

Primeiro, exiba o endereço IP público da VM com az vm show:
az vm show --resource-group myResourceGroup --name myVM -d --query publicIps -o tsv
Faça logon na máquina virtual do Linux no Azure usando suas credenciais do Azure AD. O parâmetro -l
permite que você especifique seu próprio endereço da conta do Azure AD. Substitua a conta de exemplo pela
sua. Endereços de conta devem ser inseridos em letras minúsculas. Substitua o endereço IP de exemplo pelo
endereço IP público da sua VM do comando anterior.
ssh -l azureuser@contoso.onmicrosoft.com 10.11.123.456
Você será solicitado a entrar no Azure AD com um código de uso único em https://microsoft.com/devicelogin .
Copie e cole o código de uso único na página de logon do dispositivo.
Quando solicitado, insira suas credenciais de logon do Azure AD na página de logon.
A seguinte mensagem é mostrada no navegador da Web quando você se autenticou com êxito:
You have signed in to the Microsoft Azure Linux Virtual Machine Sign-In application on your device.
Feche a janela do navegador, retorne para o prompt do SSH e pressione a tecla Enter .
Agora, você está conectado à máquina virtual do Linux no Azure com as permissões de função atribuídas, como
Usuário da VM ou Administrador da VM. Se sua conta de usuário for atribuída à função de logon de
administrador da máquina virtual , você poderá usar o sudo para executar comandos que exigem privilégios de
raiz.
Logon do AAD e Sudo

Na primeira vez que você executar o sudo, será solicitado que você autentique uma segunda vez. Se você não
quiser ter que se autenticar novamente para executar o sudo, edite o arquivo sudoers
/etc/sudoers.d/aad_admins e substitua esta linha:
%aad_admins ALL=(ALL) ALL
Por esta linha:
%aad_admins ALL=(ALL) NOPASSWD:ALL
Solucionar problemas de entrada

Alguns erros comuns quando você tenta usar SSH com as credenciais do Azure AD não incluem nenhuma
função do Azure atribuída e solicitações repetidas para entrar. Use as seções a seguir para corrigir esses
problemas.
Acesso negado: função do Azure não atribuída
Se você vir o erro a seguir no prompt do SSH, verifique se você configurou as políticas RBAC do Azure para a
VM que concede ao usuário o logon de administrador da máquina virtual ou a função de logon de usuário da
máquina virtual :
login as: azureuser@contoso.onmicrosoft.com

Using keyboard-interactive authentication.
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code
FJX327AXD to authenticate. Press ENTER when ready.
Using keyboard-interactive authentication.
Access denied: to sign-in you be assigned a role with action
'Microsoft.Compute/virtualMachines/login/action', for example 'Virtual Machine User Login'
Access denied
NOTE
Se você estiver executando problemas com as atribuições de função do Azure, consulte solucionar problemas do RBAC do
Azure.
Prompts contínuos de entrada de SSH

Ao concluir com êxito a etapa de autenticação em um navegador da Web, você poderá ser imediatamente
solicitado a entrar novamente com um novo código. Este erro normalmente é causado por uma
incompatibilidade entre o nome de entrada especificado no prompt de SSH e a conta usada para entrar no
Azure AD. Para corrigir esse problema:
Verifique se o nome de entrada especificado no prompt de SSH está correto. Um erro de digitação no nome
de entrada pode causar uma incompatibilidade entre o nome de entrada especificado no prompt de SSH e a
conta usada para entrar no Azure AD. Por exemplo, você digitou azuresuer @ contoso.onmicrosoft.com em
vez de azureuser @ contoso.onmicrosoft.com.
Se você tiver várias contas de usuário, não forneça uma conta de usuário diferente na janela do navegador
ao entrar no Azure AD.
O Linux é um sistema operacional que diferencia maiúsculas de minúsculas. Há uma diferença entre
'Azureuser@contoso.onmicrosoft.com' e 'azureuser@contoso.onmicrosoft.com', que pode causar uma
incompatibilidade. Especifique o UPN com a diferenciação correta de maiúsculas de minúsculas no prompt
de SSH.
Outras limitações
Atualmente, os usuários que herdam direitos de acesso por grupos aninhados ou atribuições de função não têm
suporte. O usuário ou grupo deve ser atribuído diretamente às atribuições de função necessárias. Por exemplo,
o uso de grupos de gerenciamento ou atribuições de função de grupo aninhado não concederá as permissões
corretas para permitir que o usuário entre.
Comentários de visualização
Compartilhe seus comentários sobre este recurso de visualização ou informe problemas usando-o no Fórum de
comentários do Azure AD
Próximas etapas
Para obter mais informações sobre o Azure Active Directory, confira O que é o Azure Active Directory
Manutenção para máquinas virtuais no Azure
O Azure atualiza a plataforma periodicamente para aprimorar a confiabilidade, o desempenho e a segurança da

infraestrutura de host para máquinas virtuais. A finalidade dessas atualizações vai desde a aplicação de patch de
componentes de software no ambiente de hospedagem até a atualização de componentes de rede ou o
encerramento de hardware.
As atualizações raramente afetam as VMs hospedadas. Quando as atualizações têm um efeito, o Azure escolhe o
método menos impactante de atualizações:
Se a atualização não exigir uma reinicialização, a VM será pausada, enquanto o host é atualizado ou a VM é
migrada ao vivo para um host já atualizado.
Se a manutenção exigir uma reinicialização, você será notificado sobre a manutenção planejada. O Azure
também fornece uma janela de tempo, na qual você pode iniciar a manutenção, em um momento mais
oportuno para você. A janela de manutenção automática normalmente é de 35 dias, a menos que a
manutenção seja urgente. O Azure está investindo em tecnologias para reduzir o número de casos em que a
manutenção planejada de plataforma exige a reinicialização das VMs. Para obter instruções sobre como
gerenciar a manutenção planejada, confira Lidar com notificações de manutenção planejada usando a CLI do
Azure, o PowerShell ou o portal.
Esta página descreve como o Microsoft Azure executa os dois tipos de manutenção. Para obter mais
informações sobre eventos não planejados (interrupções), confira Gerenciar a disponibilidade das VMs para
Windows ou o artigo correspondente para Linux.
De uma VM, você pode obter notificações sobre manutenção futura usando os Eventos Agendados para
Windows ou para Linux.
Manutenção que não exige uma reinicialização

A maioria das atualizações de plataforma não afeta as VMs do cliente. Quando uma atualização sem impacto
não é possível, o Azure escolhe o mecanismo de atualização menos impactante para as VMs dos clientes.
A manutenção de impacto mais diferente de zero pausa a VM por menos de 10 segundos. Em determinados
casos, o Azure usa mecanismos de manutenção de preservação de memória. Esses mecanismos pausam a VM
por até 30 segundos e preservam a memória na RAM. Depois, a VM é reiniciada e o respectivo relógio é
sincronizado automaticamente.
A manutenção de preservação de memória funciona para mais de 90% das VMs do Azure. Ela não funciona para
as séries G, M, N e H. Cada vez mais, o Azure usa tecnologias de migração ao vivo e aprimora o mecanismo de
manutenção de preservação de memória para reduzir as durações da pausa.
Essas operações de manutenção que não exigem uma reinicialização são aplicadas a um domínio de falha por
vez. Elas serão interrompidas se receberem sinais de integridade de aviso das ferramentas de monitoramento
de plataforma.
Esses tipos de atualizações podem afetar alguns aplicativos. Quando a VM é migrada ao vivo para um host
diferente, algumas cargas de trabalho confidenciais podem mostrar uma ligeira degradação do desempenho em
alguns minutos que levam a pausar a máquina virtual. Para se preparar para a manutenção da VM e reduzir o
impacto durante a manutenção do Azure, experimente usar os Eventos Agendados para Windows ou Linux para
esses aplicativos.
Para obter maior controle sobre todas as atividades de manutenção, incluindo impacto zero e atualizações sem
reinicialização, você pode usar o recurso de Controle de Manutenção. Você precisa estar usando Hosts
Dedicados do Azure ou uma VM isolada. O controle de manutenção oferece a opção de ignorar todas as
atualizações de plataforma e aplicar as atualizações à sua escolha de tempo em uma janela sem interrupção de
35 dias. Para obter mais informações, confira Controlar atualizações com o Controle de Manutenção e a CLI do
Azure.
Migração ao vivo
A migração ao vivo é uma operação que não exige uma reinicialização e preserva a memória da VM. Ela causa
uma pausa ou um congelamento, normalmente com duração não superior a cinco segundos. Exceto para as
séries G, M, N e H, todas as VMs de IaaS (infraestrutura como serviço) são qualificadas para a migração ao vivo.
As VMs qualificadas representam mais de 90% das VMs de IaaS implantadas na frota do Azure.
A plataforma Azure inicia a migração ao vivo nos seguintes cenários:
Manutenção planejada
Falha de hardware
Otimizações de alocação
Alguns cenários de manutenção planejada usam a migração ao vivo, e você pode usar Eventos Agendados para
saber com antecedência quando as operações de migração ao vivo serão iniciadas.
A migração ao vivo também pode ser usada para mover VMs quando os algoritmos do Azure Machine Learning
preveem uma falha de hardware iminente ou quando você deseja otimizar as alocações de VM. Para obter mais
informações sobre modelagem preditiva que detecta instâncias de hardware degradado, confira Improving
Azure VM resiliency with predictive machine learning and live migration (Aprimorar a resiliência da VM do
Azure com o machine learning de previsão e a migração ao vivo). As notificações de migração ao vivo aparecem
na portal do Azure nos logs de Monitoramento e de Integridade do Serviço, bem como nos Eventos Agendados
se você usar esses serviços.
Manutenção que requer uma reinicialização

Quando as VMs precisarem ser reinicializadas para manutenção planejada, você será notificado com
antecedência. A manutenção planejada tem duas fases: uma fase de autoatendimento e uma fase de
manutenção agendada.
Durante a fase de autoatendimento, que geralmente dura quatro semanas, você inicia a manutenção em suas
VMs. Como parte do autoatendimento, você pode consultar cada VM para ver o status e o resultado de sua
última solicitação de manutenção.
Quando você inicia a manutenção de autoatendimento, sua VM é reimplantada em um nó já atualizado. Como a
VM é reiniciada, o disco temporário é perdido e os endereços IP dinâmicos associados ao adaptador de rede
virtual são atualizados.
Se surgir um erro durante a manutenção de autoatendimento, a operação será interrompida, a VM não será
atualizada e você terá a opção de tentar novamente a manutenção de autoatendimento.
Quando a fase de autoatendimento termina, a fase de manutenção agendada é iniciada. Durante essa fase, você
ainda pode consultar a fase de manutenção, mas não pode iniciar a manutenção por conta própria.
Para obter mais informações sobre como gerenciar a manutenção que exige uma reinicialização, confira Lidar
com notificações de manutenção planejada usando a CLI do Azure, o PowerShell ou o portal.
Considerações sobre disponibilidade durante a manutenção agendada
Se você decidir aguardar até a fase de manutenção agendada, há alguns aspectos a serem considerados para
manter a disponibilidade mais alta de suas VMs.
Regiões emparelhadas
Cada região do Azure é emparelhada com outra na mesma proximidade geográfica. Juntas, elas fazem um par
de regiões. Durante a fase de manutenção agendada, o Azure atualiza somente as VMs em uma só região de um
par de regiões. Por exemplo, ao atualizar a VM no Centro-Norte dos EUA, o Azure não atualiza nenhuma VM no
Centro-Sul dos EUA ao mesmo tempo. No entanto, outras regiões, como o Norte da Europa, podem estar em
manutenção simultaneamente com Leste dos EUA. Noções básicas sobre como funcionam os pares de região
podem ajudá-lo a melhor distribuir suas VMs entre regiões. Para obter mais informações, consulte pares de
regiões do Azure.
Conjuntos de disponibilidade e conjuntos de dimensionamento
Ao implantar uma carga de trabalho usando VMs do Azure, é possível criar as VMs em um conjunto de
disponibilidade para fornecer alta disponibilidade para o aplicativo. Usando conjuntos de disponibilidade, você
pode garantir que, durante uma interrupção ou eventos de manutenção que exijam uma reinicialização, pelo
menos uma VM esteja disponível.
Em um conjunto de disponibilidade, VMs individuais são distribuídas em até 20 domínios de atualização.
Durante a manutenção agendada, somente um domínio é atualizado em um período específico. Os domínios de
atualização não são necessariamente atualizados em sequência.
Os conjuntos de dimensionamento de máquinas virtuais são um recurso de computação do Azure que pode ser
usado para implantar e gerenciar um conjunto de VMs idênticas como um só recurso. O conjunto de
dimensionamento é implantado automaticamente nos UDs, como VMs em um conjunto de disponibilidade.
Assim como com conjuntos de disponibilidade, quando você usa conjuntos de dimensionamento, somente um
UD é afetado em um determinado momento durante a manutenção agendada.
Para obter mais informações sobre como configurar suas VMs para alta disponibilidade, confira Gerenciar a
disponibilidade das VMs para Windows ou o artigo correspondente para Linux.
Zonas de disponibilidade
As zonas de disponibilidade são locais físicos exclusivos em uma região do Azure. Cada zona é composta por
um ou mais datacenters equipados com energia, resfriamento e rede independentes. Para garantir a resiliência,
há um mínimo de três zonas separadas em todas as regiões habilitadas.
Uma zona de disponibilidade é uma combinação de um domínio de falha e um domínio de atualização. Se você
criar três ou mais VMs em três zonas em uma região do Azure, as VMs serão efetivamente distribuídas em três
domínios de falha e três domínios de atualização. A plataforma do Azure reconhece essa distribuição nos
domínios de atualização para garantir que as VMs em diferentes zonas não sejam atualizadas ao mesmo tempo.
Cada atualização de infraestrutura é distribuída zona por zona, dentro de uma só região. No entanto, você pode
ter uma implantação em andamento na Zona 1 e uma implantação diferente em andamento na Zona 2, ao
mesmo tempo. Implantações não são todas serializadas. Porém, uma só implantação distribui uma zona por vez
para reduzir o risco.
Próximas etapas
Você pode usar a CLI do Azure, o Azure PowerShell ou o portal para gerenciar a manutenção planejada.
Visualização: atualização de extensão automática
para VMs e conjuntos de dimensionamento no
Azure
A atualização de extensão automática está disponível em versão prévia para VMs do Azure e conjuntos de
dimensionamento de máquinas virtuais do Azure. Quando a atualização de extensão automática está habilitada
em uma VM ou em um conjunto de dimensionamento, a extensão é atualizada automaticamente sempre que o
Publicador de extensão libera uma nova versão para essa extensão.
A atualização automática de extensão tem os seguintes recursos:
Com suporte para VMs do Azure e conjuntos de dimensionamento de máquinas virtuais do Azure. No
momento, não há suporte para conjuntos de dimensionamento de máquinas virtuais Service Fabric.
As atualizações são aplicadas em um modelo de implantação de primeira disponibilidade (detalhado abaixo).
Para um conjunto de dimensionamento de máquinas virtuais, não mais do que 20% das máquinas virtuais
do conjunto de dimensionamento serão atualizadas em um único lote. O tamanho mínimo do lote é uma
máquina virtual.
Funciona para todos os tamanhos de VM e para extensões do Windows e Linux.
Você pode recusar atualizações automáticas a qualquer momento.
A atualização de extensão automática pode ser habilitada em um conjunto de dimensionamento de
máquinas virtuais de qualquer tamanho.
Cada extensão com suporte é inscrita individualmente e você pode escolher quais extensões serão
atualizadas automaticamente.
Com suporte em todas as regiões de nuvem pública.
IMPORTANT
A atualização de extensão automática está atualmente em visualização pública. Um procedimento de aceitação é
necessário para usar a funcionalidade de visualização pública descrita abaixo. Esta versão prévia é fornecida sem um
Como funciona a atualização de extensão automática?

O processo de atualização de extensão substitui a versão de extensão existente em uma VM com uma nova
versão da mesma extensão quando publicada pelo editor de extensão. A integridade da VM é monitorada após a
instalação da nova extensão. Se a VM não estiver em um estado íntegro dentro de 5 minutos após a conclusão
da atualização, a versão da extensão será revertida para a versão anterior.
Uma falha na atualização da extensão é repetida automaticamente. Uma nova tentativa é feita automaticamente
A cada poucos dias, sem a intervenção do usuário.
Disponibilidade -primeiras atualizações
O modelo de disponibilidade-primeiro para atualizações orquestradas de plataforma garantirá que as
configurações de disponibilidade no Azure sejam respeitadas em vários níveis de disponibilidade.
Para um grupo de máquinas virtuais que passa por uma atualização, a plataforma do Azure orquestrará as
atualizações:
Entre regiões:
Uma atualização será movida no Azure globalmente de forma em fases para evitar falhas de implantação em
todo o Azure.
Uma "fase" pode ter uma ou mais regiões e uma atualização será movida entre as fases somente se as VMs
qualificadas na fase anterior forem atualizadas com êxito.
As regiões emparelhadas geograficamente não serão atualizadas simultaneamente e não poderão estar na
mesma fase regional.
O sucesso de uma atualização é medido rastreando a integridade de uma atualização de VM. A integridade
da VM é controlada por meio de indicadores de integridade da plataforma para a VM. Para conjuntos de
dimensionamento de máquinas virtuais, a integridade da VM é controlada por meio de investigações de
integridade do aplicativo ou da extensão de integridade do aplicativo, se aplicada ao conjunto de
dimensionamento.
Dentro de uma região:
As VMs em diferentes Zonas de Disponibilidade não são atualizadas simultaneamente.
As VMs únicas que não fazem parte de um conjunto de disponibilidade são agrupadas em uma base de
melhor esforço para evitar atualizações simultâneas para todas as VMs em uma assinatura.
Em um ' Set ':
Todas as VMs em um conjunto de disponibilidade ou conjunto de dimensionamento comum não são
atualizadas simultaneamente.
As VMs em um conjunto de disponibilidade comum são atualizadas em limites de domínio de atualização e
as VMs em vários domínios de atualização não são atualizadas simultaneamente.
As VMs em um conjunto de dimensionamento de máquinas virtuais comum são agrupadas em lotes e
atualizadas em limites de domínio de atualização.
Processo de atualização para conjuntos de dimensionamento de máquinas virtuais
1. Antes de iniciar o processo de atualização, o orquestrador garantirá que no máximo 20% das VMs em
todo o conjunto de dimensionamento não estejam íntegros (por qualquer motivo).
2. O orquestrador de atualização identifica o lote de instâncias de VM a serem atualizadas. Um lote de
atualização pode ter um máximo de 20% da contagem total de VMs, sujeito a um tamanho mínimo de
lote de uma máquina virtual.
3. Para conjuntos de dimensionamento com investigações de integridade de aplicativo configuradas ou
extensão de integridade de aplicativos, a atualização aguarda até 5 minutos (ou a configuração de
investigação de integridade definida) para que a VM se torne íntegra antes de atualizar o próximo lote. Se
uma VM não recuperar sua integridade após uma atualização, por padrão, a versão de extensão anterior
na VM será reinstalada.
4. O orquestrador de atualização também controla a porcentagem de VMs que se tornam não íntegras após
uma atualização. A atualização será interrompida se mais de 20% das instâncias atualizadas se tornarem
não íntegras durante o processo de atualização.
O processo acima continua até todas as instâncias no conjunto de dimensionamento serem atualizadas.
O orquestrador de atualização do conjunto de dimensionamento verifica a integridade geral do conjunto de
dimensionamento antes de atualizar cada lote. Durante a atualização de um lote, pode haver outras atividades
de manutenção planejadas ou não planejadas simultâneas que poderiam afetar a integridade das máquinas
virtuais do conjunto de dimensionamento. Nesses casos, se mais de 20% das instâncias do conjunto de
dimensionamento se tornarem não íntegros, a atualização do conjunto de dimensionamento será interrompida
no final do lote atual.
Extensões com suporte

A visualização da atualização de extensão automática dá suporte às seguintes extensões (e mais são adicionadas
periodicamente):
Dependency Agent – Windows e Linux
Extensão de integridade do aplicativo – Windows e Linux
Habilitando o acesso de visualização

A habilitação da funcionalidade de visualização requer uma aceitação única para o recurso
AutomaticExtensionUpgradePreview por assinatura, conforme detalhado abaixo.
API REST
O exemplo a seguir descreve como habilitar a visualização para sua assinatura:
POST on
`/subscriptions/{subscriptionId}/providers/Microsoft.Features/providers/Microsoft.Compute/features/Automatic
ExtensionUpgradePreview/register?api-version=2015-12-01`
O registro de recursos pode levar até 15 minutos. Para verificar o status do registro:
GET on
`/subscriptions/{subscriptionId}/providers/Microsoft.Features/providers/Microsoft.Compute/features/Automatic
ExtensionUpgradePreview?api-version=2015-12-01`
Depois que o recurso tiver sido registrado para sua assinatura, conclua o processo de aceitação propagando a
alteração para o provedor de recursos de computação.
POST on `/subscriptions/{subscriptionId}/providers/Microsoft.Compute/register?api-version=2020-06-01`
Azure PowerShell
Use o cmdlet Register-AzProviderFeature para habilitar a visualização para sua assinatura.
Register-AzProviderFeature -FeatureName AutomaticExtensionUpgradePreview -ProviderNamespace

Microsoft.Compute
Get-AzProviderFeature -FeatureName AutomaticExtensionUpgradePreview -ProviderNamespace Microsoft.Compute
CLI do Azure
Use o registro de recurso AZ para habilitar a visualização para sua assinatura.
az feature register --namespace Microsoft.Compute --name AutomaticExtensionUpgradePreview
az feature show --namespace Microsoft.Compute --name AutomaticExtensionUpgradePreview
az provider register --namespace Microsoft.Compute
Habilitando a atualização de extensão automática

Para habilitar a atualização de extensão automática para uma extensão, você deve garantir que a propriedade
enableAutomaticUpgrade seja definida como true e adicionada a cada definição de extensão individualmente.
API REST para máquinas virtuais
Para habilitar a atualização de extensão automática para uma extensão (neste exemplo, a extensão de
Dependency Agent) em uma VM do Azure, use o seguinte:
PUT on
`/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachi
nes/<vmName>/extensions/<extensionName>?api-version=2019-12-01`
{
"name":"extensionName",
"type":"Microsoft.Compute/virtualMachines/extensions",
"location":"<location>",
"properties":{
"autoUpgradeMinorVersion":true,
"enableAutomaticUpgrade":true,
"publisher":"Microsoft.Azure.Monitoring.DependencyAgent",
"type":"DependencyAgentWindows",
"typeHandlerVersion":"9.5"
}
}
API REST para conjuntos de dimensionamento de máquinas virtuais

Use o seguinte para adicionar a extensão ao modelo do conjunto de dimensionamento:
PUT on
`/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/virtualMachi
neScaleSets/<vmssName>?api-version=2019-12-01`
{
"location":"<location>",
"properties":{
"virtualMachineProfile":{
"extensionProfile":{
"extensions":[
{
"name":"<extensionName>",
"properties":{
"autoUpgradeMinorVersion":true,
"enableAutomaticUpgrade":true,
"publisher":"Microsoft.Azure.Monitoring.DependencyAgent",
"type":"DependencyAgentWindows",
"typeHandlerVersion":"9.5"
}
}
]
}
}
}
}
Azure PowerShell para máquinas virtuais

Use o cmdlet set-AzVMExtension :
Set-AzVMExtension -ExtensionName "Microsoft.Azure.Monitoring.DependencyAgent" `

-VMName "myVM" `
-ExtensionType "DependencyAgentWindows" `
-Location WestUS `
-EnableAutomaticUpgrade $true
Azure PowerShell para conjuntos de dimensionamento de máquinas virtuais

Use o cmdlet Add-AzVmssExtension para adicionar a extensão ao modelo do conjunto de dimensionamento:
Add-AzVmssExtension -VirtualMachineScaleSet $vmss

-Name "Microsoft.Azure.Monitoring.DependencyAgent" `
-Type "DependencyAgentWindows" `
-EnableAutomaticUpgrade $true
Atualize o conjunto de dimensionamento usando Update-AzVmss depois de adicionar a extensão.

CLI do Azure para Máquinas Virtuais
Use o cmdlet AZ VM Extension Set :
--vm-name myVM \
--version 9.5 \
--enable-auto-upgrade true
CLI do Azure para conjuntos de dimensionamento de máquinas virtuais

Use o cmdlet AZ vmss Extension Set para adicionar a extensão ao modelo do conjunto de dimensionamento:
az vmss extension set \

--vmss-name myVMSS \
--version 9.5 \
--enable-auto-upgrade true
Atualizações de extensão com várias extensões

Um conjunto de dimensionamento de máquinas virtuais ou VM pode ter várias extensões com a atualização de
extensão automática habilitada. A mesma VM ou conjunto de dimensionamento também pode ter outras
extensões sem a atualização de extensão automática habilitada.
Se várias atualizações de extensão estiverem disponíveis para uma máquina virtual, as atualizações poderão ser
agrupadas em lote, mas cada atualização de extensão será aplicada individualmente em uma máquina virtual.
Uma falha em uma extensão não afeta as outras extensões que podem estar sendo atualizadas. Por exemplo, se
duas extensões estiverem agendadas para uma atualização e a primeira atualização de extensão falhar, a
segunda extensão ainda será atualizada.
As atualizações de extensão automática também podem ser aplicadas quando um conjunto de
dimensionamento de máquinas virtuais ou VM tem várias extensões configuradas com o sequenciamento de
extensão. O sequenciamento de extensão é aplicável para a primeira implantação da VM e qualquer atualização
de extensão futura em uma extensão é aplicada de forma independente.
Próximas etapas
Saiba mais sobre a extensão de integridade do aplicativo
Manipulando notificações de manutenção
planejada
O Azure realiza atualizações periodicamente para aumentar a confiabilidade, o desempenho e a segurança da

infraestrutura de host para máquinas virtuais. As atualizações são as alterações como, por exemplo, aplicação de
patches no ambiente de hospedagem ou atualização e desativação de hardware. A maioria dessas atualizações é
concluída sem nenhum impacto nas máquinas virtuais hospedadas. No entanto, há casos em que as
atualizações possuem um impacto:
Se a manutenção não exigir uma reinicialização, o Azure pausará a VM por alguns segundos enquanto o
host for atualizado. Esses tipos de operações de manutenção são aplicados ao domínio de falha por
domínio de falha. O andamento será interrompido se algum sinal de integridade de aviso for recebido.
Se a manutenção requer uma reinicialização, você receberá um aviso informando para quando a
manutenção está planejada. Você recebe uma janela de tempo de cerca de 35 dias, em que você pode
iniciar a manutenção por conta própria, quando ela funciona para você.
Uma manutenção planejada que requer uma reinicialização é agendada em ondas. Cada onda tem um escopo
diferente (regiões).
Uma onda começa com uma notificação para os clientes. Por padrão, a notificação é enviada para o
administrador da assinatura e os coadministradores. Você pode adicionar mais destinatários e opções de
mensagens como email, SMS e WebHooks, usando alertas do log de atividades.
Quando uma notificação sai, uma janela de autoatendimento é disponibilizada. Durante essa janela, você
pode consultar quais das suas máquinas virtuais são afetadas e iniciar a manutenção com base nas suas
necessidades de agendamento. A janela de autoatendimento normalmente é de cerca de 35 dias.
Após a janela de autoatendimento, janela de manutenção agendada inicia. Em algum momento durante esta
janela, o Azure agenda e aplica a manutenção necessária à sua máquina virtual.
O objetivo de ter duas janelas é dar a você tempo suficiente para iniciar a manutenção e reiniciar sua máquina
virtual sabendo quando o Azure iniciará automaticamente a manutenção.
Você pode usar o portal do Azure, o PowerShell, a API REST e a CLI para consultar as janelas de manutenção
para suas VMs e iniciar a manutenção de autoatendimento.
Você deve começar a usar a manutenção durante a janela de

autoatendimento?
As diretrizes a seguir devem ajudá-lo a decidir se você deseja usar essa funcionalidade e a iniciar a manutenção
no seu próprio tempo.
NOTE
A manutenção de autoatendimento pode não estar disponível para todas as suas VMs. Para determinar se a
reimplantação pró-ativa está disponível para sua VM, procure o status de manutenção Iniciar agora . No momento, a
manutenção de autoatendimento não está disponível para os serviços de nuvem (função Web/de trabalho) nem para o
Service Fabric.
A manutenção de autoatendimento não é recomendada para implantações usando conjuntos de

disponibilidade . Os conjuntos de disponibilidade já estão atualizados apenas em um domínio de atualização
por vez.
Permita que o Azure dispare a manutenção. Para manutenção que requer reinicialização, a manutenção será
feita ao atualizar domínio pelo domínio de atualização. Os domínios de atualização não recebem
necessariamente a manutenção sequencialmente e há uma pausa de 30 minutos entre os domínios de
atualização.
Se uma perda temporária de alguma capacidade (1 domínio de atualização) for uma preocupação, você
poderá adicionar instâncias durante o período de manutenção.
Para a manutenção que não exige reinicialização, as atualizações são aplicadas no nível do domínio de falha.
Não use o autoatendimento de manutenção nos seguintes cenários:
Se você desliga as VMs com frequência, seja manualmente, usando o DevTest Labs, usando o desligamento
automático ou seguindo um agendamento, é possível reverter o status de manutenção e, portanto, aumentar
o tempo de inatividade.
Em VMs de curta duração que você sabe que serão excluídas antes do final da onda de manutenção.
Para cargas de trabalho com um estado grande armazenado no disco local (efêmero) e que se deseja manter
após a atualização.
Para casos em que você redimensiona a VM com frequência, pois isso pode reverter o status de manutenção.
Se você adotou eventos agendados que permitem um failover proativo ou o desligamento normal da carga
de trabalho, 15 minutos antes do início do desligamento da manutenção
Use a manutenção de autoatendimento se você estiver planejando executar sua VM ininterrupta durante a fase
de manutenção agendada e nenhuma das indicações de contadores mencionadas acima são aplicáveis.
É melhor usar a manutenção de autoatendimento nos seguintes casos:
Você precisa comunicar uma janela de manutenção exata para o gerenciamento ou o cliente final.
Você precisa concluir a manutenção em uma determinada data.
Você precisa controlar a sequência de manutenção, por exemplo, o aplicativo de várias camadas para
garantir uma recuperação segura.
Mais de 30 minutos de tempo de recuperação de VM são necessários entre dois domínios de atualização
(UDs). Para controlar o tempo entre domínios de atualização, você deve disparar a manutenção em suas VMs
um domínio de atualização (UD) por vez.
P: por que você precisa reinicializar minhas máquinas vir tuais agora?
R: enquanto a maioria das atualizações para a plataforma do Azure não afete a disponibilidade da máquina
virtual, há casos em que não podemos evitar o reinício de máquinas virtuais hospedadas no Azure. Nós
acumulamos várias alterações que exigem que nossos servidores sejam reiniciados, o que resultará no reinício
das máquinas virtuais.
P: se eu seguir as recomendações para alta disponibilidade usando um conjunto de
disponibilidade, estou seguro?
R: as máquinas virtuais implantadas em um conjunto de disponibilidade ou conjuntos de dimensionamento de
máquinas virtuais têm a noção de UD (domínios de atualização). Ao fazer a manutenção, o Azure respeita a
restrição de UD e não reinicia máquinas virtuais de UDs diferentes (dentro do mesmo conjunto de
disponibilidade). O Azure também espera pelo menos 30 minutos antes de passar para o próximo grupo de
máquinas virtuais.
Para obter mais informações sobre alta disponibilidade, consulte disponibilidade para máquinas virtuais no
Azure.
P: como fazer para ser notificado sobre manutenção planejada?
R: uma onda manutenção planejada começa pela definição de uma agenda para uma ou mais regiões do Azure.
Logo após, uma notificação por email é enviada para os administradores de assinatura, os coadministradores,
os proprietários e os colaboradores (um email por assinatura). Os canais adicionais e os destinatários dessa
notificação podem ser configurados usando Alertas de Log de Atividades. Caso você implante uma máquina
virtual em uma região em que a manutenção planejada já foi agendada, não receberá a notificação e precisará
verificar o estado de manutenção da VM.
P: não vejo nenhuma indicação de manutenção planejada no por tal, no PowerShell ou na CLI. Qual
é o problema?
R: As informações relacionadas à manutenção planejada ficam disponíveis durante uma onda de manutenção
planejada apenas para as VMs que serão afetadas por ela. Em outras palavras, se você não vir os dados, pode
ser que a fase de manutenção já tenha sido concluída (ou não iniciada) ou que sua máquina virtual já esteja
hospedada em um servidor atualizado.
P: há uma maneira de saber exatamente quando minha máquina vir tual será afetada?
R: ao definir a agenda, definiremos um período de tempo de vários dias. No entanto, a sequência exata dos
servidores (e de VMs) nesse período é desconhecido. Os clientes que querem saber a hora exata para suas VMs
podem usar eventos agendados e consultar na máquina virtual para receber uma notificação de 15 minutos
antes do reinício de uma VM.
P: quanto tempo levará o reinício da minha máquina vir tual?
R: dependendo do tamanho da VM, o reinício poderá levar vários minutos durante a janela de manutenção por
autoatendimento. Durante as reinicializações iniciadas pelo Azure na janela de manutenção agendada, a
reinicialização geralmente levará cerca de 25 minutos. Observe que, caso você use Serviços de Nuvem (função
Web/de trabalho), Conjuntos de Dimensionamento de Máquinas Virtuais ou conjuntos de disponibilidade, você
terá 30 minutos entre cada grupo de VMs (UD) durante a janela de manutenção agendada.
P: Qual é a experiência no caso de conjuntos de dimensionamento de máquinas vir tuais?
R: A manutenção planejada agora está disponível para conjuntos de dimensionamento de máquinas virtuais.
Para obter instruções sobre como iniciar a manutenção de autoatendimento, consulte documento manutenção
planejada para conjuntos de dimensionamento de máquinas virtuais .
P: Qual é a experiência no caso de ser viços de nuvem (função Web/de trabalho) e do Ser vice
Fabric?
R: embora essas plataformas sejam afetadas pela manutenção planejada, considera-se que os clientes que usam
essas plataformas estejam seguros, já que somente as VMs em um UD (domínio de atualização) simples serão
afetadas em determinado momento. No momento, a manutenção de autoatendimento não está disponível para
os serviços de nuvem (função Web/de trabalho) nem para o Service Fabric.
P: não vejo nenhuma informação de manutenção em minhas VMs. O que deu errado?
R: existem várias razões para não se ver informações de manutenção em suas VMs:
1. Você está usando uma assinatura marcada como Microsoft interna.
2. Suas VMs não estão agendadas para manutenção. É possível que a onda de manutenção tenha sido
concluída, cancelada ou modificada de modo que suas VMs não são afetadas por ela.
3. Você tem a VM desalocada e a iniciou. Isso pode fazer com que a VM seja movida para um local que não
tenha a onda de manutenção planejada agendada. Portanto, a VM não mostrará mais informações de
manutenção.
4. Você não tem a coluna Manutenção adicionada ao modo de exibição de lista da VM. Embora tenhamos
adicionado essa coluna à exibição padrão, os clientes que configuraram para ver colunas não padrão devem
adicionar manualmente a coluna Manutenção ao modo de exibição de lista da VM.
P: minha VM está agendada para manutenção pela segunda vez. Por?
R: há diversos casos de uso em que você verá sua VM agendada para manutenção depois de ter concluído a
reimplantação da manutenção:
1. Nós cancelamos a fase de manutenção e a reiniciamos com uma carga diferente. É possível que tenhamos
detectado uma carga com falha e seja necessário simplesmente implantar uma carga adicional.
2. Sua máquina virtual teve o serviço autorrestabelecido para outro nó devido a uma falha de hardware.
3. Você optou por parar (desalocar) e reiniciar a VM.
4. O desligamento automático está ativado para a VM.
Próximas etapas
Você pode lidar com a manutenção planejada usando o CLI do Azure, Azure PowerShell ou portal.
Manipulando notificações de manutenção
planejada usando o CLI do Azure
Este ar tigo se aplica a máquinas vir tuais que executam o Linux e o Windows.
Você pode usar a CLI para ver quando as VMs estão agendadas para manutenção. As informações de
manutenção planejada estão disponíveis em AZ VM Get-Instance-View.
As informações de manutenção só serão retornadas se houver manutenção planejada.
az vm get-instance-view -n myVM -g myResourceGroup --query instanceView.maintenanceRedeployStatus
Saída
"maintenanceRedeployStatus": {
"additionalProperties": {},
"isCustomerInitiatedMaintenanceAllowed": true,
"lastOperationMessage": null,
"lastOperationResultCode": "None",
"maintenanceWindowEndTime": "2018-06-04T16:30:00+00:00",
"maintenanceWindowStartTime": "2018-05-21T16:30:00+00:00",
"preMaintenanceWindowEndTime": "2018-05-19T12:30:00+00:00",
"preMaintenanceWindowStartTime": "2018-05-14T12:30:00+00:00"
Iniciar manutenção
A chamada a seguir iniciará a manutenção em uma VM se IsCustomerInitiatedMaintenanceAllowed for definido
como true.
az vm perform-maintenance -g myResourceGroup -n myVM
IMPORTANT
Caso você ainda tenha VMs herdadas que foram implantadas usando o modelo de implantação clássico, use a
CLI Clássica do Azure para consultar VMs e iniciar a manutenção.
Verifique se você está no modo correto para trabalhar com a VM clássica digitando:

Para obter o status de manutenção de uma VM chamada myVM, digite:
azure vm show myVM
Para iniciar a manutenção na VM clássica chamada myVM no serviço myService e na implantação

myDeployment, digite:
azure compute virtual-machine initiate-maintenance --service-name myService --name myDeployment --virtual-

machine-name myVM
Próximas etapas
Você também pode manipular a manutenção planejada usando o Azure PowerShell ou o portal.
Lidando com notificações de manutenção planejada
usando o portal
Depois que uma onda de manutenção planejada for agendada, você poderá verificar se há uma lista de
máquinas virtuais afetadas.
É possível usar o portal do Azure e procurar as VMs agendadas para manutenção.
2. No painel de navegação esquerdo, clique em máquinas vir tuais .
3. No painel máquinas virtuais, selecione o botão Editar colunas para abrir a lista de colunas disponíveis.
4. Selecione e adicione as seguintes colunas:
Status de manutenção : mostra o status de manutenção para a VM. Estes são os valores possíveis:
VA LO R DESC RIÇ Ã O
Comece agora A VM está na janela de manutenção de

autoatendimento que permite que você inicie a
manutenção por conta própria. Veja abaixo como iniciar
a manutenção em sua VM.
Agendado A VM está agendada para manutenção sem a opção de

iniciar a manutenção. Você pode aprender sobre a janela
de manutenção selecionando a janela de manutenção
agendada neste modo de exibição ou clicando na VM.
Já atualizado Sua VM já está atualizada e nenhuma ação adicional é

necessária no momento.
Tente novamente mais tarde Você iniciou a manutenção, mas ela apresentou falha.
Você poderá usar a opção de manutenção de
autoatendimento em um momento posterior.
Tente agora Você pode tentar novamente uma manutenção

autoiniciada anteriormente malsucedida.
- Sua VM não faz parte de uma onda de manutenção

planejada.
Janela de manutenção de autoatendimento : mostra a janela de tempo, quando é possível iniciar

automaticamente a manutenção nas VMs.
Janela de manutenção agendada : mostra a janela de tempo, quando o Azure fará a manutenção da
VM.
Notificação e alertas no portal

O Azure comunica uma agenda para manutenção planejada, enviando um email para o grupo de proprietário e
os coadministradores de assinatura. Você pode adicionar outros destinatários e canais para essa comunicação
com a criação de alertas de log de atividades do Azure. Para obter mais informações, consulte Criar alertas do
log de atividades em notificações de serviço.
Certifique-se de definir o tipo de evento como manutenção planejada e Ser viços como conjuntos de
dimensionamento de máquinas virtuais e/ou máquinas vir tuais .
Iniciar Manutenção na sua VM do portal

Ao examinar os detalhes da VM, você poderá ver mais detalhes relacionados à manutenção.
Na parte superior do modo de exibição de detalhes VM, uma nova faixa de opções de notificação será
adicionada se sua VM for incluída em uma onda de manutenção planejada. Além disso, uma nova opção é
adicionada ao iniciar manutenção quando possível.
Clique na notificação de manutenção para ver a página de manutenção com mais detalhes sobre a manutenção
planejada. Nesse local, você pode iniciar a manutenção da VM.
Quando você inicia a manutenção, a máquina virtual passa pelo processo de manutenção e o respectivo status é
atualizado para refletir o resultado dentro de alguns minutos.
Caso perca a janela de autoatendimento, você ainda poderá exibi-la quando a VM passar pela manutenção do
Microsoft Azure.
Próximas etapas
Você também pode manipular a manutenção planejada usando o CLI do Azure ou o PowerShell.
Manipulando a manutenção planejada usando o
PowerShell
Você pode usar Azure PowerShell para ver quando as VMs estão agendadas para manutenção. As informações
de manutenção planejadas estão disponíveis no cmdlet Get-AzVM quando você usa o parâmetro -status .
As informações de manutenção só serão retornadas se houver manutenção planejada. Se não houver nenhuma
manutenção agendada que afete a VM, o cmdlet não retornará nenhuma informação de manutenção.
Get-AzVM -ResourceGroupName myResourceGroup -Name myVM -Status
Saída
MaintenanceRedeployStatus :
IsCustomerInitiatedMaintenanceAllowed : True
PreMaintenanceWindowStartTime : 5/14/2018 12:30:00 PM
PreMaintenanceWindowEndTime : 5/19/2018 12:30:00 PM
MaintenanceWindowStartTime : 5/21/2018 4:30:00 PM
MaintenanceWindowEndTime : 6/4/2018 4:30
LastOperationResultCode : None
As propriedades a seguir são retornadas em MaintenanceRedeployStatus:
VA LO R DESC RIÇ Ã O
IsCustomerInitiatedMaintenanceAllowed Indica se você pode iniciar a manutenção na máquina virtual

neste momento
PreMaintenanceWindowStartTime O início da janela de autoatendimento de manutenção

quando você pode iniciar a manutenção na sua VM
PreMaintenanceWindowEndTime O fim da janela de autoatendimento de manutenção quando

você pode iniciar manutenção na sua VM
MaintenanceWindowStartTime O início da manutenção agendada na qual o Azure inicia a

manutenção na sua VM
MaintenanceWindowEndTime O término da janela de manutenção agendada na qual o

Azure inicia a manutenção na sua VM
LastOperationResultCode O resultado da última tentativa de iniciar a manutenção na

VM
Você também pode obter o status de manutenção para todas as VMs em um grupo de recursos usando Get-
AzVM, sem especificar a VM.
Get-AzVM -ResourceGroupName myResourceGroup -Status

O exemplo do PowerShell a seguir usa sua ID de assinatura e retorna uma lista de VMs que estão agendadas
para manutenção.
function MaintenanceIterator
{
Select-AzSubscription -SubscriptionId $args[0]
$rgList= Get-AzResourceGroup
for ($rgIdx=0; $rgIdx -lt $rgList.Length ; $rgIdx++)

{
$rg = $rgList[$rgIdx]
$vmList = Get-AzVM -ResourceGroupName $rg.ResourceGroupName
for ($vmIdx=0; $vmIdx -lt $vmList.Length ; $vmIdx++)
{
$vm = $vmList[$vmIdx]
$vmDetails = Get-AzVM -ResourceGroupName $rg.ResourceGroupName -Name $vm.Name -Status
if ($vmDetails.MaintenanceRedeployStatus )
{
Write-Output "VM: $($vmDetails.Name) IsCustomerInitiatedMaintenanceAllowed:
$($vmDetails.MaintenanceRedeployStatus.IsCustomerInitiatedMaintenanceAllowed)
$($vmDetails.MaintenanceRedeployStatus.LastOperationMessage)"
}
}
}
}
Iniciar manutenção na sua VM usando o PowerShell

Usando as informações da função na seção anterior, o seguinte iniciará a manutenção em uma VM se
IsCustomerInitiatedMaintenanceAllowed for definido como true.
Restart-AzVM -PerformMaintenance -name $vm.Name -ResourceGroupName $rg.ResourceGroupName
IMPORTANT
Caso você ainda tenha VMs herdadas que foram implantadas usando o modelo de implantação clássico, use o
PowerShell para consultar VMs e iniciar a manutenção.
Para obter o status de manutenção de uma VM, digite:
Get-AzureVM -ServiceName <Service name> -Name <VM name>
Para iniciar a manutenção na VM clássica, digite:
Restart-AzureVM -InitiateMaintenance -ServiceName <service name> -Name <VM name>

Próximas etapas
Você também pode manipular a manutenção planejada usando o CLI do Azure ou o portal.
Gerenciando atualizações de plataforma com o
controle de manutenção
Gerenciar atualizações de plataforma, que não exigem uma reinicialização, usando o controle de manutenção. O
Azure frequentemente atualiza sua infraestrutura para melhorar a confiabilidade, desempenho, segurança ou
lançamento de novos recursos. A maioria das atualizações é transparente para os usuários. Algumas cargas de
trabalho confidenciais, como jogos, streaming de mídia e transações financeiras, não podem tolerar até poucos
segundos de uma VM congelando ou desconectando para manutenção. O controle de manutenção oferece a
opção de aguardar atualizações de plataforma e aplicá-las em uma janela sem interrupção de 35 dias.
O controle de manutenção permite que você decida quando aplicar atualizações às VMs isoladas e aos hosts
dedicados do Azure.
Com o controle de manutenção, você pode:
Atualizações em lote em um pacote de atualização.
Aguarde até 35 dias para aplicar atualizações.
Automatize as atualizações de plataforma Configurando um agendamento de manutenção ou usando Azure
Functions.
As configurações de manutenção funcionam em assinaturas e grupos de recursos.
Limitações
As VMs devem estar em um host dedicadoou ser criadas usando um tamanho de VM isolado.
Se uma agenda de manutenção for declarada, ela deverá ser pelo menos 2 horas.
Após 35 dias, uma atualização será aplicada automaticamente.
O usuário deve ter acesso de colaborador de recurso .
Opções de gerenciamento
Você pode criar e gerenciar configurações de manutenção usando qualquer uma das seguintes opções:
CLI do Azure
PowerShell do Azure
Azure portal
Para obter um exemplo de Azure Functions, consulte agendando atualizações de manutenção com o controle de
manutenção e Azure Functions.
Próximas etapas
Para saber mais, consulte manutenção e atualizações.
Controlar atualizações com o controle de
manutenção e o CLI do Azure
O controle de manutenção permite que você decida quando aplicar atualizações de plataforma à infraestrutura
de host de suas VMs isoladas e hosts dedicados do Azure. Este tópico aborda as opções de CLI do Azure para o
controle de manutenção. Para obter mais informações sobre os benefícios de usar o controle de manutenção,
suas limitações e outras opções de gerenciamento, consulte gerenciando atualizações de plataforma com o
controle de manutenção.
Criar uma configuração de manutenção

Use az maintenance configuration create para criar uma configuração de manutenção. Este exemplo cria uma
configuração de manutenção chamada myconfig com escopo para o host.
az group create \
--location eastus \
--name myMaintenanceRG
az maintenance configuration create \
-g myMaintenanceRG \
--resource-name myConfig \
--maintenance-scope host\
--location eastus
Copie a ID de configuração da saída para usar mais tarde.

O uso de --maintenance-scope host garante que a configuração de manutenção seja usada para controlar
atualizações na infraestrutura de host.
Se você tentar criar uma configuração com o mesmo nome, mas em um local diferente, receberá um erro. Os
nomes de configuração devem ser exclusivos para seu grupo de recursos.
Você pode consultar as configurações de manutenção disponíveis usando az maintenance configuration list .
az maintenance configuration list --query "[].{Name:name, ID:id}" -o table
Criar uma configuração de manutenção com a janela agendada

Você também pode declarar uma janela agendada quando o Azure aplicará as atualizações em seus recursos.
Este exemplo cria uma configuração de manutenção chamada myconfig com uma janela agendada de 5 horas
na quarta segunda-feira de cada mês. Depois de criar uma janela agendada, você não precisa mais aplicar as
atualizações manualmente.
az maintenance configuration create \

-g myMaintenanceRG \
--resource-name myConfig \
--maintenance-scope host \
--location eastus \
--maintenance-window-duration "05:00" \
--maintenance-window-recur-every "Month Fourth Monday" \
--maintenance-window-start-date-time "2020-12-30 08:00" \
--maintenance-window-time-zone "Pacific Standard Time"
IMPORTANT
A duração da manutenção deve ser de 2 horas ou mais. A recorrência de manutenção deve ser definida para pelo
menos ocorrer uma vez em 35 dias.
A recorrência da manutenção pode ser expressa como diária, semanal ou mensal. Alguns exemplos são:
diário -manutenção-janela-recorrência-a cada: "dia" ou "3Days"
semanalmente -manutenção-janela-recorrência-a cada: "3Weeks" ou "semana sábado, domingo"
mensal -manutenção-janela-recorrência-a cada: "month day23, day24" ou "month Last domingo" ou
"month quarta segunda-feira"
Atribuir a configuração
Use az maintenance assignment create para atribuir a configuração à VM isolada ou ao host dedicado do Azure.
VM isolada
Aplique a configuração a uma VM usando a ID da configuração. Especifique --resource-type virtualMachines e
forneça o nome da VM para --resource-name , e o grupo de recursos para a VM no --resource-group , e o local
da VM para --location .
az maintenance assignment create \

--resource-group myMaintenanceRG \
--location eastus \
--resource-type virtualMachines \
--provider-name Microsoft.Compute \
--configuration-assignment-name myConfig \
--maintenance-configuration-id "/subscriptions/1111abcd-1a11-1a2b-1a12-
123456789abc/resourcegroups/myMaintenanceRG/providers/Microsoft.Maintenance/maintenanceConfigurations/myConf
ig"
Host dedicado
Para aplicar uma configuração a um host dedicado, você precisa incluir --resource-type hosts ,
--resource-parent-name com o nome do grupo de hosts e --resource-parent-type hostGroups .
O parâmetro --resource-id é a ID do host. Você pode usar AZ VM host Get-Instance-View para obter a ID do
host dedicado.
az maintenance assignment create \

--resource-name myHost \
--resource-type hosts \
--configuration-assignment-name myConfig \
--maintenance-configuration-id "/subscriptions/1111abcd-1a11-1a2b-1a12-
123456789abc/resourcegroups/myDhResourceGroup/providers/Microsoft.Maintenance/maintenanceConfigurations/myCo
nfig" \
-l eastus \
--resource-parent-name myHostGroup \
--resource-parent-type hostGroups
Verificar configuração
Você pode verificar se a configuração foi aplicada corretamente ou verificar qual configuração está aplicada no
momento usando az maintenance assignment list .
VM isolada
az maintenance assignment list \

--query "[].{resource:resourceGroup, configName:name}" \
--output table
Host dedicado
az maintenance assignment list \

--resource-group myDHResourceGroup \
--query "[].{ResourceGroup:resourceGroup,configName:name}" \
-o table
Verificar se há atualizações pendentes

Use az maintenance update list para ver se há atualizações pendentes. Update--Subscription para ser a ID da
assinatura que contém a VM.
Se não houver nenhuma atualização, o comando retornará uma mensagem de erro, que conterá o texto:
Resource not found...StatusCode: 404 .
Se houver atualizações, apenas uma será retornada, mesmo se houver várias atualizações pendentes. Os dados
desta atualização serão retornados em um objeto:
[
{
"impactDurationInSec": 9,
"impactType": "Freeze",
"maintenanceScope": "Host",
"notBefore": "2020-03-03T07:23:04.905538+00:00",
"resourceId": "/subscriptions/9120c5ff-e78e-4bd0-b29f-
75c19cadd078/resourcegroups/DemoRG/providers/Microsoft.Compute/hostGroups/demoHostGroup/hosts/myHost",
"status": "Pending"
}
]
VM isolada
Verifique se há atualizações pendentes para uma VM isolada. Neste exemplo, a saída é formatada como uma
tabela para facilitar a leitura.
az maintenance update list \

-g myMaintenanceRg \
-o table
Host dedicado
Para verificar se há atualizações pendentes para um host dedicado. Neste exemplo, a saída é formatada como
uma tabela para facilitar a leitura. Substitua os valores dos recursos pelos seus próprios.
az maintenance update list \

--subscription 1111abcd-1a11-1a2b-1a12-123456789abc \
-g myHostResourceGroup \
--resource-parentname myHostGroup \
--resource-parent-type hostGroups \
-o table
Aplicar atualizações
Use az maintenance apply update para aplicar atualizações pendentes. Em caso de sucesso, esse comando
retornará JSON contendo os detalhes da atualização.
VM isolada
Crie uma solicitação para aplicar atualizações a uma VM isolada.
az maintenance applyupdate create \

--provider-name Microsoft.Compute
Host dedicado
Aplicar atualizações a um host dedicado.
az maintenance applyupdate create \

--resource-group myHostResourceGroup \
Verificar o status da aplicação de atualizações

Você pode verificar o progresso das atualizações usando az maintenance applyupdate get .
Você pode usar default como o nome da atualização para ver os resultados da última atualização ou substituir
myUpdateName pelo nome da atualização que foi retornada quando você executou
az maintenance applyupdate create .
Status : Completed
ResourceId : /subscriptions/12ae7457-4a34-465c-94c1-
17c058c2bd25/resourcegroups/TestShantS/providers/Microsoft.Comp
ute/virtualMachines/DXT-test-04-iso
LastUpdateTime : 1/1/2020 12:00:00 AM
Id : /subscriptions/12ae7457-4a34-465c-94c1-
ute/virtualMachines/DXT-test-04-iso/providers/Microsoft.Maintenance/applyUpdates/default
Name : default
Type : Microsoft.Maintenance/applyUpdates
LastUpdateTime será a hora em que a atualização foi concluída, iniciada por você ou pela plataforma caso a
janela de automanutenção não tenha sido usada. Se nunca houvesse uma atualização aplicada por meio do
controle de manutenção, o valor padrão será exibido.
VM isolada
az maintenance applyupdate get \

--apply-update-name default
Host dedicado
az maintenance applyupdate get \

--resource-parent-type hostGroups \
--apply-update-name myUpdateName \
--query "{LastUpdate:lastUpdateTime, Name:name, ResourceGroup:resourceGroup, Status:status}" \
--output table
Excluir uma configuração de manutenção

Use az maintenance configuration delete para excluir uma configuração de manutenção. A exclusão da
configuração remove o controle de manutenção dos recursos associados.
az maintenance configuration delete \

--resource-name myConfig
Próximas etapas
Para saber mais, consulte manutenção e atualizações.
Controlar atualizações com controle de
manutenção e Azure PowerShell
O controle de manutenção permite que você decida quando aplicar atualizações de plataforma à infraestrutura
de host de suas VMs isoladas e hosts dedicados do Azure. Este tópico aborda as opções de Azure PowerShell
para o controle de manutenção. Para obter mais informações sobre os benefícios de usar o controle de
manutenção, suas limitações e outras opções de gerenciamento, consulte gerenciando atualizações de
plataforma com o controle de manutenção.
Habilitar o módulo do PowerShell

Lembre-se de que o PowerShellGet está atualizado.
Install-Module -Name PowerShellGet -Repository PSGallery -Force
Instale o Az.Maintenance módulo do PowerShell.
Install-Module -Name Az.Maintenance
Se você estiver instalando localmente, abra o prompt do PowerShell como administrador.

Você também pode ser solicitado a confirmar que deseja instalar a partir de um repositório não confiável. Digite
Y ou selecione Sim para todos para instalar o módulo.
Criar uma configuração de manutenção

Crie um grupo de recursos como um contêiner para sua configuração. Neste exemplo, um grupo de recursos
chamado myMaintenanceRG é criado em lesteus. Se você já tiver um grupo de recursos que deseja usar, poderá
ignorar essa parte e substituir o nome do grupo de recursos por sua conta no restante dos exemplos.
-Location eastus `
-Name myMaintenanceRG
Use New-AzMaintenanceConfiguration para criar uma configuração de manutenção. Este exemplo cria uma
configuração de manutenção chamada myconfig com escopo para o host.
$config = New-AzMaintenanceConfiguration `
-ResourceGroup myMaintenanceRG `
-Name myConfig `
-MaintenanceScope host `
-Location eastus
O uso de -MaintenanceScope host garante que a configuração de manutenção seja usada para controlar
atualizações no host.
Se você tentar criar uma configuração com o mesmo nome, mas em um local diferente, receberá um erro. Os
nomes de configuração devem ser exclusivos para seu grupo de recursos.
Você pode consultar as configurações de manutenção disponíveis usando Get-AzMaintenanceConfiguration.
Get-AzMaintenanceConfiguration | Format-Table -Property Name,Id
Criar uma configuração de manutenção com a janela agendada

Você também pode declarar uma janela agendada quando o Azure aplicará as atualizações em seus recursos.
Este exemplo cria uma configuração de manutenção chamada myconfig com uma janela agendada de 5 horas
na quarta segunda-feira de cada mês. Depois de criar uma janela agendada, você não precisa mais aplicar as
atualizações manualmente.
$config = New-AzMaintenanceConfiguration `
-ResourceGroup $RGName `
-Name $MaintenanceConfig `
-MaintenanceScope Host `
-StartDateTime "2020-10-01 00:00" `
-TimeZone "Pacific Standard Time" `
-Duration "05:00" `
-RecurEvery "Month Fourth Monday"
IMPORTANT
A duração da manutenção deve ser de 2 horas ou mais. A recorrência de manutenção deve ser definida para pelo
menos ocorrer uma vez em 35 dias.
A recorrência da manutenção pode ser expressa como diária, semanal ou mensal. Alguns exemplos são:
Daily -RecurEvery "Day" ou "3Days"
Weekly -RecurEvery "3Weeks" ou "Week sábado, domingo"
mensal -RecurEvery "mês day23, day24" ou "mês, último domingo" ou "mês quarta-feira"
Atribuir a configuração
Use New-AzConfigurationAssignment para atribuir a configuração à VM isolada ou ao host dedicado do Azure.
VM isolada
Aplique a configuração a uma VM usando a ID da configuração. Especifique -ResourceType VirtualMachines e
forneça o nome da VM para -ResourceName e o grupo de recursos da VM para -ResourceGroupName .
New-AzConfigurationAssignment `
-Location eastus `
-ResourceType VirtualMachines `
-ProviderName Microsoft.Compute `
-ConfigurationAssignmentName $config.Name `
-MaintenanceConfigurationId $config.Id
Host dedicado
Para aplicar uma configuração a um host dedicado, você também precisa incluir -ResourceType hosts ,
-ResourceParentName com o nome do grupo de hosts e -ResourceParentType hostGroups .
New-AzConfigurationAssignment `
-Location eastus `
-ResourceName myHost `
-ResourceType hosts `
-ResourceParentName myHostGroup `
-ResourceParentType hostGroups `
-ProviderName Microsoft.Compute `
-ConfigurationAssignmentName $config.Name `
-MaintenanceConfigurationId $config.Id
Verificar se há atualizações pendentes

Use Get-AzMaintenanceUpdate para ver se há atualizações pendentes. Use -subscription para especificar a
assinatura do Azure da VM se ela for diferente da que você fez logon.
Se não houver nenhuma atualização para mostrar, esse comando não retornará nada. Caso contrário, retornará
um objeto PSApplyUpdate:
{
"maintenanceScope": "Host",
"impactType": "Freeze",
"status": "Pending",
"impactDurationInSec": 9,
"notBefore": "2020-02-21T16:47:44.8728029Z",
"properties": {
"resourceId": "/subscriptions/39c6cced-4d6c-4dd5-af86-
57499cd3f846/resourcegroups/Ignite2019/providers/Microsoft.Compute/virtualMachines/MCDemo3"
}
VM isolada
Verifique se há atualizações pendentes para uma VM isolada. Neste exemplo, a saída é formatada como uma
tabela para facilitar a leitura.
Get-AzMaintenanceUpdate `
-ProviderName Microsoft.Compute | Format-Table
Host dedicado
Para verificar se há atualizações pendentes para um host dedicado. Neste exemplo, a saída é formatada como
uma tabela para facilitar a leitura. Substitua os valores dos recursos pelos seus próprios.
Get-AzMaintenanceUpdate `
-ProviderName Microsoft.Compute | Format-Table
Aplicar atualizações
Use New-AzApplyUpdate para aplicar atualizações pendentes.
VM isolada
Crie uma solicitação para aplicar atualizações a uma VM isolada.
New-AzApplyUpdate `
-ProviderName Microsoft.Compute
Em caso de êxito, esse comando retornará um PSApplyUpdate objeto. Você pode usar o atributo Name no
Get-AzApplyUpdate comando para verificar o status da atualização. Consulte verificar status da atualização.
Host dedicado
Aplicar atualizações a um host dedicado.
New-AzApplyUpdate `
-ProviderName Microsoft.Compute
Verificar status da atualização

Use Get-AzApplyUpdate para verificar o status de uma atualização. Os comandos mostrados abaixo mostram o
status da atualização mais recente usando default o para o -ApplyUpdateName parâmetro. Você pode substituir
o nome da atualização (retornado pelo comando New-AzApplyUpdate ) para obter o status de uma atualização
específica.
Status : Completed
ResourceId : /subscriptions/12ae7457-4a34-465c-94c1-
ute/virtualMachines/DXT-test-04-iso
LastUpdateTime : 1/1/2020 12:00:00 AM
Id : /subscriptions/12ae7457-4a34-465c-94c1-
ute/virtualMachines/DXT-test-04-iso/providers/Microsoft.Maintenance/applyUpdates/default
Name : de

Tutorial Azure 1

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Tutorial Azure 1

Enviado por

Direitos autorais:

Formatos disponíveis

Contents

Documentação de Máquinas Virtuais

O que é necessário pensar antes de criar uma VM?

M ÉTO DO DESC RIÇ Ã O

Azure PowerShell Use o comando Get-AzLocation.

API REST Use a operação Listar locais.

CLI do Azure Use a operação az account list-locations.

Residência de dadosResidência de dados

O que é necessário pensar antes de criar uma VM?

M ÉTO DO DESC RIÇ Ã O

Azure PowerShell Use o comando Get-AzLocation.

API REST Use a operação Listar locais.

CLI do Azure Use a operação az account list-locations.

M ÉTO DO DESC RIÇ Ã O

Portal do Azure Os valores são especificados automaticamente quando você

Azure PowerShell Get-AzVMImagePublisher -Location location

APIs REST Listar editores de imagem

CLI do Azure az vm image list-publishers --location location

REC URSO O B RIGATÓ RIO DESC RIÇ Ã O

Grupo de recursos Sim A VM deve estar contida em um grupo

Conta de armazenamento Sim A VM precisa da conta de

Rede virtual Sim A VM deve ser membro de uma rede

Endereço IP público Não A VM pode ter um endereço IP público

Interface de rede Sim A VM precisa de interface de rede para

Discos de dados Não A VM pode incluir discos de dados

Residência de dadosResidência de dados

Iniciar o Azure Cloud Shell

Criar um grupo de recursos

az group create --name myResourceGroup --location eastus

Criar máquina virtual

Abra a porta 80 para tráfego da Web

az vm open-port --port 80 --resource-group myResourceGroup --name myVM

Conectar-se à máquina virtual

Instalar servidor Web

sudo apt-get -y update

Quando terminar, digite exit para sair da sessão SSH.

Ver o servidor Web em ação

az group delete --name myResourceGroup

Criar máquina virtual

6. Em Conta do administrador , selecione Chave pública SSH .

Conectar-se à máquina virtual

Instalar servidor Web

sudo apt-get -y update

Quando terminar, digite exit para sair da sessão SSH.

Ver o servidor Web em ação

Iniciar o Azure Cloud Shell

Criar o par de chaves SSH

ssh-keygen -m PEM -t rsa -b 4096

Criar um grupo de recursos

New-AzResourceGroup -Name "myResourceGroup" -Location "EastUS"

Criar recursos de rede virtual

# Create a subnet configuration

# Create a virtual network

# Create a public IP address and specify a DNS name

# Create an inbound network security group rule for port 22

# Create an inbound network security group rule for port 80

# Create a network security group

Criar uma máquina virtual

# Define a credential object

# Create a virtual machine configuration

# Configure the SSH key

Agora, combine as definições de configuração anteriores para criar com New-AzVM:

sudo apt-get -y update

Quando terminar, digite exit para sair da sessão SSH.