Tutorial Azure 1
Tutorial Azure 1
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.
Portal do Azure Selecione um local na lista quando você criar uma VM.
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
Próximas etapas
Crie sua primeira VM!
Portal
CLI do Azure
PowerShell
Máquinas virtuais do Windows no Azure
03/03/2021 • 11 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.
Portal do Azure Selecione um local na lista quando você criar uma VM.
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.
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.
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
03/11/2020 • 6 minutes to read • Edit Online
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.
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.
ssh azureuser@publicIpAddress
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
03/03/2021 • 6 minutes to read • Edit Online
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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Entrar no Azure
Entre no portal do Azure, se você ainda não fez isso.
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.
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.
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.
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.
Tutoriais de máquina virtual do Linux Azure
Início Rápido: Criar uma máquina virtual do Linux
no Azure com o PowerShell
03/11/2020 • 9 minutes to read • Edit Online
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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
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 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.
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" `
-ResourceGroupName "myResourceGroup" `
-Location "EastUS" `
-SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $pip.Id `
-NetworkSecurityGroupId $nsg.Id
New-AzVM `
-ResourceGroupName "myResourceGroup" `
-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.
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.
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:
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.
Tutoriais de máquina virtual do Linux Azure
Início Rápido: Criar uma máquina virtual do Ubuntu
Linux usando um modelo do Resource Manager
03/11/2020 • 8 minutes to read • Edit Online
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
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
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')]",
"location": "[parameters('location')]",
"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')]",
"location": "[parameters('location')]",
"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')]",
"location": "[parameters('location')]",
"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')]",
"location": "[parameters('location')]",
"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)]"
}
}
}
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.
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.
Tutoriais de máquina virtual do Linux Azure
Início Rápido: Criar uma máquina virtual do
Windows com a CLI do Azure
03/11/2020 • 6 minutes to read • Edit Online
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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image win2016datacenter \
--admin-username azureuser
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": "52.174.34.95",
"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.
mstsc /v:publicIpAddress
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 Windows.
Tutoriais de máquina virtual do Windows Azure
Início Rápido: Criar uma máquina virtual do
Windows no Portal do Azure
03/03/2021 • 5 minutes to read • Edit Online
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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Entrar no Azure
Entre no Portal do Azure em https://portal.azure.com.
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.
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.
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.
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
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 Windows.
Tutoriais de máquina virtual do Windows Azure
Início Rápido: criar uma máquina virtual do
Windows no Azure com o PowerShell
03/11/2020 • 5 minutes to read • Edit Online
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 (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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Name "myVM" `
-Location "East US" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-PublicIpAddressName "myPublicIpAddress" `
-OpenPorts 80,3389
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
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 Windows.
Tutoriais de máquina virtual do Windows Azure
Início Rápido: Criar uma máquina virtual do
Windows usando um modelo do Resource Manager
03/11/2020 • 7 minutes to read • Edit Online
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
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
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": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
},
"adminPassword": {
"type": "securestring",
"minLength": 12,
"metadata": {
"description": "Password for the Virtual Machine."
}
},
"dnsLabelPrefix": {
"type": "string",
"defaultValue": "[toLower(concat(parameters('vmName'),'-', uniqueString(resourceGroup().id,
parameters('vmName'))))]",
"metadata": {
"description": "Unique DNS Name for the Public IP used to access the Virtual Machine."
}
},
"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",
"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",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
},
"vmName": {
"type": "string",
"defaultValue": "simple-vm",
"metadata": {
"description": "Name of the virtual machine."
}
}
},
"variables": {
"storageAccountName": "[concat('bootdiags', uniquestring(resourceGroup().id))]",
"storageAccountName": "[concat('bootdiags', uniquestring(resourceGroup().id))]",
"nicName": "myVMNic",
"addressPrefix": "10.0.0.0/16",
"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')]",
"location": "[parameters('location')]",
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"properties": {}
},
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2020-06-01",
"name": "[parameters('publicIPName')]",
"location": "[parameters('location')]",
"sku": {
"name": "[parameters('publicIpSku')]"
},
"properties": {
"publicIPAllocationMethod": "[parameters('publicIPAllocationMethod')]",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsLabelPrefix')]"
}
}
},
{
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2020-06-01",
"name": "[variables('networkSecurityGroupName')]",
"location": "[parameters('location')]",
"properties": {
"securityRules": [
{
"name": "default-allow-3389",
"properties": {
"priority": 1000,
"access": "Allow",
"direction": "Inbound",
"destinationPortRange": "3389",
"protocol": "Tcp",
"sourcePortRange": "*",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*"
}
}
]
}
},
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2020-06-01",
"name": "[variables('virtualNetworkName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
],
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('addressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]",
"networkSecurityGroup": {
"id": "[resourceId('Microsoft.Network/networkSecurityGroups',
variables('networkSecurityGroupName'))]"
}
}
}
]
}
},
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2020-06-01",
"name": "[variables('nicName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPName'))]",
"[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworkName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPName'))]"
},
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2020-06-01",
"name": "[parameters('vmName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('vmSize')]"
},
"osProfile": {
"computerName": "[parameters('vmName')]",
"adminUsername": "[parameters('adminUsername')]",
"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": {
"networkInterfaces": [
{
"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]"
}
}
}
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.
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.
Tutoriais de máquina virtual do Windows Azure
Tutorial: Criar e gerenciar VMs do Linux com a CLI
do Azure
03/11/2020 • 16 minutes to read • Edit Online
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.
O grupo de recursos é especificado ao criar ou modificar uma VM, que pode ser visto durante este tutorial.
az vm create \
--resource-group myResourceGroupVM \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--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",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "52.174.34.95",
"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.
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 .
Resultado parcial:
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.
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.
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.
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.
GPU NV, NVv2, NC, NCv2, NCv3, ND VMs especializadas, destinadas para
renderização gráfica e edição de vídeo
pesadas.
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
az vm create \
--resource-group myResourceGroupVM \
--name myVM3 \
--image UbuntuLTS \
--size Standard_F4s \
--generate-ssh-keys
Redimensionar uma VM
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:
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.
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.
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
az vm get-instance-view \
--name myVM \
--resource-group myResourceGroupVM \
--query instanceView.statuses[1] --output table
Saída:
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.
Próximas etapas
Neste tutorial, você aprendeu sobre a criação e o gerenciamento básico de VM e 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
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
03/11/2020 • 17 minutes to read • Edit Online
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
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
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
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
az vm disk attach \
--resource-group myResourceGroupDisk \
--vm-name myVM \
--name myDataDisk \
--size-gb 128 \
--sku Premium_LRS \
--new
ssh 10.101.10.10
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.
Monte o novo disco para que ele seja acessível no sistema operacional.
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"
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
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.
Adicione uma linha semelhante a esta ao arquivo /etc/fstab, substituindo o valor UUID pelo seu.
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
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 \
--resource-group myResourceGroupDisk \
--source "$osdiskid" \
--name osDisk-backup
az disk create \
--resource-group myResourceGroupDisk \
--name mySnapshotDisk \
--source osDisk-backup
az vm create \
--resource-group myResourceGroupDisk \
--name myVM \
--attach-os-disk mySnapshotDisk \
--os-type linux
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 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
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
03/03/2021 • 15 minutes to read • Edit Online
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
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.
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.
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 \
--admin-username azureuser \
--generate-ssh-keys \
--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:
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 \
--resource-group myResourceGroupAutomate \
--name myVMWithCerts \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys \
--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.
Para permitir o tráfego da web para acessar sua VM, abra a porta 443 da Internet com az vm open-port:
az vm open-port \
--resource-group myResourceGroupAutomate \
--name myVMWithCerts \
--port 443
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
03/03/2021 • 13 minutes to read • Edit Online
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 Galeria de Imagens Compartilhadas
Criar uma definição de imagem
Criar uma versão de imagem
Criar uma VM de uma imagem
Compartilhar uma galeria de imagens
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 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
Instalar a CLI do Azure.
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
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.
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:
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.
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.
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.
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.
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 \
--resource-group myGalleryRG \
--gallery-name myGallery \
--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.
Próximas etapas
Neste tutorial, você criou uma imagem de VM personalizada. Você aprendeu a:
Criar uma Galeria de Imagens Compartilhadas
Criar uma definição de imagem
Criar uma versão de imagem
Criar uma VM de uma imagem
Compartilhar uma galeria de imagens
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
03/11/2020 • 8 minutes to read • Edit Online
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 um conjunto de disponibilidade
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
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.
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.
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.
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 \
--resource-group myResourceGroupAvailability \
--name myAvailabilitySet \
--output table
Próximas etapas
Neste tutorial, você aprendeu a:
Criar um conjunto de disponibilidade
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
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
03/11/2020 • 13 minutes to read • Edit Online
#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
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 \
--admin-username azureuser \
--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.
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.
Tarefas de gerenciamento
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 \
--resource-group myResourceGroupScaleSet \
--name myScaleSet \
--output table
az vmss show \
--resource-group myResourceGroupScaleSet \
--name myScaleSet \
--query [sku.capacity] \
--output table
az vmss scale \
--resource-group myResourceGroupScaleSet \
--name myScaleSet \
--new-capacity 3
az vmss list-instance-connection-info \
--resource-group myResourceGroupScaleSet \
--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 \
--resource-group myResourceGroupScaleSet \
--name myScaleSetDisks \
--image UbuntuLTS \
--upgrade-policy-mode automatic \
--custom-data cloud-init.txt \
--admin-username azureuser \
--generate-ssh-keys \
--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:
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
Criar um conjunto de dimensionamento de máquinas virtuais
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
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
03/11/2020 • 18 minutes to read • Edit Online
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
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.
az network lb create \
--resource-group myResourceGroupLoadBalancer \
--name myLoadBalancer \
--frontend-ip-name myFrontEndPool \
--backend-pool-name myBackEndPool \
--public-ip-address myPublicIP
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:
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:
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:
for i in `seq 1 3`; do
az network nic create \
--resource-group myResourceGroupLoadBalancer \
--name myNic$i \
--vnet-name myVnet \
--subnet mySubnet \
--network-security-group myNetworkSecurityGroup \
--lb-name myLoadBalancer \
--lb-address-pools myBackEndPool
done
Quando todos os três NICs virtuais forem criados, prossiga para a próxima etapa
az vm availability-set create \
--resource-group myResourceGroupLoadBalancer \
--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:
for i in `seq 1 3`; do
az vm create \
--resource-group myResourceGroupLoadBalancer \
--name myVM$i \
--availability-set myAvailabilitySet \
--nics myNic$i \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys \
--custom-data cloud-init.txt \
--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.
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.
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:
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
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:
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
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
03/03/2021 • 19 minutes to read • Edit Online
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 um endereço IP público
Criar uma VM de front-end
Protegem o tráfego de rede
Criar uma VM de back-end
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.
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.
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.
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.
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.
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 create \
--resource-group myRGNetwork \
--name myFrontendVM \
--vnet-name myVNet \
--subnet myFrontendSubnet \
--nsg myFrontendNSG \
--public-ip-address myPublicIPAddress \
--image UbuntuLTS \
--generate-ssh-keys
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.
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
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.
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 \
--resource-group myRGNetwork \
--name myBackendVM \
--vnet-name myVNet \
--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 a rede virtual e a sub-rede
Criar um endereço IP público
Criar uma VM de front-end
Protegem o tráfego de rede
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
03/11/2020 • 14 minutes to read • Edit Online
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:
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
New-AzResourceGroup `
-ResourceGroupName "myResourceGroupVM" `
-Location "EastUS"
O grupo de recursos é especificado ao criar ou modificar uma VM, que pode ser visto durante este tutorial.
$cred = Get-Credential
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 .
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 `
-Location "EastUS" `
-PublisherName "MicrosoftWindowsServer"
O comando Get-AzVMImageSku filtrará o nome do editor e da oferta para retornar uma lista com nomes de
imagem.
Get-AzVMImageSku `
-Location "EastUS" `
-PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer"
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 `
-ResourceGroupName "myResourceGroupVM" `
-Name "myVM2" `
-Location "EastUS" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-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.
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.
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.
GPU NV, NVv2, NC, NCv2, NCv3, ND VMs especializadas, destinadas para
renderização gráfica e edição de vídeo
pesadas.
Redimensionar uma VM
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.
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 `
-ResourceGroupName "myResourceGroupVM" `
-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 `
-ResourceGroupName "myResourceGroupVM" `
-Name "myVM" -Force
$vm = Get-AzVM `
-ResourceGroupName "myResourceGroupVM" `
-VMName "myVM"
$vm.HardwareProfile.VmSize = "Standard_E2s_v3"
Update-AzVM -VM $vm `
-ResourceGroupName "myResourceGroupVM"
Start-AzVM `
-ResourceGroupName "myResourceGroupVM" `
-Name $vm.name
Estados de energia da VM
Uma VM do Azure pode ter um dentre vários estados de energia.
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 `
-ResourceGroupName "myResourceGroupVM" `
-Name "myVM" `
-Status | Select @{n="Status"; e={$_.Statuses[1].Code}}
Status
------
PowerState/running
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 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 `
-ResourceGroupName "myResourceGroupVM" `
-Name "myVM" -Force
Start-AzVM `
-ResourceGroupName "myResourceGroupVM" `
-Name "myVM"
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:
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
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
03/03/2021 • 12 minutes to read • Edit Online
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 sistema operacional e discos temporários
Discos de dados
Discos Standard e Premium
Desempenho do disco
Anexar e preparar os discos de dados
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
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
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.
New-AzVm `
-ResourceGroupName "myResourceGroupDisk" `
-Name "myVM" `
-Location "East US" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-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 `
-Location "EastUS" `
-CreateOption Empty `
-DiskSizeGB 128
$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.StorageProfile.DataDisks
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 sistema operacional e discos temporários
Discos de dados
Discos Standard e Premium
Desempenho do disco
Anexar e preparar os discos de dados
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
03/03/2021 • 5 minutes to read • Edit Online
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
$cred = 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" `
-Location "East US" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-PublicIpAddressName "myPublicIpAddress" `
-OpenPorts 80 `
-Credential $cred
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
03/03/2021 • 12 minutes to read • Edit Online
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:
Criar uma Galeria de Imagens Compartilhadas
Criar uma definição de imagem
Criar uma versão de imagem
Criar uma VM de uma imagem
Compartilhar uma galeria de imagens
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
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
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.
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:
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.
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
$resourceGroup = New-AzResourceGroup `
-Name 'myGalleryRG' `
-Location 'EastUS'
$gallery = New-AzGallery `
-GalleryName 'myGallery' `
-ResourceGroupName $resourceGroup.ResourceGroupName `
-Location $resourceGroup.Location `
-Description 'Shared Image Gallery for my organization'
$galleryImage = New-AzGalleryImageDefinition `
-GalleryName $gallery.Name `
-ResourceGroupName $resourceGroup.ResourceGroupName `
-Location $gallery.Location `
-Name 'myImageDefinition' `
-OsState specialized `
-OsType Windows `
-Publisher 'myPublisher' `
-Offer 'myOffer' `
-Sku 'mySKU'
New-AzGalleryImageVersion `
-GalleryImageDefinitionName $galleryImage.Name`
-GalleryImageVersionName '1.0.0' `
-GalleryName $gallery.Name `
-ResourceGroupName $resourceGroup.ResourceGroupName `
-Location $resourceGroup.Location `
-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.
# 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
Compartilhar a galeria
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, [email protected] neste exemplo, por
suas informações.
# Get the object ID for the user
$user = Get-AzADUser -StartsWith [email protected]
# 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
Quando não forem mais necessários, você poderá usar o cmdlet Remove-AzResourceGroup para remover o
grupo de recursos e todos os recursos relacionados:
# Delete the VM
Remove-AzResourceGroup -Name myResoureceGroup
Próximas etapas
Neste tutorial, você criou uma imagem de VM especializada. Você aprendeu a:
Criar uma Galeria de Imagens Compartilhadas
Criar uma definição de imagem
Criar uma versão de imagem
Criar uma VM de uma imagem
Compartilhar uma galeria de imagens
Avance para o próximo tutorial para aprender como criar máquinas virtuais altamente disponíveis.
Criar VMs altamente disponíveis
Tutorial: Criar e implantar máquinas virtuais
altamente disponíveis com o Azure PowerShell
03/03/2021 • 8 minutes to read • Edit Online
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.
Neste tutorial, você aprenderá como:
Criar um conjunto de disponibilidade
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
Verificar o Assistente do Azure
New-AzResourceGroup `
-Name myResourceGroupAvailability `
-Location EastUS
Crie um conjunto de disponibilidade gerenciado usando New-AzAvailabilitySet com o parâmetro -sku aligned .
New-AzAvailabilitySet `
-Location "EastUS" `
-Name "myAvailabilitySet" `
-ResourceGroupName "myResourceGroupAvailability" `
-Sku aligned `
-PlatformFaultDomainCount 2 `
-PlatformUpdateDomainCount 2
$cred = Get-Credential
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.
Conferir os tamanhos de VM disponíveis
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 `
-ResourceGroupName "myResourceGroupAvailability" `
-AvailabilitySetName "myAvailabilitySet"
Próximas etapas
Neste tutorial, você aprendeu a:
Criar um conjunto de disponibilidade
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
Verificar o Assistente do Azure
Avance para o próximo tutorial para saber mais sobre conjuntos de disponibilidade de máquinas virtuais.
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
03/11/2020 • 13 minutes to read • Edit Online
New-AzVmss `
-ResourceGroupName "myResourceGroupScaleSet" `
-Location "EastUS" `
-VMScaleSetName "myScaleSet" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-PublicIpAddressName "myPublicIPAddress" `
-LoadBalancerName "myLoadBalancer" `
-UpgradePolicyMode "Automatic"
Leva alguns minutos para criar e configurar todos os recursos e as VMs do conjunto de dimensionamento.
# Use Custom Script Extension to install IIS and configure basic website
Add-AzVmssExtension -VirtualMachineScaleSet $vmss `
-Name "customScript" `
-Publisher "Microsoft.Compute" `
-Type "CustomScriptExtension" `
-TypeHandlerVersion 1.8 `
-Setting $publicSettings
# Update the scale set and apply the Custom Script Extension to the VM instances
Update-AzVmss `
-ResourceGroupName "myResourceGroupScaleSet" `
-Name "myScaleSet" `
-VirtualMachineScaleSet $vmss
$vnet = Get-AzVirtualNetwork `
-ResourceGroupName "myResourceGroupScaleSet" `
-Name myVnet
$frontendSubnet = $vnet.Subnets[0]
$frontendSubnetConfig = Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $vnet `
-Name mySubnet `
-AddressPrefix $frontendSubnet.AddressPrefix `
-NetworkSecurityGroup $nsgFrontend
# Update the scale set and apply the Custom Script Extension to the VM instances
Update-AzVmss `
-ResourceGroupName "myResourceGroupScaleSet" `
-Name "myScaleSet" `
-VirtualMachineScaleSet $vmss
Get-AzPublicIPAddress `
-ResourceGroupName "myResourceGroupScaleSet" `
-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.
Tarefas de gerenciamento
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 `
-ResourceGroupName "myResourceGroupScaleSet" `
-VMScaleSetName "myScaleSet"
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 `
-ResourceGroupName "myResourceGroupScaleSet" `
-VMScaleSetName "myScaleSet" `
-InstanceId "1"
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"
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
Criar um conjunto de dimensionamento de máquinas virtuais
Aumentar ou diminuir o número de instâncias em um conjunto de dimensionamento
Criar regras de dimensionamento automático
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
03/03/2021 • 16 minutes to read • Edit Online
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 a Extensão de Script Personalizado para criar um site do IIS básico
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
$publicIP = New-AzPublicIpAddress `
-ResourceGroupName "myResourceGroupLoadBalancer" `
-Location "EastUS" `
-AllocationMethod "Static" `
-Name "myPublicIP"
$frontendIP = New-AzLoadBalancerFrontendIpConfig `
-Name "myFrontEndPool" `
-PublicIpAddress $publicIP
$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 `
-ResourceGroupName "myResourceGroupLoadBalancer" `
-Name "myLoadBalancer" `
-Location "EastUS" `
-FrontendIpConfiguration $frontendIP `
-BackendAddressPool $backendPool
Add-AzLoadBalancerProbeConfig `
-Name "myHealthProbe" `
-LoadBalancer $lb `
-Protocol tcp `
-Port 80 `
-IntervalInSeconds 15 `
-ProbeCount 2
Add-AzLoadBalancerRuleConfig `
-Name "myLoadBalancerRule" `
-LoadBalancer $lb `
-FrontendIpConfiguration $lb.FrontendIpConfigurations[0] `
-BackendAddressPool $lb.BackendAddressPools[0] `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80 `
-Probe $probe
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:
$availabilitySet = New-AzAvailabilitySet `
-ResourceGroupName "myResourceGroupLoadBalancer" `
-Name "myAvailabilitySet" `
-Location "EastUS" `
-Sku aligned `
-PlatformFaultDomainCount 2 `
-PlatformUpdateDomainCount 2
$cred = 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 `
-ResourceGroupName "myResourceGroupLoadBalancer" `
-Name "myVM$i" `
-Location "East US" `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-OpenPorts 80 `
-AvailabilitySetName "myAvailabilitySet" `
-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:
Get-AzPublicIPAddress `
-ResourceGroupName "myResourceGroupLoadBalancer" `
-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.
$nic = Get-AzNetworkInterface `
-ResourceGroupName "myResourceGroupLoadBalancer" `
-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:
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 a Extensão de Script Personalizado para criar um site do IIS básico
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
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
03/03/2021 • 13 minutes to read • Edit Online
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 um endereço IP público
Criar uma VM de front-end
Protegem o tráfego de rede
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
$frontendSubnet = New-AzVirtualNetworkSubnetConfig `
-Name myFrontendSubnet `
-AddressPrefix 10.0.0.0/24
$backendSubnet = New-AzVirtualNetworkSubnetConfig `
-Name myBackendSubnet `
-AddressPrefix 10.0.1.0/24
$vnet = New-AzVirtualNetwork `
-ResourceGroupName myRGNetwork `
-Location EastUS `
-Name myVNet `
-AddressPrefix 10.0.0.0/16 `
-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.
$pip = New-AzPublicIpAddress `
-ResourceGroupName myRGNetwork `
-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.
$frontendNic = New-AzNetworkInterface `
-ResourceGroupName myRGNetwork `
-Location EastUS `
-Name myFrontend `
-SubnetId $vnet.Subnets[0].Id `
-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:
$cred = Get-Credential
New-AzVM `
-Credential $cred `
-Name myFrontend `
-PublicIpAddressName myPublicIPAddress `
-ResourceGroupName myRGNetwork `
-Location "EastUS" `
-Size Standard_D1 `
-SubnetName myFrontendSubnet `
-VirtualNetworkName myVNet
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 `
-Direction Inbound `
-Priority 100 `
-SourceAddressPrefix 10.0.0.0/24 `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 1433 `
-Access Allow
$nsgFrontend = New-AzNetworkSecurityGroup `
-ResourceGroupName myRGNetwork `
-Location EastUS `
-Name myFrontendNSG `
-SecurityRules $nsgFrontendRule
$nsgBackend = New-AzNetworkSecurityGroup `
-ResourceGroupName myRGNetwork `
-Location EastUS `
-Name myBackendNSG `
-SecurityRules $nsgBackendRule
$backendNic = New-AzNetworkInterface `
-ResourceGroupName myRGNetwork `
-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:
$cred = Get-Credential
Crie myBackendVM.
New-AzVM `
-Credential $cred `
-Name myBackend `
-ImageName "MicrosoftSQLServer:SQL2016SP1-WS2016:Enterprise:latest" `
-ResourceGroupName myRGNetwork `
-Location "EastUS" `
-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.
Criar a rede virtual e a sub-rede
Criar um endereço IP público
Criar uma VM de front-end
Protegem o tráfego de rede
Criar uma VM de back-end
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
03/03/2021 • 7 minutes to read • Edit Online
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).
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.
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
03/03/2021 • 2 minutes to read • Edit Online
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).
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
03/03/2021 • 2 minutes to read • Edit Online
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)
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
03/03/2021 • 11 minutes to read • Edit Online
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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
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
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.
{
"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ó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
03/03/2021 • 21 minutes to read • Edit Online
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.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"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": {
"value": "Standard_E4s_v3"
},
"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": {
"value": "/subscriptions/abc686f6-963b-4e64-bff4-
99dc369ab1cd/resourceGroups/vnetresourcegroup/providers/Microsoft.Network/virtualNetworks/openshiftvnet/subn
ets/infrasubnet"
},
"existingCnsSubnetReference": {
"value": "/subscriptions/abc686f6-963b-4e64-bff4-
99dc369ab1cd/resourceGroups/vnetresourcegroup/providers/Microsoft.Network/virtualNetworks/openshiftvnet/subn
ets/cnssubnet"
},
"existingNodeSubnetReference": {
"value": "/subscriptions/abc686f6-963b-4e64-bff4-
99dc369ab1cd/resourceGroups/vnetresourcegroup/providers/Microsoft.Network/virtualNetworks/openshiftvnet/subn
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"
}
}
}
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
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 '
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.
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.
$ ssh [email protected]
Limpar os recursos
Quando não for mais necessário, você pode usar o comando az group delete para remover o grupo de recursos,
o cluster OpenShift e todos os recursos relacionados.
Próximas etapas
Tarefas de pós-implantação
Solução de problemas de implantação do OpenShift no Azure
Introdução ao OpenShift Container Platform
Configurar pré-requisitos
03/03/2021 • 16 minutes to read • Edit Online
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.
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
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
PA RÂ M ET RO DE EN T RA DA DESC RIÇ Ã O DO PA RÂ M ET RO
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
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
PA RÂ M ET RO DE EN T RA DA DESC RIÇ Ã O DO PA RÂ M ET RO
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
PA RÂ M ET RO DE EN T RA DA DESC RIÇ Ã O DO PA RÂ M ET RO
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
OpenShift Container Platform 3.11
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
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
PA RÂ M ET RO DE EN T RA DA DESC RIÇ Ã O DO PA RÂ M ET RO
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
PA RÂ M ET RO DE EN T RA DA DESC RIÇ Ã O DO PA RÂ M ET RO
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
Subdomínio do roteador padrão Selecione nipio para teste ou personalizado para inserir seu
próprio subdomínio para produção
PA RÂ M ET RO DE EN T RA DA DESC RIÇ Ã O DO PA RÂ M ET RO
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 [email protected]
Limpar os recursos
Quando não for mais necessário, você pode usar o comando az group delete para remover o grupo de recursos,
o cluster OpenShift e todos os recursos relacionados.
Próximas etapas
Tarefas de pós-implantação
Solução de problemas de implantação do OpenShift no Azure
Introdução ao OpenShift Container Platform
Implantar o OpenShift Container Platform ou OKD
no Azure Stack
03/03/2021 • 4 minutes to read • Edit Online
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óximas etapas
Tarefas de pós-implantação
Solução de problemas de implantação do OpenShift no Azure
Tarefas de pós-implantação
03/03/2021 • 7 minutes to read • Edit Online
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)
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 .
az account show
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:
No Console do OpenShift, agora você verá duas opções para autenticação – htpasswd_auth e [Registro de
Aplicativo].
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
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
NOTE
Conclua apenas as etapas na seção modelo de projeto OpenShift e não na seção instalação inteira.
Próximas etapas
Introdução ao OpenShift Container Platform
Solucionar problemas de implantação da
plataforma de contêiner do OpenShift 3,11 no Azure
03/03/2021 • 7 minutes to read • Edit Online
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.
OpenShift Container Platform 3.11
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"]}
Failure summary:
1. Hosts: mycluster-master-0
Play: Configure GlusterFS
Task: Load heketi topology
Message: Failed without returning a message.
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
03/03/2021 • 5 minutes to read • Edit Online
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.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"masterVmSize": {
"value": "Standard_E2s_v3"
},
"infraVmSize": {
"value": "Standard_E2s_v3"
},
"nodeVmSize": {
"value": "Standard_E2s_v3"
},
"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"
}
}
}
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 [email protected]"
}
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.
Limpar os recursos
Quando não for mais necessário, você pode usar o comando az group delete para remover o grupo de recursos,
o cluster OpenShift e todos os recursos relacionados.
Próximas etapas
Tarefas de pós-implantação
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
03/03/2021 • 48 minutes to read • Edit Online
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".
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
03/03/2021 • 12 minutes to read • Edit Online
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ê não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
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.
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",
"location": "eastus",
"macAddress": "00-0D-3A-36-2F-56",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "13.64.104.241",
"resourceGroup": "rg-oracle"
}
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:
3. Se for necessário, obtenha o endereço IP público de sua VM com az network public-ip show da seguinte
maneira:
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>
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
7. Monte o disco
$ sudo su - oracle
$ lsnrctl start
A saída deverá ser semelhante a esta:
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
mkdir /u02/oradata
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
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:
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):
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 -
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
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
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
03/03/2021 • 9 minutes to read • Edit Online
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.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--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",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "40.68.254.142",
"resourceGroup": "myResourceGroup"
}
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:
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.
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.
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:
Este comando não produz resultados, portanto verifique se o Elasticsearch está em execução na VM com este
comando curl :
{
"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"
}
Teste o Logstash no modo interativo para garantir que eles esteja funcionando corretamente:
Este é um pipeline do logstash básico que ecoa entrada padrão para saída padrão.
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"
}
}
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.
server.host: "0.0.0.0"
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
03/03/2021 • 10 minutes to read • Edit Online
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.
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.
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
Solução de problemas
Desmistificando a migração do mainframe para o Azure
Tamanhos das máquinas virtuais no Azure
03/11/2020 • 4 minutes to read • Edit Online
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.
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.
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.
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
Computação de alto desempenho
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
03/11/2020 • 3 minutes to read • Edit Online
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.
Redimensionar uma VM
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:
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
03/11/2020 • 5 minutes to read • Edit Online
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.
$resourceGroup = "myResourceGroup"
$vmName = "myVM"
Liste os tamanhos de VM que estão disponíveis no cluster do hardware onde a VM está hospedada.
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.
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 = Get-AzVM -ResourceGroupName $resourceGroup -VMName $vmName
$vm.HardwareProfile.VmSize = "<newVMSize>"
Update-AzVM -VM $vm -ResourceGroupName $resourceGroup
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.
$resourceGroup = "myResourceGroup"
$vmName = "myVM"
Liste os tamanhos de VM que estão disponíveis no cluster do hardware onde a VM está hospedada.
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.
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
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
03/03/2021 • 14 minutes to read • Edit Online
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?.
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.
Inicialização Segura ️
✔ Com inicialização confiável (versão
prévia)
VM blindada ️
✔ ❌
vTPM ️
✔ Com inicialização confiável (versão
prévia)
Formato VHDX ️
✔ ❌
Recursos e funcionalidades
Recursos da geração 1 versus geração 2
REC URSO GERA Ç Ã O 1 GERA Ç Ã O 2
Disco personalizado/imagem/troca de ️
✔ ️
✔
sistema operacional
Suporte ao conjunto de ️
✔ ️
✔
dimensionamento de máquinas
virtuais
Backup/restauração ️
✔ ️
✔
Criptografia no servidor ️
✔ ️
✔
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 .
Perguntas frequentes
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.
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
03/03/2021 • 8 minutes to read • Edit Online
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
Computação otimizada
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
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
03/03/2021 • 5 minutes to read • Edit Online
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)
Próximas etapas
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.
Tamanhos expansíveis da máquina virtual da série B
03/03/2021 • 14 minutes to read • Edit Online
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
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 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
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
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.
Próximas etapas
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.
Série DCsv2
03/03/2021 • 3 minutes to read • Edit Online
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 *)
Discos do sistema operacional efêmero: com suporte
*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
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
Outros tamanhos e informações
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Calculadora de preços: calculadora de preços
Mais informações sobre tipos de discos: tipos de disco
Próximas etapas
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.
Séries Dv2 e DSv2
03/03/2021 • 7 minutes to read • Edit Online
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
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: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: sem 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
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)
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: 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)
Próximas etapas
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.
Séries Dv3 e DSv3
03/03/2021 • 9 minutes to read • Edit Online
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
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: com suporte (requer um mínimo de 4 vCPU)
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Á 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
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: com suporte
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)
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.
Próximas etapas
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.
Séries Dav4 e Dasv4
03/03/2021 • 8 minutes to read • Edit Online
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
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: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: com suporte
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)
Série Dasv4
ACU: 230-260
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: com suporte
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
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 Á 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)
Próximas etapas
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.
Séries Ddv4 e Ddsv4
03/03/2021 • 9 minutes to read • Edit Online
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
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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: com suporte
** 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)
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: 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)
Próximas etapas
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.
Séries Dv4 e Dsv4
03/03/2021 • 4 minutes to read • Edit Online
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
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: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: sem suporte
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)
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: sem suporte
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
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)
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
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
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 Fsv2
03/03/2021 • 6 minutes to read • Edit Online
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: 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 DA VC P U A : GIB ( SSD) GIB S EM GIB ) PS DE N IC S A ( M B P S)
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.
Próximas etapas
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.
Tamanhos de máquinas virtuais com GPU
otimizadas para memória
03/11/2020 • 7 minutes to read • Edit Online
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
Computação otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
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.
Dv2 com otimização de memória e série Dsv2
03/03/2021 • 8 minutes to read • Edit Online
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.
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 P U GIB GIB GRAVA Ç Ã O N C IA : IO P S DE N IC S ( M B P S)
1 2
1 A instância é isolada em hardware dedicado a um único cliente. 2 25000 Mbps com Rede Acelerada.
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)
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.
Próximas etapas
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.
Séries Ev3 e Esv3
03/03/2021 • 9 minutes to read • Edit Online
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
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: com suporte (requer um mínimo de 4 vCPU)
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Á 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
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: com suporte
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)
Próximas etapas
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.
Séries Eav4 e Easv4
03/03/2021 • 8 minutes to read • Edit Online
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
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ções 1 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: com suporte
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
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)
Série Easv4
ACU: 230-260
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: com suporte
Atualizações de preservação de memória: com suporte
Suporte à geração de VM: gerações 1 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: com suporte
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
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
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 Á 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)
Próximas etapas
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.
Séries Edv4 e Edsv4
03/03/2021 • 8 minutes to read • Edit Online
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
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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
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
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)
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: 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)
Próximas etapas
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.
Séries Ev4 e Esv4
03/03/2021 • 8 minutes to read • Edit Online
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
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: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: sem suporte
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)
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com 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 e 2
Rede acelerada: com suporte (requer um mínimo de 4 vCPU)
Discos do sistema operacional efêmero: sem suporte
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
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)
Próximas etapas
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.
Série M
03/03/2021 • 6 minutes to read • Edit Online
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Acelerador de gravação: com suporte
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem 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)
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.
2 A instância é isolada em hardware dedicado a um único cliente.
Próximas etapas
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.
Série Mv2
03/03/2021 • 6 minutes to read • Edit Online
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
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 Á 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)
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.
Windows Server 2019 ou posterior
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
Próximas etapas
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.
Tamanhos de VM compatíveis com vCPU restrita
03/03/2021 • 6 minutes to read • Edit Online
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
Próximas etapas
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.
Tamanhos de máquinas virtuais otimizados para
armazenamento
03/11/2020 • 2 minutes to read • Edit Online
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
Computação otimizada
Memória otimizada
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Saiba como otimizar o desempenho nas máquinas virtuais da série Lsv2 para Windows ou Linux.
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 Lsv2
03/03/2021 • 9 minutes to read • Edit Online
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
Armazenamento Premium: com suporte
Armazenamento em cache Premium: sem suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Intermitência: com suporte
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem 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)
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:
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
Próximas etapas
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.
Otimizar o desempenho nas máquinas virtuais do
Linux da série Lsv2
03/11/2020 • 14 minutes to read • Edit Online
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.
Perguntas frequentes
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:
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
03/03/2021 • 12 minutes to read • Edit Online
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.
Perguntas frequentes
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
03/03/2021 • 6 minutes to read • Edit Online
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.
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
Computação otimizada
Computação de alto desempenho
Memória otimizada
Armazenamento otimizado
Gerações anteriores
Próximas etapas
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.
Série NC
03/03/2021 • 5 minutes to read • Edit Online
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.
Armazenamento Premium: sem suporte
Armazenamento em cache Premium: sem suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1
Rede acelerada: sem suporte
Discos do sistema operacional efêmero: sem suporte
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
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Série NCv2
03/03/2021 • 6 minutes to read • Edit Online
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,
otimizado para cargas de trabalho de computação paralela firmemente acopladas.
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: sem suporte
Discos do sistema operacional efêmero: sem suporte
Interconexão NVIDIA NVLink: sem suporte
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
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Série NCv3
03/03/2021 • 6 minutes to read • Edit Online
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
de trabalho HPC tradicionais como modelagem de reservatório, sequenciamento de DNA, análise de proteína,
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).
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: sem suporte
Discos do sistema operacional efêmero: sem suporte
Interconexão NVIDIA NVLink: sem suporte
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
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
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Série NCasT4_v3
03/03/2021 • 5 minutes to read • Edit Online
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem suporte
Interconexão NVIDIA NVLink: sem suporte
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)
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Série ND
03/03/2021 • 7 minutes to read • Edit Online
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.
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: sem suporte
Discos do sistema operacional efêmero: sem suporte
Interconexão NVIDIA NVLink: sem suporte
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
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
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Série NDv2 atualizada
03/03/2021 • 7 minutes to read • Edit Online
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.
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Série NV
03/03/2021 • 6 minutes to read • Edit Online
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.
Armazenamento Premium: sem suporte
Armazenamento em cache Premium: sem suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1
Rede acelerada: sem suporte
Discos do sistema operacional efêmero: sem suporte
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
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Série NVv3
03/03/2021 • 6 minutes to read • Edit Online
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.
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem suporte
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
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Série NVv4
03/03/2021 • 5 minutes to read • Edit Online
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem suporte
N ÚM ERO
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 DA
TA M A N H O VC P U GIB GIB GP U GIB M Á XIM O S ( M B P S)
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Instalar drivers NVIDIA GPU em VMs da série N
que executam o Linux
03/03/2021 • 20 minutes to read • Edit Online
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.
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.
Ubuntu 18.04 LTS NVIDIA GRID 12,0, ramificação do driver R460(. exe)
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.
Você verá uma saída semelhante ao seguinte exemplo (mostrando uma placa NVIDIA Tesla K80):
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}
rm -f /tmp/${CUDA_REPO_PKG}
sudo reboot
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
cd LISISO
sudo ./install.sh
sudo reboot
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}
rm -f /tmp/${CUDA_REPO_PKG}
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
OS.EnableRDMA=y
OS.UpdateRdmaDriver=y
<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
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
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
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/
IgnoreSP=FALSE
EnableUI=FALSE
FeatureType=0
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.
wget https://aka.ms/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:
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/
IgnoreSP=FALSE
EnableUI=FALSE
FeatureType=0
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
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=`awk '/BusID/{gsub(/"/, "", $2); print $2}' ${XCONFIG}`
NEWBUSID=`nvidia-xconfig --query-gpu-info | awk '/PCI BusID/{print $4}'`
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.
Solução de problemas
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
03/03/2021 • 8 minutes to read • Edit Online
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.
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.
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.
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
03/03/2021 • 3 minutes to read • Edit Online
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.
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.
Verificar a instalação de drivers
É 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
03/03/2021 • 2 minutes to read • Edit Online
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.
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.
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 otimizada
Computação acelerada por GPU
Computação de alto desempenho
Memória otimizada
Armazenamento otimizado
Gerações anteriores
Próximas etapas
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.
Série NP (versão prévia)
03/03/2021 • 4 minutes to read • Edit Online
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.
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem suporte
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 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)
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
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.
Tamanhos de VM de computação de alto
desempenho
03/03/2021 • 18 minutes to read • Edit Online
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.
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.
Considerações de implantação
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
Computação otimizada
Memória otimizada
Armazenamento otimizado
GPU otimizada
Gerações anteriores
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
03/03/2021 • 7 minutes to read • Edit Online
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
Armazenamento Premium: sem suporte
Armazenamento em cache Premium: sem suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1
Rede acelerada: sem suporte
Discos do sistema operacional efêmero: sem suporte
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 .
1 para aplicativos MPI, a rede de back-end RDMA dedicada é habilitada pela rede InfiniBand FDR.
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
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
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.
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.
Série HB
03/03/2021 • 5 minutes to read • Edit Online
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
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem suporte
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
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
Saiba mais sobre como configurar suas VMs, habilitar a InfiniBand, configurar a MPIe otimizar os 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.
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.
Série HBv2
03/03/2021 • 5 minutes to read • Edit Online
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
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.
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem suporte
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 120 AMD 480 350 2.45 3.1 3.3 200 Todo 480 8 8
dard EPYC s +
_HB1 7V12 960
20rs_
v2
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
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.
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.
Série HC
03/03/2021 • 5 minutes to read • Edit Online
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
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 é recomendado.
ACU: 297-315
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
Rede acelerada: com suporte
Discos do sistema operacional efêmero: sem suporte
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 44 Intel 352 191 2.7 3.4 3.7 100 Todo 700 4 8
dard Xeon s
_HC4 Plati
4rs num
8168
Outros tamanhos
Propósito geral
Memória otimizada
Armazenamento otimizado
GPU otimizada
Computação de alto desempenho
Gerações anteriores
Próximas etapas
Saiba mais sobre como configurar suas VMs, habilitar a InfiniBand, configurar a MPIe otimizar os 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 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.
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.
Verifique as cotas do vCPU usando o CLI do Azure
03/11/2020 • 4 minutes to read • Edit Online
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.
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
03/11/2020 • 5 minutes to read • Edit Online
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.
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
03/11/2020 • 4 minutes to read • Edit Online
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).
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.
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 '.
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
03/11/2020 • 3 minutes to read • Edit Online
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.
VA LO R EXP L IC A Ç Ã O
Análise de exemplo
[Família] + *[Sub-família ] + [n º de vCPUs] + [Recursos aditivos] + *[Tipo de acelerador ] + [Versão]
Exemplo 1: M416ms_v2
VA LO R EXP L IC A Ç Ã O
Family M
n º de vCPUs 416
Versão v2
Exemplo 2: NV16as_v4
VA LO R EXP L IC A Ç Ã O
Family N
Sub-família V
n º de vCPUs 16
Versão v4
Exemplo 3: NC4as_T4_v3
VA LO R EXP L IC A Ç Ã O
Family N
Sub-família C
n º de vCPUs 4
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
03/03/2021 • 32 minutes to read • Edit Online
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)
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)
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
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
A Básico
Recomendação de tamanho mais recente : série Av2
Armazenamento Premium: Sem suporte
Cache de Armazenamento Premium: Sem suporte
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 )
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)
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%.
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
1Para os aplicativos MPI, a rede de back-end RDMA dedicada é habilitada pela rede InfiniBand FDR, que fornece
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
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)
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)
Visualização: série CC
Recomendação de tamanho mais recente : série DCsv2
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
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)
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
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)
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)
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)
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.
1 A instância é isolada em hardware dedicado a um único cliente.
Série GS
Recomendação de tamanho mais recente : série Easv4, série Esv4, Edsv4 e série M
ACU: 180 - 240 1
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 Á XIM O
M EN TO DE
T EM P O RÁ R TA XA DE N IC S/ L A RG
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
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)
Série G
Recomendação de tamanho mais recente : Eav4, série Ev4 e série Edv4 e série M
ACU: 180 - 240
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)
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
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
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
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,
otimizado para cargas de trabalho de computação paralela firmemente acopladas.
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
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
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.
Armazenamento Premium: com suporte
Cache de armazenamento Premium: com suporte
Migração ao vivo: sem suporte
Atualizações de preservação de memória: sem suporte
Suporte à geração de VM: geração 1 e 2
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
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
Próximas etapas
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.
Isolamento de máquina virtual no Azure
03/03/2021 • 5 minutes to read • Edit Online
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
Perguntas frequentes
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
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)
03/11/2020 • 4 minutes to read • Edit Online
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
B Varia Varia
HB 199-216 * * 1:1
HC 297-315 * 1:1
M 160-180 2:1***
Nos links abaixo, você obtém mais informações sobre os diferentes tamanhos:
Uso geral
Memória otimizada
Computação otimizada
GPU otimizada
Computação de alto desempenho
Armazenamento otimizado
Pontuações de parâmetro de comparação de
computação de VMs do Linux
03/03/2021 • 52 minutes to read • Edit Online
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_Da_v4
(12/12/2019 12:01:48 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_Eas_v4
(12/11/2019 2:28:50 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_Ea_v4
(12/11/2019 2:29:06 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
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
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
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.
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
% 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
NCSv3-GPU habilitada
(3/21/2019 5:48:37 PM PBI 3897709)
% 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
NCSv2-GPU habilitada
(3/12/2019 11:19:19 PM PBI 3897709)
% 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
NC-GPU habilitada
(3/12/2019 11:08:03 PM PBI 3897709)
% 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
NDs-GPU habilitada
(3/12/2019 11:19:10 PM PBI 3897709)
% 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
NV-GPU habilitada
(3/12/2019 11:08:13 PM PBI 3897709)
% 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
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
03/03/2021 • 38 minutes to read • Edit Online
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.
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
TA M A N H O VC P US N Ó S N UM A CPU EXEC UÇ Õ ES M ÉDIA ST DDEV
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.
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
NCSv3-GPU habilitada
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
NCSv2-GPU habilitada
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
NC-GPU habilitada
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
NDs-GPU habilitada
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
NV-GPU habilitada
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
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
03/03/2021 • 11 minutes to read • Edit Online
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.
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).
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).
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
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.
az vmss create \
--resource-group myResourceGroup \
--name myScaleSet \
--image UbuntuLTS \
--upgrade-policy-mode automatic \
--admin-username azureuser \
--host-group myHostGroup \
--generate-ssh-keys \
--size Standard_D4s_v3 \
-g myDHResourceGroup \
--zone 1
Se você quiser escolher manualmente a qual host será implantado o conjunto de dimensionamento, adicione
--host e o nome do host.
az vm host get-instance-view \
-g myDHResourceGroup \
--host-group myHostGroup \
--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,
"vmSize": "Standard_D4s_v3"
},
{
"count": 7.0,
"vmSize": "Standard_D8s_v3"
},
{
"count": 3.0,
"vmSize": "Standard_D16s_v3"
},
{
"count": 1.0,
"vmSize": "Standard_D32-8s_v3"
},
{
"count": 1.0,
"vmSize": "Standard_D32-16s_v3"
},
{
"count": 1.0,
"vmSize": "Standard_D32s_v3"
},
{
"count": 1.0,
"vmSize": "Standard_D48s_v3"
},
{
"count": 0.0,
"vmSize": "Standard_D64-16s_v3"
},
{
"count": 0.0,
"vmSize": "Standard_D64-32s_v3"
},
{
"count": 0.0,
"vmSize": "Standard_D64s_v3"
}
]
},
"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": [
{
"id": "/subscriptions/10101010-1010-1010-1010-
101010101010/resourceGroups/MYDHRESOURCEGROUP/providers/Microsoft.Compute/virtualMachines/MYVM",
"resourceGroup": "MYDHRESOURCEGROUP"
}
]
}
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.
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.
Depois de excluir as VMs, você pode excluir o host com az vm host delete.
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.
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
03/03/2021 • 11 minutes to read • Edit Online
Este artigo orienta como criar um host dedicado do Azure para hospedar suas máquinas virtuais (VMs).
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.
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.
Próximas etapas
Para mais informações, consulte a visão geral de hosts dedicados.
Há um exemplo de modelo, aqui, que usa zonas e domínios de falha para obter resiliência máxima em
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
03/03/2021 • 9 minutes to read • Edit Online
Este artigo orienta como criar um host dedicado do Azure para hospedar suas máquinas virtuais (VMs).
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.
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.
$rgName = "myDHResourceGroup"
$location = "EastUS"
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.
Para mais informações sobre preços e SKUs do host, consulte Preços do Host Dedicado do Azure.
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 `
-ResourceGroupName $rgName `
-Sku DSv3-Type1 `
-AutoReplaceOnFailure 1 `
-PlatformFaultDomain 1
$cred = Get-Credential
New-AzVM `
-Credential $cred `
-ResourceGroupName $rgName `
-Location $location `
-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.
Get-AzHost `
-ResourceGroupName $rgName `
-Name myHost `
-HostGroupName $hostGroup.Name `
-InstanceView
Se você quiser escolher manualmente a qual host será implantado o conjunto de dimensionamento, adicione
--host e o nome do host.
$myDH = Get-AzHost `
-HostGroupName $dhGroupName `
-ResourceGroupName $dhRGName `
-Name $dhName
$myVM = Get-AzVM `
-ResourceGroupName $vmRGName `
-Name $vmName
$myVM.Host.Id = "$myDH.Id"
Stop-AzVM `
-ResourceGroupName $vmRGName `
-Name $vmName -Force
Update-AzVM `
-ResourceGroupName $vmRGName `
-VM $myVM -Debug
Start-AzVM `
-ResourceGroupName $vmRGName `
-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.
Depois de excluir todos os hosts, você poderá excluir o grupo de hosts usando Remove-AzHostGroup.
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.
Próximas etapas
Há um exemplo de modelo, aqui, que usa zonas e domínios de falha para obter resiliência máxima em
uma região.
Você também pode implantar hosts dedicados usando o portal do Azure.
Usar máquinas virtuais do Azure Spot
03/03/2021 • 10 minutes to read • Edit Online
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.
Perguntas frequentes
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
03/03/2021 • 5 minutes to read • Edit Online
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.
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ê 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 .
az login
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
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 .
Se você encontrar um erro, consulte códigos de erro.
Implantar máquinas virtuais do Azure Spot usando
o portal do Azure
03/03/2021 • 4 minutes to read • Edit Online
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.
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. Para obter mais informações sobre como definir o
preço máximo, consulte máquinas virtuais do Azure Spot – preços.
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
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 .
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 máquinas virtuais do Azure Spot usando o PowerShell, a CLIou um modelo.
Implantar máquinas virtuais do Azure Spot usando
o Azure PowerShell
03/03/2021 • 5 minutes to read • Edit Online
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.
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. Para obter mais informações sobre como definir o
preço máximo, consulte máquinas virtuais do Azure Spot – preços.
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 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:
# 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 | `
Add-AzVMNetworkInterface -Id $nic.Id
Depois que a VM for criada, você poderá consultar para ver o preço máximo de todas as VMs no grupo de
recursos.
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 o CLI do Azure, o portal ou 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 os preços de máquina virtual do Azure Spot. O meterName e skuName os dois conterão Spot .
Se você encontrar um erro, consulte códigos de erro.
Implantar máquinas virtuais do Azure Spot usando
um modelo do Resource Manager
03/03/2021 • 4 minutes to read • Edit Online
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.
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ê 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
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.
"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#",
"contentVersion": "1.0.0.0",
"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",
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2019-03-01",
"location": "eastus",
"dependsOn": [
"[concat('Microsoft.Network/publicIpAddresses/', variables('publicIpAddressName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"subnet": {
"id": "[variables('subnetRef')]"
},
"privateIPAllocationMethod": "Dynamic",
"publicIpAddress": {
"id": "[resourceId(resourceGroup().name,
'Microsoft.Network/publicIpAddresses', variables('publicIpAddressName'))]"
}
}
}
]
}
},
{
"name": "[variables('publicIpAddressName')]",
"type": "Microsoft.Network/publicIpAddresses",
"apiVersion": "2019-02-01",
"location": "eastus",
"properties": {
"publicIpAllocationMethod": "[variables('publicIpAddressType')]"
},
"sku": {
"name": "[variables('publicIpAddressSku')]"
}
},
{
"name": "[variables('virtualMachineName')]",
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2019-03-01",
"location": "eastus",
"dependsOn": [
"[concat('Microsoft.Network/networkInterfaces/', variables('networkInterfaceName'))]",
"[concat('Microsoft.Storage/storageAccounts/', variables('diagnosticsStorageAccountName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[variables('virtualMachineSize')]"
},
"storageProfile": {
"osDisk": {
"createOption": "fromImage",
"managedDisk": {
"storageAccountType": "[variables('osDiskType')]"
}
},
"imageReference": {
"publisher": "Canonical",
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "18.04-LTS",
"version": "latest"
}
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('Microsoft.Network/networkInterfaces',
variables('networkInterfaceName'))]"
}
]
},
"osProfile": {
"computerName": "[variables('virtualMachineName')]",
"adminUsername": "[variables('adminUsername')]",
"adminPassword": "[variables('adminPassword')]"
},
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "[concat('https://', variables('diagnosticsStorageAccountName'),
'.blob.core.windows.net/')]"
}
},
"priority": "Spot",
"evictionPolicy": "Deallocate",
"billingProfile": {
"maxPrice": -1
}
}
},
{
"name": "[variables('diagnosticsStorageAccountName')]",
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2019-04-01",
"location": "eastus",
"properties": {},
"kind": "[variables('diagnosticsStorageAccountKind')]",
"sku": {
"name": "[variables('diagnosticsStorageAccountType')]"
}
}
],
"outputs": {
"adminUsername": {
"type": "string",
"value": "[variables('adminUsername')]"
}
}
}
Próximas etapas
Você também pode criar uma máquina virtual do Azure Spot usando Azure PowerShell ou a CLI do Azure.
Consulte as informações de preços atuais usando a API de preços de varejo do Azure para obter informações
sobre os preços de máquina virtual do Azure Spot. O meterName e skuName os dois conterão Spot .
Se você encontrar um erro, consulte códigos de erro.
Mensagens de erro para máquinas virtuais do
Azure Spot e conjuntos de dimensionamento
03/03/2021 • 5 minutes to read • Edit Online
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.
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.
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.
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.
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
03/03/2021 • 20 minutes to read • Edit Online
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.
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 .
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.
# 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.
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.
Perguntas frequentes
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
03/03/2021 • 11 minutes to read • Edit Online
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.
New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Name "myVM" `
-Location "East US" `
-ImageName "Win2016Datacenter" `
-LicenseType "Windows_Server"
CLI
az vm create \
--resource-group myResourceGroup \
--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",
"hardwareProfile": {
"vmSize": "[variables('vmSize')]"
}
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
CLI
Converter VMs do Windows Server existentes para o Benefício Híbrido do Azure para Windows Server
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:
Type : Microsoft.Compute/virtualMachines
Location : westus
LicenseType :
CLI
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
"virtualMachineProfile": {
"storageProfile": {
"osDisk": {
"createOption": "FromImage"
},
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "2016-Datacenter",
"version": "latest"
}
},
"licenseType": "Windows_Server",
"osProfile": {
"computerNamePrefix": "[parameters('vmssName')]",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPassword')]"
}
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
03/03/2021 • 7 minutes to read • Edit Online
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.
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.
Para obter mais informações sobre imagens disponíveis, consulte Localizar e usar imagens de VM do Azure
Marketplace com Azure PowerShell
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.
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",
"hardwareProfile": {
"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"
Type : Microsoft.Compute/virtualMachines
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:
Type : Microsoft.Compute/virtualMachines
Location : westus
LicenseType :
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
03/03/2021 • 11 minutes to read • Edit Online
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.
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.
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
O que são Reservas do Azure?
03/03/2021 • 14 minutes to read • Edit Online
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.
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
03/03/2021 • 4 minutes to read • Edit Online
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.
Próximas etapas
Para obter mais informações, consulte o que são as reservas do Azure.
Distribuições do Linux endossadas no Azure
03/03/2021 • 12 minutes to read • Edit Online
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.
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"
Código-fonte: GitHub
Red Hat Enterprise Linux 6.x, 7.x, 8.x No kernel Pacote: no repositório, em
por Red Hat "WALinuxAgent"
Código-fonte: GitHub
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"
Código-fonte: GitHub
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.
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
03/03/2021 • 17 minutes to read • Edit Online
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.
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",
"location": "eastus",
"name": "myResourceGroup",
"properties": {
"provisioningState": "Succeeded"
},
"tags": null
}
A saída mostra que a sub-rede foi criada logicamente dentro da rede virtual:
{
"addressSpace": {
"addressPrefixes": [
"192.168.0.0/16"
]
},
"dhcpOptions": {
"dnsServers": []
},
"etag": "W/\"e95496fc-f417-426e-a4d8-c9e4d27fc2ee\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet",
"location": "eastus",
"name": "myVnet",
"provisioningState": "Succeeded",
"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,
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"resourceNavigationLinks": null,
"routeTable": null
}
],
"tags": {},
"type": "Microsoft.Network/virtualNetworks",
"virtualNetworkPeerings": null
}
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,
"location": "eastus",
"name": "myPublicIP",
"provisioningState": "Succeeded",
"publicIpAddressVersion": "IPv4",
"publicIpAllocationMethod": "Dynamic",
"resourceGroup": "myResourceGroup",
"resourceGuid": "4c65de38-71f5-4684-be10-75e605b3e41f",
"tags": null,
"type": "Microsoft.Network/publicIPAddresses"
}
}
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:
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:
az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNetworkSecurityGroup \
--name myNetworkSecurityGroupRuleWeb \
--protocol tcp \
--priority 1001 \
--destination-port-range 80 \
--access allow
Saída:
{
"defaultSecurityRules": [
{
"access": "Allow",
"description": "Allow inbound traffic from all VMs in VNET",
"destinationAddressPrefix": "VirtualNetwork",
"destinationPortRange": "*",
"direction": "Inbound",
"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": "*",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sourceAddressPrefix": "VirtualNetwork",
"sourcePortRange": "*"
},
{
"access": "Allow",
"description": "Allow inbound traffic from azure load balancer",
"destinationAddressPrefix": "*",
"destinationPortRange": "*",
"direction": "Inbound",
"etag": "W/\"3371b313-ea9f-4687-a336-a8ebdfd80523\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup/defaultSecurityRules/AllowAzureLoadBalancerInBou",
"name": "AllowAzureLoadBalancerInBound",
"priority": 65001,
"protocol": "*",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sourceAddressPrefix": "AzureLoadBalancer",
"sourcePortRange": "*"
},
{
"access": "Deny",
"description": "Deny all inbound traffic",
"destinationAddressPrefix": "*",
"destinationPortRange": "*",
"direction": "Inbound",
"etag": "W/\"3371b313-ea9f-4687-a336-a8ebdfd80523\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup/defaultSecurityRules/DenyAllInBound",
"name": "DenyAllInBound",
"priority": 65500,
"priority": 65500,
"protocol": "*",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sourceAddressPrefix": "*",
"sourcePortRange": "*"
},
{
"access": "Allow",
"description": "Allow outbound traffic from all VMs to all VMs in VNET",
"destinationAddressPrefix": "VirtualNetwork",
"destinationPortRange": "*",
"direction": "Outbound",
"etag": "W/\"3371b313-ea9f-4687-a336-a8ebdfd80523\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup/defaultSecurityRules/AllowVnetOutBound",
"name": "AllowVnetOutBound",
"priority": 65000,
"protocol": "*",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sourceAddressPrefix": "VirtualNetwork",
"sourcePortRange": "*"
},
{
"access": "Allow",
"description": "Allow outbound traffic from all VMs to Internet",
"destinationAddressPrefix": "Internet",
"destinationPortRange": "*",
"direction": "Outbound",
"etag": "W/\"3371b313-ea9f-4687-a336-a8ebdfd80523\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup/defaultSecurityRules/AllowInternetOutBound",
"name": "AllowInternetOutBound",
"priority": 65001,
"protocol": "*",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sourceAddressPrefix": "*",
"sourcePortRange": "*"
},
{
"access": "Deny",
"description": "Deny all outbound traffic",
"destinationAddressPrefix": "*",
"destinationPortRange": "*",
"direction": "Outbound",
"etag": "W/\"3371b313-ea9f-4687-a336-a8ebdfd80523\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup/defaultSecurityRules/DenyAllOutBound",
"name": "DenyAllOutBound",
"priority": 65500,
"protocol": "*",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sourceAddressPrefix": "*",
"sourcePortRange": "*"
}
],
"etag": "W/\"3371b313-ea9f-4687-a336-a8ebdfd80523\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup",
"location": "eastus",
"name": "myNetworkSecurityGroup",
"networkInterfaces": null,
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"resourceGuid": "47a9964e-23a3-438a-a726-8d60ebbb1c3c",
"securityRules": [
{
"access": "Allow",
"description": null,
"destinationAddressPrefix": "*",
"destinationPortRange": "22",
"direction": "Inbound",
"etag": "W/\"9e344b60-0daa-40a6-84f9-0ebbe4a4b640\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup/securityRules/myNetworkSecurityGroupRuleSSH",
"name": "myNetworkSecurityGroupRuleSSH",
"priority": 1000,
"protocol": "Tcp",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sourceAddressPrefix": "*",
"sourcePortRange": "*"
},
{
"access": "Allow",
"description": null,
"destinationAddressPrefix": "*",
"destinationPortRange": "80",
"direction": "Inbound",
"etag": "W/\"9e344b60-0daa-40a6-84f9-0ebbe4a4b640\"",
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup/securityRules/myNetworkSecurityGroupRuleWeb",
"name": "myNetworkSecurityGroupRuleWeb",
"priority": 1001,
"protocol": "Tcp",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"sourceAddressPrefix": "*",
"sourcePortRange": "*"
}
],
"subnets": null,
"tags": null,
"type": "Microsoft.Network/networkSecurityGroups"
}
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",
"ipConfigurations": [
{
"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,
"name": "ipconfig1",
"primary": true,
"privateIpAddress": "192.168.1.4",
"privateIpAddressVersion": "IPv4",
"privateIpAllocationMethod": "Dynamic",
"provisioningState": "Succeeded",
"publicIpAddress": {
"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,
"resourceGroup": "myResourceGroup",
"resourceGuid": null,
"tags": null,
"type": null
},
"resourceGroup": "myResourceGroup",
"subnet": {
"addressPrefix": null,
"etag": null,
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subne
ts/mySubnet",
"ipConfigurations": null,
"name": null,
"networkSecurityGroup": null,
"provisioningState": null,
"resourceGroup": "myResourceGroup",
"resourceNavigationLinks": null,
"routeTable": null
}
}
],
"location": "eastus",
"macAddress": null,
"name": "myNic",
"networkSecurityGroup": {
"defaultSecurityRules": null,
"defaultSecurityRules": null,
"etag": null,
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkSecurityGroups/myNetw
orkSecurityGroup",
"location": null,
"name": null,
"networkInterfaces": null,
"provisioningState": null,
"resourceGroup": "myResourceGroup",
"resourceGuid": null,
"securityRules": null,
"subnets": null,
"tags": null,
"type": null
},
"primary": null,
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"resourceGuid": "b3dbaa0e-2cf2-43be-a814-5cc49fea3304",
"tags": null,
"type": "Microsoft.Network/networkInterfaces",
"virtualMachine": null
}
}
az vm availability-set create \
--resource-group myResourceGroup \
--name myAvailabilitySet
az vm create \
--resource-group myResourceGroup \
--name myVM \
--location eastus \
--availability-set myAvailabilitySet \
--nics myNic \
--image UbuntuLTS \
--admin-username azureuser \
--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",
"location": "eastus",
"macAddress": "00-0D-3A-13-71-C8",
"powerState": "VM running",
"privateIpAddress": "192.168.1.5",
"publicIpAddress": "13.90.94.252",
"resourceGroup": "myResourceGroup"
}
ssh [email protected]
Saída:
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
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.
azureuser@myVM:~$
Você pode instalar o NGINX e ver o fluxo de tráfego para a VM. Instale o NGINX conforme demonstrado a
seguir:
Para ver o site NGINX padrão em ação, abra seu navegador da Web e digite o FQDN:
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:
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
03/11/2020 • 7 minutes to read • Edit Online
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 .
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"projectName": {
"type": "string",
"metadata": {
"description": "Specifies a name for generating resource names."
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"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": [
{
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2020-05-01",
"name": "[variables('networkSecurityGroupName')]",
"location": "[parameters('location')]",
"properties": {
"securityRules": [
{
"name": "ssh_rule",
"properties": {
"description": "Locks inbound down to ssh default port 22.",
"protocol": "Tcp",
"sourcePortRange": "*",
"destinationPortRange": "22",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 123,
"direction": "Inbound"
}
}
]
}
},
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2020-05-01",
"name": "[variables('publicIPAddressName')]",
"location": "[parameters('location')]",
"properties": {
"publicIPAllocationMethod": "Dynamic"
},
"sku": {
"name": "Basic"
}
},
{
{
"comments": "Simple Network Security Group for subnet [variables('vNetSubnetName')]",
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2020-05-01",
"name": "[variables('networkSecurityGroupName2')]",
"location": "[parameters('location')]",
"properties": {
"securityRules": [
{
"name": "default-allow-22",
"properties": {
"priority": 1000,
"access": "Allow",
"direction": "Inbound",
"destinationPortRange": "22",
"protocol": "Tcp",
"sourceAddressPrefix": "*",
"sourcePortRange": "*",
"destinationAddressPrefix": "*"
}
}
]
}
},
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2020-05-01",
"name": "[variables('vNetName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName2'))]"
],
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('vNetAddressPrefixes')]"
]
},
"subnets": [
{
"name": "[variables('vNetSubnetName')]",
"properties": {
"addressPrefix": "[variables('vNetSubnetAddressPrefix')]",
"networkSecurityGroup": {
"id": "[resourceId('Microsoft.Network/networkSecurityGroups',
variables('networkSecurityGroupName2'))]"
}
}
}
]
}
},
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2020-05-01",
"name": "[variables('networkInterfaceName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', variables('publicIPAddressName'))]",
"[resourceId('Microsoft.Network/virtualNetworks', variables('vNetName'))]",
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses',
"id": "[resourceId('Microsoft.Network/publicIPAddresses',
variables('publicIPAddressName'))]"
},
"subnet": {
"id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('vNetName'),
variables('vNetSubnetName'))]"
}
}
}
]
}
},
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2019-12-01",
"name": "[variables('vmName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkInterfaces', variables('networkInterfaceName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('vmSize')]"
},
"osProfile": {
"computerName": "[variables('vmName')]",
"adminUsername": "[parameters('adminUsername')]",
"linuxConfiguration": {
"disablePasswordAuthentication": true,
"ssh": {
"publicKeys": [
{
"path": "[concat('/home/', parameters('adminUsername'), '/.ssh/authorized_keys')]",
"keyData": "[parameters('adminPublicKey')]"
}
]
}
}
},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "18.04-LTS",
"version": "latest"
},
"osDisk": {
"createOption": "fromImage"
}
},
"networkProfile": {
"networkInterfaces": [
{
"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.
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
03/03/2021 • 5 minutes to read • Edit Online
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)
PUT https://management.azure.com/subscriptions/{subscription-
id}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vmName}?api-
version=2017-12-01
Para obter informações gerais sobre como trabalhar com solicitações da API REST, confira Componentes de uma
solicitação/resposta da API REST.
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
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
03/03/2021 • 5 minutes to read • Edit Online
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 \
--resource-group myResourceGroup \
--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:
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.)
3. Criar a NIC usando az network nic create. O exemplo a seguir cria uma NIC chamada myNic anexada à
sub-rede mySubnet:
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
03/11/2020 • 7 minutes to read • Edit Online
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.
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.
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
03/11/2020 • 6 minutes to read • Edit Online
8. Selecione OK para configurar o pipeline de entrega contínua para implantar na máquina virtual.
9. Os detalhes da implantação para a máquina virtual são exibidos. Você pode selecionar o link para acessar
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".
11. 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. Verifique se o pipeline
de build selecionado publica a implantação na pasta raiz do pacote.
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
azul-verde para máquinas virtuais do Linux do
Azure
03/11/2020 • 6 minutes to read • Edit Online
8. Selecione OK para configurar o pipeline de entrega contínua para implantar na máquina virtual.
9. Os detalhes da implantação para a máquina virtual são exibidos. Você pode selecionar o link para acessar
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.
10. 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. Verifique se o pipeline
de build selecionado publica a implantação na pasta raiz do pacote.
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: Implantar seu aplicativo em máquinas
virtuais do Linux no Azure usando o Azure DevOps
Services e o Azure Pipelines
03/03/2021 • 16 minutes to read • Edit Online
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.
NOTE
O Petclinic é um aplicativo Java Spring boot criado usando o Maven.
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.
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.
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:
- deployment: VMDeploy
displayName: web
pool:
vmImage: 'Ubuntu-16.04'
environment:
name: <environment name>
resourceType: VirtualMachine
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:
- deployment: VMDeploy
displayName: web
environment:
name: <environment name>
resourceType: VirtualMachine
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
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)
Abra a porta 80 para tráfego da Web
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.
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.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--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",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "40.68.254.142",
"resourceGroup": "myResourceGroup"
}
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.
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.
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.
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:
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.
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:
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:
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:
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';
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 :
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');
?>
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
Abra a porta 80 para tráfego da Web
Instalar Apache, MySQL e PHP
Verificar a instalação e a configuração
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
03/03/2021 • 9 minutes to read • Edit Online
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 um Cofre de chaves do Azure
Gerar ou carregar um certificado para o Cofre da Chave
Criar uma VM e instalar o servidor Web NGINX
Inserir o certificado na VM e configurar o NGINX com uma associação de TLS
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.
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.
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
az vm create \
--resource-group myResourceGroupSecureWeb \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys \
--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.
Para permitir o tráfego da web para acessar sua VM, abra a porta 443 da Internet com az vm open-port:
az vm open-port \
--resource-group myResourceGroupSecureWeb \
--name myVM \
--port 443
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 um Cofre de chaves do Azure
Gerar ou carregar um certificado para o Cofre da Chave
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
03/03/2021 • 8 minutes to read • Edit Online
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 um Cofre de chaves do Azure
Gerar ou carregar um certificado para o Cofre da Chave
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.
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 `
-Location $location `
-EnabledForDeployment
$policy = New-AzKeyVaultCertificatePolicy `
-SubjectName "CN=www.contoso.com" `
-SecretContentType "application/x-pkcs12" `
-IssuerName Self `
-ValidityInMonths 12
Add-AzKeyVaultCertificate `
-VaultName $keyvaultName `
-Name "mycert" `
-CertificatePolicy $policy
$cred = 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" `
-Location $location `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-PublicIpAddressName "myPublicIpAddress" `
-Credential $cred `
-OpenPorts 443
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.
$PublicSettings = '{
"fileUris":["https://raw.githubusercontent.com/Azure-Samples/compute-automation-
configurations/master/secure-iis.ps1"],
"commandToExecute":"powershell -ExecutionPolicy Unrestricted -File secure-iis.ps1"
}'
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 :
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.
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:
cat ~/.ssh/id_rsa.pub
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 \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--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):
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
03/11/2020 • 8 minutes to read • Edit Online
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.
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.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS\
--admin-username azureuser \
--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:
Se você tiver configurado uma frase secreta quando criou o par de chaves, insira a frase secreta quando
solicitado.
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 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
03/11/2020 • 6 minutes to read • Edit Online
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.
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:
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
03/03/2021 • 19 minutes to read • Edit Online
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.
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]-----+
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.
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
É 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.
cat ~/.ssh/id_rsa.pub
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
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 .)
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.
ssh-add ~/.ssh/id_rsa
touch ~/.ssh/config
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 o Portal do Azure
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
03/03/2021 • 10 minutes to read • Edit Online
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
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:
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:
Reinicie o serviço xrdp para que as alterações entrem em vigor da seguinte maneira:
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.
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.
Solucionar problemas
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:
Se o serviço xrdp-sesman não estiver escutando, em uma VM do Ubuntu, reinicie o serviço da seguinte maneira:
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
03/03/2021 • 10 minutes to read • Edit Online
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.
PUT
https://management.azure.com/subscriptions/<YourSubscriptionId>/resourcegroups/<YourResourceGroupName
>?api-version=2020-06-01
{
"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",
"contentVersion": "1.0.0.0"
},
"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",
"contentVersion": "1.0.0.0"
},
"parametersLink": {
"uri": "http://mystorageaccount.blob.core.windows.net/templates/parameters.json",
"contentVersion": "1.0.0.0"
},
"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": {
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storageAccountType": {
"type": "string",
"defaultValue": "Standard_LRS",
"allowedValues": [
"Standard_LRS",
"Standard_GRS",
"Standard_ZRS",
"Premium_LRS"
],
"metadata": {
"description": "Storage Account type"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"variables": {
"storageAccountName": "[concat(uniquestring(resourceGroup().id), 'standardsa')]"
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2018-02-01",
"name": "[variables('storageAccountName')]",
"location": "[parameters('location')]",
"sku": {
"name": "[parameters('storageAccountType')]"
},
"kind": "StorageV2",
"properties": {}
}
],
"outputs": {
"storageAccountName": {
"type": "string",
"value": "[variables('storageAccountName')]"
}
}
},
"parameters": {
"location": {
"value": "eastus2"
}
}
}
}
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
03/03/2021 • 8 minutes to read • Edit Online
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.
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
03/03/2021 • 12 minutes to read • Edit Online
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.
$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.
$resourceGroupName = 'myResourceGroup'
$vmName = 'myVM'
$location = 'westus'
$snapshotName = 'mySnapshot'
$snapshotConfig = New-AzSnapshotConfig `
-SourceUri $disk.Id `
-OsType Windows `
-CreateOption Copy `
-Location $location
Crie o instantâneo.
$snapShot = New-AzSnapshot `
-Snapshot $snapshotConfig `
-SnapshotName $snapshotName `
-ResourceGroupName $resourceGroupName
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
$osDiskName = 'myOsDisk'
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 `
-AddressPrefix 10.0.0.0/24
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"
$vnet = New-AzVirtualNetwork `
-Name $vnetName -ResourceGroupName $destinationResourceGroup `
-Location $location `
-AddressPrefix 10.0.0.0/16 `
-Subnet $singleSubnet
$nsgName = "myNsg"
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"
$pip = New-AzPublicIpAddress `
-Name $ipName -ResourceGroupName $destinationResourceGroup `
-Location $location `
-AllocationMethod Dynamic
$nicName = "myNicName"
$nic = New-AzNetworkInterface -Name $nicName `
-ResourceGroupName $destinationResourceGroup `
-Location $location -SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $pip.Id `
-NetworkSecurityGroupId $nsg.Id
Concluir a VM
Crie a VM usando New-AzVM com as configurações que acabamos de criar.
Se esse comando for bem-sucedido, você verá uma saída como esta:
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
03/03/2021 • 12 minutes to read • Edit Online
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.
mkdir java-azure-test
cd java-azure-test
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>
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/
package com.fabrikam.testAzureApp;
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();
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:
azure.virtualMachines.define("myVM")
.withRegion(Region.US_EAST)
.withExistingResourceGroup("myResourceGroup")
.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:
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();
System.out.println("Press enter to continue...");
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();
System.out.println("Press enter to continue...");
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();
System.out.println("Press enter to continue...");
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. 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
03/03/2021 • 7 minutes to read • Edit Online
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 .
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"adminUsername": {
"type": "string",
"metadata": {
"description": "Username for the Virtual Machine."
}
},
"adminPassword": {
"type": "securestring",
"minLength": 12,
"metadata": {
"description": "Password for the Virtual Machine."
}
},
"dnsLabelPrefix": {
"type": "string",
"defaultValue": "[toLower(concat(parameters('vmName'),'-', uniqueString(resourceGroup().id,
parameters('vmName'))))]",
"metadata": {
"description": "Unique DNS Name for the Public IP used to access the Virtual Machine."
}
},
"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-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",
"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",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
},
"vmName": {
"type": "string",
"defaultValue": "simple-vm",
"metadata": {
"description": "Name of the virtual machine."
}
}
},
"variables": {
"storageAccountName": "[concat('bootdiags', uniquestring(resourceGroup().id))]",
"nicName": "myVMNic",
"addressPrefix": "10.0.0.0/16",
"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')]",
"location": "[parameters('location')]",
"sku": {
"name": "Standard_LRS"
},
"kind": "Storage",
"properties": {}
},
{
"type": "Microsoft.Network/publicIPAddresses",
"apiVersion": "2020-06-01",
"name": "[parameters('publicIPName')]",
"location": "[parameters('location')]",
"sku": {
"name": "[parameters('publicIpSku')]"
},
"properties": {
"publicIPAllocationMethod": "[parameters('publicIPAllocationMethod')]",
"dnsSettings": {
"domainNameLabel": "[parameters('dnsLabelPrefix')]"
}
}
},
{
"type": "Microsoft.Network/networkSecurityGroups",
"apiVersion": "2020-06-01",
"name": "[variables('networkSecurityGroupName')]",
"location": "[parameters('location')]",
"properties": {
"securityRules": [
{
"name": "default-allow-3389",
"properties": {
"priority": 1000,
"access": "Allow",
"direction": "Inbound",
"destinationPortRange": "3389",
"protocol": "Tcp",
"sourcePortRange": "*",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*"
}
}
]
}
},
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2020-06-01",
"name": "[variables('virtualNetworkName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"
],
],
"properties": {
"addressSpace": {
"addressPrefixes": [
"[variables('addressPrefix')]"
]
},
"subnets": [
{
"name": "[variables('subnetName')]",
"properties": {
"addressPrefix": "[variables('subnetPrefix')]",
"networkSecurityGroup": {
"id": "[resourceId('Microsoft.Network/networkSecurityGroups',
variables('networkSecurityGroupName'))]"
}
}
}
]
}
},
{
"type": "Microsoft.Network/networkInterfaces",
"apiVersion": "2020-06-01",
"name": "[variables('nicName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPName'))]",
"[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworkName'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPName'))]"
},
"subnet": {
"id": "[variables('subnetRef')]"
}
}
}
]
}
},
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2020-06-01",
"name": "[parameters('vmName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('vmSize')]"
},
"osProfile": {
"computerName": "[parameters('vmName')]",
"adminUsername": "[parameters('adminUsername')]",
"adminPassword": "[parameters('adminPassword')]"
},
"storageProfile": {
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "[parameters('OSVersion')]",
"sku": "[parameters('OSVersion')]",
"version": "latest"
},
"osDisk": {
"createOption": "FromImage",
"managedDisk": {
"storageAccountType": "StandardSSD_LRS"
}
},
"dataDisks": [
{
"diskSizeGB": 1023,
"lun": 0,
"createOption": "Empty"
}
]
},
"networkProfile": {
"networkInterfaces": [
{
"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]"
}
}
}
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 :
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.
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
03/03/2021 • 4 minutes to read • Edit Online
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.
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.
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
03/03/2021 • 4 minutes to read • Edit Online
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
$certificateName = "somename"
[System.Collections.HashTable]$TableForJSON = @{
"data" = $filecontentencoded;
"dataType" = "pfx";
"password" = "<password>";
}
[System.String]$JSONObject = $TableForJSON | ConvertTo-Json
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
PowerShell
Você pode obter essa URL usando o comando do PowerShell abaixo
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
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.
N A M ESPA C E SO L UÇ Ã O DE P RO B L EM A S
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
03/03/2021 • 25 minutes to read • Edit Online
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.
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 :
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"}'
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:
Para obter mais informações sobre os modelos do Resource Manager, consulte Criando modelos do Azure
Resource Manager.
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",
"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'))]"
}
}
}
waagent --version
"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"
]
},
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:
O seguinte exemplo de saída mostra que autoUpgradeMinorVersion foi definido como true:
"resources": [
{
"autoUpgradeMinorVersion": true,
"forceUpdateTag": null,
"id":
"/subscriptions/guid/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM/extensi
ons/CustomScriptExtension",
az vm get-instance-view \
--resource-group rgName \
--name myVM \
--query "instanceView.extensions"
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 \
--resource-group myResourceGroup \
--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 .
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 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
03/03/2021 • 16 minutes to read • Edit Online
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.
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
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
Type: Boolean
Default: n
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
Type: String
Default: 10
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
Type: Boolean
Default: n
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
Type: Boolean
Default: y
Habilite ou desabilite a atualização automática para o processamento de estado de meta; o padrão é habilitada.
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.
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 :
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:
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.
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
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:
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.
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",
"type": "extensions",
"name": "config-app",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'),copyindex())]",
"[variables('musicstoresqlName')]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"typeHandlerVersion": "1.9",
"autoUpgradeMinorVersion": true,
"settings": {
"fileUris": [
"https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-
windows/scripts/configure-music-app.ps1"
]
},
"protectedSettings": {
"commandToExecute": "[concat('powershell -ExecutionPolicy Unrestricted -File configure-music-app.ps1
-user ',parameters('adminUsername'),' -password ',parameters('adminPassword'),' -sqlserver
',variables('musicstoresqlName'),'.database.windows.net')]"
}
}
}
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
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": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"typeHandlerVersion": "1.9",
"autoUpgradeMinorVersion": true,
"settings": {
"fileUris": [
"https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-music-
windows/scripts/configure-music-app.ps1"
]
},
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:
O seguinte exemplo de saída mostra que autoUpgradeMinorVersion foi definido como true:
ForceUpdateTag :
Publisher : Microsoft.Compute
VirtualMachineExtensionType : CustomScriptExtension
TypeHandlerVersion : 1.9
AutoUpgradeMinorVersion : True
Permissões de agente
Para executar suas tarefas, o agente precisa executar como Sistema Local.
-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:
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 .
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 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.
Visão geral do Agente de Máquina Virtual do Azure
03/03/2021 • 9 minutes to read • Edit Online
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')]",
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2016-04-30-preview",
"location": "[parameters('location')]",
"dependsOn": ["[concat('Microsoft.Network/networkInterfaces/', parameters('networkInterfaceName'))]"],
"properties": {
"osProfile": {
"computerName": "[parameters('virtualMachineName')]",
"adminUsername": "[parameters('adminUsername')]",
"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
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.
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
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.
Azure Disk Encryption para Linux
(Microsoft.Azure.Security.AzureDiskEncryptionForLinux)
03/03/2021 • 6 minutes to read • Edit Online
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).
{
"type": "extensions",
"name": "[name]",
"apiVersion": "2019-07-01",
"location": "[location]",
"properties": {
"publisher": "Microsoft.Azure.Security",
"type": "AzureDiskEncryptionForLinux",
"typeHandlerVersion": "1.1",
"autoUpgradeMinorVersion": true,
"settings": {
"DiskFormatQuery": "[diskFormatQuery]",
"EncryptionOperation": "[encryptionOperation]",
"KeyEncryptionAlgorithm": "[keyEncryptionAlgorithm]",
"KeyVaultURL": "[keyVaultURL]",
"KeyVaultResourceId": "[KeyVaultResourceId]",
"KeyEncryptionKeyURL": "[keyEncryptionKeyURL]",
"KekVaultResourceId": "[KekVaultResourceId",
"SequenceVersion": "sequenceVersion]",
"VolumeType": "[volumeType]"
}
}
}
{
"type": "extensions",
"name": "[name]",
"apiVersion": "2019-07-01",
"location": "[location]",
"properties": {
"protectedSettings": {
"AADClientSecret": "[aadClientSecret]",
"Passphrase": "[passphrase]"
},
"publisher": "Microsoft.Azure.Security",
"type": "AzureDiskEncryptionForLinux",
"typeHandlerVersion": "0.1",
"settings": {
"AADClientID": "[aadClientID]",
"DiskFormatQuery": "[diskFormatQuery]",
"EncryptionOperation": "[encryptionOperation]",
"KeyEncryptionAlgorithm": "[keyEncryptionAlgorithm]",
"KeyEncryptionKeyURL": "[keyEncryptionKeyURL]",
"KeyVaultURL": "[keyVaultURL]",
"SequenceVersion": "sequenceVersion]",
"VolumeType": "[volumeType]"
}
}
}
Usando AADClientCertificate :
{
"type": "extensions",
"name": "[name]",
"apiVersion": "2019-07-01",
"location": "[location]",
"properties": {
"protectedSettings": {
"AADClientCertificate": "[aadClientCertificate]",
"Passphrase": "[passphrase]"
},
"publisher": "Microsoft.Azure.Security",
"type": "AzureDiskEncryptionForLinux",
"typeHandlerVersion": "0.1",
"settings": {
"AADClientID": "[aadClientID]",
"DiskFormatQuery": "[diskFormatQuery]",
"EncryptionOperation": "[encryptionOperation]",
"KeyEncryptionAlgorithm": "[keyEncryptionAlgorithm]",
"KeyEncryptionKeyURL": "[keyEncryptionKeyURL]",
"KeyVaultURL": "[keyVaultURL]",
"SequenceVersion": "sequenceVersion]",
"VolumeType": "[volumeType]"
}
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
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.
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)
03/03/2021 • 4 minutes to read • Edit Online
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:
Sistemas operacionais e VMs com suporte
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.
{
"type": "extensions",
"name": "[name]",
"apiVersion": "2019-07-01",
"location": "[location]",
"properties": {
"publisher": "Microsoft.Azure.Security",
"type": "AzureDiskEncryption",
"typeHandlerVersion": "2.2",
"autoUpgradeMinorVersion": true,
"settings": {
"EncryptionOperation": "[encryptionOperation]",
"KeyEncryptionAlgorithm": "[keyEncryptionAlgorithm]",
"KeyVaultURL": "[keyVaultURL]",
"KeyVaultResourceId": "[keyVaultResourceID]",
"KeyEncryptionKeyURL": "[keyEncryptionKeyURL]",
"KekVaultResourceId": "[kekVaultResourceID]",
"SequenceVersion": "sequenceVersion]",
"VolumeType": "[volumeType]"
}
}
}
{
"type": "extensions",
"name": "[name]",
"apiVersion": "2019-07-01",
"location": "[location]",
"properties": {
"protectedSettings": {
"AADClientSecret": "[aadClientSecret]"
},
"publisher": "Microsoft.Azure.Security",
"type": "AzureDiskEncryption",
"typeHandlerVersion": "1.1",
"settings": {
"AADClientID": "[aadClientID]",
"EncryptionOperation": "[encryptionOperation]",
"KeyEncryptionAlgorithm": "[keyEncryptionAlgorithm]",
"KeyVaultURL": "[keyVaultURL]",
"KeyVaultResourceId": "[keyVaultResourceID]",
"KeyEncryptionKeyURL": "[keyEncryptionKeyURL]",
"KekVaultResourceId": "[kekVaultResourceID]",
"SequenceVersion": "sequenceVersion]",
"VolumeType": "[volumeType]"
}
}
}
Usando AADClientCertificate :
{
"type": "extensions",
"name": "[name]",
"apiVersion": "2019-07-01",
"location": "[location]",
"properties": {
"protectedSettings": {
"AADClientCertificate": "[aadClientCertificate]"
},
"publisher": "Microsoft.Azure.Security",
"type": "AzureDiskEncryption",
"typeHandlerVersion": "1.1",
"settings": {
"AADClientID": "[aadClientID]",
"EncryptionOperation": "[encryptionOperation]",
"KeyEncryptionAlgorithm": "[keyEncryptionAlgorithm]",
"KeyVaultURL": "[keyVaultURL]",
"KeyVaultResourceId": "[keyVaultResourceID]",
"KeyEncryptionKeyURL": "[keyEncryptionKeyURL]",
"KekVaultResourceId": "[kekVaultResourceID]",
"SequenceVersion": "sequenceVersion]",
"VolumeType": "[volumeType]"
}
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação de modelo
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.
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
03/03/2021 • 12 minutes to read • Edit Online
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')]": {} } }
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",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"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.
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação de modelo
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "KeyVaultForLinux",
"apiVersion": "2019-07-01",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vmName>)]"
],
"properties": {
"publisher": "Microsoft.Azure.KeyVault",
"type": "KeyVaultForLinux",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"secretsManagementSettings": {
"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">,
"observedCertificates": <list of KeyVault URIs representing monitored certificates, e.g.:
"https://myvault.vault.azure.net/secrets/mycertificate"
}
}
}
}
"secretsManagementSettings": {
"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.
# Build settings
$settings = '{"secretsManagementSettings":
{ "pollingIntervalInS": "' + <pollingInterval> +
'", "certificateStoreName": "' + <certStoreName> +
'", "certificateStoreLocation": "' + <certStoreLoc> +
'", "observedCertificates": ["' + <observedCert1> + '","' + <observedCert2> + '"] } }'
$extName = "KeyVaultForLinux"
$extPublisher = "Microsoft.Azure.KeyVault"
$extType = "KeyVaultForLinux"
# Build settings
$settings = '{"secretsManagementSettings":
{ "pollingIntervalInS": "' + <pollingInterval> +
'", "certificateStoreName": "' + <certStoreName> +
'", "certificateStoreLocation": "' + <certStoreLoc> +
'", "observedCertificates": ["' + <observedCert1> + '","' + <observedCert2> + '"] } }'
$extName = "KeyVaultForLinux"
$extPublisher = "Microsoft.Azure.KeyVault"
$extType = "KeyVaultForLinux"
CLI do Azure
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.
Perguntas frequentes
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.
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 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
03/03/2021 • 12 minutes to read • Edit Online
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')]": {}
}
}
"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 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:
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "KVVMExtensionForWindows",
"apiVersion": "2019-07-01",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vmName>)]"
],
"properties": {
"publisher": "Microsoft.Azure.KeyVault",
"type": "KeyVaultForWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"secretsManagementSettings": {
"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>,
"observedCertificates": <list of KeyVault URIs representing monitored certificates, e.g.:
"https://myvault.vault.azure.net/secrets/mycertificate"
},
"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.
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
certificateStoreName MY string
Implantação de modelo
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "KeyVaultForWindows",
"apiVersion": "2019-07-01",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vmName>)]"
],
"properties": {
"publisher": "Microsoft.Azure.KeyVault",
"type": "KeyVaultForWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"secretsManagementSettings": {
"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">,
"observedCertificates": <list of KeyVault URIs representing monitored certificates, e.g.:
["https://myvault.vault.azure.net/secrets/mycertificate",
"https://myvault.vault.azure.net/secrets/mycertificate2"]>
}
}
}
}
"secretsManagementSettings": {
"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.
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 = "KeyVaultForWindows"
$extPublisher = "Microsoft.Azure.KeyVault"
$extType = "KeyVaultForWindows"
# Build settings
$settings = '{"secretsManagementSettings":
{ "pollingIntervalInS": "' + <pollingInterval> +
'", "certificateStoreName": "' + <certStoreName> +
'", "certificateStoreLocation": "' + <certStoreLoc> +
'", "observedCertificates": ["' + <observedCert1> + '","' + <observedCert2> + '"] } }'
$extName = "KeyVaultForWindows"
$extPublisher = "Microsoft.Azure.KeyVault"
$extType = "KeyVaultForWindows"
CLI do Azure
Logs e configuração
%windrive%\WindowsAzure\Logs\Plugins\Microsoft.Azure.KeyVault.KeyVaultForWindows\
<version>\akvvm_service_<date>.log
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 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.
Backup do Azure para SQL Server em execução na
VM do Azure
03/03/2021 • 4 minutes to read • Edit Online
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.
Esquema de extensão
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": "",
"protectedSettings": {
"objectStr": "",
"logsBlobUri": "",
"statusBlobUri": ""
}
},
"publicSettings": {
"locale": "en-us",
"taskId": "1c0ae461-9d3b-418c-a505-bb31dfe2095d",
"objectStr": "",
"commandStartTimeUTCTicks": "636295005824665976",
"vmType": "vmType"
}
}]
}
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação de modelo
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.
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
03/03/2021 • 24 minutes to read • Edit Online
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.
Esquema de extensão
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.
{
"name": "config-app",
"type": "Extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2019-03-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', concat(variables('vmName'),copyindex()))]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Azure.Extensions",
"type": "CustomScript",
"typeHandlerVersion": "2.1",
"autoUpgradeMinorVersion": true,
"settings": {
"skipDos2Unix":false,
"timestamp":123456789
},
"protectedSettings": {
"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
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
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>"],
"commandToExecute": "<command-to-execute>",
"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.
{
"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.)
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:
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.sh"],
"commandToExecute": "sh script1.sh",
"managedIdentity" : { "clientId": "31b403aa-c364-4240-a7ff-d85fb6cd7232" }
}
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.sh"],
"commandToExecute": "sh script1.sh",
"managedIdentity" : { "objectId": "12dd289c-0583-46e5-b9b4-115d5c19ef4b" }
}
NOTE
A propriedade managedIdentity não pode ser usada em conjunto com as propriedades storageAccountName ou
storageAccountKey
Implantação de modelo
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.
{
"name": "config-app",
"type": "extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2019-03-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', concat(variables('vmName'),copyindex()))]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Azure.Extensions",
"type": "CustomScript",
"typeHandlerVersion": "2.1",
"autoUpgradeMinorVersion": true,
"settings": {
},
"protectedSettings": {
"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 \
--resource-group myResourceGroup \
--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.
az vm extension set \
--resource-group exttest \
--vm-name exttest \
--name customScript \
--publisher Microsoft.Azure.Extensions \
--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"}'
{
"fileUris": ["https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-
music-linux/scripts/config-music.sh"],
"commandToExecute": "./config-music.sh"
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM --name customScript \
--publisher Microsoft.Azure.Extensions \
--settings ./script-config.json
{
"commandToExecute": "apt-get -y update && apt-get install -y apache2"
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM --name customScript \
--publisher Microsoft.Azure.Extensions \
--settings ./script-config.json
{
"fileUris": ["https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-
music-linux/scripts/config-music.sh"]
}
{
"commandToExecute": "./config-music.sh <param1>"
}
Comando CLI do Azure:
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name customScript \
--publisher Microsoft.Azure.Extensions \
--settings ./script-config.json \
--protected-settings ./protected-config.json
Solução de problemas
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:
/var/log/waagent.log
/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"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 file=0 event="download
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"
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=enabled
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=end
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
03/03/2021 • 24 minutes to read • Edit Online
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
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 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 Server 2012 R2
Windows 10
Windows Server 2016
Windows Server 2016 Core
Windows Server 2019
Windows Server 2019 Core
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.
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 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
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. 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
provisão da extensão.
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.
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, 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.
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, será necessário 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 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.
Esquema de extensão
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.
{
"apiVersion": "2018-06-01",
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "virtualMachineName/config-app",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'),copyindex())]",
"[variables('musicstoresqlName')]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"typeHandlerVersion": "1.10",
"autoUpgradeMinorVersion": true,
"settings": {
"fileUris": [
"script location"
],
"timestamp":123456789
},
"protectedSettings": {
"commandToExecute": "myExecutionCommand",
"storageAccountName": "myStorageAccountName",
"storageAccountKey": "myStorageAccountKey",
"managedIdentity" : {}
}
}
}
NOTE
A propriedade managedIdentity não pode ser usada em conjunto com as propriedades storageAccountName ou
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.
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
NOTE
Esses nomes de propriedade diferenciam maiúsculas de minúsculas. Para evitar problemas de implantação, use os nomes
conforme mostrado aqui.
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
Usar configurações públicas talvez seja útil para depuração, mas é recomendável usar 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 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.
Propriedade: managedIdentity
NOTE
Essa propriedade precisa ser especificada somente em configurações protegidas.
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 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.ps1"],
"commandToExecute": "powershell.exe script1.ps1",
"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:
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.ps1"],
"commandToExecute": "powershell.exe script1.ps1",
"managedIdentity" : { "clientId": "31b403aa-c364-4240-a7ff-d85fb6cd7232" }
}
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.ps1"],
"commandToExecute": "powershell.exe script1.ps1",
"managedIdentity" : { "objectId": "12dd289c-0583-46e5-b9b4-115d5c19ef4b" }
}
NOTE
A propriedade managedIdentity não pode ser usada em conjunto com as propriedades storageAccountName ou
storageAccountKey
Implantação de modelo
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
Implantação do PowerShell
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.
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")
$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" `
-Publisher "Microsoft.Compute" `
-ExtensionType "CustomScriptExtension" `
-TypeHandlerVersion "1.10" `
-Settings $settings `
-ProtectedSettings $protectedSettings;
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.
VMs clássicas
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.
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.
# 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
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
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:
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
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
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. 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
03/03/2021 • 8 minutes to read • Edit Online
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.
Conectividade com a Internet
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.
Implantação de modelo
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 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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('vmName'),'/', parameters('vmExtensionName'))]",
"apiVersion": "2019-07-01",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', parameters('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Security",
"type": "IaaSAntimalware",
"typeHandlerVersion": "1.3",
"autoUpgradeMinorVersion": true,
"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
}
}
Implantação do PowerShell
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
-2147156224 MSI está ocupado com uma instalação Tente executar a instalação do último
diferente
C Ó DIGO DO ERRO SIGN IF IC A DO A Ç Ã O P O SSÍVEL
-2147156208 Pouco espaço em disco < 200 MB Excluir arquivos não utilizados e tentar
novamente 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
1 Função Incorreta
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 site de suporte do Azuree 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 Linux de janelas de VM instantânea para
Azure Backup
03/03/2021 • 6 minutes to read • Edit Online
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
Esquema de extensão
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.
{
"type": "extensions",
"name": "VMSnapshot",
"location":"<myLocation>",
"properties": {
"publisher": "Microsoft.RecoveryServices",
"type": "VMSnapshot",
"typeHandlerVersion": "1.9",
"autoUpgradeMinorVersion": true,
"settings": {
"locale":"<location>",
"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"
},
"protectedSettings": {
"objectStr": "<blob SAS uri representation of VM sent 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>"
}
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação de modelo
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.
/var/log/waagent.log
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
Esquema de extensão
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.
{
"type": "extensions",
"name": "VMSnapshot",
"location":"<myLocation>",
"properties": {
"publisher": "Microsoft.Azure.RecoveryServices",
"type": "VMSnapshot",
"typeHandlerVersion": "1.9",
"autoUpgradeMinorVersion": true,
"settings": {
"locale":"<location>",
"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"
},
"protectedSettings": {
"objectStr": "<blob SAS uri representation of VM sent 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>"
}
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação de modelo
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.
C:\Packages\Plugins\Microsoft.Azure.RecoveryServices.VMSnapshot
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:
Ubuntu 12+
Debian 7e8
CentOS 6.5+ e 7
CoreOS 899.17.0+
Esquema de extensão
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.
{
"type": "extensions",
"name": "Microsoft.Azure.NetworkWatcher",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.NetworkWatcher",
"type": "NetworkWatcherAgentLinux",
"typeHandlerVersion": "1.4",
"autoUpgradeMinorVersion": true
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO
apiVersion 2015-06-15
editor Microsoft.Azure.NetworkWatcher
tipo NetworkWatcherAgentLinux
typeHandlerVersion 1.4
Implantação de modelo
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.
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:
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
03/03/2021 • 4 minutes to read • Edit Online
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.
Conectividade com a Internet
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.
Esquema de extensão
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.
{
"type": "extensions",
"name": "Microsoft.Azure.NetworkWatcher",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.NetworkWatcher",
"type": "NetworkWatcherAgentWindows",
"typeHandlerVersion": "1.4",
"autoUpgradeMinorVersion": true
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO
apiVersion 2015-06-15
editor Microsoft.Azure.NetworkWatcher
tipo NetworkWatcherAgentWindows
typeHandlerVersion 1.4
Implantação de modelo
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.
Implantação do PowerShell
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"
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
03/03/2021 • 7 minutes to read • Edit Online
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 .
<#
.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
}
if ($foundVMs)
{
Write-Host "Finished $(if ($NoUpdate) {"searching"} else {"updating"}) out of date
AzureNetworkWatcherExtension on VMs"
}
else
{
Write-Host "All AzureNetworkWatcherExtensions up to date"
}
}
Usar o PowerShell
Execute os seguintes comandos em um prompt do PowerShell:
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:
#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
#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"
#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.
#Windows command
az vm extension set --resource-group "DALANDEMO" --vm-name "Linux-01" --name "NetworkWatcherAgentWindows" --
publisher "Microsoft.Azure.NetworkWatcher"
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
Azure, leia as Perguntas frequentes sobre o suporte do Microsoft Azure.
Extensão de driver InfiniBand para Linux
03/03/2021 • 6 minutes to read • Edit Online
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: Red Hat Enterprise Linux 7,4, 7,5, 7,6, 7,7, 8,1, 8, 2
Esquema de extensão
O JSON a seguir mostra o esquema para a extensão.
{
"name": "<myExtensionName>",
"type": "extensions",
"apiVersion": "2015-06-15",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <myVM>)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "InfiniBandDriverLinux",
"typeHandlerVersion": "1.1",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
Propriedades
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação
Modelo do Azure Resource Manager
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 configuração pós-implantação.
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 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",
"type": "extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', myVM)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "InfiniBandDriverLinux",
"typeHandlerVersion": "1.1",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-ResourceGroupName "myResourceGroup" `
-VMName "myVM" `
-Location "southcentralus" `
-Publisher "Microsoft.HpcCompute" `
-ExtensionName "InfiniBandDriverLinux" `
-ExtensionType "InfiniBandDriverLinux" `
-TypeHandlerVersion 1.1 `
-SettingString '{ `
}'
CLI do Azure
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name InfiniBandDriverLinux \
--publisher Microsoft.HpcCompute \
--version 1.1
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.
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 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
03/03/2021 • 6 minutes to read • Edit Online
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
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. Observe a NIC InfiniBand apropriada para os
tamanhos de VM da série H e N de interesse.
Esquema de extensão
O JSON a seguir mostra o esquema para a extensão.
{
"name": "<myExtensionName>",
"type": "extensions",
"apiVersion": "2015-06-15",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <myVM>)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "InfiniBandDriverWindows",
"typeHandlerVersion": "1.2",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
Propriedades
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação
Modelo do Azure Resource Manager
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 configuração pós-implantação.
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 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",
"type": "extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', myVM)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "InfiniBandDriverWindows",
"typeHandlerVersion": "1.2",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-ResourceGroupName "myResourceGroup" `
-VMName "myVM" `
-Location "southcentralus" `
-Publisher "Microsoft.HpcCompute" `
-ExtensionName "InfiniBandDriverWindows" `
-ExtensionType "InfiniBandDriverWindows" `
-TypeHandlerVersion 1.2 `
-SettingString '{ `
}'
CLI do Azure
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name InfiniBandDriverWindows \
--publisher Microsoft.HpcCompute \
--version 1.2
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.
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.
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.
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 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
03/03/2021 • 8 minutes to read • Edit Online
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
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: Red Hat Enterprise Linux 7,3, 7,4, 7,5, 7,6, 7,7, 7,8
Esquema de extensão
O JSON a seguir mostra o esquema para a extensão.
{
"name": "<myExtensionName>",
"type": "extensions",
"apiVersion": "2015-06-15",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <myVM>)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "NvidiaGpuDriverLinux",
"typeHandlerVersion": "1.3",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
Propriedades
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
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).
Implantação
Modelo do Azure Resource Manager
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 configuração pós-implantação.
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 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",
"type": "extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', myVM)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "NvidiaGpuDriverLinux",
"typeHandlerVersion": "1.3",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-ResourceGroupName "myResourceGroup" `
-VMName "myVM" `
-Location "southcentralus" `
-Publisher "Microsoft.HpcCompute" `
-ExtensionName "NvidiaGpuDriverLinux" `
-ExtensionType "NvidiaGpuDriverLinux" `
-TypeHandlerVersion 1.3 `
-SettingString '{ `
}'
CLI do Azure
O exemplo a seguir espelha os exemplos de Azure Resource Manager e PowerShell acima.
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name NvidiaGpuDriverLinux \
--publisher Microsoft.HpcCompute \
--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.
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name NvidiaGpuDriverLinux \
--publisher Microsoft.HpcCompute \
--version 1.3 \
--settings '{ \
"updateOS": true, \
"driverVersion": "10.0.130" \
}'
Solução de problemas e suporte
Solucionar problemas
Os dados sobre o estado das implantações de extensão podem ser recuperados no Portal do Azure usando o
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.
A saída de execução de extensão é registrada no arquivo a seguir. Consulte esse arquivo para acompanhar o
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
C Ó DIGO DE SA ÍDA SIGN IF IC A DO A Ç Ã O P O SSÍVEL
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 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.
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
03/03/2021 • 6 minutes to read • Edit Online
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
Esquema de extensão
O JSON a seguir mostra o esquema para a extensão.
{
"name": "<myExtensionName>",
"type": "extensions",
"apiVersion": "2015-06-15",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <myVM>)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "NvidiaGpuDriverWindows",
"typeHandlerVersion": "1.3",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
Propriedades
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação
Modelo do Azure Resource Manager
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 configuração pós-implantação.
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 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",
"type": "extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', myVM)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "NvidiaGpuDriverWindows",
"typeHandlerVersion": "1.3",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-ResourceGroupName "myResourceGroup" `
-VMName "myVM" `
-Location "southcentralus" `
-Publisher "Microsoft.HpcCompute" `
-ExtensionName "NvidiaGpuDriverWindows" `
-ExtensionType "NvidiaGpuDriverWindows" `
-TypeHandlerVersion 1.3 `
-SettingString '{ `
}'
CLI do Azure
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name NvidiaGpuDriverWindows \
--publisher Microsoft.HpcCompute \
--version 1.3 \
--settings '{ \
}'
C:\WindowsAzure\Logs\Plugins\Microsoft.HpcCompute.NvidiaGpuDriverWindows\
Códigos do Erro
C Ó DIGO DO ERRO SIGN IF IC A DO A Ç Ã O P O SSÍVEL
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
arquivos de log para determinar a
causa do erro.
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 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.
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 VMs série N, consulte tamanhos de máquinas virtuais otimizados para GPU.
Extensão de driver de GPU AMD para Windows
03/03/2021 • 5 minutes to read • Edit Online
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:
Esquema de extensão
O JSON a seguir mostra o esquema para a extensão.
{
"name": "<myExtensionName>",
"type": "extensions",
"apiVersion": "2015-06-15",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <myVM>)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "AmdGpuDriverWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
Propriedades
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação
Modelo do Azure Resource Manager
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 configuração pós-implantação.
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 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",
"type": "extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2015-06-15",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', myVM)]"
],
"properties": {
"publisher": "Microsoft.HpcCompute",
"type": "AmdGpuDriverWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
}
}
}
PowerShell
Set-AzVMExtension
-ResourceGroupName "myResourceGroup" `
-VMName "myVM" `
-Location "southcentralus" `
-Publisher "Microsoft.HpcCompute" `
-ExtensionName "AmdGpuDriverWindows" `
-ExtensionType "AmdGpuDriverWindows" `
-TypeHandlerVersion 1.0 `
-SettingString '{ `
}'
CLI do Azure
az vm extension set `
--resource-group myResourceGroup `
--vm-name myVM `
--name AmdGpuDriverWindows `
--publisher Microsoft.HpcCompute `
--version 1.0 `
--settings '{ `
}'
C:\WindowsAzure\Logs\Plugins\Microsoft.HpcCompute.AmdGpuDriverMicrosoft\
Códigos do Erro
C Ó DIGO DO ERRO SIGN IF IC A DO A Ç Ã O P O SSÍVEL
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
arquivos de log para determinar a
causa do erro.
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 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.
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 VMs série N, consulte tamanhos de máquinas virtuais otimizados para GPU.
Instalar o agente de Azure Monitor (versão prévia)
03/03/2021 • 5 minutes to read • Edit Online
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.
P RO P RIEDA DE W IN DO W S L IN UX
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
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
03/03/2021 • 13 minutes to read • Edit Online
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
Esquema de extensão
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "OMSExtension",
"apiVersion": "2018-06-01",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vm-name>)]"
],
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "OmsAgentForLinux",
"typeHandlerVersion": "1.13",
"autoUpgradeMinorVersion": true,
"settings": {
"workspaceId": "myWorkspaceId"
},
"protectedSettings": {
"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.
Valores de propriedade
NOME VA LO R/ EXEM P LO
apiVersion 2018-06-01
publicador Microsoft.EnterpriseCloud.Monitoring
type OmsAgentForLinux
typeHandlerVersion 1.13
Implantação de modelo
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.
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.
{
"type": "extensions",
"name": "OMSExtension",
"apiVersion": "2018-06-01",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vm-name>)]"
],
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "OmsAgentForLinux",
"typeHandlerVersion": "1.13",
"settings": {
"workspaceId": "myWorkspaceId"
},
"protectedSettings": {
"workspaceKey": "myWorkSpaceKey"
}
}
}
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "<parentVmResource>/OMSExtension",
"apiVersion": "2018-06-01",
"location": "<location>",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', <vm-name>)]"
],
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "OmsAgentForLinux",
"typeHandlerVersion": "1.13",
"settings": {
"workspaceId": "myWorkspaceId"
},
"protectedSettings": {
"workspaceKey": "myWorkSpaceKey"
}
}
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name OmsAgentForLinux \
--publisher Microsoft.EnterpriseCloud.Monitoring \
--protected-settings '{"workspaceKey":"myWorkspaceKey"}' \
--settings '{"workspaceId":"myWorkspaceId"}'
/opt/microsoft/omsagent/bin/stdout
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.
Informações adicionais podem ser encontradas no Guia de solução de problemas do Log Analytics-Agent-for-
Linux.
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 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 do Log Analytics para
Windows
03/03/2021 • 10 minutes to read • Edit Online
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
Esquema de extensão
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.
{
"type": "extensions",
"name": "OMSExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "MicrosoftMonitoringAgent",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"workspaceId": "myWorkSpaceId"
},
"protectedSettings": {
"workspaceKey": "myWorkspaceKey"
}
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO
apiVersion 2015-06-15
publicador Microsoft.EnterpriseCloud.Monitoring
type MicrosoftMonitoringAgent
typeHandlerVersion 1.0
Implantação de modelo
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 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.
{
"type": "extensions",
"name": "OMSExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "MicrosoftMonitoringAgent",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"workspaceId": "myWorkSpaceId"
},
"protectedSettings": {
"workspaceKey": "myWorkspaceKey"
}
}
}
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "<parentVmResource>/OMSExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.EnterpriseCloud.Monitoring",
"type": "MicrosoftMonitoringAgent",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"workspaceId": "myWorkSpaceId"
},
"protectedSettings": {
"workspaceKey": "myWorkspaceKey"
}
}
}
Implantação do PowerShell
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.
C:\WindowsAzure\Logs\Plugins\Microsoft.EnterpriseCloud.Monitoring.MicrosoftMonitoringAgent\
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 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 máquina virtual de dependência do
Azure Monitor para Linux
03/03/2021 • 5 minutes to read • Edit Online
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.
Esquema de extensão
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.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vmName": {
"type": "string",
"metadata": {
"description": "The name of existing Linux Azure VM."
}
}
},
"variables": {
"vmExtensionsApiVersion": "2017-03-30"
},
"resources": [
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('vmName'),'/DAExtension')]",
"apiVersion": "[variables('vmExtensionsApiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentLinux",
"typeHandlerVersion": "9.5",
"autoUpgradeMinorVersion": true
}
}
],
"outputs": {
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO
apiVersion 01-01-2015
publicador Microsoft.Azure.Monitoring.DependencyAgent
type DependencyAgentLinux
typeHandlerVersion 9,5
Implantação de modelo
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 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.
{
"type": "extensions",
"name": "DAExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentLinux",
"typeHandlerVersion": "9.5",
"autoUpgradeMinorVersion": true
}
}
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "<parentVmResource>/DAExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentLinux",
"typeHandlerVersion": "9.5",
"autoUpgradeMinorVersion": true
}
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name DependencyAgentLinux \
--publisher Microsoft.Azure.Monitoring.DependencyAgent \
--version 9.5
/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
03/03/2021 • 5 minutes to read • Edit Online
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.
Esquema de extensã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.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"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": [
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('vmName'),'/DAExtension')]",
"apiVersion": "[variables('vmExtensionsApiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentWindows",
"typeHandlerVersion": "9.5",
"autoUpgradeMinorVersion": true
}
}
],
"outputs": {
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO
apiVersion 01-01-2015
publicador Microsoft.Azure.Monitoring.DependencyAgent
type DependencyAgentWindows
typeHandlerVersion 9,5
Implantação de modelo
Você pode implantar as extensões de VM do Azure com modelos de 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 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.
{
"type": "extensions",
"name": "DAExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentWindows",
"typeHandlerVersion": "9.5",
"autoUpgradeMinorVersion": true
}
}
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "<parentVmResource>/DAExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.Azure.Monitoring.DependencyAgent",
"type": "DependencyAgentWindows",
"typeHandlerVersion": "9.5",
"autoUpgradeMinorVersion": true
}
}
Implantação do PowerShell
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.
C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Monitoring.DependencyAgent\
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 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.
Introdução ao manipulador de extensão de Desired
State Configuration do Azure
03/03/2021 • 18 minutes to read • Edit Online
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.
configuration IISInstall
{
node "localhost"
{
WindowsFeature IIS
{
Ensure = "Present"
Name = "Web-Server"
}
}
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name Microsoft.Powershell.DSC \
--publisher Microsoft.Powershell \
--version 2.77 --protected-settings '{}' \
--settings '{}'
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name DSCForLinux \
--publisher Microsoft.OSTCExtensions \
--version 2.7 --protected-settings '{}' \
--settings '{}'
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)
03/03/2021 • 13 minutes to read • Edit Online
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.
Conectividade com a Internet
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.
Esquema de extensão
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>"
}'
{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}
public.json
{
"FileUri": "<mof-file-uri>",
"ExtensionAction": "Push"
}
Formato do PowerShell
$privateConfig = '{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}'
$publicConfig = '{
"FileUri": "<mof-file-uri>",
"ExtensionAction": "Push"
}'
{
"FileUri": "<mof-file-uri>"
}
Formato do PowerShell
$publicConfig = '{
"FileUri": "<mof-file-uri>"
}'
Aplicar um arquivo de configuração meta MOF (em uma conta de armazenamento do Azure ) à VM
protected.json
{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}
public.json
{
"ExtensionAction": "Pull",
"FileUri": "<meta-mof-file-uri>"
}
Formato do PowerShell
$privateConfig = '{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}'
$publicConfig = '{
"ExtensionAction": "Pull",
"FileUri": "<meta-mof-file-uri>"
}'
{
"FileUri": "<meta-mof-file-uri>",
"ExtensionAction": "Pull"
}
Formato do PowerShell
$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
{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}
public.json
{
"ExtensionAction": "Install",
"FileUri": "<resource-zip-file-uri>"
}
Formato do PowerShell
$privateConfig = '{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}'
$publicConfig = '{
"ExtensionAction": "Install",
"FileUri": "<resource-zip-file-uri>"
}'
Instalar um módulo de recurso personalizado (um arquivo zip no armazenamento público ) para a VM
public.json
{
"ExtensionAction": "Install",
"FileUri": "<resource-zip-file-uri>"
}
Formato do PowerShell
$publicConfig = '{
"ExtensionAction": "Install",
"FileUri": "<resource-zip-file-uri>"
}'
{
"ResourceName": "<resource-name>",
"ExtensionAction": "Remove"
}
Formato do PowerShell
$publicConfig = '{
"ResourceName": "<resource-name>",
"ExtensionAction": "Remove"
}'
Implantação de modelo
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.
Implantação da CLI do Azure
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
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.
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:
Gerenciador de Recursos
Você pode mudar para o modo do Gerenciador de Recursos do Azure executando:
NOTE
No modo de Azure Resource Manager, o azure vm extension list não está disponível por enquanto.
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 = '{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}'
$publicConfig = '{
"ExtensionAction": "Push",
"FileUri": "<mof-file-uri>"
}'
Gerenciador de Recursos
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.
Você pode implantar a extensão DSCForLinux executando:
$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 = '{
"StorageAccountName": "<storage-account-name>",
"StorageAccountKey": "<storage-account-key>"
}'
$publicConfig = '{
"ExtensionAction": "Push",
"FileUri": "<mof-file-uri>"
}'
Set-AzVMExtension -ResourceGroupName $rgName -VMName $vmName -Location $location `
-Name $extensionName -Publisher $publisher -ExtensionType $extensionName `
-TypeHandlerVersion $version -SettingString $publicConfig -ProtectedSettingString $privateConfig
/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
03/03/2021 • 9 minutes to read • Edit Online
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
Conectividade com a Internet
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.
Esquema de extensão
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "Microsoft.Powershell.DSC",
"apiVersion": "2018-10-01",
"location": "<location>",
"properties": {
"publisher": "Microsoft.Powershell",
"type": "DSC",
"typeHandlerVersion": "2.77",
"autoUpgradeMinorVersion": true,
"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"
}
}
},
"protectedSettings": {
"configurationArguments": {
"parameterOfTypePSCredential1": {
"userName": "UsernameValue1",
"password": "PasswordValue1"
},
"parameterOfTypePSCredential2": {
"userName": "UsernameValue2",
"password": "PasswordValue2"
}
},
"configurationUrlSasToken": "?g!bber1sht0k3n",
"configurationDataUrlSasToken": "?dataAcC355T0k3N"
}
}
}
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
Implantação de modelo
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 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.
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:\WindowsAzure\Logs\Plugins\{Extension_Name}\{Extension_Version}
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 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.
Pssar credenciais para o manipulador de extensões
DSC do Azure
03/03/2021 • 4 minutes to read • Edit Online
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
$vm | Update-AzVM
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 obter mais informações sobre o DSC do PowerShell, vá até o Centro de documentação do PowerShell.
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
03/03/2021 • 18 minutes to read • Edit Online
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.
Detalhes
N O M E DA P RO P RIEDA DE TYPE DESC RIÇ Ã O
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 :
"protectedSettings": {
"configurationArguments": {
"parameterOfTypePSCredential1": {
"userName": "UsernameValue1",
"password": "PasswordValue1"
}
}
}
"settings": {
"configurationArguments": {
"RegistrationUrl" : "[parameters('registrationUrl1')]",
"NodeConfigurationName" : "nodeConfigurationNameValue1"
}
},
"protectedSettings": {
"configurationArguments": {
"RegistrationKey": {
"userName": "NOT_USED",
"Password": "registrationKey"
}
}
}
"settings": {
"configuration": {
"url": "https://demo.blob.core.windows.net/iisinstall.zip",
"script": "IisInstall.ps1",
"function": "IISInstall"
}
},
"protectedSettings": {
"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/',
parameters('automationAccountName'))).registrationUrl]",
"NodeConfigurationName" : "[parameters('NodeConfigName')]"
},
"protectedSettings": {
"configurationArguments": {
"RegistrationKey": {
"userName": "NOT_USED",
"Password": "[listKeys(resourceId('Microsoft.Automation/automationAccounts/',
parameters('automationAccountName')), '2018-01-15').Keys[0].value]"
}
}
}
"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"
}
}
},
"protectedSettings": {
"Items": {
"Key1": "PasswordValue1",
"Key2": "PasswordValue2"
},
"DataBlobUri": "https://UrlToConfigurationDataWithOptionalSasToken.psd1"
}
settings.wmfVersion settings.wmfVersion
settings.configuration.url settings.ModulesUrl
settings.configuration.module.name settings.ModuleSource
settings.configuration.module.version settings.ModuleVersion
settings.configurationArguments settings.Properties
settings.privacy.dataCollection settings.Privacy.dataCollection
settings.advancedOptions.downloadMappings settings.advancedOptions.downloadMappings
protectedSettings.configurationArguments protectedSettings.Properties
protectedSettings.configurationUrlSasToken settings.SasToken
Solução de problemas
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:
"configurationArguments": {
"RegistrationKey": {
"userName": "NOT_USED",
"Password": "RegistrationKey"
}
}
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.
Para obter mais informações sobre o DSC do PowerShell, vá até o Centro de documentação do PowerShell.
Gerenciar usuários administrativos, SSH e verificar
ou reparar discos em VMs Linux do usando a
extensão VMAccess com a CLI do Azure
03/03/2021 • 10 minutes to read • Edit Online
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:
Suse 11 e 12
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.
az vm user update \
--resource-group myResourceGroup \
--name myVM \
--username azureuser \
--ssh-key-value ~/.ssh/id_rsa.pub
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 \
--resource-group myResourceGroup \
--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 \
--resource-group myResourceGroup \
--name myVM
Excluir um usuário
O exemplo a seguir exclui um usuário chamado myNewUser na VM denominada myVM :
az vm user delete \
--resource-group myResourceGroup \
--name myVM \
--username myNewUser
{
"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"
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name VMAccessForLinux \
--publisher Microsoft.OSTCExtensions \
--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"
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name VMAccessForLinux \
--publisher Microsoft.OSTCExtensions \
--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
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name VMAccessForLinux \
--publisher Microsoft.OSTCExtensions \
--version 1.4 \
--protected-settings reset_sshd.json
{
"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"
}
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"
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name VMAccessForLinux \
--publisher Microsoft.OSTCExtensions \
--version 1.4 \
--protected-settings delete_user.json
{
"check_disk": "true",
"repair_disk": "true, mydiskname"
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name VMAccessForLinux \
--publisher Microsoft.OSTCExtensions \
--version 1.4 \
--protected-settings disk_check_repair.json
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 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 para VM do Chef para Linux e Windows
03/03/2021 • 6 minutes to read • Edit Online
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.
Conectividade com a Internet
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).
Esquema de extensão
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'),'/', parameters('chef_vm_extension_type'))]",
"apiVersion": "2017-12-01",
"location": "[parameters('location')]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Chef.Bootstrap.WindowsAzure",
"type": "[parameters('chef_vm_extension_type')]",
"typeHandlerVersion": "1210.13",
"settings": {
"bootstrap_options": {
"chef_server_url": "[parameters('chef_server_url')]",
"validation_client_name": "[parameters('chef_validation_client_name')]"
},
"runlist": "[parameters('chef_runlist')]"
},
"protectedSettings": {
"validation_key": "[parameters('chef_validation_key')]"
}
}
}
Configurações
NOME VA LO R/ EXEM P LO T IP O DE DA DO S N EC ESSÁ RIO ?
Configurações protegidas
NOME EXEM P LO T IP O DE DA DO S N EC ESSÁ RIO ?
Implantação de modelo
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 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.
/var/lib/waagent/Chef.Bootstrap.WindowsAzure.LinuxChefClient
Windows
C:\Packages\Plugins\Chef.Bootstrap.WindowsAzure.ChefClient\
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
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 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 do Agente Linux de Stackify Retrace
03/03/2021 • 6 minutes to read • Edit Online
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
Esquema de extensão
O JSON a seguir mostra o esquema para a extensão do Agente Stackify Retrace. A extensão requer environment
e activationKey .
{
"type": "extensions",
"name": "StackifyExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[resourceId('Microsoft.Compute/virtualMachines',variables('vmName'))]"
],
"properties": {
"publisher": "Stackify.LinuxAgent.Extension",
"type": "StackifyLinuxAgentExtension",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"environment": "myEnvironment"
},
"protectedSettings": {
"activationKey": "myActivationKey"
}
}
}
Implantação de modelo
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 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 .
{
"type": "extensions",
"name": "StackifyExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[resourceId('Microsoft.Compute/virtualMachines',variables('vmName'))]"
],
"properties": {
"publisher": "Stackify.LinuxAgent.Extension",
"type": "StackifyLinuxAgentExtension",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"environment": "myEnvironment"
},
"protectedSettings": {
"activationKey": "myActivationKey"
}
}
}
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.
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "<parentVmResource>/StackifyExtension",
"apiVersion": "[variables('apiVersion')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Stackify.LinuxAgent.Extension",
"type": "StackifyLinuxAgentExtension",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"environment": "myEnvironment"
},
"protectedSettings": {
"activationKey": "myActivationKey"
}
}
}
Implantação do PowerShell
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.
A extensão requer environment e activationKey .
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.
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.
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.
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
03/03/2021 • 5 minutes to read • Edit Online
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.
vim ~/clouddrive/azurepolicy.rules.json
{
"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.
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.
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 '{
"notAllowedExtensions": {
"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 \
--resource-group myResourceGroup \
--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 \
--resource-group myResourceGroup \
--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
03/03/2021 • 5 minutes to read • Edit Online
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.
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.
nano $home/clouddrive/parameters.json
{
"notAllowedExtensions": {
"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 '{
"notAllowedExtensions": {
"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 `
-ResourceGroupName "myResourceGroup" `
-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
03/03/2021 • 9 minutes to read • Edit Online
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
cat /etc/waagent.conf
# AutoUpdate.Enabled=y
AutoUpdate.Enabled=y
cat /etc/waagent.conf
# AutoUpdate.Enabled=y
AutoUpdate.Enabled=y
RHEL/CentOS 7
Verificar a versão atual do pacote
cat /etc/waagent.conf
# AutoUpdate.Enabled=y
AutoUpdate.Enabled=y
SUSE SLES
SUSE SLES 11 SP4
Verificar a versão atual do pacote
cat /etc/waagent.conf
# AutoUpdate.Enabled=y
AutoUpdate.Enabled=y
Para habilitar a execução:
cat /etc/waagent.conf
# AutoUpdate.Enabled=y
AutoUpdate.Enabled=y
Debian
Debian 7 "Jesse"/Debian 7 "Stretch"
Verificar a versão atual do pacote
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"
Verificar a versão atual do pacote
Verifique se a atualização automática está habilitada primeiro, verifique se ela está habilitada:
cat /etc/waagent.conf
AutoUpdate.Enabled=y
AutoUpdate.Enabled=y
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
[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:
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.
wget https://github.com/Azure/WALinuxAgent/archive/v2.2.x.zip
unzip v2.2.x.zip
cd WALinuxAgent-2.2.x
wget https://github.com/Azure/WALinuxAgent/archive/v2.2.14.zip
unzip v2.2.14.zip
cd WALinuxAgent-2.2.14
cat /etc/waagent.conf
# AutoUpdate.Enabled=y
AutoUpdate.Enabled=y
waagent -version
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.
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
"extensions_extensionname_protectedSettings": {
"defaultValue": null,
"type": "SecureObject"
}
"protectedSettings": {
"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
modelo do Resource Manager.
"storageAccountName": {
"defaultValue": null,
"type": "SecureString"
},
"storageAccountKey": {
"defaultValue": null,
"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
03/03/2021 • 5 minutes to read • Edit Online
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
}
]
}
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):
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
03/03/2021 • 4 minutes to read • Edit Online
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:
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
03/03/2021 • 7 minutes to read • Edit Online
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.
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.
SERVIÇ O C O N F IGURA Ç Ã O
Azure AD Domain Services Redes virtuais que contêm serviços do Azure AD Domain
Services
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.
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:
1. Entre no 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.
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
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 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 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 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.
SERVIÇ O C O N F IGURA Ç Ã O REC O M EN DA Ç Ã O
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.
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
03/03/2021 • 29 minutes to read • Edit Online
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ê.
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.
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
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.
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.
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:
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.
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.
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.
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.
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.
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
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.
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.
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
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
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
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
Planejamento da migração de recursos de IaaS do
clássico para o Azure Resource Manager
03/03/2021 • 29 minutes to read • Edit Online
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ê.
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.
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.
Visão geral da migração de recursos de IaaS com suporte da plataforma 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
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
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
Grupos de segurança de rede
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)
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)
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.
Armadilhas a serem evitadas
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
Considerações técnicas e compensações
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.
Armadilhas a serem evitadas
O teste parcial pode causar problemas e atraso na migração.
Além da migração
Considerações técnicas e compensações
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
Armadilhas a serem evitadas
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
Visão geral da migração de recursos de IaaS com suporte da plataforma 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
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
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
Migrar recursos de IaaS do modelo clássico para o
Azure Resource Manager usando a CLI do Azure
03/03/2021 • 12 minutes to read • Edit Online
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ê.
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
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.
azure login
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.
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.
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.
Quando você terminar de verificar esta etapa, volte para o modo asm .
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.
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 .
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.
Se a configuração preparada estiver correta, será possível continuar e confirmar os recursos usando o comando
a seguir.
Prepare a rede virtual de sua preferência para migração usando o comando a seguir.
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>
Se a configuração preparada estiver correta, será possível continuar e confirmar os recursos usando o comando
a seguir.
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.
Se a configuração preparada estiver correta, será possível continuar e confirmar os recursos usando o comando
a seguir.
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
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
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
Migrar recursos de IaaS do clássico para o Azure
Resource Manager usando o PowerShell
03/03/2021 • 21 minutes to read • Edit Online
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ê.
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.
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.
Connect-AzAccount
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.
Aguarde cinco minutos para que o registro seja concluído. Verifique o status da aprovação usando o seguinte
comando:
Add-AzureAccount
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.
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.
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:
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.
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:
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:
Se a configuração preparada estiver correta, será possível continuar e confirmar os recursos usando o comando
a seguir:
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:
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:
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:
Se a configuração preparada estiver correta, será possível continuar e confirmar os recursos usando o comando
a seguir:
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.
$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:
O comando a seguir retorna todas as imagens de VM com discos de dados armazenados na conta
de armazenamento.
Exclua todas as imagens de VM retornadas pelos comandos anteriores usando este comando:
$storageAccountName = "myStorageAccount"
Move-AzureStorageAccount -Validate -StorageAccountName $storageAccountName
Se a configuração preparada estiver correta, será possível continuar e confirmar os recursos usando o
comando a seguir:
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
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 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
Erros que normalmente ocorrem durante a
migração do clássico para Azure Resource Manager
03/03/2021 • 17 minutes to read • Edit Online
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 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.
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.
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>"
C A DEIA DE C A RA C T ERES DE ERRO AT EN UA Ç Ã 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
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".
C A DEIA DE C A RA C T ERES DE ERRO AT EN UA Ç Ã O
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
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)
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
# 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
AffinityGroup :
AttachedTo :
IsCorrupted : False
Label :
Location : East US
DiskSizeInGB : 11
DiskSizeInGB : 11
MediaLink : https://contosostorage.blob.core.windows.net/vhds/coreosvm-dd1.vhd
DiskName : coreosvm-coreosvm-0-201611230636240687
SourceImageName :
OS :
IOType : Standard
OperationDescription : Get-AzureDisk
OperationId : 0c56a2b7-a325-123b-7043-74c27d5a61fd
OperationStatus : 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
MediaLink : https://contosostorage.blob.core.windows.net/vhds/coreosvm-dd1.vhd
DiskName : coreosvm-coreosvm-0-201611230636240687
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
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
CLI do Azure
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
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
Confira as perguntas mais frequentes sobre a migração de recursos de IaaS do clássico para o Azure
Resource Manager
Ferramentas da comunidade para migrar recursos
de IaaS do clássico para o Azure Resource Manager
03/03/2021 • 3 minutes to read • Edit Online
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 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
Visão geral da migração de recursos de IaaS com suporte da plataforma 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
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
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
Perguntas frequentes sobre a migração clássica para
a migração do Azure Resource Manager
03/03/2021 • 16 minutes to read • Edit Online
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ê.
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 .
Próximas etapas
Para Linux:
Visão geral da migração de recursos de IaaS com suporte da plataforma 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
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
Para Windows:
Visão geral da migração de recursos de IaaS com suporte da plataforma 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
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
Tutorial: Saiba mais sobre o gerenciamento de
máquinas virtuais do Linux com a CLI do Azure
03/03/2021 • 19 minutes to read • Edit Online
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
Use o ambiente Bash no Azure Cloud Shell.
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 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:
O exemplo anterior pressupõe que você já conhece os parâmetros para uma política. Se precisar exibir os
parâmetros, use:
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:
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:
Vamos supor que você quer adicionar uma terceira marca. Execute o comando novamente com a nova marca.
Ele é adicionado às marcas existentes.
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)
# Get the resource IDs for all resources in the resource group
r=$(az resource list -g myResourceGroup --query [].id --output tsv)
Como alternativa, você pode aplicar as marcas do grupo de recursos aos recursos sem manter as marcas
existentes:
# Get the resource IDs for all resources in the resource group
r=$(az resource list -g myResourceGroup --query [].id --output tsv)
Para combinar vários valores em uma única marca, use uma cadeia de caracteres JSON.
Para aplicar marcas a uma máquina virtual, use o comando az resource tag. Nenhuma marca existente no
recurso é mantida.
É possível utilizar os valores retornados para tarefas de gerenciamento, como parar todas as máquinas virtuais
com um valor de marca.
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:
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. Saia da sessão SSH para sua VM e então exclua os recursos da seguinte
maneira:
Próximas etapas
Neste tutorial, você criou uma imagem de VM personalizada. Você aprendeu a:
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
03/03/2021 • 19 minutes to read • Edit Online
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.
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 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"}
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 `
-ResourceGroupName myResourceGroup
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:
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:
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:
# Get the resource group
$group = Get-AzResourceGroup myResourceGroup
Como alternativa, você pode aplicar as marcas do grupo de recursos aos recursos sem manter as marcas
existentes:
# 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.
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:
É possível utilizar os valores retornados para tarefas de gerenciamento, como parar todas as máquinas virtuais
com um valor de marca.
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:
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
Neste tutorial, você criou uma imagem de VM personalizada. Você aprendeu a:
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
03/11/2020 • 14 minutes to read • Edit Online
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.
hv_utils 24418 0
hv_vmbus 397185 7
hv_balloon,hyperv_keyboard,hv_netvsc,hid_hyperv,hv_utils,hyperv_fb,hv_storvsc
ps -ef | grep hv
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
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:
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
Para obter mais informações, consulte Hora precisa para Windows Server 2016.
Sincronização de Data/Hora para VMs do Windows
no Azure
03/03/2021 • 16 minutes to read • Edit Online
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.
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.
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).
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:
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.
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
03/03/2021 • 24 minutes to read • Edit Online
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.
Esquema de extensão
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.
{
"name": "config-app",
"type": "Extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2019-03-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', concat(variables('vmName'),copyindex()))]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Azure.Extensions",
"type": "CustomScript",
"typeHandlerVersion": "2.1",
"autoUpgradeMinorVersion": true,
"settings": {
"skipDos2Unix":false,
"timestamp":123456789
},
"protectedSettings": {
"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
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
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>"],
"commandToExecute": "<command-to-execute>",
"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.
{
"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.)
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:
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.sh"],
"commandToExecute": "sh script1.sh",
"managedIdentity" : { "clientId": "31b403aa-c364-4240-a7ff-d85fb6cd7232" }
}
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.sh"],
"commandToExecute": "sh script1.sh",
"managedIdentity" : { "objectId": "12dd289c-0583-46e5-b9b4-115d5c19ef4b" }
}
NOTE
A propriedade managedIdentity não pode ser usada em conjunto com as propriedades storageAccountName ou
storageAccountKey
Implantação de modelo
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.
{
"name": "config-app",
"type": "extensions",
"location": "[resourceGroup().location]",
"apiVersion": "2019-03-01",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', concat(variables('vmName'),copyindex()))]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Azure.Extensions",
"type": "CustomScript",
"typeHandlerVersion": "2.1",
"autoUpgradeMinorVersion": true,
"settings": {
},
"protectedSettings": {
"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 \
--resource-group myResourceGroup \
--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.
az vm extension set \
--resource-group exttest \
--vm-name exttest \
--name customScript \
--publisher Microsoft.Azure.Extensions \
--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"}'
{
"fileUris": ["https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-
music-linux/scripts/config-music.sh"],
"commandToExecute": "./config-music.sh"
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM --name customScript \
--publisher Microsoft.Azure.Extensions \
--settings ./script-config.json
{
"commandToExecute": "apt-get -y update && apt-get install -y apache2"
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM --name customScript \
--publisher Microsoft.Azure.Extensions \
--settings ./script-config.json
{
"fileUris": ["https://raw.githubusercontent.com/Microsoft/dotnet-core-sample-templates/master/dotnet-core-
music-linux/scripts/config-music.sh"]
}
{
"commandToExecute": "./config-music.sh <param1>"
}
Comando CLI do Azure:
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name customScript \
--publisher Microsoft.Azure.Extensions \
--settings ./script-config.json \
--protected-settings ./protected-config.json
Solução de problemas
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:
/var/log/waagent.log
/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"
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 file=0 event="download
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"
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=enabled
time=2018-04-26T17:47:23Z version=v2.0.6/git@1008306-clean operation=enable seq=0 event=end
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
03/03/2021 • 24 minutes to read • Edit Online
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
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 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 Server 2012 R2
Windows 10
Windows Server 2016
Windows Server 2016 Core
Windows Server 2019
Windows Server 2019 Core
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.
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 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
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. 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
provisão da extensão.
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.
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, 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.
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, será necessário 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 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.
Esquema de extensão
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.
{
"apiVersion": "2018-06-01",
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "virtualMachineName/config-app",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'),copyindex())]",
"[variables('musicstoresqlName')]"
],
"tags": {
"displayName": "config-app"
},
"properties": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"typeHandlerVersion": "1.10",
"autoUpgradeMinorVersion": true,
"settings": {
"fileUris": [
"script location"
],
"timestamp":123456789
},
"protectedSettings": {
"commandToExecute": "myExecutionCommand",
"storageAccountName": "myStorageAccountName",
"storageAccountKey": "myStorageAccountKey",
"managedIdentity" : {}
}
}
}
NOTE
A propriedade managedIdentity não pode ser usada em conjunto com as propriedades storageAccountName ou
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.
Valores de propriedade
NOME VA LO R/ EXEM P LO T IP O DE DA DO S
NOTE
Esses nomes de propriedade diferenciam maiúsculas de minúsculas. Para evitar problemas de implantação, use os nomes
conforme mostrado aqui.
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
Usar configurações públicas talvez seja útil para depuração, mas é recomendável usar 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 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.
Propriedade: managedIdentity
NOTE
Essa propriedade precisa ser especificada somente em configurações protegidas.
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 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.ps1"],
"commandToExecute": "powershell.exe script1.ps1",
"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:
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.ps1"],
"commandToExecute": "powershell.exe script1.ps1",
"managedIdentity" : { "clientId": "31b403aa-c364-4240-a7ff-d85fb6cd7232" }
}
{
"fileUris": ["https://mystorage.blob.core.windows.net/privatecontainer/script1.ps1"],
"commandToExecute": "powershell.exe script1.ps1",
"managedIdentity" : { "objectId": "12dd289c-0583-46e5-b9b4-115d5c19ef4b" }
}
NOTE
A propriedade managedIdentity não pode ser usada em conjunto com as propriedades storageAccountName ou
storageAccountKey
Implantação de modelo
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
Implantação do PowerShell
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.
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")
$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" `
-Publisher "Microsoft.Compute" `
-ExtensionType "CustomScriptExtension" `
-TypeHandlerVersion "1.10" `
-Settings $settings `
-ProtectedSettings $protectedSettings;
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.
VMs clássicas
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.
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.
# 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
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
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:
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
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
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. 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.
Executar scripts de shell em sua VM Linux usando o
recurso Executar Comando
03/03/2021 • 7 minutes to read • Edit Online
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
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.
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.
Não é recomendável executar um script que causará uma parada ou atualização do agente de VM. Isso pode
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
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
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.
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
03/03/2021 • 17 minutes to read • Edit Online
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.
T IP O DESC RIÇ Ã O
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.
Windows Automatizado
Manual
Linux Manual
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.
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.
Se você tiver mais de 2.000 trabalhadores híbridos, para obter uma lista de todos eles, poderá executar o
seguinte script do PowerShell:
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
03/03/2021 • 12 minutes to read • Edit Online
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.
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.
WARNING
Este comando reinicia a VM do Azure. Você perderá sua conexão RDP durante o processo de reinicialização.
Get-NetAdapter
NOTE
Anote o “ifIndex” do comutador virtual recém-criado.
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.
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
03/03/2021 • 7 minutes to read • Edit Online
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.
mkdir -p /mnt/MyAzureFileShare
Montar o compartilhamento
Monte o compartilhamento de arquivos do Azure para o diretório.
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.
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
03/03/2021 • 5 minutes to read • Edit Online
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
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
03/03/2021 • 21 minutes to read • Edit Online
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.
RedHat:RHEL:7-LVM:7.4.2018010506
RedHat:RHEL:7-LVM:7.5.2018081518
RedHat:RHEL:7-LVM:7.6.2019062414
RedHat:RHEL:7-RAW:7.4.2018010506
RedHat:RHEL:7-RAW:7.5.2018081518
RedHat:RHEL:7-RAW:7.6.2019062120
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
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.
yum --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel7-
eus.config' install 'rhui-azure-rhel7-eus'
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
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.
wget https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel8-eus.config
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 ').
5. Atualizar a VM do RHEL
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
yum --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel7.config'
install 'rhui-azure-rhel7'
4. Atualizar a VM do RHEL
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
wget https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel8.config
5. Atualizar a VM do RHEL
# 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.
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:
yum --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel6.config'
install 'rhui-azure-rhel6'
Para RHEL 7:
yum --config='https://rhelimage.blob.core.windows.net/repositories/rhui-microsoft-azure-rhel7.config'
install 'rhui-azure-rhel7'
Para RHEL 8:
1. Crie um arquivo de configuração:
vi rhel8.config
4. Atualize sua VM
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
03/03/2021 • 17 minutes to read • Edit Online
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
Use o ambiente Bash no Azure Cloud Shell.
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 \
--resource-group myResourceGroup \
--name myNewVM \
--nics myNic \
--size Standard_DS1_v2 --os-type Linux \
--attach-os-disk myVHD \
--plan-name planName \
--plan-publisher planPublisher \
--plan-product planProduct
Se você receber uma mensagem sobre como aceitar os termos da imagem, consulte a seção aceitar os termos
mais adiante neste artigo.
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
Offer Publisher Sku Urn
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
...
Resultado parcial:
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:
Offer Publisher Sku Urn Version
------- ----------- ----------------- ----------------------------------------------- -------------
Debian credativ 8 credativ:Debian:8:8.0.201602010 8.0.201602010
Debian credativ 8 credativ:Debian:8:8.0.201603020 8.0.201603020
Debian credativ 8 credativ:Debian:8:8.0.201604050 8.0.201604050
Debian credativ 8 credativ:Debian:8:8.0.201604200 8.0.201604200
Debian credativ 8 credativ:Debian:8:8.0.201606280 8.0.201606280
Debian credativ 8 credativ:Debian:8:8.0.201609120 8.0.201609120
Debian credativ 8 credativ:Debian:8:8.0.201611020 8.0.201611020
Debian credativ 8 credativ:Debian:8:8.0.201701180 8.0.201701180
Debian credativ 8 credativ:Debian:8:8.0.201703150 8.0.201703150
Debian credativ 8 credativ:Debian:8:8.0.201704110 8.0.201704110
Debian credativ 8 credativ:Debian:8:8.0.201704180 8.0.201704180
Debian credativ 8 credativ:Debian:8:8.0.201706190 8.0.201706190
Debian credativ 8 credativ:Debian:8:8.0.201706210 8.0.201706210
Debian credativ 8 credativ:Debian:8:8.0.201708040 8.0.201708040
Debian credativ 8 credativ:Debian:8:8.0.201710090 8.0.201710090
Debian credativ 8 credativ:Debian:8:8.0.201712040 8.0.201712040
Debian credativ 8 credativ:Debian:8:8.0.201801170 8.0.201801170
Debian credativ 8 credativ:Debian:8:8.0.201803130 8.0.201803130
Debian credativ 8 credativ:Debian:8:8.0.201803260 8.0.201803260
Debian credativ 8 credativ:Debian:8:8.0.201804020 8.0.201804020
Debian credativ 8 credativ:Debian:8:8.0.201804150 8.0.201804150
Debian credativ 8 credativ:Debian:8:8.0.201805160 8.0.201805160
Debian credativ 8 credativ:Debian:8:8.0.201807160 8.0.201807160
Debian credativ 8 credativ:Debian:8:8.0.201901221 8.0.201901221
...
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:
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:
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 :
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.
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",
"location": "westus",
"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:
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
03/03/2021 • 12 minutes to read • Edit Online
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.
$vm = Get-azvm `
-ResourceGroupName myResourceGroup `
-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"
...
...
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
$pubName="<publisher>"
Get-AzVMImageOffer -Location $locName -PublisherName $pubName | Select Offer
$offerName="<offer>"
Get-AzVMImageSku -Location $locName -PublisherName $pubName -Offer $offerName | Select Skus
$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
...
$pubName="MicrosoftWindowsServer"
Get-AzVMImageOffer -Location $locName -PublisherName $pubName | Select Offer
Saída:
Offer
-----
Windows-HUB
WindowsServer
WindowsServerSemiAnnual
$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
...
$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.
$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.
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.
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.
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
03/03/2021 • 4 minutes to read • Edit Online
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.
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
03/03/2021 • 10 minutes to read • Edit Online
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.
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.
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.
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
Flatcar Container Linux
Oracle Linux
Red Hat Enterprise Linux
SLES e openSUSE
Ubuntu
Próximas etapas
Saiba como criar uma Galeria de Imagens Compartilhadas.
Provisionamento de VM do Linux do Azure
03/11/2020 • 6 minutes to read • Edit Online
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.
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.
Próximas etapas
Se precisar, você poderá desabilitar o provisionamento e remover o agente do Linux.
Informações para distribuições não endossadas
03/03/2021 • 17 minutes to read • Edit Online
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:
Distribuições com base em CentOS
Debian Linux
Flatcar Container Linux
Oracle Linux
Red Hat Enterprise Linux
SLES e openSUSE
Ubuntu
Este artigo concentra-se na orientação geral para executar a distribuição do Linux no Azure.
cd /boot
sudo cp initrd-`uname -r`.img initrd-`uname -r`.img.bak
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))
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
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.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=2048 ## NOTE: Set this to your desired size.
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.
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:
NETWORKING=yes
HOSTNAME=localhost.localdomain
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:
7. Certifique-se de que o serviço de rede será iniciado na inicialização executando o seguinte comando:
[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
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6
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.
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:
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:
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.
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. 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.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.EnableSwap=y
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:
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
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. Crie ou edite o arquivo /etc/sysconfig/network e adicione o texto a seguir:
NETWORKING=yes
HOSTNAME=localhost.localdomain
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
NM_CONTROLLED=no
5. 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:
[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-7
#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
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
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:
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:
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. 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:
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.
9. Depois de editar /etc/default/grub como mostrado acima, execute o comando a seguir para recompilar
a configuração do grub:
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:
Recompile o initramfs:
sudo dracut -f -v
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
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:
14. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
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
# export HISTSIZE=0
# logout
15. 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 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
03/03/2021 • 6 minutes to read • Edit Online
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 .
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 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.
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. Para obter mais informações, consulte Notas de Instalação do Linux.
# sudo update-grub
Debian 9 "Stretch"
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:
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
03/11/2020 • 2 minutes to read • Edit Online
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.
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
Linux a partir de um disco personalizado.
Introdução ao FreeBSD no Azure
03/03/2021 • 7 minutes to read • Edit Online
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
FreeBSD 11.2 no Azure Marketplace
FreeBSD 12.0 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.
Se o bash não estiver instalado no seu computador FreeBSD, execute o comando a seguir antes da instalação.
Se o Python não estiver instalado no seu computador FreeBSD, execute o comando a seguir antes da instalação.
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 group create --name myResourceGroup --location eastus
az vm create --name myFreeBSD11 \
--resource-group myResourceGroup \
--image MicrosoftOSTC:FreeBSD:11.0:latest \
--admin-username azureuser \
--generate-ssh-keys
Em seguida, é possível entrar na VM do FreeBSD pelo endereço IP impresso na saída acima da implantação.
NOTE
A VM do FreeBSD só oferece suporte ao CustomScript versão 1. x até o momento.
$ sudo <COMMAND>
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
03/03/2021 • 5 minutes to read • Edit Online
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.
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 .
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
03/03/2021 • 16 minutes to read • Edit Online
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.
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
HOSTNAME=localhost.localdomain
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:
7. Certifique-se de que o serviço de rede será iniciado na inicialização executando o seguinte comando:
# chkconfig network on
9. 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 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.
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.
10. Confira se o servidor SSH está instalado e configurado para iniciar no tempo de inicialização. Geralmente,
esse é o padrão.
11. Instale o Agente Linux do Azure executando o comando a seguir. A versão mais recente é 2.0.15.
ResourceDisk.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=2048 ## NOTE: set this to whatever you need it to be.
13. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
no Azure:
14. Clique em Ação -> Desligar no Gerenciador do Hyper-V. Agora, seu VHD Linux está pronto para ser
carregado no Azure.
NETWORKING=yes
HOSTNAME=localhost.localdomain
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
5. 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:
6. Certifique-se de que o serviço de rede será iniciado na inicialização executando o seguinte comando:
8. Execute o comando a seguir para limpar os metadados atuais do yum e instalar atualizações:
9. 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 "/etc/default/grub" em um editor de texto e edite o
parâmetro GRUB_CMDLINE_LINUX . Por exemplo:
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. 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:
11. Confira se o servidor SSH está instalado e configurado para iniciar no tempo de inicialização. Geralmente,
esse é o padrão.
12. Instale o agente Linux do Azure e as dependências:
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
14. 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:
15. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
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
# 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.
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
03/03/2021 • 6 minutes to read • Edit Online
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.
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:
IMPORTANT
Depois de instalar o agente do Azure, convém verificar se ele está em execução da seguinte maneira:
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.
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:
Para separar logicamente os VHDs que você carregue, crie um contêiner dentro da conta de armazenamento
com criar contêiner de armazenamento az:
Por fim, carregue o VHD com carregamento de blob de armazenamento az da seguinte maneira:
az vm create \
--resource-group myResourceGroup \
--name myOpenBSD61 \
--image "https://mystorageaccount.blob.core.windows.net/vhds/OpenBSD61.vhd" \
--os-type linux \
--admin-username azureuser \
--ssh-key-value ~/.ssh/id_rsa.pub
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
03/03/2021 • 57 minutes to read • Edit Online
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.
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. 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
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 RHEL 6, NetworkManager pode interferir com o agente Linux do Azure. Desinstale este pacote ao
executar o seguinte comando:
NETWORKING=yes
HOSTNAME=localhost.localdomain
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:
# sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
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
executar o seguinte comando:
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:
10. 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 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:
console=ttyS0 earlyprintk=ttyS0 rootdelay=300
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.
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 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
ResourceDisk.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=2048 ## NOTE: set this to whatever you need it to be.
15. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
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 waagent -force -deprovision
# 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.
RHEL 7 usando o Gerenciador do Hyper-V
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. Crie ou edite o arquivo /etc/sysconfig/network e adicione o texto a seguir:
NETWORKING=yes
HOSTNAME=localhost.localdomain
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
PERSISTENT_DHCLIENT=yes
NM_CONTROLLED=yes
5. Certifique-se de que o serviço de rede será iniciado durante a inicialização executando o seguinte
comando:
6. Registre a sua assinatura do Red Hat para habilitar a instalação de pacotes do repositório RHEL ao
executar o seguinte comando:
7. 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 esta modificação, abra /etc/default/grub em um editor de
texto e edite o parâmetro GRUB_CMDLINE_LINUX . Por exemplo:
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.
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 a opção crashkernel configurada se quiser.
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:
ClientAliveInterval 180
10. 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:
11. Instale o agente Linux do Azure, o Cloud-init e outros utilitários necessários executando o seguinte
comando:
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:
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
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:
ResourceDisk.Format=n
ResourceDisk.EnableSwap=n
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
16. Clique em ação > desligar no Gerenciador do Hyper-V. Agora, seu VHD Linux está pronto para ser
carregado no Azure.
RHEL 8 usando o Gerenciador do Hyper-V
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. Verifique se o serviço Gerenciador de rede será iniciado no momento da inicialização executando o
seguinte comando:
5. Registre a sua assinatura do Red Hat para habilitar a instalação de pacotes do repositório RHEL ao
executar o seguinte comando:
# sudo subscription-manager register --auto-attach --username=XXX --password=XXX
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:
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:
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 a opção crashkernel configurada se quiser.
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.
7. Depois de editar /etc/default/grub , execute o comando a seguir para recompilar a configuração do
grub:
8. 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:
ClientAliveInterval 180
9. Instale o agente Linux do Azure, o Cloud-init e outros utilitários necessários executando o seguinte
comando:
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:
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
11. 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:
ResourceDisk.Format=n
ResourceDisk.EnableSwap=n
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.
14. Clique em ação > desligar no Gerenciador do Hyper-V. Agora, seu VHD Linux está pronto para ser
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:
NETWORKING=yes
HOSTNAME=localhost.localdomain
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 Azure ou no Hyper-V:
# sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
7. Certifique-se de que o serviço de rede será iniciado durante a inicialização executando o seguinte
comando:
# chkconfig network on
8. Registre a sua assinatura do Red Hat para habilitar a instalação de pacotes do repositório RHEL ao
executar o seguinte comando:
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.
Além dos itens acima, recomendamos remover 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 a opção crashkernel configurada se quiser.
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.
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
12. Verifique se o servidor SSH está instalado e configurado para começar na hora da inicialização:
# chkconfig sshd on
PasswordAuthentication yes
ClientAliveInterval 180
13. 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:
# chkconfig waagent on
15. 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 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:
ResourceDisk.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=2048 ## NOTE: set this to whatever you need it to be.
# subscription-manager unregister
17. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
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
# export HISTSIZE=0
# logout
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.
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" | \
gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')
# rounded_size=$((($size/$MB + 1)*$MB))
# qemu-img resize rhel-6.9.raw $rounded_size
NETWORKING=yes
HOSTNAME=localhost.localdomain
6. Certifique-se de que o serviço de rede será iniciado durante a inicialização executando o seguinte
comando:
7. Registre a sua assinatura do Red Hat para habilitar a instalação de pacotes do repositório RHEL ao
executar o seguinte comando:
8. 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 essa configuração, abra /etc/default/grub em um editor de
texto e edite o parâmetro GRUB_CMDLINE_LINUX . Por exemplo:
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:
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 a opção crashkernel configurada se quiser.
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.
9. Depois de editar /etc/default/grub , execute o comando a seguir para recompilar a configuração do
grub:
# grub2-mkconfig -o /boot/grub2/grub.cfg
Recrie initramfs:
# dracut -f -v
12. Verifique se o servidor SSH está instalado e configurado para começar na hora da inicialização:
PasswordAuthentication yes
ClientAliveInterval 180
13. 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:
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 '
17. Cancele o registro da assinatura (se necessário) executando o seguinte comando:
# 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
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.
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-7.4.raw" | \
gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')
# rounded_size=$((($size/$MB + 1)*$MB))
# qemu-img resize rhel-7.4.raw $rounded_size
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
executar o seguinte comando:
# sudo rpm -e --nodeps NetworkManager
2. Crie um arquivo chamado network no diretório /etc/sysconfig/ que contém o seguinte texto:
NETWORKING=yes
HOSTNAME=localhost.localdomain
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
4. 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 Azure ou no Hyper-V:
# sudo rm -f /etc/udev/rules.d/70-persistent-net.rules
5. Certifique-se de que o serviço de rede será iniciado durante a inicialização executando o seguinte
comando:
6. Registre a sua assinatura do Red Hat para habilitar a instalação de pacotes do repositório RHEL ao
executar o seguinte comando:
7. 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:
8. 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 /etc/default/grub em um editor de texto e edite o
parâmetro GRUB_CMDLINE_LINUX . Por exemplo:
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. Além dos itens acima, recomendamos
remover os seguintes parâmetros:
rhgb quiet crashkernel=auto
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 a opção crashkernel configurada se quiser.
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.
9. Adicione os módulos do Hyper-V em initramfs:
Edite /etc/dracut.conf e adicione o seguinte conteúdo:
Recrie initramfs:
# dracut -f -v
10. 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:
ClientAliveInterval 180
ResourceDisk.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=2048 ## NOTE: set this to whatever you need it to be.
14. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
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
# export HISTSIZE=0
# logout
15. Desligue a máquina virtual e, em seguida, converta o arquivo VMDK em um arquivo .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.
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" | \
gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')
# rounded_size=$((($size/$MB + 1)*$MB))
# qemu-img resize rhel-6.9.raw $rounded_size
NETWORKING=yes
HOSTNAME=localhost.localdomain
3. Certifique-se de que o serviço de rede será iniciado durante a inicialização executando o seguinte
comando:
4. Registre a sua assinatura do Red Hat para habilitar a instalação de pacotes do repositório RHEL ao
executar o seguinte comando:
5. 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 esta modificação, abra /etc/default/grub em um editor de
texto e edite o parâmetro GRUB_CMDLINE_LINUX . Por exemplo:
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:
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 a opção crashkernel configurada se quiser.
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.
6. Depois de editar /etc/default/grub , execute o comando a seguir para recompilar a configuração do
grub:
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:
ClientAliveInterval 180
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:
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
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.
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-7.4.raw" | \
gawk 'match($0, /"virtual-size": ([0-9]+),/, val) {print val[1]}')
# rounded_size=$((($size/$MB + 1)*$MB))
# qemu-img resize rhel-7.4.raw $rounded_size
# 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
# Firewall configuration
firewall --disabled
# Enable SELinux
selinux --enforcing
# Don't configure X
skipx
%packages
@base
@console-internet
chrony
sudo
parted
-dracut-config-rescue
%end
%post --log=/var/log/anaconda/post-install.log
#!/bin/bash
# Install WALinuxAgent
yum install -y WALinuxAgent
# Install cloud-init
yum install -y cloud-init cloud-utils-growpart gdisk hyperv-daemons
# Configure network
cat << EOF > /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=no
PERSISTENT_DHCLIENT=yes
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
%end
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:
Edite /etc/dracut.conf e adicione o seguinte conteúdo:
Recrie initramfs:
# dracut -f -v
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
03/03/2021 • 12 minutes to read • Edit Online
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.
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
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.
9. Verifique se o arquivo/etc/fstab faz referência ao disco usando seu UUID (por UUID)
10. 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:
DHCLIENT_SET_HOSTNAME="no"
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'!
13. Confira se o servidor SSH está instalado e configurado para iniciar no tempo de inicialização. Geralmente,
esse é o padrão.
14. Alternar configuração
Não crie 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:
15. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
no Azure:
# 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.
# A L IA S NAME H A B IL ITA DA AT UA L IZ A R
Se o comando retornar "Nenhum repositório definido...", use os seguintes comandos para adicionar esses
repositórios:
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:
6. 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:
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. Além disso, remova os seguintes parâmetros
da linha de inicialização do kernel, se existirem:
libata.atapi_enabled=0 reserve=0x1f0,0x8
DHCLIENT_SET_HOSTNAME="no"
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'!
9. Confira se o servidor SSH está instalado e configurado para iniciar no tempo de inicialização. Geralmente,
esse é o padrão.
10. Não crie espaço de permuta no disco do SO.
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. 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 (consulte a etapa anterior), modifique os seguintes parâmetros em
/etc/waagent.conf de maneira apropriada:
ResourceDisk.Format=y
ResourceDisk.Filesystem=ext4
ResourceDisk.MountPoint=/mnt/resource
ResourceDisk.EnableSwap=y
ResourceDisk.SwapSizeMB=2048 ## NOTE: set this to whatever you need it to be.
11. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
no Azure:
13. 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 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
03/03/2021 • 9 minutes to read • Edit Online
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
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 para o
formato VHD usando o Gerenciador do Hyper-V ou o Convert-VHD cmdlet.
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 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 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.
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.
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.
# sudo sed -i
's/https:\/\/fanyv88.com:443\/http\/archive\.ubuntu\.com\/ubuntu\//https:\/\/fanyv88.com:443\/http\/azure\.archive\.ubuntu\.com\/ubuntu\//g'
/etc/apt/sources.list
# sudo sed -i 's/http:\/\/[a-z][a-
z]\.archive\.ubuntu\.com\/ubuntu\//https:\/\/fanyv88.com:443\/http\/azure\.archive\.ubuntu\.com\/ubuntu\//g'
/etc/apt/sources.list
# sudo apt-get update
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 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:
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.
6. Confira se o servidor SSH está instalado e configurado para iniciar no tempo de inicialização. Geralmente,
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.
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
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.
12. Execute os comandos a seguir para desprovisionar a máquina virtual e prepará-la para provisionamento
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.
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
Linux a partir de um disco personalizado.
Suporte à cloud-init para máquinas virtuais no
Azure
03/03/2021 • 19 minutes to read • Edit Online
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).
RHEL
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
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
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
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
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
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
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
SuSE: SLES-{BYOS/SAP/SAP-BYOS}: 12-SP3:2020.06.10
SuSE: SLES-{BYOS/SAP/SAP-BYOS}: 12-SP2:2020.06.10
Debian
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
Atualmente, o Azure Stack dará suporte ao provisionamento de imagens habilitadas para cloud-init.
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
package_upgrade: true
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 \
--resource-group myResourceGroup \
--name centos74 \
--image OpenLogic:CentOS-CI:7-CI:latest \
--custom-data cloud-init.txt \
--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.
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.
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
03/11/2020 • 5 minutes to read • Edit Online
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.
- 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
03/03/2021 • 11 minutes to read • Edit Online
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.
/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.
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
03/11/2020 • 4 minutes to read • Edit Online
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
#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.
O exemplo a seguir cria um grupo de recursos chamado myResourceGroup no local eastus.
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 \
--resource-group myResourceGroup \
--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>
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:
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)
Usar a cloud-init para atualizar e instalar pacotes
em uma VM do Linux no Azure
03/11/2020 • 4 minutes to read • Edit Online
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
#cloud-config
package_upgrade: true
packages:
- httpd
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.
O exemplo a seguir cria um grupo de recursos chamado myResourceGroup no local eastus.
Agora, crie uma VM com az vm create e especifique o arquivo de inicialização de nuvem com
--custom-data cloud_init_upgrade.txt da seguinte maneira:
az vm create \
--resource-group myResourceGroup \
--name centos74 \
--image OpenLogic:CentOS:7-CI:latest \
--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:
ssh <publicIpAddress>
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.
Próximas etapas
Para obter exemplos adicionais de alterações de configuração do cloud-init, consulte o seguinte:
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)
Usar cloud-init para adicionar um usuário a uma
VM Linux no Azure
03/11/2020 • 5 minutes to read • Edit Online
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.
#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.
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.
O exemplo a seguir cria um grupo de recursos chamado myResourceGroup no local eastus.
Agora, crie uma VM com az vm create e especifique o arquivo de inicialização de nuvem com
--custom-data cloud_init_add_user.txt da seguinte maneira:
az vm create \
--resource-group myResourceGroup \
--name centos74 \
--image OpenLogic:CentOS:7-CI:latest \
--custom-data cloud_init_add_user.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:
ssh <publicIpAddress>
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
Para obter exemplos adicionais de alterações de configuração do cloud-init, consulte o seguinte:
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)
Usar Cloud-init para configurar uma partição de
permuta em uma VM do Linux
03/11/2020 • 4 minutes to read • Edit Online
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
#cloud-config
disk_setup:
ephemeral0:
table_type: gpt
layout: [66, [33,82]]
overwrite: true
fs_setup:
- device: ephemeral0.1
filesystem: ext4
- device: ephemeral0.2
filesystem: swap
mounts:
- ["ephemeral0.1", "/mnt"]
- ["ephemeral0.2", "none", "swap", "sw", "0", "0"]
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.
O exemplo a seguir cria um grupo de recursos chamado myResourceGroup no local eastus.
Agora, crie uma VM com az vm create e especifique o arquivo de inicialização de nuvem com
--custom-data cloud_init_swappart.txt da seguinte maneira:
az vm create \
--resource-group myResourceGroup \
--name centos74 \
--image OpenLogic:CentOS:7-CI:latest \
--custom-data cloud_init_swappart.txt \
--generate-ssh-keys
ssh <publicIpAddress>
Depois que você tiver SSH'ed na VM, verifique se a partição de permuta foi criada
swapon -s
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
Para obter exemplos adicionais de alterações de configuração do cloud-init, consulte o seguinte:
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)
Usar cloud-init para executar um script de bash em
uma VM Linux no Azure
03/11/2020 • 4 minutes to read • Edit Online
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
#!/bin/sh
echo "this has been written via cloud-init" + $(date) >> /tmp/myScript.txt
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.
O exemplo a seguir cria um grupo de recursos chamado myResourceGroup no local eastus.
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 \
--resource-group myResourceGroup \
--name centos74 \
--image OpenLogic:CentOS:7-CI:latest \
--custom-data simple_bash.sh \
--generate-ssh-keys
ssh <publicIpAddress>
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:
Próximas etapas
Para obter exemplos adicionais de alterações de configuração do cloud-init, consulte o seguinte:
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)
Criando imagens generalizadas sem um agente de
provisionamento
03/03/2021 • 9 minutes to read • Edit Online
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.
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"
import http.client
import sys
from xml.etree import ElementTree
wireserver_ip = '168.63.129.16'
wireserver_conn = http.client.HTTPConnection(wireserver_ip)
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}')
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()
<Health>
<GoalStateIncarnation>1</GoalStateIncarnation>
<Container>
<ContainerId>CONTAINER_ID</ContainerId>
<RoleInstanceList>
<Role>
<InstanceId>INSTANCE_ID</InstanceId>
<Health>
<State>Ready</State>
</Health>
</Role>
</RoleInstanceList>
</Container>
</Health>
[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
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 image create \
--resource-group demo1 \
--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 \
--resource-group demo12 \
--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:
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
03/03/2021 • 8 minutes to read • Edit Online
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.
NOTE
Se você não fizer isso, a plataforma tentará enviar a configuração de extensão e o tempo limite após 40min.
Você pode reabilitar facilmente esse processamento de extensão da plataforma, com o comando acima, mas
defini-lo como ' true '.
Para SUSE
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
Para SUSE
rm /etc/ssh/ssh_host_*key*
touch /var/run/utmp
userdel -f -r <admin_user_account>
passwd -d root
Depois de concluir o acima, você poderá criar a imagem personalizada usando o CLI do Azure.
Criar uma imagem gerenciada regular
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')]",
"adminUsername": "[parameters('adminUsername')]",
"linuxConfiguration": {
"disablePasswordAuthentication": "true",
"provisionVMAgent": false,
"ssh": {
"publicKeys": [
{
"path": "[concat('/home/', parameters('adminUsername'), '/.ssh/authorized_keys')]",
"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
03/03/2021 • 9 minutes to read • Edit Online
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.
az vm deallocate \
--resource-group myResourceGroup \
--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 \
--resource-group myResourceGroup \
--name myVM
az image create \
--resource-group myResourceGroup \
--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.
az vm create \
--resource-group myResourceGroup \
--name myVMDeployed \
--image myImage\
--admin-username azureuser \
--ssh-key-value ~/.ssh/id_rsa.pub
"id": "/subscriptions/guid/resourceGroups/MYRESOURCEGROUP/providers/Microsoft.Compute/images/myImage",
"location": "westus",
"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" \
--admin-username azureuser \
--ssh-key-value ~/.ssh/id_rsa.pub
az vm show \
--resource-group myResourceGroup \
--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
03/03/2021 • 35 minutes to read • Edit Online
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.
IMPORTANT
Use uma sessão do PowerShell com privilégios elevados para executar os exemplos neste artigo.
sfc.exe /scannow
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).
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:
3. Abra o DiskPart:
diskpart.exe
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 :
6. Verifique se as variáveis de ambiente Temp e tmp estão definidas com seus valores padrão:
Get-Service -Name BFE, Dhcp, Dnscache, IKEEXT, iphlpsvc, nsi, mpssvc, RemoteRegistry |
Where-Object StartType -ne Automatic |
Set-Service -StartupType Automatic
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.
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:
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
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
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
GO A L P O L ÍT IC A VA LO R
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
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 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
winmgmt.exe /verifyrepository
netstat.exe -anob
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:
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights
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
volmgr.sy 10.0.150 - -
s 63.0
termdd.sy 6.1.7601. - - - - - -
s 23403 –
KB31255
74
rdpdd.dll 6.1.7601. - - - - - -
23403 –
KB31255
74
rdpwd.sys 6.1.7601. - - - - - -
23403 –
KB31255
74
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.
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.
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.
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.
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.
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.
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
03/03/2021 • 4 minutes to read • Edit Online
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
conjunto de disponibilidade.
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.
IMPORTANT
Se você planeja executar o Sysprep antes de carregar o VHD no Azure pela primeira vez, verifique se você preparou sua
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.
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:
$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 `
-ResourceGroupName $rgName `
-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 `
-ResourceGroupName $rgName `
-Name "myVM" `
-Image $image.Id `
-Location $location `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-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
03/03/2021 • 10 minutes to read • Edit Online
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.
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.
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.
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 .
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 ).
$vmName = "myVM"
$rgName = "myResourceGroup"
$location = "EastUS"
$imageName = "myImage"
6. Crie a imagem.
2. Obtenha a VM.
$diskID = $vm.StorageProfile.OsDisk.ManagedDisk.Id
5. Crie a imagem.
$rgName = "myResourceGroup"
$location = "EastUS"
$snapshotName = "mySnapshot"
$imageName = "myImage"
2. Crie o instantâneo.
4. Crie a imagem.
$vmName = "myVM"
$rgName = "myResourceGroup"
$location = "EastUS"
$imageName = "myImage"
$osVhdUri = "https://mystorageaccount.blob.core.windows.net/vhdcontainer/vhdfilename.vhd"
2. Pare/desaloque a VM.
Próximas etapas
Criar uma VM de uma imagem gerenciada.
Criar uma VM por meio de uma imagem
gerenciada
03/03/2021 • 4 minutes to read • Edit Online
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.
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.
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 `
-ResourceGroupName "myResourceGroup" `
-Name "myVMfromImage" `
-ImageName "myImage" `
-Location "East US" `
-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
03/03/2021 • 9 minutes to read • Edit Online
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
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.
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.
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
03/03/2021 • 3 minutes to read • Edit Online
Compartilhar a galeria
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 \
--resource-group myGalleryRG \
--gallery-name myGallery \
--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 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
03/03/2021 • 6 minutes to read • Edit Online
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.
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.
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 sua imagem no armazenamento Premium adicionando
--storage-account-type premium_lrs ou armazenando o 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 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
03/03/2021 • 8 minutes to read • Edit Online
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.
Ao trabalhar com este artigo, substitua os nomes de recursos onde necessário.
Você também pode usar um disco gerenciado em vez de um instantâneo. Para obter um disco gerenciado, use
AZ Disk List.
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.
resourceGroup=myGalleryRG
gallery=myGallery
imageDef=myImageDefinition
az sig image-definition create \
--resource-group $resourceGroup \
--gallery-name $gallery \
--gallery-image-definition $imageDef \
--publisher myPublisher \
--offer myOffer \
--sku mySKU \
--os-type Linux \
--os-state specialized
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ê 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 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.
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.
Clonar uma imagem gerenciada para uma versão
de imagem usando o CLI do Azure
03/03/2021 • 6 minutes to read • Edit Online
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.
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 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.
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 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 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"
az sig image-version create \
--resource-group $resourceGroup \
--gallery-name $gallery \
--gallery-image-definition $imageDef \
--gallery-image-version 1.0.0 \
--target-regions "southcentralus=1" "eastus2=1=standard_zrs" \
--replica-count 2 \
--managed-image $imageID
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 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.
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.
Copiar uma imagem de outra galeria usando o CLI
do Azure
03/03/2021 • 6 minutes to read • Edit Online
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.
Ao trabalhar com este artigo, substitua os nomes de recursos onde necessário.
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 .
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 .
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 \
--resource-group myGalleryRG \
--gallery-name myGallery \
--gallery-image-definition myImageDefinition \
--gallery-image-version 1.0.0 \
--query "id" -o tsv
{
"description": null,
"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"
},
"location": "eastus",
"name": "myImageDefinition",
"osState": "Specialized",
"osType": "Linux",
"privacyStatementUri": null,
"provisioningState": "Succeeded",
"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.
az sig image-definition create \
--resource-group myNewGalleryRG \
--gallery-name myNewGallery \
--gallery-image-definition myImageDefinition \
--publisher myPublisher \
--offer myOffer \
--sku mySKU \
--os-type Linux \
--hyper-v-generation V1 \
--os-state specialized
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 sua imagem no armazenamento Premium adicionando
--storage-account-type premium_lrs ou armazenando o 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 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.
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 VM com base em uma versão de
imagem generalizada usando a CLI
03/03/2021 • 2 minutes to read • Edit Online
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.
resourceGroup=myGalleryRG
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.
Substitua os nomes dos recursos conforme necessário no exemplo.
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
03/03/2021 • 2 minutes to read • Edit Online
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.
Substitua os nomes dos recursos conforme necessário no exemplo.
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.
resourceGroup=myGalleryRG
gallery=myGallery
az sig image-definition list \
--resource-group $resourceGroup \
--gallery-name $gallery \
--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.
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.
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 Galeria de Imagens Compartilhadas
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
03/03/2021 • 4 minutes to read • Edit Online
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.
Liste as versões da imagem compartilhada em uma galeria usando az sig image-version list.
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
Data de fim da vida útil
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 \
--gallery-name myGallery \
--resource-group myGalleryRG \
--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.
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 .
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 .
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 delete \
--resource-group myGalleryRG \
--gallery-name myGallery
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.
Compartilhar imagens de VM da galeria em
locatários do Azure usando o CLI do Azure
03/03/2021 • 7 minutes to read • Edit Online
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.
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 .
3. Em atribuir acesso a:, deixe isso como usuário, grupo ou entidade de ser viço do Azure ad .
4. Em selecionar tipo myGalleryApp , em seguida, selecione-o quando aparecer na lista. Quando terminar,
selecione Salvar .
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.
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.
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:
Próximas etapas
Se você tiver algum problema, você poderá solucionar problemas de galerias de imagens compartilhadas.
Compartilhar imagens de VM da galeria em
locatários do Azure usando o PowerShell
03/03/2021 • 7 minutes to read • Edit Online
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.
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 .
3. Em atribuir acesso a:, deixe isso como usuário, grupo ou entidade de ser viço do Azure ad .
4. Em selecionar tipo myGalleryApp , em seguida, selecione-o quando aparecer na lista. Quando terminar,
selecione Salvar .
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.
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.
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.
$resourceGroup = "myResourceGroup"
$location = "South Central US"
$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>"
# Networking pieces
$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 myNic -ResourceGroupName $resourceGroup -Location $location `
-SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id
# Create a virtual machine configuration using the $image variable to specify the shared image
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize Standard_D1_v2 | `
Set-AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred | `
Set-AzVMSourceImage -Id $image | `
Add-AzVMNetworkInterface -Id $nic.Id
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
03/03/2021 • 6 minutes to read • Edit Online
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.
$resourceGroup = New-AzResourceGroup `
-Name 'myGalleryRG' `
-Location 'West Central US'
$gallery = New-AzGallery `
-GalleryName 'myGallery' `
-ResourceGroupName $resourceGroup.ResourceGroupName `
-Location $resourceGroup.Location `
-Description 'Shared Image Gallery for my organization'
Compartilhar a galeria
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, [email protected] neste exemplo, por
suas informações.
Próximas etapas
Crie uma imagem de uma VM, de uma imagem gerenciadaou de uma imagem em outra galeria.
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.
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 Galeria de Imagens Compartilhadas
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
Criar uma imagem de uma VM
03/03/2021 • 8 minutes to read • Edit Online
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.
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 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.
Ao trabalhar com este artigo, substitua os nomes de recursos onde necessário.
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 .
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 `
-ResourceGroupName myResourceGroup
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 `
-ResourceGroupName myResourceGroup
É 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
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 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 `
-GalleryName $gallery.Name `
-ResourceGroupName $gallery.ResourceGroupName `
-Location $gallery.Location `
-Name 'myImageDefinition' `
-OsState specialized `
-OsType Windows `
-Publisher 'myPublisher' `
-Offer 'myOffer' `
-Sku 'mySKU'
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
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 sua imagem no armazenamento Premium adicionando
-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.
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 PowerShell
03/03/2021 • 9 minutes to read • Edit Online
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.
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.
Ao trabalhar com este artigo, substitua os nomes de recursos onde necessário.
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 `
-ResourceGroupName myResourceGroup
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
$source = Get-AzDisk `
-Name myDisk
-ResourceGroupName myResourceGroup
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
Você pode listar todas as galerias e definições de imagem por nome. Os resultados estão no formato
gallery\image definition\image version .
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.
$gallery = Get-AzGallery `
-Name myGallery `
-ResourceGroupName myResourceGroup
$imageDefinition = New-AzGalleryImageDefinition `
-GalleryName $gallery.Name `
-ResourceGroupName $gallery.ResourceGroupName `
-Location $gallery.Location `
-Name 'myImageDefinition' `
-OsState specialized `
-OsType Windows `
-Publisher 'myPublisher' `
-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.
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.
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
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
-StorageAccountType Standard_ZRS ao criar a versão da imagem.
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.
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.
Clonar uma imagem gerenciada para uma imagem
da Galeria de imagens compartilhadas
03/03/2021 • 7 minutes to read • Edit Online
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.
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 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.
Ao trabalhar com este artigo, substitua o grupo de recursos e os nomes de VM quando for necessário.
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 .
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.
$gallery = Get-AzGallery `
-Name myGallery `
-ResourceGroupName myResourceGroup
$imageDefinition = New-AzGalleryImageDefinition `
-GalleryName $gallery.Name `
-ResourceGroupName $gallery.ResourceGroupName `
-Location $gallery.Location `
-Name 'myImageDefinition' `
-OsState generalized `
-OsType Windows `
-Publisher 'myPublisher' `
-Offer 'myOffer' `
-Sku 'mySKU'
$managedImage = Get-AzImage `
-ImageName myImage `
-ResourceGroupName myResourceGroup
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 progresso, digite $job.State .
$job.State
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 sua imagem no armazenamento Premium adicionando
-StorageAccountType Premium_LRS ou armazenando o armazenamento com redundância de zona adicionando
-StorageAccountType Standard_ZRS ao criar a versão da imagem.
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.
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.
Copiar uma imagem de outra galeria usando o
PowerShell
03/03/2021 • 6 minutes to read • Edit Online
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.
Ao trabalhar com este artigo, substitua os nomes de recursos onde necessário.
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 `
-ResourceGroupName myResourceGroup `
-Name 1.0.0
{
"description": null,
"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"
},
"location": "eastus",
"name": "myImageDefinition",
"osState": "Specialized",
"osType": "Windows",
"privacyStatementUri": null,
"provisioningState": "Succeeded",
"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' `
-OsState specialized `
-OsType Windows `
-HyperVGeneration v1 `
-Publisher 'myPublisher' `
-Offer 'myOffer' `
-Sku 'mySKU'
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
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 -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 .
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.
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 VM usando uma imagem generalizada
03/03/2021 • 5 minutes to read • Edit Online
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
located>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition/versions/1.0.0"
.
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.
# 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 `
-GalleryName myGallery `
-ResourceGroupName myResourceGroup `
-Name myImageDefinition
New-AzVM `
-ResourceGroupName $resourceGroup `
-Location $location `
-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.
# 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 `
-GalleryName myGallery `
-ResourceGroupName myResourceGroup `
-Name myImageDefinition
# Network pieces
$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 myNic `
-ResourceGroupName $resourceGroup `
-Location $location `
-SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $pip.Id `
-NetworkSecurityGroupId $nsg.Id
# Create a virtual machine configuration using $imageDefinition.Id to use the latest image version.
$vmConfig = New-AzVMConfig `
-VMName $vmName `
-VMSize Standard_D1_v2 | `
Set-AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred | `
Set-AzVMSourceImage -Id $imageDefinition.Id | `
Set-AzVMSourceImage -Id $imageDefinition.Id | `
Add-AzVMNetworkInterface -Id $nic.Id
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.
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 Galeria de Imagens Compartilhadas
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
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 VM usando uma imagem especializada
03/03/2021 • 4 minutes to read • Edit Online
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
located>/resourceGroups/myGalleryRG/providers/Microsoft.Compute/galleries/myGallery/images/myImageDefinition/versions/1.0.0"
.
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 dos recursos conforme necessário no exemplo.
$resourceGroup = "mySIGSpecializedRG"
$location = "South Central US"
$vmName = "mySpecializedVM"
# 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 `
-GalleryName myGallery `
-ResourceGroupName myResourceGroup `
-Name myImageDefinition
$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 `
-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 Set-AzVMSourceImage -Id $imageDefinition.Id to use the latest
available image version.
$vmConfig = New-AzVMConfig `
-VMName $vmName `
-VMSize Standard_D1_v2 | `
Set-AzVMSourceImage -Id $imageDefinition.Id | `
Add-AzVMNetworkInterface -Id $nic.Id
$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
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.
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 Galeria de Imagens Compartilhadas
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
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.
Listar, atualizar e excluir recursos de imagem
usando o PowerShell
03/03/2021 • 3 minutes to read • Edit Online
Você pode gerenciar seus recursos da Galeria de imagens compartilhadas usando Azure PowerShell.
Listar informações
Liste todas as galerias por nome.
Excluir uma versão de imagem. Este exemplo exclui a versão da imagem chamada 1.0.0.
Remove-AzGalleryImageVersion `
-GalleryImageDefinitionName myImageDefinition `
-GalleryName myGallery `
-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
Data de fim da vida útil
Versão da imagem:
Contagem de réplicas regionais
Regiões de destino
Exclusão da mais recente
Data de fim da vida útil
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 `
-GalleryName $gallery.Name `
-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 `
-GalleryName $gallery.Name `
-Name $galleryVersion.Name `
-ResourceGroupName $resourceGroup.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 `
-GalleryName $gallery.Name `
-Name $galleryVersion.Name `
-ResourceGroupName $resourceGroup.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.
$resourceGroup = "myResourceGroup"
$gallery = "myGallery"
$imageDefinition = "myImageDefinition"
$imageVersion = "myImageVersion"
Remove-AzGalleryImageVersion `
-GalleryImageDefinitionName $imageDefinition `
-GalleryName $gallery `
-Name $imageVersion `
-ResourceGroupName $resourceGroup
Remove-AzGalleryImageDefinition `
-ResourceGroupName $resourceGroup `
-GalleryName $gallery `
-GalleryImageDefinitionName $imageDefinition
Remove-AzGallery `
-Name $gallery `
-ResourceGroupName $resourceGroup
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.
Compartilhar imagens de VM da galeria em
locatários do Azure usando o PowerShell
03/03/2021 • 7 minutes to read • Edit Online
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.
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 .
3. Em atribuir acesso a:, deixe isso como usuário, grupo ou entidade de ser viço do Azure ad .
4. Em selecionar tipo myGalleryApp , em seguida, selecione-o quando aparecer na lista. Quando terminar,
selecione Salvar .
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.
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.
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.
$resourceGroup = "myResourceGroup"
$location = "South Central US"
$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>"
# Networking pieces
$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 myNic -ResourceGroupName $resourceGroup -Location $location `
-SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id
# Create a virtual machine configuration using the $image variable to specify the shared image
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize Standard_D1_v2 | `
Set-AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred | `
Set-AzVMSourceImage -Id $image | `
Add-AzVMNetworkInterface -Id $nic.Id
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
03/03/2021 • 19 minutes to read • Edit Online
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.
Compartilhar a galeria
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.
6. Em função , selecione leitor .
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
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.
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
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 Galeria de Imagens Compartilhadas
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
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 galeria de imagens compartilhadas do
Azure usando o portal
03/03/2021 • 19 minutes to read • Edit Online
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.
Ao trabalhar com este artigo, substitua o grupo de recursos e os nomes de VM quando for 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.
O exemplo a seguir cria uma galeria chamada myGallery no grupo de recursos myGalleryRG.
1. Entre no Portal do Azure em https://portal.azure.com.
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 .
10. Depois que a implantação for concluída, selecione Ir para o recurso .
Compartilhar a galeria
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.
6. Em função , selecione leitor .
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
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.
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
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 Galeria de Imagens Compartilhadas
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
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.
Solucionar problemas de galerias de imagens
compartilhadas no Azure
03/03/2021 • 46 minutes to read • Edit Online
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.
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.
Próximas etapas
Saiba mais sobre galerias de imagens compartilhadas.
Visualização: Use chaves gerenciadas pelo cliente
para criptografar imagens
03/03/2021 • 12 minutes to read • Edit Online
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:
Demora alguns minutos para que o registro seja concluído. Use Get-AzProviderFeature para verificar o status
do registro do recurso:
Quando RegistrationState retorna Registered , você pode passar para a próxima etapa.
Verifique o registro do seu provedor. Verifique se ele volta como Registered .
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}
$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}
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
Quando esse código retornar "state": "Registered" , você poderá passar para a próxima etapa.
Verifique seu registro:
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.
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.
az sig image-version create \
-g MyResourceGroup \
--gallery-image-version 1.0.0 \
--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.
Próximas etapas
Saiba mais sobre Criptografia de disco do lado do servidor.
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 um disco gerenciado com base em uma
versão de imagem
03/03/2021 • 4 minutes to read • Edit Online
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 .
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>"
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>"
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 `
-GalleryImageDefinitionName myImageDefinition `
-GalleryName myGallery `
-ResourceGroupName myResourceGroup `
-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.
$diskConfig = New-AzDiskConfig `
-Location EastUS `
-CreateOption FromImage `
-GalleryImageReference @{Id = $sourceImgVer.Id}
Crie o disco.
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.
$diskConfig = New-AzDiskConfig `
-Location EastUS `
-CreateOption FromImage `
-GalleryImageReference @{Id = $sourceImgVer.Id; Lun=0}
Crie o disco.
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.
$vm = Get-azvm `
-ResourceGroupName myResourceGroup `
-Name myVM
$vm.Plan
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 .
$gallery = Get-AzGallery `
-Name myGallery `
-ResourceGroupName myGalleryRG
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.
# Create some variables for the new VM.
$resourceGroup = "mySIGPubVM"
$location = "West Central US"
$vmName = "mySIGPubVM"
# 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.
$vmConfig = New-AzVMConfig `
-VMName $vmName `
-VMSize Standard_D1_v2 | `
Set-AzVMSourceImage -Id $imageDefinition.Id | `
Set-AzVMPlan `
-Publisher $imageDefinition.PurchasePlan.Publisher `
-Product $imageDefinition.PurchasePlan.Product `
-Name $imageDefinition.PurchasePlan.Name | `
Add-AzVMNetworkInterface -Id $nic.Id
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.
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.
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
03/03/2021 • 9 minutes to read • Edit Online
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
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.
Registrar os recursos
Para usar o Construtor de Imagens do Azure durante a versão prévia, você precisa registrar o novo recurso.
Criar uma variável para a ID da assinatura. Obtenha isso usando az account show -o json | grep id .
subscriptionID=<Subscription ID>
# get identity id
imgBuilderCliId=$(az identity show -g $sigResourceGroup -n $identityName -o json | grep "clientId" | cut -
c16- | tr -d '",')
# 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
az sig create \
-g $sigResourceGroup \
--gallery-name $sigName
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
az resource create \
--resource-group $sigResourceGroup \
--properties @helloImageTemplateforSIG.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateforSIG01
az resource invoke-action \
--resource-group $sigResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-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 \
--resource-group $sigResourceGroup \
--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
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 \
--resource-group $sigResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateforSIG01
Obtenha a versão da imagem criada pelo Construtor de Imagens, que sempre começa com 0. , e exclua a
versão da imagem
Exclua a galeria.
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
03/03/2021 • 10 minutes to read • Edit Online
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
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.
Registrar os recursos
Para usar o Construtor de Imagens do Azure durante a versão prévia, você precisa registrar o novo recurso.
Definir variáveis
Usaremos algumas informações repetidamente, portanto, criaremos algumas variáveis para armazená-las.
Criar uma variável para a ID da assinatura. Obtenha isso usando az account show | grep id .
# get identity id
imgBuilderCliId=$(az identity show -g $imageResourceGroup -n $idenityName | grep "clientId" | cut -c16- | tr
-d '",')
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/quickquickstarts/0_Creating_a_Cust
om_Windows_Managed_Image/helloImageTemplateWin.json -o 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
az resource create \
--resource-group $imageResourceGroup \
--properties @helloImageTemplateWin.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateWin01
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.
az resource delete \
--resource-group $imageResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateLinux01
az resource invoke-action \
--resource-group $imageResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-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 \
--resource-group $imageResourceGroup \
--name aibImgWinVm00 \
--admin-username aibuser \
--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
az resource delete \
--resource-group $imageResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateWin01
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
03/03/2021 • 14 minutes to read • Edit Online
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ê não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
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.
OPÇ ÃO EXEM P LO / L IN K
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 .
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.
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
# Azure region
$location = 'WestUS2'
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.
$myRoleImageCreationUrl =
'https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solutions/12_Creating_AIB_Securit
y_Roles/aibRoleImageCreation.json'
$myRoleImageCreationPath = "$env:TEMP\myRoleImageCreation.json"
$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.
$myGalleryName = 'myImageGallery'
$imageDefName = 'winSvrImages'
$SrcObjParams = @{
SourceTypePlatformImage = $true
Publisher = 'MicrosoftWindowsServer'
Offer = 'WindowsServer'
Sku = '2019-Datacenter'
Version = 'latest'
}
$srcPlatform = New-AzImageBuilderSourceObject @SrcObjParams
$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
$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
$ImgTemplateParams = @{
ImageTemplateName = $imageTemplateName
ResourceGroupName = $imageResourceGroup
Source = $srcPlatform
Distribute = $disSharedImg
Customize = $Customizer01, $Customizer02
Location = $location
UserAssignedIdentityId = $identityNameResourceId
}
New-AzImageBuilderTemplate @ImgTemplateParams
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.
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).
$Cred = Get-Credential
Verificar as personalizações
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 o PowerShell e execute Get-Content conforme mostrado no exemplo a
seguir:
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
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
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.
Próximas etapas
Para saber mais sobre os componentes do arquivo. JSON usado neste artigo, consulte referência de modelo do
Image Builder.
Controles de conformidade regulatória do Azure
Policy para o Construtor de Imagens do Azure
03/03/2021 • 3 minutes to read • Edit Online
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.
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)
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
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.
Pré-requisitos
Use o ambiente Bash no Azure Cloud Shell.
Registrar os recursos
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.
# your subscription
# get the current subID : 'az account show | grep id'
subscriptionID=$(az account show | grep id | tr -d '",' | cut -c7-)
# 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.
# Create VNET
# 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.
Para obter mais informações sobre a rede do Image Builder, consulte Opções de rede do serviço do Azure Image
Builder.
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
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solutions/12_Creating_AIB_Security
_Roles/aibRoleNetworking.json -o aibRoleNetworking.json
curl
https://raw.githubusercontent.com/danielsollondon/azvmimagebuilder/master/solutions/12_Creating_AIB_Security
_Roles/aibRoleImageCreation.json -o aibRoleImageCreation.json
# get identity id
imgBuilderCliId=$(az identity show -g $imageResourceGroup -n $idenityName | grep "clientId" | cut -c16- | tr
-d '",')
# make role name unique, to avoid clashes in the same Azure Active Directory domain
imageRoleDefName="Azure Image Builder Image Def"$(date +'%s')
netRoleDefName="Azure Image Builder Network Def"$(date +'%s')
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.
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
Envie a configuração de imagem para o serviço Construtor de Imagens do Azure.
az resource create \
--resource-group $imageResourceGroup \
--properties @existingVNETLinux.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n existingVNETLinuxTemplate01
az resource invoke-action \
--resource-group $imageResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n existingVNETLinuxTemplate01 \
--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 \
--resource-group $imageResourceGroup \
--name aibImgVm0001 \
--admin-username aibuser \
--image $imageName \
--location $location \
--generate-ssh-keys
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
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.
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 \
--resource-group $imageResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n existingVNETLinuxTemplate01
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
Saiba mais sobre as Galerias de Imagens Compartilhadas do no Azure.
Usar o construtor de imagens do Azure para VMs
do Windows permitindo o acesso a uma VNET do
Azure existente
03/03/2021 • 11 minutes to read • Edit Online
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
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.
OPÇ ÃO EXEM P LO / L IN K
# 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.
Configurar a rede
Se você não tiver um VNET\Subnet\NSG existente, use o script a seguir para criar um.
## NOTE! The VNET must always be in the same region as the Azure Image Builder service region.
$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.
$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
# create identity
New-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name $idenityName
# create role definitions from role configurations examples, this avoids granting contributor to the SPN
New-AzRoleDefinition -InputFile ./aibRoleImageCreation.json
New-AzRoleDefinition -InputFile ./aibRoleNetworking.json
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
Envie a configuração de imagem para o serviço Construtor de Imagens do Azure.
# note this will take minute, as validation is run (security / dependencies etc.)
$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)
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": ""
},
$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)
## remove definitions
Remove-AzRoleDefinition -Id $imageRoleDefObjId -Force
Remove-AzRoleDefinition -Id $networkRoleObjId -Force
## delete identity
Remove-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name $idenityName -Force
Próximas etapas
Saiba mais sobre as Galerias de Imagens Compartilhadas do no Azure.
Opções de rede do serviço do Azure Image Builder
03/03/2021 • 8 minutes to read • Edit Online
Você precisa optar por implantar o construtor de imagens do Azure com ou sem uma VNET existente.
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": ""
},
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
Exemplo de CLI do AZ
Exemplo de PowerShell
3. Permitir que o construtor de imagens do Azure crie um ALB e adicione VMs à VNET
Exemplo de CLI do AZ
Exemplo de PowerShell
4. Permitir que o construtor de imagens do Azure Leia/grave imagens de origem e crie imagens
Exemplo de CLI do AZ
Exemplo de PowerShell
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
03/03/2021 • 13 minutes to read • Edit Online
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
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.
Pré-requisitos
Use o ambiente Bash no Azure Cloud Shell.
Registrar os recursos
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.
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.
identityName="aibIdentity"
imageResourceGroup=<Resource group>
az identity create \
--resource-group $imageResourceGroup \
--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.
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
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/images/read
Microsoft.Compute/galleries/images/versions/read
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/join/action
# Create a unique role name to avoid clashes in the same Azure Active Directory domain
imageRoleDefName="Azure Image Builder Image Def"$(date +'%s')
# Grant the custom role to the user-assigned managed identity for Azure Image Builder.
az role assignment create \
--assignee $imgBuilderCliId \
--role $imageRoleDefName \
--scope /subscriptions/$subscriptionID/resourceGroups/$imageResourceGroup
# Grant the custom role to the user-assigned managed identity for Azure Image Builder.
az role assignment create \
--assignee $imgBuilderCliId \
--role $netRoleDefName \
--scope /subscriptions/$subscriptionID/resourceGroups/$VnetResourceGroup
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.
No modelo do Image Builder, você precisa fornecer a identidade gerenciada atribuída pelo usuário.
"type": "Microsoft.VirtualMachineImages/imageTemplates",
"apiVersion": "2019-05-01-preview",
"location": "<Region>",
..
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"<Image Builder ID>": {}
}
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
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 o PowerShell
03/03/2021 • 12 minutes to read • Edit Online
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
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.
OPÇ ÃO EXEM P LO / L IN K
Registrar os recursos
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.
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.
$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.
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
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/read
Microsoft.Compute/galleries/images/read
Microsoft.Compute/galleries/images/versions/read
Microsoft.Network/virtualNetworks/read
Microsoft.Network/virtualNetworks/subnets/join/action
# Create a unique role name to avoid clashes in the same Azure Active Directory domain
$timeInt=$(get-date -UFormat "%s")
$imageRoleDefName="Azure Image Builder Image Def"+$timeInt
# Grant the custom role to the user-assigned managed identity for Azure Image Builder.
$parameters = @{
ObjectId = $identityNamePrincipalId
RoleDefinitionName = $imageRoleDefName
Scope = '/subscriptions/' + $sub_id + '/resourceGroups/' + $imageResourceGroup
}
New-AzRoleAssignment @parameters
# Create a unique role name to avoid clashes in the same AAD domain
$timeInt=$(get-date -UFormat "%s")
$networkRoleDefName="Azure Image Builder Network Def"+$timeInt
# Assign the custom role to the user-assigned managed identity for Azure Image Builder
$parameters = @{
ObjectId = $identityNamePrincipalId
RoleDefinitionName = $networkRoleDefName
Scope = '/subscriptions/' + $sub_id + '/resourceGroups/' + $res_group
}
New-AzRoleAssignment @parameters
Próximas etapas
Para obter mais informações, consulte visão geral do construtor de imagens do Azure.
Tarefa DevOps do serviço do construtor de imagem
do Azure
03/03/2021 • 19 minutes to read • Edit Online
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.
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
$timeInt=$(get-date -UFormat "%s")
$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')
# create storage account and blob in resource group
az storage account create -n $scriptStorageAcc -g $strResourceGroup -l $location --sku Standard_LRS
/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.
& '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:
Se você estiver ok usando o diretório "/tmp", poderá usar o código abaixo para executar o script.
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.
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"
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.
Quando o Build da imagem é iniciado, o status de execução é relatado nos logs de liberação:
Quando a compilação da imagem for concluída, você verá uma saída semelhante ao seguinte texto:
Perguntas frequentes
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:
...
Source for image: { type: 'SharedImageVersion',
imageVersionId:
'/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.Compute/galleries/<galleryName>
/images/<imageDefName>/versions/<imgVersionNumber>' }
...
template name: t_1556938436xxx
...
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
Para obter mais informações, consulte visão geral do construtor de imagens do Azure.
Visualização: Criar um modelo do Construtor de
Imagens do Azure
03/03/2021 • 37 minutes to read • Edit Online
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:
{
"type": "Microsoft.VirtualMachineImages/imageTemplates",
"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": {}
}
}
"type": "Microsoft.VirtualMachineImages/imageTemplates",
"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
"location": "<region>",
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": [],
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": {
"type": "UserAssigned",
"userAssignedIdentities": {
"<imgBuilderId>": {}
}
},
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",
"publisher": "Canonical",
"offer": "UbuntuServer",
"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:
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>",
]
}
],
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>",
"sha256Checksum": "<sha256 checksum>"
},
],
"customize": [
{
"type": "Shell",
"name": "<name>",
"inline": "<commands to run>"
},
],
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
{
"type": "WindowsRestart",
"restartCommand": "shutdown /r /f /t 0",
"restartCheckCommand": "echo Azure-Image-Builder-Restarted-the-VM >
c:\\buildArtifacts\\azureImageBuilderRestart.txt",
"restartTimeout": "5m"
}
],
"customize": [
{
"type": "PowerShell",
"name": "<name>",
"scriptUri": "<path to script>",
"runElevated": "<true false>",
"sha256Checksum": "<sha256 checksum>"
},
{
"type": "PowerShell",
"name": "<name>",
"inline": "<PowerShell syntax to run>",
"validExitCodes": "<exit code>",
"runElevated": "<true or false>"
}
],
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.
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.
"customize": [
{
"type": "WindowsUpdate",
"searchCriteria": "IsInstalled=0",
"filters": [
"exclude:$_.Title -like '*Preview*'",
"include:$true"
],
"updateLimit": 20
}
],
OS support: Windows
Personalizar propriedades:
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
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",
"provisioningState": "Succeeded"
},
"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>",
"location": "<region>",
"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>"
]
}
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>"
}
}
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.
az resource invoke-action \
--resource-group $imageResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateLinux01 \
--action Run
az resource invoke-action \
--resource-group $imageResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-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
03/03/2021 • 9 minutes to read • Edit Online
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
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.
Registrar os recursos
Para usar o Construtor de Imagens do Azure durante a versão prévia, você precisa registrar o novo recurso.
Criar uma variável para a ID da assinatura. Obtenha isso usando az account show | grep id .
subscriptionID=<Subscription ID>
# get identity id
imgBuilderCliId=$(az identity show -g $sigResourceGroup -n $idenityName | grep "clientId" | cut -c16- | tr -
d '",')
# 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
az sig create \
-g $sigResourceGroup \
--gallery-name $sigName
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
az resource create \
--resource-group $sigResourceGroup \
--properties @helloImageTemplateforSIG.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateforSIG01
az resource invoke-action \
--resource-group $sigResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-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 \
--resource-group $sigResourceGroup \
--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
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 \
--resource-group $sigResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateforSIG01
Obtenha a versão da imagem criada pelo Construtor de Imagens, que sempre começa com 0. , e exclua a
versão da imagem
Exclua a galeria.
Próximas etapas
Saiba mais sobre as Galerias de Imagens Compartilhadas do no Azure.
Visualização: Criar uma imagem do Windows e
distribuí-la para uma Galeria de Imagens
Compartilhadas
03/03/2021 • 11 minutes to read • Edit Online
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.
Para distribuir a imagem a uma Galeria de Imagens Compartilhadas, o modelo usa sharedImage como o valor
da seção distribute do modelo.
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
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.
Registrar os recursos
Para usar o Construtor de Imagens do Azure durante a versão prévia, você precisa registrar o novo recurso.
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
ResourceTypes,RegistrationState
Get-AzResourceProvider -ProviderNamespace Microsoft.Storage | Format-table -Property
ResourceTypes,RegistrationState
Get-AzResourceProvider -ProviderNamespace Microsoft.Compute | Format-table -Property
ResourceTypes,RegistrationState
Get-AzResourceProvider -ProviderNamespace Microsoft.KeyVault | Format-table -Property
ResourceTypes,RegistrationState
Criar variáveis
Usaremos algumas informações repetidamente, portanto, criaremos algumas variáveis para armazená-las.
Substitua os valores das variáveis, como username e vmpassword , por suas informações.
# Location
$location="westus"
# Create a resource group for Image Template and Shared Image Gallery
New-AzResourceGroup `
-Name $imageResourceGroup `
-Location $location
# create identity
New-AzUserAssignedIdentity -ResourceGroupName $imageResourceGroup -Name $identityName
$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
### 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
$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
Invoke-AzResourceAction `
-ResourceName $imageTemplateName `
-ResourceGroupName $imageResourceGroup `
-ResourceType Microsoft.VirtualMachineImages/imageTemplates `
-ApiVersion "2019-05-01-preview" `
-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.
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
Crie uma VM com base na versão da imagem criada pelo Construtor de Imagens do Azure.
Obtenha a versão da imagem que você criou.
$imageVersion = Get-AzGalleryImageVersion `
-ResourceGroupName $imageResourceGroup `
-GalleryName $sigGalleryName `
-GalleryImageDefinitionName $imageDefName
# Network pieces
$subnetConfig = New-AzVirtualNetworkSubnetConfig -Name mySubnet -AddressPrefix 192.168.1.0/24
$vnet = New-AzVirtualNetwork -ResourceGroupName $vmResourceGroup -Location $replRegion2 `
-Name MYvNET -AddressPrefix 192.168.0.0/16 -Subnet $subnetConfig
$pip = New-AzPublicIpAddress -ResourceGroupName $vmResourceGroup -Location $replRegion2 `
-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 $vmResourceGroup -Location $replRegion2 `
-Name myNetworkSecurityGroup -SecurityRules $nsgRuleRDP
$nic = New-AzNetworkInterface -Name myNic -ResourceGroupName $vmResourceGroup -Location $replRegion2 `
-SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id -NetworkSecurityGroupId $nsg.Id
# Create a virtual machine configuration using $imageVersion.Id to specify the shared image
$vmConfig = New-AzVMConfig -VMName $vmName -VMSize Standard_D1_v2 | `
Set-AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred | `
Set-AzVMSourceImage -Id $imageVersion.Id | `
Add-AzVMNetworkInterface -Id $nic.Id
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 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.
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.
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.
remover definições
excluir identidade
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
03/03/2021 • 5 minutes to read • Edit Online
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.
Usaremos um modelo .json de exemplo para configurar a imagem. O arquivo. JSON que estamos usando está
aqui: helloImageTemplateforSIGfromSIG.jsem.
Registrar os recursos
Para usar o Construtor de Imagens do Azure durante a versão prévia, você precisa registrar o novo recurso.
Criar uma variável para a ID da assinatura. Obtenha isso usando az account show | grep id .
subscriptionID=<Subscription ID>
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 .
Criar a imagem
Envie a configuração de imagem para o serviço do construtor de imagem de VM.
az resource create \
--resource-group $sigResourceGroup \
--properties @helloImageTemplateforSIGfromSIG.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateforSIGfromSIG01
az resource invoke-action \
--resource-group $sigResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-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 \
--resource-group $sigResourceGroup \
--name aibImgVm001 \
--admin-username azureuser \
--location $location \
--image
"/subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup/providers/Microsoft.Compute/galleries/$sigN
ame/images/$imageDefName/versions/latest" \
--generate-ssh-keys
ssh azureuser@<pubIp>
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 :-) **
*******************************************************
Próximas etapas
Para saber mais sobre os componentes do arquivo. JSON usado neste artigo, consulte referência de modelo do
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
03/03/2021 • 6 minutes to read • Edit Online
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.
Usaremos um modelo .json de exemplo para configurar a imagem. O arquivo. JSON que estamos usando está
aqui: helloImageTemplateforSIGfromWinSIG.jsem.
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.
Registrar os recursos
Para usar o Construtor de Imagens do Azure durante a versão prévia, você precisa registrar o novo recurso.
Criar uma variável para a ID da assinatura. Obtenha isso usando az account show | grep id .
subscriptionID=<Subscription ID>
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 .
Criar a imagem
Envie a configuração de imagem para o serviço do construtor de imagem de VM.
az resource create \
--resource-group $sigResourceGroup \
--properties @helloImageTemplateforSIGfromWinSIG.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n imageTemplateforSIGfromWinSIG01
az resource invoke-action \
--resource-group $sigResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-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 \
--resource-group $sigResourceGroup \
--name aibImgWinVm002 \
--admin-username $username \
--admin-password $vmpassword \
--image
"/subscriptions/$subscriptionID/resourceGroups/$sigResourceGroup/providers/Microsoft.Compute/galleries/$sigN
ame/images/$imageDefName/versions/latest" \
--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:\
Próximas etapas
Para saber mais sobre os componentes do arquivo. JSON usado neste artigo, consulte referência de modelo do
Image Builder.
Criar uma imagem e usar uma identidade
gerenciada atribuída pelo usuário para acessar
arquivos no armazenamento do Azure
03/03/2021 • 8 minutes to read • Edit Online
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
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.
Registrar os recursos
Para usar o Construtor de Imagens do Azure durante a versão prévia, você precisa registrar o novo recurso.
Criar uma variável para a ID da assinatura. Obtenha isso usando az account show | grep id .
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.
# create user assigned identity for image builder to access the storage account where the script is located
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 '",')
# script container
scriptStorageAccContainer=scriptscont$(date +'%s')
# script url
scriptUrl=https://$scriptStorageAcc.blob.core.windows.net/$scriptStorageAccContainer/customizeScript.sh
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.
az role assignment create \
--assignee $imgBuilderCliId \
--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
Envie a configuração de imagem para o serviço Construtor de Imagens do Azure.
az resource create \
--resource-group $imageResourceGroup \
--properties @helloImageTemplateMsi.json \
--is-full-object \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateMsi01
az resource invoke-action \
--resource-group $imageResourceGroup \
--resource-type Microsoft.VirtualMachineImages/imageTemplates \
-n helloImageTemplateMsi01 \
--action Run
az vm create \
--resource-group $imageResourceGroup \
--name aibImgVm00 \
--admin-username aibuser \
--image $imageName \
--location $location \
--generate-ssh-keys
Depois que a VM tiver sido criada, inicie uma sessão SSH com a VM.
ssh aibuser@<publicIp>
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
Quando tiver terminado, você poderá excluir os recursos se eles não forem mais necessários.
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
03/03/2021 • 34 minutes to read • Edit Online
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
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
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
imagem do Azure usando o PowerShell
Erro ao obter imagem gerenciada
Erro
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.
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
imagem do Azure usando o PowerShell
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.
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:
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=""
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.
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).
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=""
"provisioningState": "Succeeded",
"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
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
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
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
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
"provisioningState": "Succeeded",
"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.
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
imagem do Azure usando o PowerShell
Tempo de Sysprep
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
Source for image: { type: 'SharedImageVersion',
imageVersionId:
'/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.Compute/galleries/<galleryName>
/images/<imageDefName>/versions/<imgVersionNumber>' }
template name: t_1556938436xxx
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
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:
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.
c:\DeprovisioningScript.ps1
Linux:
/tmp/DeprovisioningScript.sh
Próximas etapas
Para obter mais informações, consulte visão geral do construtor de imagens do Azure.
Como usar o Packer para criar imagens de máquina
virtual Linux no Azure
03/03/2021 • 10 minutes to read • Edit Online
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.
az ad sp create-for-rbac --query "{ client_id: appId, client_secret: password, tenant_id: tenant }"
{
"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:
PA RÂ M ET RO O N DE O BT ER
"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"
},
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.
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.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image myPackerImage \
--admin-username azureuser \
--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.
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 \
--resource-group myResourceGroup \
--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
03/11/2020 • 10 minutes to read • Edit Online
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.
$rgName = "myPackerGroup"
$location = "East US"
New-AzResourceGroup -Name $rgName -Location $location
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
PA RÂ M ET RO O N DE O BT ER
"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.
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.
New-AzVm `
-ResourceGroupName $rgName `
-Name "myVM" `
-Location $location `
-VirtualNetworkName "myVnet" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-PublicIpAddressName "myPublicIpAddress" `
-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.
Get-AzPublicIPAddress `
-ResourceGroupName $rgName `
-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?
03/03/2021 • 9 minutes to read • Edit Online
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.
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
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.
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
03/03/2021 • 9 minutes to read • Edit Online
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
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 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
03/03/2021 • 7 minutes to read • Edit Online
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
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.
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
#run as root or preface with sudo
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
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:
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:
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:
wget https://aka.ms/lis
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
03/03/2021 • 6 minutes to read • Edit Online
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"
}
[
"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.
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.
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?
03/03/2021 • 9 minutes to read • Edit Online
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.
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
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.
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
03/03/2021 • 19 minutes to read • Edit Online
Aprenda como configurar e gerenciar várias máquinas virtuais para garantir a alta disponibilidade do aplicativo
Linux no Azure.
Saiba mais sobre como implantar uma VM do Windows ou do Linux em uma Zona de Disponibilidade.
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.
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
Próximas etapas
Para saber mais sobre o balanceamento de carga das máquinas virtuais, veja Balanceamento de carga de
máquinas virtuais.
Tutorial: Criar e implantar máquinas virtuais
altamente disponíveis com a CLI do Azure
03/11/2020 • 8 minutes to read • Edit Online
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 um conjunto de disponibilidade
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
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.
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.
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.
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 \
--resource-group myResourceGroupAvailability \
--name myAvailabilitySet \
--output table
Próximas etapas
Neste tutorial, você aprendeu a:
Criar um conjunto de disponibilidade
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
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 e implantar máquinas virtuais
altamente disponíveis com o Azure PowerShell
03/03/2021 • 8 minutes to read • Edit Online
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.
Neste tutorial, você aprenderá como:
Criar um conjunto de disponibilidade
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
Verificar o Assistente do Azure
New-AzResourceGroup `
-Name myResourceGroupAvailability `
-Location EastUS
Crie um conjunto de disponibilidade gerenciado usando New-AzAvailabilitySet com o parâmetro -sku aligned .
New-AzAvailabilitySet `
-Location "EastUS" `
-Name "myAvailabilitySet" `
-ResourceGroupName "myResourceGroupAvailability" `
-Sku aligned `
-PlatformFaultDomainCount 2 `
-PlatformUpdateDomainCount 2
$cred = Get-Credential
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.
Conferir os tamanhos de VM disponíveis
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 `
-ResourceGroupName "myResourceGroupAvailability" `
-AvailabilitySetName "myAvailabilitySet"
Próximas etapas
Neste tutorial, você aprendeu a:
Criar um conjunto de disponibilidade
Criar uma VM em um conjunto de disponibilidade
Verificar os tamanhos de VM disponíveis
Verificar o Assistente do Azure
Avance para o próximo tutorial para saber mais sobre conjuntos de disponibilidade de máquinas virtuais.
Criar um conjunto de dimensionamento da VM
Alterar a conjunto de disponibilidade para uma VM
03/03/2021 • 2 minutes to read • Edit Online
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.
# Set variables
$resourceGroup = "myResourceGroup"
$vmName = "myVM"
$newAvailSetName = "myAvailabilitySet"
# 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
# Recreate the VM
New-AzVM `
-ResourceGroupName $resourceGroup `
-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
03/03/2021 • 2 minutes to read • Edit Online
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.
az vm create \
-n myVM \
-g myPPGGroup \
--image UbuntuLTS \
--ppg myPPG \
--generate-ssh-keys \
--size Standard_D1_v2 \
-l westus
Conjuntos de Disponibilidade
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.
Conjuntos de dimensionamento
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
03/03/2021 • 5 minutes to read • Edit Online
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.
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.
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.
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
03/03/2021 • 5 minutes to read • Edit Online
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.
$resourceGroup = "myPPGResourceGroup"
$location = "East US"
$ppgName = "myPPG"
New-AzResourceGroup -Name $resourceGroup -Location $location
$ppg = New-AzProximityPlacementGroup `
-Location $location `
-Name $ppgName `
-ResourceGroupName $resourceGroup `
-ProximityPlacementGroupType Standard
Get-AzProximityPlacementGroup
$vmName = "myVM"
New-AzVm `
-ResourceGroupName $resourceGroup `
-Name $vmName `
-Location $location `
-OpenPorts 3389 `
-ProximityPlacementGroup $ppg.Id
Conjuntos de Disponibilidade
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
$resourceGroup = "myResourceGroup"
$avSetName = "myAvailabilitySet"
$avSet = Get-AzAvailabilitySet -ResourceGroupName $resourceGroup -Name $avSetName
$vmIds = $avSet.VirtualMachinesReferences
foreach ($vmId in $vmIDs){
$string = $vmID.Id.Split("/")
$vmName = $string[8]
Stop-AzVM -ResourceGroupName $resourceGroup -Name $vmName -Force
}
$avSet.ProximityPlacementGroup = ""
Update-AzAvailabilitySet -AvailabilitySet $avSet
foreach ($vmId in $vmIDs){
$string = $vmID.Id.Split("/")
$vmName = $string[8]
Start-AzVM -ResourceGroupName $resourceGroup -Name $vmName
}
Conjuntos de dimensionamento
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
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
disponibilidade com a CLI do Azure
03/03/2021 • 7 minutes to read • Edit Online
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.
A saída é semelhante ao exemplo condensado a seguir, que mostra as Zonas de Disponibilidade nas quais cada
tamanho de VM está disponível:
O grupo de recursos é especificado ao criar ou modificar uma VM, que pode ser visto durante este tutorial.
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": "",
"id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myResourceGroupVM/providers/Microsoft.Compute/virtualMachines/myVM",
"location": "eastus2",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "10.0.0.4",
"publicIpAddress": "52.174.34.95",
"resourceGroup": "myResourceGroupVM",
"zones": "1"
}
A saída mostra que o disco gerenciado está na mesma região da disponibilidade da VM:
{
"creationData": {
"createOption": "FromImage",
"imageReference": {
"id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
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,
"id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myResourceGroupVM/providers/Microsoft.Compute/disks/osdisk_761c570dab",
"location": "eastus2",
"managedBy": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-
xxxxxxxxxxxx/resourceGroups/myResourceGroupVM/providers/Microsoft.Compute/virtualMachines/myVM",
"name": "myVM_osdisk_761c570dab",
"osType": "Linux",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroupVM",
"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.
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
03/03/2021 • 24 minutes to read • Edit Online
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.
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.
Criptografia no servidor
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.
Azure Disk Encryption
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.
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?
03/03/2021 • 31 minutes to read • Edit Online
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.
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
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
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
* 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
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
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
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
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
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
03/03/2021 • 19 minutes to read • Edit Online
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.
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
Atualmente limitado a suporte a Azure Resource Manager ou SDK.
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.
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.
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).
Disponibilidade regional
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.
P15, P20 2
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.
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.
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
03/03/2021 • 12 minutes to read • Edit Online
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:
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
Atualmente limitado a suporte a Azure Resource Manager ou SDK.
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.
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.
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).
Disponibilidade regional
O SSDs Premium compartilhado está disponível em todas as regiões em que os discos gerenciados estão
disponíveis.
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.
P15, P20 2
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.
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
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
Ex e m p l o d e d i sc o r e g i o n a l
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.
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.
$resourceGroup = "myResourceGroup"
$location = "WestCentralUS"
$vm = Add-AzVMDataDisk -VM $vm -Name "mySharedDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 0
PR_REGISTER_KEY
PR_REGISTER_AND_IGNORE
PR_GET_CONFIGURATION
PR_RESERVE
PR_PREEMPT_RESERVATION
PR_CLEAR_RESERVATION
PR_RELEASE_RESERVATION
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
03/03/2021 • 20 minutes to read • Edit Online
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.
Propósito geral Dv3, Dav4, Dv2, Av2 B, DSv2, Dsv3, DC, DCv2, Dasv4
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
03/03/2021 • 11 minutes to read • Edit Online
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
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 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 chaves HSM exigem a camada Premium de cofres de chaves do Azure.
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.
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.
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.
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.
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 .
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.
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.
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
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 aos 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.
Próximas etapas
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?
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
03/03/2021 • 13 minutes to read • Edit Online
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 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
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 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.
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.
$ResourceGroupName="yourResourceGroupName"
$LocationName="westcentralus"
$keyVaultName="yourKeyVaultName"
$keyName="yourKeyName"
$keyDestination="Software"
$diskEncryptionSetName="yourDiskEncryptionSetName"
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.
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.
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"
Crie um disco vazio criptografado usando a criptografia do lado do servidor com chaves gerenciadas pelo
cliente e anexe -o a uma VM
Copie o script, substitua todos os valores de exemplo pelos seus próprios parâmetros e, em seguida, execute-o.
$vmName = "yourVMName"
$LocationName = "westcentralus"
$ResourceGroupName = "yourResourceGroupName"
$diskName = "yourDiskName"
$diskSKU = "Premium_LRS"
$diskSizeinGiB = 30
$diskLUN = 1
$diskEncryptionSetName="yourDiskEncryptionSetName"
$vm = Add-AzVMDataDisk -VM $vm -Name $diskName -CreateOption Empty -DiskSizeInGB $diskSizeinGiB -
StorageAccountType $diskSKU -Lun $diskLUN -DiskEncryptionSetId $diskEncryptionSet.Id
$rgName = "yourResourceGroupName"
$diskName = "yourDiskName"
$diskEncryptionSetName = "yourDiskEncryptionSetName"
$NetworkName = "yourVNETName"
$SubnetName = "yourSubnetName"
$SubnetAddressPrefix = "10.0.0.0/24"
$VnetAddressPrefix = "10.0.0.0/16"
# Enable encryption at rest with customer managed keys for OS disk by setting DiskEncryptionSetId property
# Add a data disk encrypted at rest with customer managed keys by setting DiskEncryptionSetId property
Mude a chave de um DiskEncryptionSet para alternar a chave de todos os recursos que fazem referência ao
DiskEncryptionSet
Copie o script, substitua todos os valores de exemplo pelos seus próprios parâmetros e, em seguida, execute-o.
$ResourceGroupName="yourResourceGroupName"
$keyVaultName="yourKeyVaultName"
$keyName="yourKeyName"
$diskEncryptionSetName="yourDiskEncryptionSetName"
$ResourceGroupName="yourResourceGroupName"
$DiskName="yourDiskName"
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 aos 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.
Próximas etapas
Conheça os modelos do Azure Resource Manager para criar discos criptografados com chaves gerenciadas
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
Usar o CLI do Azure para habilitar a criptografia do
lado do servidor com chaves gerenciadas pelo
cliente para discos gerenciados
03/03/2021 • 9 minutes to read • Edit Online
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.
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 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.
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.
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
keyVaultKeyUrl=$(az keyvault key show --vault-name $keyVaultName --name $keyName --query [key.kid] -o
tsv)
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.
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
rgName=yourResourceGroupName
vmName=yourVMName
location=westcentralus
vmSize=Standard_DS3_V2
image=UbuntuLTS
diskEncryptionSetName=yourDiskencryptionSetName
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
rgName=yourResourceGroupName
diskName=yourDiskName
diskEncryptionSetName=yourDiskEncryptionSetName
rgName=yourResourceGroupName
vmssName=yourVMSSName
location=westcentralus
vmSize=Standard_DS3_V2
image=UbuntuLTS
diskEncryptionSetName=yourDiskencryptionSetName
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
rgName=yourResourceGroupName
diskName=yourDiskName
diskSkuName=Premium_LRS
diskSizeinGiB=30
location=westcentralus
diskLUN=2
diskEncryptionSetName=yourDiskEncryptionSetName
Mude a chave de um DiskEncryptionSet para alternar a chave de todos os recursos que fazem referência ao
DiskEncryptionSet
rgName=yourResourceGroupName
keyVaultName=yourKeyVaultName
keyName=yourKeyName
diskEncryptionSetName=yourDiskEncryptionSetName
keyVaultKeyUrl=$(az keyvault key show --vault-name $keyVaultName --name $keyName --query [key.kid] -o tsv)
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 aos 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.
Próximas etapas
Conheça os modelos do Azure Resource Manager para criar discos criptografados com chaves gerenciadas
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
Use o portal do Azure para habilitar a criptografia
de ponta a ponta usando a criptografia no host
03/03/2021 • 9 minutes to read • Edit Online
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
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.
Regiões com suporte
Atualmente disponível somente nas seguintes regiões:
Oeste dos EUA
Oeste dos EUA 2
Leste dos EUA
Leste dos EUA 2
Centro-Sul dos Estados Unidos
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:
Propósito geral Dv3, Dav4, Dv2, Av2 B, DSv2, Dsv3, DC, DCv2, Dasv4
TYPE SEM SUP O RT E C O M SUP O RT E
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 [email protected]
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.
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.
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 .
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.
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.
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
03/03/2021 • 13 minutes to read • Edit Online
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 criptografia em
criptografia de host de ponta a ponta para os dados da VM.
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.
Regiões com suporte
Atualmente disponível somente nas seguintes regiões:
Oeste dos EUA
Oeste dos EUA 2
Leste dos EUA
Leste dos EUA 2
Centro-Sul dos Estados Unidos
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:
Propósito geral Dv3, Dav4, Dv2, Av2 B, DSv2, Dsv3, DC, DCv2, Dasv4
TYPE SEM SUP O RT E C O M SUP O RT E
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 [email protected]
com suas IDs de assinatura para obter o recurso habilitado para suas assinaturas.
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
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"
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.
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.
$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"
# Enable encryption with a customer managed key for OS disk by setting DiskEncryptionSetId property
# Add a data disk encrypted with a customer managed key by setting DiskEncryptionSetId property
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.
$VMLocalAdminUser = "yourVMLocalAdminUserName"
$VMLocalAdminSecurePassword = ConvertTo-SecureString <password> -AsPlainText -Force
$LocationName = "yourRegion"
$ResourceGroupName = "yourResourceGroupName"
$ComputerName = "yourComputerName"
$VMName = "yourVMName"
$VMSize = "yourVMSize"
$NetworkName = "yourNetworkName"
$NICName = "yourNICName"
$SubnetName = "yourSubnetName"
$SubnetAddressPrefix = "10.0.0.0/24"
$VnetAddressPrefix = "10.0.0.0/16"
$ResourceGroupName = "yourResourceGroupName"
$VMName = "yourVMName"
$ResourceGroupName = "yourResourceGroupName"
$VMName = "yourVMName"
$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.
$VMLocalAdminUser = "yourLocalAdminUser"
$VMLocalAdminSecurePassword = ConvertTo-SecureString Password@123 -AsPlainText -Force
$LocationName = "westcentralus"
$ResourceGroupName = "yourResourceGroupName"
$ComputerNamePrefix = "yourComputerNamePrefix"
$VMScaleSetName = "yourVMSSName"
$VMSize = "Standard_DS3_v2"
$diskEncryptionSetName="yourDiskEncryptionSetName"
$NetworkName = "yourVNETName"
$SubnetName = "yourSubnetName"
$SubnetAddressPrefix = "10.0.0.0/24"
$VnetAddressPrefix = "10.0.0.0/16"
# Enable encryption with a customer managed key for the OS disk by setting DiskEncryptionSetId property
# Add a data disk encrypted with a customer managed key by setting DiskEncryptionSetId property
Crie um conjunto de dimensionamento de máquinas virtuais com criptografia no host habilitado com chaves
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.
$VMLocalAdminUser = "yourLocalAdminUser"
$VMLocalAdminSecurePassword = ConvertTo-SecureString Password@123 -AsPlainText -Force
$LocationName = "westcentralus"
$ResourceGroupName = "yourResourceGroupName"
$ComputerNamePrefix = "yourComputerNamePrefix"
$VMScaleSetName = "yourVMSSName"
$VMSize = "Standard_DS3_v2"
$NetworkName = "yourVNETName"
$SubnetName = "yourSubnetName"
$SubnetAddressPrefix = "10.0.0.0/24"
$VnetAddressPrefix = "10.0.0.0/16"
$ResourceGroupName = "yourResourceGroupName"
$VMScaleSetName = "yourVMSSName"
$ResourceGroupName = "yourResourceGroupName"
$VMScaleSetName = "yourVMSSName"
$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"
}
]
}
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.
Exemplos de modelo do Azure Resource Manager
Use o CLI do Azure para habilitar a criptografia de
ponta a ponta usando a criptografia no host
03/03/2021 • 10 minutes to read • Edit Online
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 criptografia em
criptografia de host de ponta a ponta para os dados da VM.
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.
Regiões com suporte
Atualmente disponível somente nas seguintes regiões:
Oeste dos EUA
Oeste dos EUA 2
Leste dos EUA
Leste dos EUA 2
Centro-Sul dos Estados Unidos
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:
Propósito geral Dv3, Dav4, Dv2, Av2 B, DSv2, Dsv3, DC, DCv2, Dasv4
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 [email protected]
com suas IDs de assinatura para obter o recurso habilitado para suas assinaturas.
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.
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.
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
keyVaultKeyUrl=$(az keyvault key show --vault-name $keyVaultName --name $keyName --query [key.kid] -o
tsv)
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.
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
diskEncryptionSetName=yourDiskEncryptionSetName
az vm create -g $rgName \
-n $vmName \
-l $location \
--encryption-at-host \
--image $image \
--size $vmSize \
--generate-ssh-keys \
--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 \
--encryption-at-host \
--image $image \
--size $vmSize \
--generate-ssh-keys \
--data-disk-sizes-gb 128 128 \
rgName=yourRGName
vmName=yourVMName
az vm update -n $vmName \
-g $rgName \
--set securityProfile.encryptionAtHost=true
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 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.
rgName=yourRGName
vmssName=yourVMSSName
location=westus2
vmSize=Standard_DS3_V2
image=UbuntuLTS
diskEncryptionSetName=yourDiskEncryptionSetName
Crie um conjunto de dimensionamento de máquinas virtuais com criptografia no host habilitado com chaves
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
vmssName=yourVMSSName
location=westus2
vmSize=Standard_DS3_V2
image=UbuntuLTS
rgName=yourRGName
vmssName=yourVMName
{
"resourceType": "virtualMachines",
"name": "Standard_DS1_v2",
"tier": "Standard",
"size": "DS1_v2",
"family": "standardDSv2Family",
"locations": [
"CentralUSEUAP"
],
"capabilities": [
{
"name": "EncryptionAtHostSupported",
"value": "True"
}
]
}
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.
Exemplos de modelo do Azure Resource Manager
Usar o portal do Azure para habilitar a criptografia
dupla em repouso para discos gerenciados
03/03/2021 • 3 minutes to read • Edit Online
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
1. Entre no portal do Azure.
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.
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
gerenciadas 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.
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.
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.
Pré-requisitos
Instale a versão mais recente do Azure PowerShelle entre em uma conta do Azure usando Connect-AzAccount.
Introdução
1. 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="westus2"
$keyVaultName="yourKeyVaultName"
$keyName="yourKeyName"
$keyDestination="Software"
$diskEncryptionSetName="yourDiskEncryptionSetName"
Próximas etapas
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.
Azure PowerShell-habilitar chaves gerenciadas pelo cliente com discos gerenciados por criptografia do lado
do servidor
Exemplos de modelo do Azure Resource Manager
Usar o CLI do Azure para habilitar a criptografia
dupla em repouso para discos gerenciados
03/03/2021 • 3 minutes to read • Edit Online
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.
Pré-requisitos
Instale o CLI do Azure mais recente e faça logon em uma conta do Azure com AZ login.
Introdução
1. 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.
subscriptionId=yourSubscriptionID
rgName=yourResourceGroupName
location=westcentralus
keyVaultName=yourKeyVaultName
keyName=yourKeyName
diskEncryptionSetName=yourDiskEncryptionSetName
diskName=yourDiskName
Próximas etapas
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 de modelo do Azure Resource Manager
Habilitar chaves gerenciadas pelo cliente com criptografia do lado do servidor-exemplos
Cenários do Azure Disk Encryption em VMs Linux
03/03/2021 • 35 minutes to read • Edit Online
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
Requisitos de armazenamento de chave de criptografia
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
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. 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.
az login
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>"
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:
Get-command *diskencryption*
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.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MySecureVM';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$sequenceVersion = [Guid]::NewGuid();
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.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MyExtraSecureVM';
$KeyVaultName = 'MySecureVault';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
$sequenceVersion = [Guid]::NewGuid();
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
cmdlet Get-AzVmDiskEncryptionStatus.
PA RÂ M ET RO DESC RIÇ Ã O
Para obter mais informações sobre como configurar o modelo de criptografia de disco de VM Linux, confira
Azure Disk Encryption para Linux.
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:
4. Monte os discos:
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"
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.
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.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MySecureVM';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$sequenceVersion = [Guid]::NewGuid();
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.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MyExtraSecureVM';
$KeyVaultName = 'MySecureVault';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
$sequenceVersion = [Guid]::NewGuid();
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-
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]
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.
Desabilitar a criptografia com a CLI do Azure: para desabilitar a criptografia, use o comando az vm
encryption disable.
Próximas etapas
Visão geral do Azure Disk Encryption
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
03/03/2021 • 25 minutes to read • Edit Online
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
Requisitos de armazenamento de chave de criptografia
IMPORTANT
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. 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.
az login
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>"
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:
Get-command *diskencryption*
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MyExtraSecureVM';
$KeyVaultName = 'MySecureVault';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
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]
Verifique se os discos estão criptografados: Para verificar o status de criptografia de uma VM IaaS,
use o cmdlet Get-AzVmDiskEncryptionStatus .
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]
Verifique se os discos estão criptografados: Para verificar o status de criptografia de uma VM IaaS,
use o comando AZ VM Encryption show .
PA RÂ M ET RO DESC RIÇ Ã O
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.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MyExtraSecureVM';
$KeyVaultName = 'MySecureVault';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
$sequenceVersion = [Guid]::NewGuid();
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]
Desabilitar criptografia
É possível desabilitar a criptografia usando o Azure PowerShell, a CLI do Azure ou com um modelo do Resource
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.
Desabilitar a criptografia com a CLI do Azure: para desabilitar a criptografia, use o comando az vm
encryption disable.
Próximas etapas
Visão geral do Azure Disk Encryption
Azure Disk Encryption scripts de exemplo
Guia de solução de problemas do Azure Disk Encryption
Início Rápido: criar e criptografar uma VM do Linux
com a CLI do Azure
03/03/2021 • 4 minutes to read • Edit Online
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 criar e criptografar uma VM (máquina virtual) do Linux.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
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
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.
az vm create \
--resource-group "myResourceGroup" \
--name "myVM" \
--image "Canonical:UbuntuServer:16.04-LTS:latest" \
--size "Standard_D2S_V3"\
--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": "52.174.34.95",
"resourceGroup": "myResourceGroup"
}
IMPORTANT
Cada cofre de chaves deve ter um nome exclusivo no Azure. Nos exemplos a seguir, substitua pelo nome que você
escolher.
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.
"EncryptionOperation": "EnableEncryption"
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 o Key Vault.
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.
Visão geral do Azure Disk Encryption
Início Rápido: Criar e criptografar uma VM do
Windows com a CLI do Azure
03/03/2021 • 5 minutes to read • Edit Online
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 criar e criptografar uma VM (máquina virtual) do Windows Server
2016.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Pré-requisitos
Use o ambiente Bash no Azure Cloud Shell.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image win2016datacenter \
--admin-username azureuser \
--admin-password myPassword12
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": "52.174.34.95",
"resourceGroup": "myResourceGroup"
}
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.
Você pode verificar que a criptografia está habilitada na sua VM com show az vm
"EncryptionOperation": "EnableEncryption"
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 o Key Vault.
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 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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
$cred = Get-Credential
IMPORTANT
Cada cofre de chaves deve ter um nome exclusivo no Azure. Nos exemplos a seguir, substitua pelo nome que você
escolher.
OsVolumeEncrypted : EncryptionInProgress
DataVolumesEncrypted : NotMounted
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : OS disk encryption started
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:
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.
Visão geral do Azure Disk Encryption
Início Rápido: Criar e criptografar uma máquina
virtual do Windows no Azure com o PowerShell
03/11/2020 • 3 minutes to read • Edit Online
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 criar uma
máquina virtual (VM) do Windows, criar um Key Vault para o armazenamento de chaves de criptografia e
criptografar a VM.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
$cred = Get-Credential
New-AzVM -Name MyVm -Credential $cred -ResourceGroupName MyResourceGroup -Image win2016datacenter -Size
Standard_D2S_V3
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.
OsVolumeEncrypted : Encrypted
DataVolumesEncrypted : NoDiskFound
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : Provisioning succeeded
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:
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 os pré-requisitos do Azure Disk
Encryption para VMs IaaS.
Visão geral do Azure Disk Encryption
Início Rápido: Criar e criptografar uma máquina
virtual com o portal do Azure
03/03/2021 • 5 minutes to read • Edit Online
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 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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Entrar no Azure
Entre no portal do Azure.
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".
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 .
Levará alguns minutos para que sua VM seja implantada. Quando a implantação for concluída, vá para a
próxima seção.
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
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 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.
Visão geral do Azure Disk Encryption
Início Rápido: Criar e criptografar uma máquina
virtual do Windows com o portal do Azure
03/03/2021 • 5 minutes to read • Edit Online
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 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.
Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.
Entrar no Azure
Entre no portal do Azure.
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"
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
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 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.
Visão geral do Azure Disk Encryption
Criar e configurar um cofre de chaves para Azure
Disk Encryption
03/03/2021 • 13 minutes to read • Edit Online
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
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. 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.
az login
Connect-AzAccount
Azure PowerShell
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".
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.
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.
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.
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.
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 .
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.
Azure PowerShell
Use o cmdlet Add-AzKeyVaultKey do Azure PowerShell para gerar uma nova KEK e armazená-la no cofre de
chaves.
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.
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
03/03/2021 • 14 minutes to read • Edit Online
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
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. 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.
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.
az login
Connect-AzAccount
Azure PowerShell
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".
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.
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.
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.
Set-AzKeyVaultAccessPolicy -VaultName "<your-unique-keyvault-name>" -ResourceGroupName
"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.
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 .
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.
Azure PowerShell
Use o cmdlet Add-AzKeyVaultKey do Azure PowerShell para gerar uma nova KEK e armazená-la no cofre de
chaves.
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.
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.
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.
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.
OsVolumeEncrypted : VMRestartPending
DataVolumesEncrypted : NotMounted
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : OS disk successfully encrypted, reboot the VM
OsVolumeEncrypted : EncryptionInProgress
DataVolumesEncrypted : NotMounted
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : OS disk encryption started
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] .
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
chmod +x /usr/local/sbin/azure_crypt_key.sh
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:
# 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
DRACUT_SYSTEMD=0
if [ -z "$DRACUT_SYSTEMD" ]; then
para:
if [ 1 ]; then
MountPoint=/tmp-keydisk-mount
KeyFileName=LinuxPassPhraseFileName
echo "Trying to get the key from disks ..." >&2
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
if [ -f $MountPoint/$KeyFileName ]; then
echo "> keyfile got..." >&2
cp $MountPoint/$KeyFileName /tmp-keyfile >&2
luksfile=/tmp-keyfile
umount $MountPoint >&2
break
fi
done
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:
# 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
DRACUT_SYSTEMD=0
para
if [ 1 ]; then
MountPoint=/tmp-keydisk-mount
KeyFileName=LinuxPassPhraseFileName
echo "Trying to get the key from disks ..." >&2
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
if [ -f $MountPoint/$KeyFileName ]; then
echo "> keyfile got..." >&2
cp $MountPoint/$KeyFileName /tmp-keyfile >&2
luksfile=/tmp-keyfile
umount $MountPoint >&2
break
fi
done
$AadClientId = "My-AAD-Client-Id"
$AadClientSecret = "My-AAD-Client-Secret"
# This is the passphrase that was provided for encryption during the distribution installation
$passphrase = "contoso-password"
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.
# This is the passphrase that was provided for encryption during the distribution installation
$passphrase = "contoso-password"
$apiversion = "2015-06-01"
##############################
# Get Auth URI
##############################
$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
##############################
# Get Auth Token
##############################
$response = Invoke-RestMethod -Method POST -Uri $uri -Headers $headers -Body $body
$access_token = $response.access_token
##############################
# Get KEK info
##############################
$keyid = $response.key.kid
##############################
# 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
$response = Invoke-RestMethod -Method POST -Uri $uri -Headers $headers -Body $body
$wrappedSecret = $response.value
##############################
# Store secret
##############################
$secretName = [guid]::NewGuid().ToString()
$uri = $KeyVault.VaultUri + "/secrets/" + $secretName + "?api-version=" + $apiversion
$secretAttributes = @{"enabled" = $true}
$secretTags = @{"DiskEncryptionKeyEncryptionAlgorithm" = "RSA-OAEP"; "DiskEncryptionKeyFileName" =
"LinuxPassPhraseFileName"}
$headers = @{"Authorization" = "Bearer " + $access_token; "Content-Type" = "application/json"}
$bodyObj = @{"value" = $wrappedSecret; "attributes" = $secretAttributes; "tags" = $secretTags}
$body = $bodyObj | ConvertTo-Json
$response = Invoke-RestMethod -Method PUT -Uri $uri -Headers $headers -Body $body
$secretUrl = $response.id
Use $KeyEncryptionKey e $secretUrl na próxima etapa para anexar o disco do sistema operacional usando KEK.
Set-AzVMOSDisk `
-VM $VirtualMachine `
-Name $OSDiskName `
-SourceImageUri $VhdUri `
-VhdUri $OSDiskUri `
-Linux `
-CreateOption FromImage `
-DiskEncryptionKeyVaultId $KeyVault.ResourceId `
-DiskEncryptionKeyUrl $SecretUrl
Set-AzVMOSDisk `
-VM $VirtualMachine `
-Name $OSDiskName `
-SourceImageUri $CopiedTemplateBlobUri `
-VhdUri $OSDiskUri `
-Linux `
-CreateOption FromImage `
-DiskEncryptionKeyVaultId $KeyVault.ResourceId `
-DiskEncryptionKeyUrl $SecretUrl `
-KeyEncryptionKeyVaultId $KeyVault.ResourceId `
-KeyEncryptionKeyURL $KeyEncryptionKey.Id
Azure Disk Encryption scripts de exemplo
03/03/2021 • 13 minutes to read • Edit Online
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.
Para compactar a partição do SO e preparar o computador para BitLocker, execute o bdehdcfg, se necessário:
NOTE
Prepare a VM com um VHD de dados/recursos separado para obter a chave externa usando o BitLocker.
# In cloud shell, the account ID is a managed service identity, so specify the username directly
# $upn = "[email protected]"
# 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
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.
# This is the passphrase that was provided for encryption during the distribution installation
$passphrase = "contoso-password"
$apiversion = "2015-06-01"
##############################
# Get Auth URI
##############################
$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
##############################
# Get Auth Token
##############################
$response = Invoke-RestMethod -Method POST -Uri $uri -Headers $headers -Body $body
$access_token = $response.access_token
##############################
# Get KEK info
##############################
##############################
$keyid = $response.key.kid
##############################
# 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
$response = Invoke-RestMethod -Method POST -Uri $uri -Headers $headers -Body $body
$wrappedSecret = $response.value
##############################
# Store secret
##############################
$secretName = [guid]::NewGuid().ToString()
$uri = $KeyVault.VaultUri + "/secrets/" + $secretName + "?api-version=" + $apiversion
$secretAttributes = @{"enabled" = $true}
$secretTags = @{"DiskEncryptionKeyEncryptionAlgorithm" = "RSA-OAEP"; "DiskEncryptionKeyFileName" =
"LinuxPassPhraseFileName"}
$headers = @{"Authorization" = "Bearer " + $access_token; "Content-Type" = "application/json"}
$bodyObj = @{"value" = $wrappedSecret; "attributes" = $secretAttributes; "tags" = $secretTags}
$body = $bodyObj | ConvertTo-Json
$response = Invoke-RestMethod -Method PUT -Uri $uri -Headers $headers -Body $body
$secretUrl = $response.id
Use $KeyEncryptionKey e $secretUrl na próxima etapa para anexar o disco do sistema operacional usando KEK.
Set-AzVMOSDisk `
-VM $VirtualMachine `
-Name $OSDiskName `
-SourceImageUri $CopiedTemplateBlobUri `
-VhdUri $OSDiskUri `
-Windows `
-CreateOption FromImage `
-DiskEncryptionKeyVaultId $KeyVault.ResourceId `
-DiskEncryptionKeyUrl $SecretUrl `
-KeyEncryptionKeyVaultId $KeyVault.ResourceId `
-KeyEncryptionKeyURL $KeyEncryptionKey.Id
Azure Disk Encryption em uma rede isolada
03/11/2020 • 4 minutes to read • Edit Online
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.
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
03/03/2021 • 12 minutes to read • Edit Online
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
sistema operacional.
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"
Use os seguintes comandos para capturar as configurações de criptografia para discos de dados:
$RGNAME = "RGNAME"
$VMNAME = "VMNAME"
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"
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:
RGNAME="RGNAME"
VMNAME="VNAME"
Discos de dados:
RGNAME="RGNAME"
VMNAME="VMNAME"
az vm encryption show --name ${VMNAME} --resource-group ${RGNAME} --query "substatus"
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
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 ${TARGETDISKNAME} --query
encryptionSettingsCollection.encryptionSettings[].diskEncryptionKey.secretUrl -o tsv; \
echo -ne "key Encryption Key: "; az disk show -g ${RGNAME} -n ${TARGETDISKNAME} --query
encryptionSettingsCollection.encryptionSettings[].keyEncryptionKey.keyUrl -o tsv; \
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:
Esse comando obtém a cadeia de conexão para uma conta de armazenamento específica e a armazena em uma
variável:
Escolha o disco que você deseja consultar e armazene o nome dele em uma variável:
DiskName="diskname.vhd"
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:
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.
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
CLI do Azure:
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
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
lsblk
cat /etc/fstab
$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:
Portal:
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.
E remova as entradas/etc/fstab:
vi /etc/fstab
lsblk
E verifique se os discos estão configurados:
cat /etc/fstab
NOTE
Os nomes de/dev/mapper/Device aqui precisam ser substituídos para seus valores reais com base na saída de lsblk .
vgdisplay -v vgdata
pvs
lvdisplay
lvdisplay vgdata/lvdata1
lvdisplay vgdata/lvdata2
Criar sistemas de arquivos sobre as estruturas para volumes lógicos
mkdir /data0
mkdir /data1
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
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
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
lsblk
df -h
Próximas etapas
Redimensionar dispositivos de gerenciamento de volume lógico criptografados com Azure Disk Encryption
Guia de solução de problemas do Azure Disk Encryption
Como redimensionar dispositivos de gerenciamento
de volume lógico que usam Azure Disk Encryption
03/03/2021 • 20 minutes to read • Edit Online
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
vgs
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
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
df -h /mountpoint
pvs
vgs
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.
ls -l /dev/disk/azure/scsi1/
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 .
pvs
vgs
12. Use lsblk para identificar o LV que precisa ser redimensionado:
lsblk
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.
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.
umount /mountpoint
3. Exclua o LV:
lvremove /dev/vgname/lvname
lsblk -fs
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 .
df -h /datalvm*
IMPORTANT
Não é possível redimensionar discos virtuais enquanto a VM está em execução. Desaloque sua VM para esta
etapa.
lsblk -o "NAME,SIZE"
pvdisplay /dev/resizeddisk
pvresize /dev/resizeddisk
pvdisplay /dev/resizeddisk
Aplique o mesmo procedimento para todos os discos que você deseja redimensionar.
11. Verifique as informações de VG.
vgdisplay vgname
df -h /datalvm2
vgdisplay vgname
2. Verifique o tamanho do sistema de arquivos e o LV que você deseja expandir:
lvdisplay /dev/vgname/lvname
df -h mountpoint
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}
mount -a
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.
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
umount ${newmount}
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
vgdisplay vgname
lvdisplay /dev/vgname/lvname
df -h mountpoint
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
lsblk
lsblk -s
pvs
vgs
4. Verifique suas informações de LV:
lvs
df -h /mountpoint(s)
fdisk
fdisk -l | egrep ^"Disk /"
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.
fdisk
fdisk -l | egrep ^"Disk /"
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
pvdisplay /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
lvdisplay vgname/lvname
df -h /mountpoint
Próximas etapas
Solucionar problemas Azure Disk Encryption
Redimensionar um disco do sistema operacional
com partição GPT
03/03/2021 • 19 minutes to read • Edit Online
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.
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.
Se sua VM (máquina virtual) tiver uma partição GPT no disco do sistema operacional, aumente o tamanho 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.
2. Aumente o tamanho do disco do sistema operacional no portal.
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:
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
# growpart /dev/sda 4
CHANGED: partition=4 start=3151872 old: size=59762655 end=62914527 new: size=97511391 end=100663263
linux:~ # 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 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
#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
Filesystem Type Size Used Avail Use% Mounted on
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
tmpfs tmpfs 92M 0 92M 0% /run/user/1000
tmpfs tmpfs 92M 0 92M 0% /run/user/490
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:
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.
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.
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]
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.
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.
11. Verifique se o novo tamanho de VP é o tamanho esperado, comparando-o aos valores originais
[tamanho/livre] :
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.
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
Saída de exemplo:
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.
2. Aumente o tamanho do disco do sistema operacional no portal.
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.
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 '
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
reboot
19. Execute o comando xfs_growfs na partição para redimensioná-lo
xfs_growfs /dev/sda2
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 adicionais para VMs
Requisitos de rede
Requisitos de armazenamento de chave de criptografia
Depois de reiniciar a VM para o novo kernel, a nova versão do kernel pode ser confirmada usando:
uname -a
OsVolumeEncrypted : EncryptionInProgress
DataVolumesEncrypted : EncryptionInProgress
OsVolumeEncryptionSettings :
ProgressMessage : Transitioning
OsVolumeEncrypted : EncryptionInProgress
DataVolumesEncrypted : EncryptionInProgress
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : Encryption succeeded for data volumes
OsVolumeEncrypted : EncryptionInProgress
DataVolumesEncrypted : EncryptionInProgress
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : Provisioning succeeded
OsVolumeEncrypted : EncryptionInProgress
DataVolumesEncrypted : EncryptionInProgress
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
ProgressMessage : OS disk encryption started
OsVolumeEncrypted : Encrypted
DataVolumesEncrypted : NotMounted
OsVolumeEncryptionSettings : Microsoft.Azure.Management.Compute.Models.DiskEncryptionSettings
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.
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
Criptografia de dados em repouso do Azure
Guia de solução de problemas do Azure Disk
Encryption
03/11/2020 • 6 minutes to read • Edit Online
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
Requisitos de armazenamento de chave de criptografia
\windows\system32\bdehdcfg.exe
\windows\system32\bdehdcfglib.dll
\windows\system32\en-US\bdehdcfglib.dll.mui
\windows\system32\en-US\bdehdcfg.exe.mui
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:
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
Criptografia de dados em repouso do Azure
Perguntas frequentes do Azure Disk Encryption
para máquinas virtuais
03/03/2021 • 20 minutes to read • Edit Online
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.
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.
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".
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.
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:
Visão geral do Azure Disk Encryption
Aplicar a criptografia de disco na Central de Segurança do Azure
Criptografia de dados em repouso do Azure
Perguntas frequentes sobre Azure Disk Encryption
para máquinas virtuais do Windows
03/03/2021 • 16 minutes to read • Edit Online
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.
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.
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.
* 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.
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:
Visão geral do Azure Disk Encryption
Aplicar a criptografia de disco na Central de Segurança do Azure
Criptografia de dados em repouso do Azure
Azure Disk Encryption com Azure Active Directory
(AD) (versão anterior)
03/11/2020 • 5 minutes to read • Edit Online
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:
Sistemas operacionais e VMs com suporte
Requisitos adicionais da VM
[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]
"SystemDefaultTlsVersions"=dword:00000001
"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.
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)
Script da CLI dos pré-requisitos do Azure Disk Encryption
Script do PowerShell dos pré-requisitos do Azure Disk Encryption
Azure Disk Encryption com o Azure AD (versão
anterior)
03/11/2020 • 5 minutes to read • Edit Online
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.
[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]
"SystemDefaultTlsVersions"=dword:00000001
"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.
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 Windows (versão anterior)
Script da CLI dos pré-requisitos do Azure Disk Encryption
Script do PowerShell dos pré-requisitos do Azure Disk Encryption
Criando e configurando um cofre de chaves para
Azure Disk Encryption com o Azure AD (versão
anterior) para VMs do Linux
03/11/2020 • 26 minutes to read • Edit Online
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 . 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.
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.
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.
Caso queira, também é possível gerar ou importar uma KEK (chave de criptografia de chave).
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
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.
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'
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.
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 do grupo de recursos, o nome do Key Vault, a ID do
objeto, os termos legais e o contrato e clique em comprar .
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 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
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.
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.
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
.
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 .
# 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';
$KVRGname = 'MyKeyVaultResourceGroup';
$KeyVaultName = 'MySecureVault';
New-AzResourceGroup –Name $KVRGname –Location $Loc;
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc;
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$KeyVaultResourceId = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).ResourceId;
$diskEncryptionKeyVaultUrl = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).VaultUri;
$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.
#Step 4: Create a new key in the key vault with the Add-AzKeyVaultKey cmdlet.
# Fill in 'MyKeyEncryptionKey' with your value.
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName -Destination 'Software';
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;
$VMName = 'MySecureVM';
$VMRGName = 'MyVirtualMachineResourceGroup';
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $vmName -AadClientID $aadClientID -
AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -
DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl $keyEncryptionKeyUrl -
KeyEncryptionKeyVaultId $KeyVaultResourceId;
$KVRGname = 'MyKeyVaultResourceGroup'
$KeyVaultName= 'MySecureVault'
$Loc = 'MyLocation'
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDiskEncryption
# 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())
$AADClientID = $AzureAdApplication.ApplicationId
$aadClientCertThumbprint= $cert.Thumbprint
$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
$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
IMPORTANT
No momento, não há suporte para a autenticação baseada em certificado do Azure AD em VMs do Linux.
$KVRGname = 'MyKeyVaultResourceGroup'
$KeyVaultName= 'MySecureVault'
$Loc = 'MyLocation'
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDiskEncryption
# 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())
$AADClientID = $AzureAdApplication.ApplicationId
$aadClientCertThumbprint= $cert.Thumbprint
$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 deployment
#Setting some variables with the key vault information and generating a KEK
# FIll in 'KEKName'
$KEKName ='KEKName'
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname
$DiskEncryptionKeyVaultUrl = $KeyVault.VaultUri
$KeyVaultResourceId = $KeyVault.ResourceId
$KEK = Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $KEKName -Destination "Software"
$KeyEncryptionKeyUrl = $KEK.Key.kid
$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
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
Azure Disk Encryption com o Azure AD (versão
anterior)
03/03/2021 • 26 minutes to read • Edit Online
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 . 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.
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.
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.
Caso queira, também é possível gerar ou importar uma KEK (chave de criptografia de chave).
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
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.
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'
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.
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 do grupo de recursos, o nome do Key Vault, a ID do
objeto, os termos legais e o contrato e clique em comprar .
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 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
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.
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.
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 .
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 .
# 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';
$KVRGname = 'MyKeyVaultResourceGroup';
$KeyVaultName = 'MySecureVault';
New-AzResourceGroup –Name $KVRGname –Location $Loc;
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc;
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$KeyVaultResourceId = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).ResourceId;
$diskEncryptionKeyVaultUrl = (Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName
$KVRGname).VaultUri;
$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.
#Step 4: Create a new key in the key vault with the Add-AzKeyVaultKey cmdlet.
# Fill in 'MyKeyEncryptionKey' with your value.
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName -Destination 'Software';
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;
$VMName = 'MySecureVM';
$VMRGName = 'MyVirtualMachineResourceGroup';
Set-AzVMDiskEncryptionExtension -ResourceGroupName $VMRGName -VMName $vmName -AadClientID $aadClientID -
AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl -
DiskEncryptionKeyVaultId $KeyVaultResourceId -KeyEncryptionKeyUrl $keyEncryptionKeyUrl -
KeyEncryptionKeyVaultId $KeyVaultResourceId;
$KVRGname = 'MyKeyVaultResourceGroup'
$KeyVaultName= 'MySecureVault'
$Loc = 'MyLocation'
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDiskEncryption
# 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())
$AADClientID = $AzureAdApplication.ApplicationId
$aadClientCertThumbprint= $cert.Thumbprint
$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
#Enable encryption on the VM using Azure AD client ID and the client certificate thumbprint
$KVRGname = 'MyKeyVaultResourceGroup'
$KeyVaultName= 'MySecureVault'
$Loc = 'MyLocation'
New-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname -Location $Loc
Set-AzKeyVaultAccessPolicy -VaultName $KeyVaultName -ResourceGroupName $KVRGname -EnabledForDiskEncryption
# 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())
$AADClientID = $AzureAdApplication.ApplicationId
$aadClientCertThumbprint= $cert.Thumbprint
$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 deployment
#Setting some variables with the key vault information and generating a KEK
# FIll in 'KEKName'
$KEKName ='KEKName'
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname
$DiskEncryptionKeyVaultUrl = $KeyVault.VaultUri
$KeyVaultResourceId = $KeyVault.ResourceId
$KEK = Add-AzKeyVaultKey -VaultName $KeyVaultName -Name $KEKName -Destination "Software"
$KeyEncryptionKeyUrl = $KEK.Key.kid
$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
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)
03/11/2020 • 33 minutes to read • Edit Online
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:
Requisitos adicionais para VMs
Rede e Política de Grupo
Requisitos de armazenamento de chave de criptografia
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.
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].
Verifique se os discos estão criptografados: Para verificar o status de criptografia de uma VM IaaS,
use o comando AZ VM Encryption show .
$VMRGName = 'MyVirtualMachineResourceGroup';
$KVRGname = 'MyKeyVaultResourceGroup';
$vmName = 'MySecureVM';
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$sequenceVersion = [Guid]::NewGuid();
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.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
$sequenceVersion = [Guid]::NewGuid();
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-
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].
Verifique se os discos estão criptografados: Para verificar o status de criptografia de uma VM IaaS,
use o cmdlet Get-AzVmDiskEncryptionStatus .
PA RÂ M ET RO DESC RIÇ Ã O
PA RÂ M ET RO DESC RIÇ Ã O
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.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
2. Monte os discos.
3. Adicione ao fstab.
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.
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
É possível habilitar a criptografia de disco no VHD criptografado usando o cmdlet do PowerShell Set-
AzVMOSDisk. O exemplo a seguir fornece alguns parâmetros comuns.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MySecureVM';
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$sequenceVersion = [Guid]::NewGuid();
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.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MyExtraSecureVM';
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
$sequenceVersion = [Guid]::NewGuid();
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].
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 .
Desabilitar a criptografia com a CLI do Azure: para desabilitar a criptografia, use o comando az vm
encryption disable.
Próximas etapas
Visão geral do Azure Disk Encryption para Linux
Criando e configurando um cofre de chaves para Azure Disk Encryption com o Azure AD (versão anterior)
Azure Disk Encryption com o Azure AD para VMs
do Windows (versão anterior)
03/11/2020 • 24 minutes to read • Edit Online
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.
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.
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:
PA RÂ M ET RO DESC RIÇ Ã O
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MySecureVM';
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
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 de chave é especificada, o Azure Disk Encryption usa essa chave para agrupar os segredos de
criptografia antes de gravar no Key Vault.
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = ‘MyExtraSecureVM’;
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
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]
Verifique se os discos estão criptografados: Para verificar o status de criptografia de uma VM IaaS,
use o cmdlet Get-AzVmDiskEncryptionStatus .
Verifique se os discos estão criptografados: Para verificar o status de criptografia de uma VM IaaS,
use o comando AZ VM Encryption show .
PA RÂ M ET RO DESC RIÇ Ã O
$sequenceVersion = [Guid]::NewGuid();
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MySecureVM';
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
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 de chave é especificada, o Azure Disk Encryption usa essa chave para agrupar os segredos 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.
$sequenceVersion = [Guid]::NewGuid();
$KVRGname = 'MyKeyVaultResourceGroup';
$VMRGName = 'MyVirtualMachineResourceGroup';
$vmName = 'MyExtraSecureVM';
$aadClientID = 'My-AAD-client-ID';
$aadClientSecret = 'My-AAD-client-secret';
$KeyVaultName = 'MySecureVault';
$keyEncryptionKeyName = 'MyKeyEncryptionKey';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name
$keyEncryptionKeyName).Key.kid;
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]
Habilitar criptografia em um disco adicionado recentemente com CLI do Azure
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.
Criptografar uma VM em execução usando um segredo do cliente:
$VMRGName = 'MyVirtualMachineResourceGroup'
$KVRGname = 'MyKeyVaultResourceGroup';
$AADClientID ='My-AAD-client-ID';
$KeyVaultName = 'MySecureVault';
$VMName = 'MySecureVM';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
# Fill in the certificate path and the password so the thumbprint can be set as a variable.
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.
$VMRGName = 'MyVirtualMachineResourceGroup';
$KVRGname = 'MyKeyVaultResourceGroup';
$AADClientID ='My-AAD-client-ID';
$KeyVaultName = 'MySecureVault';
$VMName = 'MySecureVM';
$keyEncryptionKeyName ='KEKName';
$KeyVault = Get-AzKeyVault -VaultName $KeyVaultName -ResourceGroupName $KVRGname;
$diskEncryptionKeyVaultUrl = $KeyVault.VaultUri;
$KeyVaultResourceId = $KeyVault.ResourceId;
$keyEncryptionKeyUrl = (Get-AzKeyVaultKey -VaultName $KeyVaultName -Name $keyEncryptionKeyName).Key.kid;
## Fill in the certificate path and the password so the thumbprint can be read and set as a variable.
# Enable disk encryption using the client certificate thumbprint and a KEK
Desabilitar criptografia
É possível desabilitar a criptografia usando o Azure PowerShell, a CLI do Azure ou com um modelo do Resource
Manager.
Desabilitar criptografia de disco com Azure PowerShell: para desabilitar a criptografia, use o
cmdlet Disable-AzureRmVMDiskEncryption.
Desabilitar a criptografia com a CLI do Azure: para desabilitar a criptografia, use o comando az vm
encryption disable.
Próximas etapas
Visão geral do Azure Disk Encryption
Usando os ultra discos do Azure
03/03/2021 • 27 minutes to read • Edit Online
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.
REGIÕ ES O P Ç Õ ES DE REDUN DÂ N C IA
* 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.
subscription="<yourSubID>"
# example value is southeastasia
region="<yourLocation>"
# example value is Standard_E64s_v3
vmSize="<yourVMSize>"
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
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>"
$region = "westus"
$vmSize = "Standard_E64s_v3"
(Get-AzComputeResourceSku | where {$_.Locations.Contains($region) -and ($_.Name -eq $vmSize) })
[0].Capabilities
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.
Clique em Salvar .
Selecione adicionar disco de dados e, em seguida, no menu suspenso para nome , selecione criar disco .
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
03/03/2021 • 13 minutes to read • Edit Online
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.
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
IOPS não armazenado em cache: 12.800
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
IOPS em cache: 16.000
IOPS não armazenado em cache: 12.800
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 em cache: 16.000
IOPS não armazenado em cache: 12.800
Disco do sistema operacional p30
IOPS: 5.000
Cache de host: leitura/gravação
Dois discos de dados p30 × 2
IOPS: 5.000
Cache de host: leitura/gravação
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.
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
03/11/2020 • 5 minutes to read • Edit Online
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.
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.
Próximas etapas
Reduzir os custos com a reserva de discos do Azure
O que são Reservas do Azure?
Reduzir os custos com a reserva de discos do Azure
03/03/2021 • 13 minutes to read • Edit Online
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.
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
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
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
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
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.
EL EM EN TO DESC RIÇ Ã O
EL EM EN TO DESC RIÇ Ã O
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.
Próximas etapas
O que são Reservas do Azure?
Entenda como seu desconto de reserva é aplicado a Armazenamento em Disco do Azure
Armazenamento Premium do Azure: projeto para
alto desempenho
03/03/2021 • 76 minutes to read • Edit Online
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.
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.
% 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
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:
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 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.
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.
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
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.
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
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.
Custo de discos por mês US$ 1.638,40 (32 discos x 1 TB) US$ 544,34 (4 discos x P30)
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.
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
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
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
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.
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.
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
03/03/2021 • 16 minutes to read • Edit Online
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 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.
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
03/03/2021 • 16 minutes to read • Edit Online
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
MB/s provisionados: 100
Máximo de MB/s de intermitência: 170
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.
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.
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
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
03/03/2021 • 4 minutes to read • Edit Online
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. Para saber mais sobre as camadas de desempenho, consulte camadas de desempenho para
discos gerenciados.
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.
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
resourceGroupName=<yourResourceGroupNameHere>
diskName=<yourDiskNameHere>
performanceTier=<yourDesiredPerformanceTier>
az login
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:
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
03/03/2021 • 3 minutes to read • Edit Online
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. Para saber mais sobre as camadas de desempenho, consulte camadas de desempenho para
discos gerenciados.
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.
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:
1. Entre no portal do Azure.
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:
1. Entre no portal do Azure.
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
03/03/2021 • 16 minutes to read • Edit Online
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.
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
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.
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
Acelerador de Gravação.
Substitua myVM , myWAVMs , log001 , tamanho do disco e LunID do disco com valores apropriados para sua
implantação específica.
NOTE
Executar o script acima desanexará o disco especificado, habilitará o Acelerador de Gravação no disco e, em seguida,
anexará o disco novamente
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
Agora você pode instalar o armclient usando o seguinte comando em cmd.exe ou o PowerShell
choco install armclient
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",
"hardwareProfile": {
"vmSize": "Standard_M64s"
},
"storageProfile": {
"imageReference": {
"publisher": "SUSE",
"offer": "SLES-SAP",
"sku": "12-SP3",
"version": "latest"
},
"osDisk": {
"osType": "Linux",
"name": "mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a",
"createOption": "FromImage",
"caching": "ReadWrite",
"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": {
"storageAccountType": "Premium_LRS",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
disks/data1"
},
"diskSizeGB": 1023
},
{
"lun": 1,
"name": "log1",
"createOption": "Attach",
"caching": "None",
"managedDisk": {
"storageAccountType": "Premium_LRS",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
disks/data2"
},
"diskSizeGB": 1023
}
]
},
"osProfile": {
"computerName": "mylittlesapVM",
"adminUsername": "pl",
"linuxConfiguration": {
"disablePasswordAuthentication": false
},
"secrets": []
},
"networkProfile": {
"networkInterfaces": [
{
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Network/
networkInterfaces/mylittlesap518"
}
]
},
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "https://mylittlesapdiag895.blob.core.windows.net/"
}
},
"provisioningState": "Succeeded"
},
"type": "Microsoft.Compute/virtualMachines",
"location": "westeurope",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
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",
"createOption": "Attach",
"caching": "None",
"writeAcceleratorEnabled": true,
"managedDisk": {
"storageAccountType": "Premium_LRS",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
disks/data2"
},
"diskSizeGB": 1023
}
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",
"hardwareProfile": {
"vmSize": "Standard_M64s"
},
"storageProfile": {
"imageReference": {
"publisher": "SUSE",
"offer": "SLES-SAP",
"sku": "12-SP3",
"version": "latest"
},
"osDisk": {
"osType": "Linux",
"name": "mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a",
"createOption": "FromImage",
"caching": "ReadWrite",
"managedDisk": {
"storageAccountType": "Premium_LRS",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
disks/mylittlesap_OsDisk_1_754a1b8bb390468e9b4c429b81cc5f5a"
},
"diskSizeGB": 30
},
"dataDisks": [
{
"lun": 0,
"name": "data1",
"createOption": "Attach",
"caching": "None",
"managedDisk": {
"storageAccountType": "Premium_LRS",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
disks/data1"
},
"diskSizeGB": 1023
},
{
"lun": 1,
"name": "log1",
"createOption": "Attach",
"caching": "None",
"writeAcceleratorEnabled": true,
"managedDisk": {
"storageAccountType": "Premium_LRS",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
disks/data2"
},
"diskSizeGB": 1023
}
]
},
"osProfile": {
"computerName": "mylittlesapVM",
"adminUsername": "pl",
"linuxConfiguration": {
"disablePasswordAuthentication": false
},
"secrets": []
},
"networkProfile": {
"networkInterfaces": [
{
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Network/
networkInterfaces/mylittlesap518"
}
]
},
"diagnosticsProfile": {
"bootDiagnostics": {
"enabled": true,
"storageUri": "https://mylittlesapdiag895.blob.core.windows.net/"
}
},
"provisioningState": "Succeeded"
},
"type": "Microsoft.Compute/virtualMachines",
"location": "westeurope",
"id":
"/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/mylittlesap/providers/Microsoft.Compute/
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
03/03/2021 • 15 minutes to read • Edit Online
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.
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,
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:
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.
[global]
size=30g
direct=1
iodepth=256
ioengine=libaio
bs=4k
numjobs=4
[reader1]
rw=randread
directory=/mnt/readcache
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:
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.
[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
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 alta de fila de 128.
Um tamanho de bloco pequeno de 4 KB.
Vários threads que executam leituras e gravações aleatórias.
Execute o seguinte comando para iniciar o teste FIO por 30 segundos:
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.
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
03/03/2021 • 10 minutes to read • Edit Online
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.
REC URSO L IM IT E
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.
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
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
D E1 E2 E3 E4 E6 E10 E15 E20 E30 E40 E50 E60 E70 E80
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
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
M P1 P2 P3 P4 P6 P 10 P 15 P 20 P 30 P 40 P 50 P 60 P 70 P 80
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
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
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
Discos de máquina vir tual não gerenciados Premium: limites por conta
REC URSO L IM IT E
1Entrada refere-se a todos os dados de solicitações que são enviados a uma conta de armazenamento. Saída
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
Taxa de 100 MB/s 150 MB/s 200 MB/s 250 MB/s 250 MB/s
transferência
máxima por
disco
REC URSO L IM IT E
Confira também
Assinatura do Azure e limite de serviços, cotas e restrições
Criar um instantâneo incremental para discos
gerenciados
03/03/2021 • 9 minutes to read • Edit Online
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
Modelo do Resource Manager
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:
$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.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)
03/03/2021 • 14 minutes to read • Edit Online
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.
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)
03/03/2021 • 19 minutes to read • Edit Online
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.
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.
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.
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.
TIP
Digite o nome do cofre de backup para selecionar a identidade gerenciada do cofre.
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 .
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.
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.
9. Após uma validação bem-sucedida, selecione revisar e configurar para configurar o backup dos discos
selecionados.
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)
03/03/2021 • 13 minutes to read • Edit Online
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.
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
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
Digite o nome do cofre de backup para selecionar a identidade gerenciada do cofre.
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
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 .
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.
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
03/11/2020 • 45 minutes to read • Edit Online
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.
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.
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:
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.
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.
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ê.
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
03/03/2021 • 2 minutes to read • Edit Online
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.
osDiskId=$(az vm show \
-g myResourceGroup \
-n myVM \
--query "storageProfile.osDisk.managedDisk.id" \
-o tsv)
az snapshot create \
-g myResourceGroup \
--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.
az snapshot list \
-g myResourceGroup \
- table
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
03/03/2021 • 3 minutes to read • Edit Online
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.
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:
$resourceGroupName = 'myResourceGroup'
$location = 'eastus'
$vmName = 'myVM'
$snapshotName = 'mySnapshot'
2. Obtenha a VM:
$vm = Get-AzVM `
-ResourceGroupName $resourceGroupName `
-Name $vmName
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 `
-ResourceGroupName $resourceGroupName
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
03/11/2020 • 15 minutes to read • Edit Online
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.
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.
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.
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
03/03/2021 • 15 minutes to read • Edit Online
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:
Supor te a tipo de disco Disco do sistema operacional Somente disco do sistema operacional
gerenciado e não gerenciado gerenciado
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
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.
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 .
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 \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--ephemeral-os-disk true \
--os-disk-caching ReadOnly \
--admin-username azureuser \
--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": {
"name": "Standard_DS2_v2",
"capacity": "2"
},
"properties": {
"upgradePolicy": {
"mode": "Automatic"
},
"virtualMachineProfile": {
"storageProfile": {
"osDisk": {
"diffDiskSettings": {
"option": "Local"
},
"caching": "ReadOnly",
"createOption": "FromImage"
},
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "16.04-LTS",
"version": "latest"
}
},
"osProfile": {
"computerNamePrefix": "myvmss",
"adminUsername": "azureuser",
"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.
{
"type": "Microsoft.Compute/virtualMachines",
"name": "myVirtualMachine",
"location": "East US 2",
"apiVersion": "2018-06-01",
"properties": {
"storageProfile": {
"osDisk": {
"diffDiskSettings": {
"option": "Local"
},
"caching": "ReadOnly",
"createOption": "FromImage"
},
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "2016-Datacenter-smalldisk",
"version": "latest"
},
"hardwareProfile": {
"vmSize": "Standard_DS2_v2"
}
},
"osProfile": {
"computerNamePrefix": "myvirtualmachine",
"adminUsername": "azureuser",
"adminPassword": "P@ssw0rd!"
}
}
}
POST https://management.azure.com/subscriptions/{sub-
id}/resourceGroups/{rgName}/providers/Microsoft.Compute/VirtualMachines/{vmName}/reimage?a pi-version=2018-
06-01"
Perguntas frequentes
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
foreach($vmSize in $vmSizes)
{
foreach($capability in $vmSize.capabilities)
{
if($capability.Name -eq 'EphemeralOSDiskSupported' -and $capability.Value -eq 'true')
{
$vmSize
}
}
}
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
03/03/2021 • 6 minutes to read • Edit Online
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.
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
03/03/2021 • 5 minutes to read • Edit Online
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.
# 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
}
}
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
03/03/2021 • 23 minutes to read • Edit Online
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
armazenamento Premium.
É 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.
NOTE
O Site Recovery não dá suporte à migração de discos dos espaços de armazenamento.
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.
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 .
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.
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.
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.
Solução de problemas
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
03/11/2020 • 23 minutes to read • Edit Online
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
armazenamento Premium.
É 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.
NOTE
O Site Recovery não dá suporte à migração de discos dos espaços de armazenamento.
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.
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 .
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.
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.
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.
Solução de problemas
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
03/03/2021 • 3 minutes to read • Edit Online
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
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.
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
03/11/2020 • 8 minutes to read • Edit Online
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
sistema operacional.
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.
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 .
az vm availability-set show \
--resource-group myResourceGroup \
--name myAvailabilitySet \
--query [virtualMachines[*].id] \
--output table
2. Desaloque todas as VMs usando az vm deallocate. O seguinte exemplo desaloca a VM myVM no grupo de
recursos chamado myResourceGroup :
az vm availability-set convert \
--resource-group myResourceGroup \
--name myAvailabilitySet
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:
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 :
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
03/03/2021 • 7 minutes to read • Edit Online
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
sistema operacional.
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.
$rgName = "myResourceGroup"
$vmName = "myVM"
Stop-AzVM -ResourceGroupName $rgName -Name $vmName -Force
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:
$rgName = 'myResourceGroup'
$avSetName = 'myAvailabilitySet'
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
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
}
Solução de problemas
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.
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
03/03/2021 • 13 minutes to read • Edit Online
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.
az vm disk attach \
-g myResourceGroup \
--vm-name myVM \
--name myDataDisk \
--new \
--size-gb 50
Localize o disco
Uma vez conectado à sua VM, você precisa encontrar o disco. Neste exemplo, estamos usando lsblk para listar
os discos.
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 .
sudo parted /dev/sdc --script mklabel gpt mkpart xfspart xfs 0% 100%
sudo mkfs.xfs /dev/sdc1
sudo partprobe /dev/sdc1
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 :
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:
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
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.
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.
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
RHEL/CentOS
Solução de problemas
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 :
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
03/03/2021 • 12 minutes to read • Edit Online
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.
3. Quando terminar, selecione salvar na parte superior da página para criar o disco gerenciado e atualizar a
configuração da VM.
Localize o disco
Uma vez conectado à sua VM, você precisa encontrar o disco. Neste exemplo, estamos usando lsblk para listar
os discos.
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 :
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 .
sudo parted /dev/sdc --script mklabel gpt mkpart xfspart xfs 0% 100%
sudo mkfs.xfs /dev/sdc1
sudo partprobe /dev/sdc1
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 :
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
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.
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
RHEL/CentOS
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
03/03/2021 • 4 minutes to read • Edit Online
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.
$rgName = 'myResourceGroup'
$vmName = 'myVM'
$location = 'East US'
$storageType = 'Premium_LRS'
$dataDiskName = $vmName + '_datadisk1'
$diskConfig = New-AzDiskConfig -SkuName $storageType -Location $location -CreateOption Empty -DiskSizeGB 128
$dataDisk1 = New-AzDisk -DiskName $dataDiskName -Disk $diskConfig -ResourceGroupName $rgName
$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:
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
03/11/2020 • 3 minutes to read • Edit Online
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.
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
03/03/2021 • 5 minutes to read • Edit Online
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
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
03/03/2021 • 5 minutes to read • Edit Online
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.
Primeiro, localize o disco de dados que você quer desanexar. O exemplo a seguir usa o dmesg para filtrar em
discos SCSI:
Aqui, sdc é o disco que queremos destacar. Também é necessário capturar o UUID do disco.
sudo -i blkid
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.
sudo vi /etc/fstab
Use umount para desmontar o disco. O exemplo a seguir desmonta a partição /dev/sdc1 do ponto de
montagem /datadrive:
az vm disk detach \
-g myResourceGroup \
--vm-name myVm \
-n myDataDisk
O disco permanecerá no armazenamento, mas não estará mais conectado a uma máquina virtual.
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
03/03/2021 • 3 minutes to read • Edit Online
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.
$VirtualMachine = Get-AzVM `
-ResourceGroupName "myResourceGroup" `
-Name "myVM"
Remove-AzVMDataDisk `
-VM $VirtualMachine `
-Name "myDisk"
Update-AzVM `
-ResourceGroupName "myResourceGroup" `
-VM $VirtualMachine
O disco permanecerá no armazenamento, mas não estará mais conectado a uma máquina virtual.
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
03/03/2021 • 6 minutes to read • Edit Online
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.
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 \
--resource-group myResourceGroup \
--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 \
--resource-group myResourceGroup \
--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:
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:
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
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:
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
03/03/2021 • 9 minutes to read • Edit Online
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.
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.)
6. Selecione Salvar .
Connect-AzAccount
Select-AzSubscription –SubscriptionName 'my-subscription-name'
$rgName = 'my-resource-group-name'
$vmName = 'my-vm-name'
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.)
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.
Connect-AzAccount
Select-AzSubscription –SubscriptionName 'my-subscription-name'
$rgName = 'my-resource-group-name'
$vmName = 'my-vm-name'
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
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 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:
Connect-AzAccount
Select-AzSubscription -SubscriptionName 'my-subscription-name'
$rgName = 'my-resource-group-name'
$vmName = 'my-vm-name'
$vm = Get-AzVM -ResourceGroupName $rgName -Name $vmName
Stop-AzVM -ResourceGroupName $rgName -Name $vmName
$disk= Get-AzDisk -ResourceGroupName $rgName -DiskName $vm.StorageProfile.OsDisk.Name
$disk.DiskSizeGB = 1023
Update-AzDisk -ResourceGroupName $rgName -Disk $disk -DiskName $disk.Name
Start-AzVM -ResourceGroupName $rgName -Name $vmName
Connect-AzAccount
Select-AzSubscription -SubscriptionName 'my-subscription-name'
$rgName = 'my-resource-group-name'
$vmName = 'my-vm-name'
$vm = Get-AzVM -ResourceGroupName $rgName -Name $vmName
Stop-AzVM -ResourceGroupName $rgName -Name $vmName
$vm.StorageProfile.OSDisk.DiskSizeGB = 1023
Update-AzVM -ResourceGroupName $rgName -VM $vm
Start-AzVM -ResourceGroupName $rgName -Name $vmName
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
Próximas etapas
Você também pode conectar discos usando o portal do Azure.
Usando discos em modelos de Azure Resource
Manager
03/11/2020 • 11 minutes to read • Edit Online
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.
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2018-07-01",
"name": "[variables('storageAccountName')]",
"location": "[resourceGroup().location]",
"sku": {
"name": "Standard_LRS"
},
"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.
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2018-10-01",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {...},
"osProfile": {...},
"storageProfile": {
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "[parameters('windowsOSVersion')]",
"version": "latest"
},
"osDisk": {
"name": "osdisk",
"vhd": {
"uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob, 'vhds/osdisk.vhd')]"
},
"caching": "ReadWrite",
"createOption": "FromImage"
},
"dataDisks": [
{
"name": "datadisk1",
"diskSizeGB": 1023,
"lun": 0,
"vhd": {
"uri": "[concat(reference(resourceId('Microsoft.Storage/storageAccounts/',
variables('storageAccountName'))).primaryEndpoints.blob, 'vhds/datadisk1.vhd')]"
},
"createOption": "Empty"
}
]
},
"networkProfile": {...},
"diagnosticsProfile": {...}
}
}
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 .
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2018-10-01",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]"
],
"properties": {
"hardwareProfile": {...},
"osProfile": {...},
"storageProfile": {
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "[parameters('windowsOSVersion')]",
"version": "latest"
},
"osDisk": {
"createOption": "FromImage"
},
"dataDisks": [
{
"diskSizeGB": 1023,
"lun": 0,
"createOption": "Empty"
}
]
},
"networkProfile": {...},
"diagnosticsProfile": {...}
}
}
{
"type": "Microsoft.Compute/disks",
"apiVersion": "2018-06-01",
"name": "[concat(variables('vmName'),'-datadisk1')]",
"location": "[resourceGroup().location]",
"sku": {
"name": "Standard_LRS"
},
"properties": {
"creationData": {
"createOption": "Empty"
},
"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.
{
"type": "Microsoft.Compute/virtualMachines",
"apiVersion": "2018-10-01",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"dependsOn": [
"[resourceId('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
"[resourceId('Microsoft.Network/networkInterfaces/', variables('nicName'))]",
"[resourceId('Microsoft.Compute/disks/', concat(variables('vmName'),'-datadisk1'))]"
],
"properties": {
"hardwareProfile": {...},
"osProfile": {...},
"storageProfile": {
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "[parameters('windowsOSVersion')]",
"version": "latest"
},
"osDisk": {
"createOption": "FromImage"
},
"dataDisks": [
{
"lun": 0,
"name": "[concat(variables('vmName'),'-datadisk1')]",
"createOption": "attach",
"managedDisk": {
"id": "[resourceId('Microsoft.Compute/disks/', concat(variables('vmName'),'-
datadisk1'))]"
}
}
]
},
"networkProfile": {...},
"diagnosticsProfile": {...}
}
}
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",
"location": "[resourceGroup().location]",
"name": "[variables('avSetName')]",
"properties": {
"PlatformUpdateDomainCount": 3,
"PlatformFaultDomainCount": 2
},
"sku": {
"name": "Aligned"
}
}
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",
"caching": "ReadWrite",
"createOption": "FromImage",
"managedDisk": {
"storageAccountType": "StandardSSD_LRS"
}
}
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
03/03/2021 • 5 minutes to read • Edit Online
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.
#The name of the new snapshot which will be secured via Private Links
snapshotNameSecuredWithPL=yourSnapshotNameSecuredWithPL
az login
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
03/03/2021 • 6 minutes to read • Edit Online
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.
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.
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.
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
03/03/2021 • 10 minutes to read • Edit Online
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.
TIP
Se você estiver criando um disco do sistema operacional, adicione -HyperVGeneration '<yourGeneration>' a
New-AzDiskConfig .
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:
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.
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>'
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ê.
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>
# 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'
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
03/11/2020 • 9 minutes to read • Edit Online
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.
TIP
Se você estiver criando um disco do sistema operacional, adicione--Hyper-v-Generation ao az disk create .
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:
{
"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.
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:
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ê.
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>
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
03/03/2021 • 2 minutes to read • Edit Online
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.
1. Entre no portal do Azure.
2. No menu à esquerda, selecione máquinas vir tuais .
3. Selecione a VM na lista.
4. Na página da VM, selecione parar .
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
03/03/2021 • 3 minutes to read • Edit Online
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
sistema operacional.
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 .
2. Selecione a VM na lista.
3. Na folha da VM, clique em Parar .
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
03/11/2020 • 5 minutes to read • Edit Online
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
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 .
4. Selecione salvar e seu disco começará a ser baixado. O status do download será exibido em atividades .
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
03/11/2020 • 2 minutes to read • Edit Online
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 \
-g myResourceGroupDisk \
--query '[*].{diskId:id}' \
--output table
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 \
-g myResourceGroup \
-n myVM \
--os-disk /subscriptions/<subscription ID>/resourceGroups/swap/providers/Microsoft.Compute/disks/myDisk
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
03/11/2020 • 2 minutes to read • Edit Online
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
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
$vm = Get-AzVM -ResourceGroupName myResourceGroup -Name myVM
# 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
03/03/2021 • 3 minutes to read • Edit Online
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
1. Conectar-se à VM
2. sudo lsscsi
A primeira coluna listada conterá o LUN, o formato é [host: Channel: target: _ * LUN * *].
Listando dispositivos de bloco
1. Conectar-se à VM
2. sudo ls -l /sys/block/*/device
A última coluna listada conterá o LUN, o formato é [host: Channel: target:LUN ]
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.
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.
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.
else
echo $id
fi
done
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.
Depois de examinar todos os discos desanexados, execute o script novamente e defina a variável
deleteUnattachedVHDs como 1. Essa ação permite excluir todos os VHDs não gerenciados desanexados.
if [ "$leaseStatus" == "unlocked" ]
then
if (( $deleteUnattachedVHDs == 1 ))
then
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
03/11/2020 • 4 minutes to read • Edit Online
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.
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.
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.
Depois de examinar todos os discos desanexados, execute o script novamente e defina a variável
deleteUnattachedVHDs como $true . Essa ação permite excluir todos os VHDs não gerenciados desanexados.
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
03/03/2021 • 3 minutes to read • Edit Online
Quando você exclui uma VM (máquina virtual) no Azure, por padrão, nenhum disco anexado à máquina virtual
é 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.
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 .
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
03/03/2021 • 47 minutes to read • Edit Online
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.
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:
Grupos de segurança de rede
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.
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.
Após criar um endereço IP público, você pode associá-lo a uma VM, atribuindo-o a uma NIC.
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.
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.
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.
Esta tabela lista os métodos que você pode usar para criar um balanceador de carga interno.
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.
CLI do Azure Crie e conecte a uma VM para uma rede virtual, sub-rede e
NIC criar como etapas individuais.
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
03/11/2020 • 7 minutes to read • Edit Online
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.
OPÇ ÃO EXEM P LO / L IN K
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:
az vm create \
--resource-group myResourceGroup \
--name myVm1 \
--image UbuntuLTS \
--generate-ssh-keys \
--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 \
--resource-group myResourceGroup \
--name myVm2 \
--image UbuntuLTS \
--generate-ssh-keys
Anote o publicIpAddress . Você usará esse endereço para conectar-se à VM pela Internet na próxima etapa.
ssh <publicIpAddress>
ping myVm1 -c 4
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:
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
03/11/2020 • 5 minutes to read • Edit Online
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
usando a CLI do Azure.
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.
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, myNetworkSecurityGroup e myVnet.
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.
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:
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:
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
03/11/2020 • 5 minutes to read • Edit Online
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 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" `
-Direction "Inbound" `
-Priority "100" `
-SourceAddressPrefix "Internet" `
-SourcePortRange * `
-DestinationAddressPrefix * `
-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 :
$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName "myResourceGroup" `
-Location "EastUS" `
-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:
$vnet = Get-AzVirtualNetwork `
-ResourceGroupName "myResourceGroup" `
-Name "myVnet"
Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $vnet `
-Name "mySubnet" `
-AddressPrefix $subnetPrefix.AddressPrefix `
-NetworkSecurityGroup $nsg
Por fim, atualize sua rede virtual com Set-AzVirtualNetwork para que suas alterações entrem em vigor:
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 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.
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
aplicativo altamente disponível.
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:
Visão geral do Azure Resource Manager
Grupos de segurança
Crie uma máquina virtual com um endereço IP
público estático usando a CLI do Azure
03/03/2021 • 5 minutes to read • Edit Online
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.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys \
--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:
az network public-ip show \
--resource-group myResourceGroup \
--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:
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
03/11/2020 • 12 minutes to read • Edit Online
Este artigo fornece detalhes sobre como criar uma VM com várias NICs com a CLI do Azure.
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:
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:
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:
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--size Standard_DS3_v2 \
--admin-username azureuser \
--generate-ssh-keys \
--nics myNic1 myNic2
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 \
--resource-group myResourceGroup \
--vm-name myVM \
--nics myNic3
Remova a NIC com az vm nic remove. O exemplo a seguir remove myNic3 de myVM:
az vm nic remove \
--resource-group myResourceGroup \
--vm-name myVM \
--nics myNic3
"copy": {
"name": "multiplenics"
"count": "[parameters('count')]"
}
Você pode ler um exemplo completo em Criando várias NICs usando modelos do Gerenciador de Recursos.
Adicione tabelas de roteamento ao SO convidado concluindo as etapas em Configure o SO convidado para
várias NICs.
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:
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:
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
03/11/2020 • 14 minutes to read • Edit Online
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
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.
2. Crie uma rede virtual e sub-redes com New-AzVirtualNetwork. O seguinte exemplo cria uma rede virtual
chamada myVnet:
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:
$cred = Get-Credential
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):
4. Anexe os dois adaptadores de rede que você criou anteriormente com Add-AzVMNetworkInterface:
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:
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:
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:
5. Adicione rotas para NICs secundárias ao SO, concluindo as etapas em Configurar o sistema operacional
para várias NICs.
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:
"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.
===========================================================================
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
===========================================================================
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):
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
03/03/2021 • 20 minutes to read • Edit Online
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.
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.
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:
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:
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:
az network nic create \
--resource-group myResourceGroup \
--name myNic \
--vnet-name myVnet \
--subnet mySubnet \
--accelerated-networking true \
--public-ip-address myPublicIp \
--network-security-group myNetworkSecurityGroup
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--size Standard_DS4_v2 \
--admin-username azureuser \
--generate-ssh-keys \
--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",
"powerState": "VM running",
"privateIpAddress": "192.168.0.4",
"publicIpAddress": "40.68.254.142",
"resourceGroup": "myResourceGroup"
}
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
az vm deallocate \
--resource-group myResourceGroup \
--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:
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:
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"
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
03/03/2021 • 2 minutes to read • Edit Online
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
03/03/2021 • 2 minutes to read • Edit Online
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.
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
03/11/2020 • 15 minutes to read • Edit Online
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 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
resolução de nomes usando seu
próprio servidor DNS.
DNS inverso para IPs internos Resolução de nome usando o seu n/a
próprio servidor DNS
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.
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.
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
03/03/2021 • 10 minutes to read • Edit Online
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 :
az vm create \
--resource-group myResourceGroup \
--name myVM \
--nics myNic \
--image UbuntuLTS \
--admin-username azureuser \
--ssh-key-value ~/.ssh/id_rsa.pub
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.
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 .
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
03/03/2021 • 15 minutes to read • Edit Online
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
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
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?
03/03/2021 • 18 minutes to read • Edit Online
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.
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.
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
03/03/2021 • 79 minutes to read • Edit Online
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.
Redes virtuais e máquinas virtuais no Azure
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Redes virtuais e máquinas virtuais no Azure
Informações sobre grupos de segurança de rede
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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 logs de fluxo de NSG
Como habilitar o Observador de Rede
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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 implantar o Firewall do Azure
Como configurar alertas com o Firewall do Azure
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Responsabilidade : Cliente
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
Como criar uma Rede Virtual
Como criar um NSG com uma configuração de segurança
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Como configurar e gerenciar o Azure Policy
Exemplos de Azure Policy para rede
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
Visão geral do agente do log Analytics
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
Como alternativa, você pode habilitar o e os dados integrados para o Azure Sentinel ou um SIEM de terceiros
para configurar alertas para atividades anormais.
Como integrar o Azure Sentinel
Como gerenciar alertas na central de segurança do Azure
Como alertar sobre dados de log do log Analytics
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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.
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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.
Como realizar consultas personalizadas no Azure Monitor
Fontes de dados do Syslog no Azure Monitor
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : 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.
Como criar e usar marcas
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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 criar e usar marcas
Como criar uma Rede Virtual
Como criar um NSG com uma configuração de segurança
Como implantar o Firewall do Azure
Como configurar alerta ou alerta e negar com o Firewall do Azure
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Compartilhado
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.
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Compartilhado
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
Como criar alertas para eventos do log de atividades do Azure
Log da análise do Armazenamento do Azure
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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.
Solução Gerenciamento de Atualizações no Azure
Gerenciar atualizações e patches para suas VMs
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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.
Backup em VMs do Azure que usam criptografia
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
03/03/2021 • 82 minutes to read • Edit Online
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.
Redes virtuais e máquinas virtuais no Azure
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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 logs de fluxo de NSG
Como habilitar o Observador de Rede
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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 implantar o Firewall do Azure
Como configurar alertas com o Firewall do Azure
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Responsabilidade : Cliente
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.
Como criar e usar marcas
Como criar uma Rede Virtual
Como criar um NSG com uma configuração de segurança
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Como configurar e gerenciar o Azure Policy
Exemplos de Azure Policy para rede
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
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 é
armazenado por padrã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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Visão geral do agente do log Analytics
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
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.
Visão geral do agente do log Analytics
Extensão da máquina virtual do log Analytics para Windows
Como integrar o Azure Sentinel
Compreender o workspace do Log Analytics
Como realizar consultas personalizadas no Azure Monitor
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
Como alternativa, você pode habilitar o e os dados integrados para o Azure Sentinel ou um SIEM de terceiros
para configurar alertas para atividades anormais.
Como integrar o Azure Sentinel
Como gerenciar alertas na central de segurança do Azure
Como alertar sobre dados de log do log Analytics
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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 configurar o Microsoft antimalware para serviços de nuvem e máquinas virtuais
Como habilitar o monitoramento em nível de convidado para máquinas virtuais
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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.
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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.
Coleta de dados na Central de Segurança do Azure
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : 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.
Como criar e usar marcas
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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 criar e usar marcas
Como criar uma Rede Virtual
Como criar um NSG com uma configuração de segurança
Como implantar o Firewall do Azure
Como configurar alerta ou alerta e negar com o Firewall do Azure
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Compartilhado
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.
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Compartilhado
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
Como criar alertas para eventos do log de atividades do Azure
Log da análise do Armazenamento do Azure
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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.
Solução Gerenciamento de Atualizações no Azure
Gerenciar atualizações e patches para suas VMs
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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.
Solução Gerenciamento de Atualizações no Azure
Gerenciar atualizações e patches para suas VMs
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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.
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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.
Como configurar e gerenciar o Azure Policy
Informações sobre como baixar o modelo de VM
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Como configurar e gerenciar o Azure Policy
Compreendendo os efeitos do Azure Policy
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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 como baixar o modelo de VM
Informações sobre a criação de modelos do ARM
Como carregar um VHD de VM personalizado para o Azure
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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.
Entender o RBAC do Azure
Como configurar o RBAC do Azure
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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 o Azure Policy
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
7.10: implementar monitoramento automatizado 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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Uma visão geral do backup de VM do Azure
Como fazer backup de chaves do cofre de chaves no Azure
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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.
Backup em VMs do Azure que usam criptografia
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não aplicável
Responsabilidade : Cliente
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
Monitoramento da Central de Segurança do Azure : Sim
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
Monitoramento da central de segurança do Azure : não disponível
Responsabilidade : Cliente
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
03/03/2021 • 8 minutes to read • Edit Online
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
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.
REC O M EN DA Ç Ã O C O M EN TÁ RIO S C EN T RA L DE SEGURA N Ç A
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
REC O M EN DA Ç Ã O C O M EN TÁ RIO S C EN T RA L DE SEGURA N Ç A
Monitoramento
REC O M EN DA Ç Ã O C O M EN TÁ RIO S C EN T RA L DE SEGURA N Ç A
Rede
REC O M EN DA Ç Ã O C O M EN TÁ RIO S C EN T RA L DE SEGURA N Ç A
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
03/03/2021 • 20 minutes to read • Edit Online
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
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
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 .
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.
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
03/03/2021 • 11 minutes to read • Edit Online
É 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.
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.
Criptografia no 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.
Azure Disk Encryption
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.
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
03/03/2021 • 191 minutes to read • Edit Online
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.
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)
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
máquinas virtuais do
Windows
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)
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
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)
CMMC nível 3
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 – CMMC nível
3. Para saber mais sobre esse padrão de conformidade, confira Cybersecurity Maturity Model Certification
(CMMC).
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)
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)
ISO 27001:2013
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 – ISO
27001:2013. Para obter mais informações sobre esse padrão de conformidade, confira ISO 27001:2013.
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)
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
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)
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
Analytics – imagem
de VM (sistema
operacional) não
listada
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)
NIST SP 800-53 R4
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 – 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
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)
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
Analytics – imagem
de VM (sistema
operacional) não
listada
Próximas etapas
Saiba mais sobre a Conformidade Regulatória do Azure Policy.
Confira os internos no repositório Azure Policy GitHub.
Definições internas do Azure Policy para máquinas
virtuais do Microsoft Azure
03/03/2021 • 87 minutes to read • Edit Online
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.
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
DESC RIÇ Ã O EF EITO ( S)
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.
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
Microsoft.VirtualMachineImages
NOME VERSÃ O
( PO RTA L DO A ZURE ) DESC RIÇ Ã O EF EITO ( S) ( GIT HUB)
Microsoft.ClassicCompute
NOME VERSÃ O
( PO RTA L DO A ZURE ) DESC RIÇ Ã O EF EITO ( S) ( GIT HUB)
NOME VERSÃ O
DESC RIÇ Ã O EF EITO ( S)
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
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?.
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"
}
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"
}
}
{
"field": "Microsoft.Compute/imageId",
"in": ["{imageId1}","{imageId2}"]
}
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines/extensions"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/publisher",
"equals": "Microsoft.Compute"
},
{
"field": "Microsoft.Compute/virtualMachines/extensions/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
03/11/2020 • 5 minutes to read • Edit Online
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?.
Use um curinga para modificar a política anterior a fim de permitir qualquer imagem do Windows Server
Datacenter:
{
"field": "Microsoft.Compute/imageSku",
"like": "*Datacenter"
}
Use anyOf para modificar a política anterior para permitir qualquer Windows Server 2012 R2 Datacenter ou
uma imagem superior:
{
"anyOf": [
{
"field": "Microsoft.Compute/imageSku",
"like": "2012-R2-Datacenter*"
},
{
"field": "Microsoft.Compute/imageSku",
"like": "2016-Datacenter*"
}
]
}
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"
}
}
{
"if": {
"allOf": [
{
"field": "type",
"in": [
"Microsoft.Compute/virtualMachines",
"Microsoft.Compute/VirtualMachineScaleSets"
]
},
{
"not": {
"field": "Microsoft.Compute/imageId",
"contains": "resourceGroups/CustomImage"
}
}
]
},
"then": {
"effect": "deny"
}
}
{
"field": "Microsoft.Compute/imageId",
"in": ["{imageId1}","{imageId2}"]
}
}
]
},
"then": {
"effect": "deny"
}
}
{
"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?
03/03/2021 • 15 minutes to read • Edit Online
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.
Perguntas frequentes
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
*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
03/11/2020 • 4 minutes to read • Edit Online
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.
Para abrir o Cloud Shell, basta selecionar Experimentar no canto superior direito de um bloco de código. Você
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.
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.
$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.
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
03/11/2020 • 4 minutes to read • Edit Online
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.
Para abrir o Cloud Shell, basta selecionar Experimentar no canto superior direito de um bloco de código. Você
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.
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 .
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.
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
03/03/2021 • 8 minutes to read • Edit Online
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)
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 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.
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 chave privada
SSH do arquivo local .
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 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
03/11/2020 • 3 minutes to read • Edit Online
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)?
03/03/2021 • 11 minutes to read • Edit Online
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.
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.
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
03/11/2020 • 2 minutes to read • Edit Online
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.
{
"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
03/11/2020 • 3 minutes to read • Edit Online
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.
Para cofres de chaves existentes, você pode usar este cmdlet do PowerShell:
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"
{
"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
03/03/2021 • 16 minutes to read • Edit Online
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.
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.
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:
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:
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
03/03/2021 • 15 minutes to read • Edit Online
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.
sudo vi /etc/hosts
Quando terminar, salve e saia do arquivo de hosts usando o :wq comando do editor.
sudo yum install realmd sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools
RHEL 6
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 [email protected] é usada para inicializar o Kerberos. Insira sua
própria conta de usuário que faça parte do domínio gerenciado:
kinit [email protected]
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
[email protected] :
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:
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:
Se o adcli info 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. 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.
[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
sudo vi /etc/sssd/sssd.conf
[sssd]
services = nss, pam, ssh, autofs
config_file_version = 2
domains = AADDSCONTOSO.COM
[domain/AADDSCONTOSO.COM]
id_provider = ad
sudo vi /etc/ssh/sshd_config
PasswordAuthentication yes
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
RHEL 6
sudo visudo
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
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
03/03/2021 • 12 minutes to read • Edit Online
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 do CentOS Linux 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 faz parte do domínio gerenciado.
sudo vi /etc/hosts
Quando terminar, salve e saia do arquivo de hosts usando o :wq comando do editor.
sudo yum install realmd sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools
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 [email protected] é usada para inicializar o Kerberos. Insira sua
própria conta de usuário que faça parte do domínio gerenciado:
kinit [email protected]
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
[email protected] :
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:
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.
sudo vi /etc/ssh/sshd_config
PasswordAuthentication yes
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:
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:
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
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.
Ingressar uma máquina virtual Ubuntu Linux em um
domínio Azure Active Directory Domain Services
gerenciado
03/03/2021 • 16 minutes to read • Edit Online
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 Ubuntu Linux 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.
sudo vi /etc/hosts
Quando terminar, salve e saia do arquivo de hosts usando o :wq comando do 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:
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 [email protected] é usada para inicializar o Kerberos. Insira sua
própria conta de usuário que faça parte do domínio gerenciado:
kinit -V [email protected]
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
[email protected] :
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:
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.
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
sudo vi /etc/sssd/sssd.conf
# 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 vi /etc/ssh/sshd_config
PasswordAuthentication yes
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:
sudo vi /etc/pam.d/common-session
2. Adicione a seguinte linha a este arquivo abaixo da linha session optional pam_sss.so :
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.
1. Abra o arquivo do sudoers para edição:
sudo visudo
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
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.
Configurar identidades gerenciadas para recursos
do Azure em uma VM usando o portal do Azure
03/03/2021 • 7 minutes to read • Edit Online
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.
Próximas etapas
Usando o portal do Azure, conceda acesso de identidade gerenciada de uma VM do Azure a outro recurso do
Azure.
Configurar identidades gerenciadas para recursos
do Azure em uma VM do Azure usando a CLI do
Azure
03/03/2021 • 15 minutes to read • Edit Online
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, 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
Se você ainda não tiver uma conta do Azure, inscreva-se em uma conta gratuita antes de continuar.
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.
Use o ambiente Bash no Azure Cloud Shell.
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 login
2. Use az vm identity assign com identity assign para habilitar a identidade atribuída ao sistema para
uma VM existente:
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"
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
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>
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
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"
}
az vm identity assign -g <RESOURCE GROUP> -n <VM NAME> --identities <USER ASSIGNED IDENTITY>
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.
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:
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, 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 .
Se você ainda não tiver uma conta do Azure, inscreva-se em uma conta gratuita antes de continuar.
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 .
2. Recupere e tome nota do ObjectID (conforme especificado no campo Id dos valores retornados) do
grupo:
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:
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
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.
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:
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.
Próximas etapas
Identidades gerenciadas para visão geral de recursos do Azure
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
Configurar identidades gerenciadas para recursos
do Azure em uma VM do Azure usando modelos
03/03/2021 • 14 minutes to read • Edit Online
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, 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 .
Se você ainda não tiver uma conta do Azure, inscreva-se em uma conta gratuita antes de continuar.
"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",
"type": "Microsoft.Compute/virtualMachines",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "SystemAssigned",
},
},
//The following appears only if you provisioned the optional VM extension (to be deprecated)
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'),'/ManagedIdentityExtensionForWindows')]",
"apiVersion": "2018-06-01",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.ManagedIdentity",
"type": "ManagedIdentityExtensionForWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"port": 50342
}
}
}
]
"builtInRoleType": {
"type": "string",
"defaultValue": "Reader"
},
"rbacGuid": {
"type": "string"
}
{
"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'))]"
]
}
{
"apiVersion": "2018-06-01",
"type": "Microsoft.Compute/virtualMachines",
"name": "[parameters('vmName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "None"
}
}
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.
{
"apiVersion": "2018-06-01",
"type": "Microsoft.Compute/virtualMachines",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "userAssigned",
"userAssignedIdentities": {
"
[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',variables('<USERASSIGNEDIDENTITYNAME>
'))]": {}
}
}
}
{
"apiVersion": "2017-12-01",
"type": "Microsoft.Compute/virtualMachines",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "userAssigned",
"identityIds": [
"
[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',variables('<USERASSIGNEDIDENTITYNAME>
'))]"
]
}
}
2. Quando você terminar, as seguintes seções deverão ser adicionadas à seção resource do modelo e ela
será semelhante à seguinte:
Microsoft.Compute/vir tualMachines API versão 2018-06-01
"resources": [
{
//other resource provider properties...
"apiVersion": "2018-06-01",
"type": "Microsoft.Compute/virtualMachines",
"name": "[variables('vmName')]",
"location": "[resourceGroup().location]",
"identity": {
"type": "userAssigned",
"userAssignedIdentities": {
"
[resourceID('Microsoft.ManagedIdentity/userAssignedIdentities/',variables('<USERASSIGNEDIDENTITYNAME>
'))]": {}
}
}
},
//The following appears only if you provisioned the optional VM extension (to be deprecated)
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'),'/ManagedIdentityExtensionForWindows')]",
"apiVersion": "2018-06-01-preview",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.ManagedIdentity",
"type": "ManagedIdentityExtensionForWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"port": 50342
}
}
}
]
//The following appears only if you provisioned the optional VM extension (to be deprecated)
{
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(variables('vmName'),'/ManagedIdentityExtensionForWindows')]",
"apiVersion": "2015-05-01-preview",
"location": "[resourceGroup().location]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/', variables('vmName'))]"
],
"properties": {
"publisher": "Microsoft.ManagedIdentity",
"type": "ManagedIdentityExtensionForWindows",
"typeHandlerVersion": "1.0",
"autoUpgradeMinorVersion": true,
"settings": {
"port": 50342
}
}
}
]
Caso você tenha uma identidade gerenciada atribuída ao sistema, mantenha a identidade com o valor
type no valor identity .
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.
Configurar identidades gerenciadas para recursos
do Azure em uma VM do Azure usando chamadas
da API REST
03/03/2021 • 27 minutes to read • Edit Online
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 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
Se você ainda não tiver uma conta do Azure, inscreva-se em uma conta gratuita antes de continuar.
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.
Use o ambiente Bash no Azure Cloud Shell.
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.
az account get-access-token
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
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01 HTTP/1.1
Cabeçalhos de 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,
"createOption":"Empty",
"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
}
}
]
}
}
}
az account get-access-token
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.
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
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
"Authorization:Bearer <ACCESS TOKEN>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"identity":{
"type":"SystemAssigned"
}
}
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
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
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>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"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":{
}
}
}
}
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
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>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
12-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"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"
]
}
}
az account get-access-token
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:
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, 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.
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
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>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"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 .
az account get-access-token
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.
az account get-access-token
4. Crie uma identidade gerenciada atribuída pelo usuário usando as instruções encontradas aqui: Crie uma
identidade gerenciada atribuída pelo usuário.
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.
API DE 2018 VERSÃO-06-01
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":"UserAssigned","identityIds":
["/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1"]},
"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":"myPassword12"},"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
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"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-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":"myPassword12"
},
"networkProfile":{
"networkInterfaces":[
{
"id":"/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/myNic",
"properties":{
"primary":true
}
}
]
}
}
}
PUT https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
12-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"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-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":"myPassword12"
},
"networkProfile":{
"networkInterfaces":[
{
"id":"/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Network/networkInterfaces/myNic",
"properties":{
"primary":true
}
}
]
}
}
}
az account get-access-token
2. Crie uma identidade gerenciada atribuída pelo usuário usando as instruções encontradas aqui, Crie uma
identidade gerenciada atribuída pelo usuário.
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 .
Cabeçalhos de solicitação
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.
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01' -X PATCH -d '{"identity":{"type":"UserAssigned", "userAssignedIdentities":
{"/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1":
{}}}}' -H "Content-Type: application/json" -H "Authorization:Bearer <ACCESS TOKEN>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"identity":{
"type":"UserAssigned",
"userAssignedIdentities":{
"/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1":{
}
}
}
}
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
12-01' -X PATCH -d '{"identity":{"type":"userAssigned", "identityIds":["/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1"]}}
' -H "Content-Type: application/json" -H "Authorization:Bearer <ACCESS TOKEN>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
12-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"identity":{
"type":"userAssigned",
"identityIds":[
"/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1"
]
}
}
5. Se você tiver uma identidade gerenciada designada pelo usuário ou designada pelo sistema atribuída à
sua VM:
API DE 2018 VERSÃO-06-01
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:
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
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>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"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":{
}
}
}
}
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:
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
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>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
12-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"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"
]
}
}
az account get-access-token
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:
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>"
Cabeçalhos de solicitação
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:
API DE 2018 VERSÃO-06-01
Adicionar null para o usuário atribuído gerenciado identidade que você deseja remover:
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01' -X PATCH -d '{"identity":{"type":"SystemAssigned, UserAssigned", "userAssignedIdentities":
{"/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID2":nu
ll}}}' -H "Content-Type: application/json" -H "Authorization:Bearer <ACCESS TOKEN>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-
06-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"identity":{
"type":"SystemAssigned, UserAssigned",
"userAssignedIdentities":{
"/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID2":nu
ll
}
}
}
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
12-01' -X PATCH -d '{"identity":{"type":"SystemAssigned, UserAssigned", "identityIds":
["/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1"]}}
' -H "Content-Type: application/json" -H "Authorization:Bearer <ACCESS TOKEN>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2017-
12-01 HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"identity":{
"type":"SystemAssigned, UserAssigned",
"identityIds":[
"/subscriptions/<SUBSCRIPTION
ID>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ID1"
]
}
}
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:
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
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
"Authorization:Bearer <ACCESS TOKEN>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-06-01
HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"identity":{
"type":"SystemAssigned"
}
}
Se sua VM tiver somente identidades gerenciadas atribuídas pelo usuário e você quiser removê-las, use o
seguinte comando:
curl 'https://management.azure.com/subscriptions/<SUBSCRIPTION
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>"
PATCH https://management.azure.com/subscriptions/<SUBSCRIPTION
ID>/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM?api-version=2018-06-01
HTTP/1.1
Cabeçalhos de solicitação
Corpo da solicitação
{
"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
03/03/2021 • 3 minutes to read • Edit Online
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 AD (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 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.
. A M O ST RA
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
03/03/2021 • 19 minutes to read • Edit Online
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
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. 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.
Debian Debian 9
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
versão 2.0.31 ou posterior. Execute az --version para encontrar a versão. Se você precisa instalar ou atualizar,
consulte Instalar 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
autenticação do Azure AD.
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys
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:
az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory.LinuxSSH \
--name AADLoginForLinux \
--resource-group myResourceGroup \
--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.
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
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.
WARNING
A autenticação multifator habilitada/imposta por usuário do Azure AD não tem suporte para entrada de VM.
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.
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.
NOTE
Se você estiver executando problemas com as atribuições de função do Azure, consulte solucionar problemas do RBAC do
Azure.
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
03/11/2020 • 14 minutes to read • Edit Online
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
03/03/2021 • 15 minutes to read • Edit Online
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
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.
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.
O registro de recursos pode levar até 15 minutos. Para verificar o status do registro:
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.
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
O registro de recursos pode levar até 15 minutos. Para verificar o status do registro:
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.
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"
}
}
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"
}
}
]
}
}
}
}
az vm extension set \
--resource-group myResourceGroup \
--vm-name myVM \
--name DependencyAgentLinux \
--publisher Microsoft.Azure.Monitoring.DependencyAgent \
--version 9.5 \
--enable-auto-upgrade true
Próximas etapas
Saiba mais sobre a extensão de integridade do aplicativo
Manipulando notificações de manutenção
planejada
03/03/2021 • 16 minutes to read • Edit Online
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.
Perguntas frequentes
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
03/03/2021 • 2 minutes to read • Edit Online
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.
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.
Implantações clássicas
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.
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:
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
03/03/2021 • 4 minutes to read • Edit Online
Este ar tigo se aplica a máquinas vir tuais que executam o Linux e o Windows.
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.
1. Entre no portal do Azure.
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
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.
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
03/11/2020 • 4 minutes to read • Edit Online
Este ar tigo se aplica a máquinas vir tuais que executam o Linux e o Windows.
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.
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
VA LO R DESC RIÇ Ã O
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.
function MaintenanceIterator
{
Select-AzSubscription -SubscriptionId $args[0]
$rgList= Get-AzResourceGroup
Implantações clássicas
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.
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:
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
03/03/2021 • 9 minutes to read • Edit Online
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.
az group create \
--location eastus \
--name myMaintenanceRG
az maintenance configuration create \
-g myMaintenanceRG \
--resource-name myConfig \
--maintenance-scope host\
--location eastus
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 .
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.
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
Host dedicado
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.
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.
Host dedicado
Aplicar atualizações a um host dedicado.
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
Host dedicado
Próximas etapas
Para saber mais, consulte manutenção e atualizações.
Controlar atualizações com controle de
manutenção e Azure PowerShell
03/03/2021 • 8 minutes to read • Edit Online
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.
New-AzResourceGroup `
-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.
$config = New-AzMaintenanceConfiguration `
-ResourceGroup $RGName `
-Name $MaintenanceConfig `
-MaintenanceScope Host `
-Location $location `
-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 `
-ResourceGroupName myResourceGroup `
-Location eastus `
-ResourceName myVM `
-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 `
-ResourceGroupName myResourceGroup `
-Location eastus `
-ResourceName myHost `
-ResourceType hosts `
-ResourceParentName myHostGroup `
-ResourceParentType hostGroups `
-ProviderName Microsoft.Compute `
-ConfigurationAssignmentName $config.Name `
-MaintenanceConfigurationId $config.Id
{
"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 `
-ResourceGroupName myResourceGroup `
-ResourceName myVM `
-ResourceType VirtualMachines `
-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 `
-ResourceGroupName myResourceGroup `
-ResourceName myHost `
-ResourceType hosts `
-ResourceParentName myHostGroup `
-ResourceParentType hostGroups `
-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 `
-ResourceGroupName myResourceGroup `
-ResourceName myVM `
-ResourceType VirtualMachines `
-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 `
-ResourceGroupName myResourceGroup `
-ResourceName myHost `
-ResourceType hosts `
-ResourceParentName myHostGroup `
-ResourceParentType hostGroups `
-ProviderName Microsoft.Compute
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-
17c058c2bd25/resourcegroups/TestShantS/providers/Microsoft.Comp
ute/virtualMachines/DXT-test-04-iso/providers/Microsoft.Maintenance/applyUpdates/default
Name : de