Executar uma máquina virtual do Windows no Azure Stack Hub

  • Artigo

O aprovisionamento de uma máquina virtual (VM) no Azure Stack Hub requer alguns componentes adicionais para além da própria VM, incluindo recursos de rede e armazenamento. Este artigo mostra as melhores práticas para executar uma VM do Windows no Azure.

Arquitetura da VM do Windows no Azure Stack Hub

Grupo de recursos

Um grupo de recursos é um contentor lógico que contém recursos relacionados do Azure Stack Hub. Em geral, agrupe os recursos com base na respetiva duração e quem os irá gerir.

Coloque recursos estreitamente associados que partilhem o mesmo ciclo de vida no mesmo grupo de recursos. Os grupos de recursos permitem-lhe implementar e monitorizar recursos como um grupo e monitorizar os custos de faturação por grupo de recursos. Também pode eliminar recursos como um conjunto, o que é útil para implementações de teste. Atribua nomes significativos aos recursos para simplificar a localização de um recurso específico e compreender a sua função. Para obter mais informações, veja Convenções de Nomenclatura Recomendadas para Recursos do Azure.

Máquina virtual

Pode aprovisionar uma VM a partir de uma lista de imagens publicadas ou de um ficheiro de imagem gerida personalizada ou de disco rígido virtual (VHD) carregado para o armazenamento de Blobs do Azure Stack Hub.

O Azure Stack Hub oferece diferentes tamanhos de máquina virtual do Azure. Para obter mais informações, veja Tamanhos para máquinas virtuais no Azure Stack Hub. Se estiver a mover uma carga de trabalho existente para o Azure Stack Hub, comece pelo tamanho da VM que corresponde à correspondência mais próxima dos servidores no local/Azure. Em seguida, meça o desempenho da carga de trabalho real em termos de operações de CPU, memória e entrada/saída do disco por segundo (IOPS) e ajuste o tamanho conforme necessário.

Discos

O custo tem por base a capacidade do disco aprovisionado. O IOPS e o débito (ou seja, a taxa de transferência de dados) dependem do tamanho da VM, pelo que, quando aprovisiona um disco, considere os três fatores (capacidade, IOPS e débito).

O IOPS de Disco (Operações de Entrada/Saída Por Segundo) no Azure Stack Hub é uma função do tamanho da VM em vez do tipo de disco. Isto significa que, para uma VM de série Standard_Fs, independentemente de escolher SSD ou HDD para o tipo de disco, o limite de IOPS para um único disco de dados adicional é 2300 IOPS. O limite de IOPS imposto é um limite (máximo possível) para evitar vizinhos ruidosos. Não é uma garantia de IOPS que obterá num tamanho de VM específico.

Também recomendamos a utilização de Managed Disks. Os discos geridos simplificam a gestão de discos ao processar o armazenamento automaticamente. Os discos geridos não precisam de uma conta de armazenamento. Basta especificar o tamanho e o tipo de disco e, em seguida, será implementado como um recurso de elevada disponibilidade.

O disco do SO é um VHD armazenado no armazenamento de blobs do Azure Stack Hub, pelo que persiste mesmo quando o computador anfitrião está inativo. Também recomendamos a criação de um ou mais discos de dados, que são VHDs persistentes utilizados para dados da aplicação. Sempre que possível, instale as aplicações num disco de dados e não no disco do SO. Algumas aplicações legadas poderão ter de instalar componentes na unidade C:. Nesse caso, pode redimensionar o disco do SO através do PowerShell.

A VM também é criada com um disco temporário (a unidade D: no Windows). Este disco é armazenado num volume temporário na infraestrutura de armazenamento do Azure Stack Hub. Pode ser eliminado durante reinícios e outros eventos de ciclo de vida da VM. Utilize este disco apenas para dados temporários, tais como ficheiros de paginação ou de troca.

Rede

