Paso 1: Preparar la implementación de Azure

Importante:

Para evitar la pérdida de datos, asegúrese de que la infraestructura que utiliza no elimina automáticamente los discos del clúster al reiniciarlo o apagarlo. Si esta función está activada, asegúrese de desactivarla.

Azure subscription and permissions

La implementación requiere acceso a una suscripción de Azure y un grupo de recursos con el rol RBAC Propietario. El rol de propietario es necesario para crear una identidad administrada asignada por el usuario con el rol de colaborador asignado en el ámbito del grupo de recursos. La identidad administrada es necesaria para gestionar las máquinas virtuales (realizar acciones de escalado ascendente y descendente, aplicar protección de instancias, actualizar el sistema operativo).

Puede comprobar su asignación de roles haciendo lo siguiente:

Grupo de recursos → Control de accesos (IAM) → Comprobar acceso → Ver mi acceso

Cuotas

The deployment provisions a number of Standard_D (general purpose), Standard_F and/or Standard_NC (with GPU) VMs. The Azure subscription has a quota on the number of cores that can be provisioned for the VM family.

Algunas de las máquinas virtuales implementadas deben aprovisionarse con SSD premium y, según la configuración, con Ultra SSD. Asegúrese de que estos SSD estén disponibles y no estén bloqueados por ninguna política.

Usamos grupos elásticos de SQL para implementar las bases de datos. Asegúrate de que los grupos elásticos de SQL no sean bloqueados por ninguna política.

Para comprobar la cuota de suscripción, ve a Uso + cuotas en el portal de Azure.

Nota:

Asegúrese de que su cuota sea suficiente para la implementación de Automation Suite; de lo contrario, la implementación fallará. Solicita un aumento seleccionando Solicitar aumento.

Instance protection

Como parte del proceso de instalación, añadimos protección de instancias de las operaciones de conjunto de escalado a todos los nodos del conjunto de escalas de servidor. Dado que estas operaciones se realizan desde Azure, sin el contexto del servidor, se evita el mal funcionamiento del clúster. Proporcionamos runbooks para las operaciones de gestión de clústeres. Para obtener más información sobre la protección de instancias de conjunto de escalado, consulta la documentación de Azure.

Instance termination

Importante:

Terminating the Server Virtual Machine instances will most likely result in data loss and cause the cluster to crash. Do not attempt terminating the Server Virtual Machine instances.

Proporcionamos soporte para la finalización de instancias de máquinas virtuales de agentes. Esto significa que cuando se termina una instancia de máquina virtual de agente, acordonamos, drenamos y eliminamos ese nodo del clúster de Automation Suite.

Ejecutamos un script en cada instancia de máquina virtual de agente que agrupa el servicio de metadatos de instancia para eventos de terminación. Cada vez que recibimos un evento, activamos un cordón y un comando de drenaje en el nodo respectivo, y un servidor también ejecuta un comando de eliminación de nodo para ese nodo específico.

Hay registros ampliados disponibles para este proceso. Puedes encontrar los registros de cada operación de finalización de nodo en la cuenta de almacenamiento principal de implementación en el contenedor logs . Cada archivo de registro contiene el nombre del nodo y tiene el sufijo -termination.log .

Disponibilidad de la región de la familia de VM

Asegúrese de que las SKU de VM estén disponibles para la región de la implementación.

Puede comprobar la disponibilidad en: Productos de Azure por región.

Cluster certificate configuration

La plantilla de Azure te permite proporcionar certificados para un dominio personalizado que especifiques durante la implementación, de modo que no tengas que hacerlo manualmente después de la implementación. Sin embargo, debes asegurarte de que los certificados .crt estén codificados en Base64 antes de proporcionarlos.

The following script generates the Base64-encoded strings from a single .pfx certificate (server certificate). You can then use these strings when filling in the template parameters. You can run this bash script on a Windows machine using Windows Subsystem for Linux. It uses openssl to convert the certificates. Keep in mind that the server certificate (the .pfx) should meet somerequirements.

Ejecuta los siguientes comandos uno por uno, ya que algunos requieren la contraseña del 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

To connect AI Center to an external Orchestrator, you must set Connect AiCenter to an external Orchestrator to true and provide certificates for Orchestrator and Identity to the parameters listed in Deploying Automation Suite to Azure. For details on how to obtain the certificates, see Chain certificates.

Para codificar los certificados en formato base64, ejecute los siguientes comandos:

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

To register AI Center to the external Orchestrator, you must run the RegisterAiCenterExternalOrchestrator runbook.

Resistencia a fallos de zona en un clúster de producción multinodo preparada para alta disponibilidad

By default, the templates deploy the VMs across as many Azure Availability Zones as possible to enable the resilience to zonal failures in a multi-node HA-ready production cluster.

Nota:

Not all Azure Regions support Availability Zones. See Azure Geograpies for details.

VM SKUs have additional Availability Zones restrictions that you can check using the CLI cmdlet. See Get-AzComputeResourceSku for details.

El clúster se considera resistente a los fallos de zona si los servidores se distribuyen en tres zonas de disponibilidad de Azure. Si la región de Azure no admite zonas de disponibilidad para tipo de VM seleccionada para los servidores, la implementación continuará sin resistencia de zona.

Dns

La plantilla proporciona un equilibrador de carga de Azure con una IP pública y una etiqueta de DNS para acceder a los servicios.

La etiqueta de DNS es propiedad de Microsoft y debe tener un formato similar a: <dnsName>.<regionName>.cloudapp.azure.com.

También implementamos una zona DNS privada, para que los VM del clúster puedan resolver varios subdominios. Esto es necesario para el proceso de instalación. Para resolver registros en una zona DNS privada desde la red virtual, compruebe que el servidor DNS esté establecido en Azure-provided o 168.63.129.16.

If you want to access the cluster over the internet, you can check out Step 3: Post-deployment steps.

Implementar en una red virtual existente

La plantilla permite implementar los nodos en una red virtual existente. Sin embargo, la red virtual debe disponer de una subred que cumpla los siguientes requisitos:

• tiene suficiente espacio de direcciones libre para acomodar todos los nodos y el equilibrador de carga interno
• conectividad saliente, preferiblemente configurada a través de una puerta de enlace NAT según la recomendación de Microsoft
• permite el tráfico HTTPS en el puerto 443
• Optional: has a service endpoint configured for Microsoft.Storage. This is needed if you enable the backup at deployment time.

Al implementar en una red virtual existente, debe tener el rol de RBAC de propietario para crear una asignación de rol de colaborador en su ámbito. Esto es necesario para la operación de actualización de instancia al escalar horizontalmente.

Copia de seguridad

The template allows you to enable the backup at deployment time. This implies creating a Microsoft Storage Account with a variable storage capacity (depending on the number of server nodes - # of server nodes x 512GB) used as an NFS share and configuring the backup for the cluster. By default, the backup interval is set to 90 minutes, and the retention interval is 72 hours. You can change the backup and retention intervals post-deployment. For details, see BackupCluster.