Etapa 1: preparando a implantação do Azure

Importante: para evitar a perda de dados, certifique-se de que a infraestrutura que você usa não exclua automaticamente discos de clusters na reinicialização ou desligamento do cluster. Se essa capacidade estiver habilitada, certifique-se desabilitá-la.

Azure subscription and permissions

A implantação requer acesso a uma assinatura do Azure e um grupo de recursos com a função RBAC de Proprietário. A função Proprietário é necessária para criar uma Identidade Gerenciada atribuída pelo usuário com a função Contribuidor atribuída no escopo do Grupo de Recursos. A Identidade gerenciada é necessária para gerenciar as VMs (executar ações de escalabilidade e escalabilidade, aplicar proteção de instância, atualizar o sistema operacional).

Você pode verificar sua atribuição de função da seguinte maneira:

Grupo de recursos → Controle de acesso (IAM) → Verificar acesso → Exibir meu acesso

Cotas

A implantação provisiona um número de VMs Standard_D (uso geral), Standard_E e/ou Standard_NC (com GPU). A assinatura do Azure tem uma cota no número de núcleos que podem ser provisionados para a família da VM.

Verifique a cota de assinatura acessando Uso + cotas no portal do Azure.

Observação: certifique-se de que sua cota seja suficiente para a implantação do Automation Suite; caso contrário, a implantação falhará. Solicite um aumento clicando em Solicitar aumento.

Instance protection

Como parte do processo de instalação, adicionamos a proteção de instância de operações de conjunto de escala a todos os nós do Conjunto de escalas de servidor. Como essas operações são realizadas a partir do Azure, sem o contexto do servidor, o mau funcionamento do cluster é evitado. Fornecemos runbooks para operações de gerenciamento de cluster. Para obter mais sobre a Proteção de instância de conjunto de escala, consulte a documentação do Azure.

Instance termination

Importante: encerrar as instâncias da máquina virtual do servidor provavelmente resultará em perda de dados e fará com que o cluster falhe. Não tente encerrar as instâncias da máquina virtual do servidor.

Fornecemos suporte de encerramento de instância para instâncias de máquina virtual de agente. Isso significa que, quando uma instância de máquina virtual do agente é encerrada, nós isolamos, drenamos e excluímos esse nó do cluster do Automation Suite.

Executamos um script em cada Instância de Máquina Virtual de Agente que agrupa o Serviço de Metadados de Instância para eventos de Rescisão. Sempre que recebemos um evento, disparamos um comando de isolamento e drenagem no respectivo nó, e um servidor também executa um comando de exclusão de nó para esse nó específico.

Logs estendidos estão disponíveis para este processo. Você pode encontrar os logs para cada operação de encerramento de nó na conta de armazenamento principal de implantação no contêiner logs . Cada arquivo de log contém o nome do nó e possui o sufixo -termination.log .

Disponibilidade de região da família de VMs

Certifique-se de que as SKUs da VM estejam disponíveis para a região na qual você vai implantar.

Você pode verificar a disponibilidade em: Produtos do Azure por região.

Configuração de Certificados

O modelo do Azure permite que você forneça certificados para um domínio personalizado que você especifica durante a implantação para que você não precise fazer manualmente essa pós-implantação. No entanto, você precisa garantir que os certificados .crt sejam codificados em Base64 antes de fornecê-los.

O script a seguir gera as strings codificadas em Base64 de um único certificado .pfx (certificado do servidor). Você pode usar essas strings ao preencher os parâmetros do modelo. Você pode executar este script bash em uma máquina Windows usando o Windows Subsystem for Linux. Ele usa openssl para converter os certificados. Lembre-se de que o certificado do servidor (o .pfx) deve atender a alguns [requisitos(doc:multi-node-configuring-the-certificates#server-certificate-requirements).

Execute os seguintes comandos, um por um, pois alguns exigem a senha do certificado .pfx :

pfxFile=<path of the pfx file>

# Key
openssl pkcs12 -in $pfxFile -nocerts -out serverCertKeyEncrypted.key
openssl rsa -in serverCertKeyEncrypted.key -out serverCertKeyDecrypted.key

# Server cert
openssl x509 -in $pfxFile -clcerts -nokeys -out serverCert.crt

# CA Bundle:
openssl pkcs12 -in $pfxFile  -cacerts -nokeys -chain | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > caBundle.crt

# Converting to base64 and removing newlines
cat serverCertKeyDecrypted.key | base64 | tr -d '\n' > base64CertKey
cat serverCert.crt | base64 | tr -d '\n' > base64Cert
cat caBundle.crt | base64 | tr -d '\n' > base64CABundle

Resiliência a falhas zonais em um cluster de produção pronto para alta disponibilidade de vários nós

Por padrão, os modelos implantam as VMs em todas as Zonas de Disponibilidade do Azure possíveis para habilitar a resiliência a falhas zonais em um cluster de produção pronto para alta disponibilidade de vários nós.

Observação:

Nem todas as regiões do Azure suportam as Zonas de Disponibilidade. Consulte Geografias do Azure para obter mais detalhes.

Os SKUs da VM tem restrições adicionais de Zonas de Disponibilidade que você pode verificar usando a CLI cmdlet. Consulte Get-AzComputeResourceSku para obter mais detalhes.

O cluster é considerado resiliente a falhas zonais se os servidores estiverem espalhados em três Zonas de Disponibilidade do Azure. Se a região do Azure não for compatível com Zonas de Disponibilidade para o tipo de VM selecionado para os servidores, a implantação continuará sem a resiliência de zona.

Dns

O modelo provisiona um Balanceador de carga do Azure com um IP público e um rótulo de DNS para acessar os serviços.

O rótulo de DNS é de propriedade da Microsoft e deve ter um formato semelhante a: <dnsName>.<regionName>.cloudapp.azure.com.

Também implantamos uma zona de DNS privada, pemitindo que as VMs do cluster possam resolver diversos subdomínios. Isso é necessário para o processo de instalação. Para resolver registros em uma zona de DNS privada da rede virtual, certifique-se de que o servidor de DNS esteja definido como Azure-provided ou 168.63.129.16.

Se quiser acessar o cluster pela internet, você pode verificar a Etapa 3: Etapas pós-implantação.

Implantação em uma rede virtual existente

O modelo permite que você implante os nós em uma rede virtual existente. No entanto, a rede virtual deve ter uma sub-rede que atenda aos seguintes requisitos:

• tem espaço de endereço livre suficiente para acomodar todos os nós e o balanceador de carga interno;
• conectividade de saída; de preferência configurada por meio de um gateway NAT de acordo com a recomendação da Microsoft;
• permite tráfego de HTTPS na porta 443;
• Opcional: tem um terminal de serviço configurado para Microsoft.Storage. Isso é necessário se você ativar o backup no momento da implantação.

Ao implantar em uma rede virtual existente, você deve ter a função Proprietário RBAC nela para criar uma atribuição de função Colaborador em seu escopo. Isso é necessário para a operação de Atualização de Instância durante a expansão.

Backup

O modelo permite que você habilite o backup no momento da implantação. Isso implica criar uma Conta de Armazenamento da Microsoft com uma capacidade de armazenamento 10TiB usada como um compartilhamento NFS e configurar o backup para o cluster. O intervalo de backup é definido como 12 horas para corresponder à frequência de backup do Banco de Dados SQL do Azure.