Os componentes de rede incluem os seguintes recursos:

  • Rede virtual. Cada VM é implementada numa rede virtual que pode ser segmentada em várias sub-redes.

  • Interface de rede (NIC). A NIC permite à VM comunicar com a rede virtual. Se precisar de vários NICs para a VM, tenha em atenção que é definido um número máximo de NICs para cada tamanho de VM.

  • Endereço IP público/VIP. É necessário um endereço IP público para comunicar com a VM, por exemplo, através do ambiente de trabalho remoto (RDP). O endereço IP público pode ser dinâmico ou estático. Por predefinição, é dinâmico.

  • Reserve um endereço IP estático se precisar de um endereço IP fixo que não seja alterado , por exemplo, se precisar de criar um registo DNS "A" ou adicionar o endereço IP a uma lista segura.

  • Também pode criar um nome de domínio completamente qualificado (FQDN) para o endereço IP. Depois, pode registar um registo CNAME no DNS que aponte para o FQDN. Para obter mais informações, veja Criar um nome de domínio completamente qualificado no portal do Azure.

  • Grupo de segurança de rede (NSG). Os NSGs são utilizados para permitir ou negar o tráfego de rede para VMs. Os NSGs podem ser associados a sub-redes ou a instâncias de VM individuais.

Todos os NSGs contêm um conjunto de regras predefinidas, incluindo uma regra que bloqueia todo o tráfego de entrada da Internet. Não é possível eliminar as regras predefinidas, mas estas podem ser substituídas por outras. Para ativar o tráfego da Internet, crie regras que permitam o tráfego de entrada para portas específicas , por exemplo, a porta 80 para HTTP. Para ativar o RDP, adicione uma regra do NSG que permita o tráfego de entrada para a porta TCP 3389.

Operações

Diagnósticos. Ative a monitorização e os diagnósticos, incluindo métricas básicas de estado de funcionamento, registos de infraestrutura de diagnósticos e diagnósticos de arranque. Os diagnósticos de arranque poderão ajudá-lo a diagnosticar falhas no arranque se a VM não estiver no estado de arranque. Crie uma conta de Armazenamento do Azure para armazenar os registos. Para conter os registos de diagnósticos, é suficiente uma conta de armazenamento localmente redundante (LRS) standard. Para obter mais informações, veja Enable monitoring and diagnostics (Ativar a monitorização e os diagnósticos).

Disponibilidade. A VM pode estar sujeita a um reinício devido à manutenção planeada, conforme agendado pelo operador do Azure Stack Hub. Para elevada disponibilidade de um sistema de produção de várias VMs no Azure, as VMs são colocadas num conjunto de disponibilidade que as espalha por vários domínios de falha e atualiza domínios. Na escala mais pequena do Azure Stack Hub, um domínio de falha num conjunto de disponibilidade é definido como um único nó na unidade de escala.

Embora a infraestrutura do Azure Stack Hub já seja resiliente a falhas, a tecnologia subjacente (clustering de ativação pós-falha) ainda implica algum tempo de inatividade para as VMs num servidor físico afetado se existir uma falha de hardware. O Azure Stack Hub suporta ter um conjunto de disponibilidade com um máximo de três domínios de falha para ser consistente com o Azure.

Domínios de falha

As VMs colocadas num conjunto de disponibilidade serão fisicamente isoladas umas das outras ao espalhá-las o mais uniformemente possível sobre vários domínios de falha (nós do Azure Stack Hub). Se ocorrer uma falha de hardware, as VMs do domínio de falha falhada serão reiniciadas noutros domínios de falha. Serão mantidos em domínios de falha separados das outras VMs, mas no mesmo conjunto de disponibilidade, se possível. Quando o hardware voltar a estar online, as VMs serão reequilibradas para manter a elevada disponibilidade.

Domínios de atualização

Os domínios de atualização são outra forma de o Azure fornecer elevada disponibilidade em conjuntos de disponibilidade. Um domínio de atualização é um grupo lógico de hardware subjacente que pode ser submetido a manutenção ao mesmo tempo. As VMs localizadas no mesmo domínio de atualização serão reiniciadas em conjunto durante a manutenção planeada. À medida que os inquilinos criam VMs num conjunto de disponibilidade, a plataforma do Azure distribui automaticamente as VMs por estes domínios de atualização.

