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 Proprietário. A função Proprietário é necessária para criar uma Identidade Gerenciada atribuída pelo usuário com a função Colaborador atribuída no escopo do Grupo de Recursos. A identidade gerenciada é necessária para gerenciar as VMs (executar ações de expansão e expansão, 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 várias VMs Standard_D (uso geral), Standard_F 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 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 proteção de instância de operações do conjunto de dimensionamento a todos os nós do conjunto de dimensionamento do servidor. Como essas operações são executadas no Azure, sem o contexto do servidor, o mau funcionamento do cluster é evitado. Fornecemos runbooks para operações de gerenciamento de cluster. Para saber mais sobre 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 do agente que está agrupando o serviço de metadados da instância para eventos de encerramento. Sempre que recebemos um evento, acionamos um cordão e um comando de 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.

Cluster certificate configuration

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 a partir de um único certificado .pfx (certificado do servidor). Você pode usar essas strings ao preencher os parâmetros do modelo. Você pode executar esse script de bash em uma máquina Windows usando o Subsistema do Windows para Linux. Ele usa openssl para converter os certificados. Lembre-se de que o certificado do servidor (o .pfx) deve atender a algunsrequisitos.

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 pkcs12 -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

External Orchestrator certificates

Para conectar o AI Center a um Orchestrator externo, você deve definir Connect AiCenter to an external Orchestrator como true e fornecer certificados para o Orchestrator e o Identity para os parâmetros listados em Implantação do Automation Suite no Azure. Para obter detalhes sobre como obter os certificados, consulte Certificados em cadeia.

Para codificar os certificados no formato base64, execute os seguintes comandos:

cat orchestrator.cer | base64 | tr -d '\n' > orchestratorCert
cat identity.cer | base64 | tr -d '\n' > identityCert

Para registrar o AI Center no Orchestrator externo, você deve executar o runbook RegisterAiCenterExternalOrchestrator.

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; preferencialmente configurado através de um gateway NAT conforme 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 variável (dependendo do número de nós do servidor - # of server nodes x 512GiB) usada como um compartilhamento NFS e configurando o backup para o cluster. O intervalo de backup é definido como 45 minutos.