No Azure Stack Hub, as VMs são migradas em direto pelos outros anfitriões online no cluster antes de o anfitrião subjacente ser atualizado. Uma vez que não existe tempo de inatividade do inquilino durante uma atualização do anfitrião, a funcionalidade de domínio de atualização no Azure Stack Hub só existe para compatibilidade de modelos com o Azure. As VMs num conjunto de disponibilidade mostrarão 0 como o número de domínio de atualização no portal.

Cópias de segurança Para obter recomendações sobre como proteger as VMs IaaS do Azure Stack Hub, veja Proteger VMs implementadas no Azure Stack Hub.

Parar uma VM. O Azure faz uma distinção entre os estados “parada” e “desalocada”. Se o estado da VM for "parada", será cobrado, mas não se for "desalocada". No portal do Azure Stack Hub, o botão Parar desaloca a VM. Se encerrar com o SO enquanto tiver sessão iniciada, a VM será parada, mas não desalocada, pelo que continuarão a ser cobrado custos.

A eliminar uma VM. Se eliminar uma VM, os discos da VM não serão eliminados. Isto significa que pode eliminar em segurança a VM sem perder dados. No entanto, ainda lhe será cobrado o armazenamento. Para eliminar o disco da VM, elimine o objeto de disco gerido. Para impedir a eliminação acidental, utilize um bloqueio de recursos para bloquear o grupo de recursos inteiro ou bloqueie recursos individuais, como a VM.

Considerações de segurança

Integre as VMs para Centro de Segurança do Azure para obter uma vista central do estado de segurança dos seus recursos do Azure. O Centro de Segurança monitoriza potenciais problemas de segurança e fornece uma visão global do estado de funcionamento da segurança da sua implementação. O Centro de Segurança está configurado por subscrição do Azure. Ative a recolha de dados de segurança conforme descrito em Integrar a sua subscrição do Azure no Security Center Standard. Quando a recolha de dados está ativada, o Centro de Segurança analisa automaticamente todas as VMs criadas nessa subscrição.

Gestão de patches. Para configurar a gestão de patches na VM, veja este artigo. Se estiver ativada, o Centro de Segurança verifica se as atualizações críticas e de segurança estão em falta. Utilize definições da Política de Grupo na VM para ativar as atualizações de sistema automáticas.

Antimalware. Se estiver ativado, o Centro de Segurança verifica se está instalado software antimalware. Também pode utilizar o Centro de Segurança para instalar software antimalware no portal do Azure.

Controlo de acesso. Utilize o controlo de acesso baseado em funções (RBAC) para controlar o acesso aos recursos do Azure. O RBAC permite-lhe atribuir funções de autorização a membros da sua equipa de DevOps. Por exemplo, a Função Leitor pode ver recursos do Azure, mas não criá-los, geri-los nem eliminá-los. Algumas permissões são específicas para um tipo de recurso do Azure. Por exemplo, a função Contribuidor de Máquina Virtual pode reiniciar ou desalocar uma VM, repor a palavra-passe de administrador, criar uma nova VM e assim sucessivamente. Outras funções RBAC incorporadas que podem ser úteis para esta arquitetura incluem Utilizador de DevTest Labs e Contribuidor de Rede.

Nota

O RBAC não limita as ações que os utilizadores que tenham sessão iniciada numa VM podem fazer. Estas permissões são determinadas pelo tipo de conta no SO convidado.

Registos de auditoria. Utilize os registos de atividades para ver as ações de aprovisionamento e outros eventos de VM.

Encriptação de dados. O Azure Stack Hub utiliza a encriptação AES bitLocker de 128 bits para proteger os dados de utilizador e infraestrutura inativos no subsistema de armazenamento. Para obter mais informações, veja Data at rest encryption in Azure Stack Hub (Encriptação de dados inativos no Azure Stack Hub).

Passos seguintes