Aplicación de n niveles en Azure

Blob Storage
DNS
Load Balancer
Virtual Network
Virtual Machines

Esta arquitectura de referencia muestra cómo implementar máquinas virtuales (VM) y una red virtual configurada para una aplicación de n niveles, con SQL Server en Windows para la capa de datos. Implemente esta solución.

Arquitectura de n niveles con Microsoft Azure

Descargue un archivo Visio de esta arquitectura.

Architecture

La arquitectura tiene los siguientes componentes.

General

  • Grupo de recursos. Los grupos de recursos se utilizan para agrupar los recursos de Azure con el fin de que puedan administrarse según su duración, su propietario u otros criterios.

  • Zonas de disponibilidad. Las zonas de disponibilidad son ubicaciones físicas dentro de una región de Azure. Cada zona consta de uno o varios centros de datos con alimentación, refrigeración y redes independientes. Si se colocan las máquinas virtuales a través de zonas, la aplicación se vuelve resistente a los errores dentro de una zona.

Redes y equilibrio de carga

  • Red virtual y subredes. Todas las máquinas virtuales se implementan en una red virtual que se puede dividir en subredes. Cree una subred independiente para cada nivel.

  • Application Gateway. Application Gateway es un equilibrador de carga de nivel 7. En esta arquitectura, enruta las solicitudes HTTP al front-end web. Application Gateway proporciona también un firewall de aplicaciones web (WAF) que protege la aplicación contra puntos vulnerables de la seguridad comunes.

  • Equilibradores de carga. Use Azure Standard Load Balancer para distribuir el tráfico de red desde el nivel web al nivel de empresa y desde el nivel de empresa a SQL Server.

  • Grupos de seguridad de red (NSG). Use NSG para restringir el tráfico de red dentro de la red virtual. Por ejemplo, en la arquitectura de tres niveles que se muestra aquí, el nivel de base de datos no acepta el tráfico procedente del front-end web, solo el procedente del nivel de empresa y la subred de administración.

  • Protección contra DDoS. Aunque la plataforma de Azure proporciona protección básica contra ataques de denegación de servicio distribuido (DDoS), se recomienda usar el estándar de protección contra DDoS, que tiene características de mitigación de DDoS. Consulte Consideraciones sobre la seguridad.

  • Azure DNS. Azure DNS es un servicio de hospedaje para dominios DNS. Proporciona resolución de nombres mediante la infraestructura de Microsoft Azure. Al hospedar dominios en Azure, puede administrar los registros DNS con las mismas credenciales, API, herramientas y facturación que con los demás servicios de Azure.

Máquinas virtuales

  • Grupo de disponibilidad AlwaysOn de SQL Server Proporciona alta disponibilidad en el nivel de datos, al habilitar la replicación y la conmutación por error. Usa la tecnología de clúster de conmutación por error de Windows Server (WSFC) para la conmutación por error.

  • Servidores de Active Directory Domain Services (AD DS) . Los objetos de equipo del clúster de conmutación por error y sus roles en clúster asociados se crean en Active Directory Domain Services (AD DS).

  • Testigo en la nube. Un clúster de conmutación por error requiere que más de la mitad de sus nodos se estén ejecutando, lo que se conoce como tener cuórum. Si el clúster tiene solo dos nodos, una partición de la red podría provocar que cada uno de ellos creyera que es el principal. En ese caso, se necesita un testigo que sea quien dilucide cuál es el principal y establezca el cuórum. Un testigo es un recurso, como por ejemplo un disco compartido, que puede actuar como dilucidador para establecer el cuórum. Un testigo en la nube es un tipo de testigo que usa Azure Blob Storage. Para más información acerca del concepto de quórum, consulte Understanding cluster and pool quorum (Descripción del cuórum de clúster y de grupo). Para más información acerca del testigo en la nube, consulte Implementación de un testigo en la nube en un clúster de conmutación por error.

  • JumpBox. También se denomina host bastión. Tradicionalmente, se trata de una máquina virtual segura en la red que usan los administradores para conectarse al resto de máquinas virtuales. El JumpBox tiene un NSG que solo permite el tráfico remoto que procede de direcciones IP públicas de una lista segura. El NSG debe permitir el tráfico de Protocolo de escritorio remoto (RDP). Azure ofrece la solución administrada de Azure Bastion para satisfacer esta necesidad.

Recomendaciones

Los requisitos pueden diferir de los de la arquitectura que se describe aquí. Use estas recomendaciones como punto de partida.

Máquinas virtuales

Para recomendaciones sobre cómo configurar las máquinas virtuales, consulte Ejecución de una máquina virtual Windows en Azure.

Virtual network

Cuando cree la red virtual, determine cuántas direcciones IP requieren los recursos de cada subred. Especifique una máscara de subred y un intervalo de direcciones de la red lo suficientemente grande para la dirección IP requerida con el uso de la notación CIDR. Use un espacio de direcciones que se encuentre dentro de los bloques de direcciones IP privados estándar, que son 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16.

Elija un intervalo de direcciones que no se superponga con la red local, en caso de que necesite configurar una puerta de enlace entre la red virtual y la red local más adelante. Una vez creada la red virtual, no se puede cambiar el intervalo de direcciones.

Diseñe subredes teniendo en cuenta los requisitos de funcionalidad y seguridad. Todas las máquinas virtuales dentro del mismo nivel o rol deben incluirse en la misma subred, lo que puede servir como un límite de seguridad. Para más información sobre cómo diseñar las redes virtuales y las subredes, consulte Planeamiento y diseño de Azure Virtual Networks.

Application Gateway

Para obtener más información sobre la configuración de Application Gateway, consulte Introducción a la configuración de Application Gateway.

Equilibradores de carga

No exponga las máquinas virtuales directamente a Internet; en su lugar, asigne una dirección IP privada a cada una. Los clientes se conectan mediante la dirección IP pública asociada a Application Gateway.

Defina reglas del equilibrador de carga para dirigir el tráfico de red a las máquinas virtuales. Por ejemplo, para habilitar el tráfico HTTP, asigne el puerto 80 de la configuración de front-end al puerto 80 del grupo de direcciones de back-end. Cuando un cliente envía una solicitud HTTP al puerto 80, el equilibrador de carga selecciona una dirección IP de back-end mediante un algoritmo hash que incluye la dirección IP de origen. Las solicitudes del cliente se distribuyen entre todas las máquinas virtuales del grupo de direcciones de back-end.

Grupos de seguridad de red

Use reglas NSG para restringir el tráfico entre los niveles. En la arquitectura de tres niveles mostrada anteriormente, el nivel web no se comunica directamente con el nivel de base de datos. Para aplicar esta regla, el nivel de base de datos debe bloquear el tráfico entrante desde la subred del nivel Web.

  1. Deniegue todo el tráfico entrante de la red virtual. (Use la etiqueta VIRTUAL_NETWORK de la regla).
  2. Permita el tráfico entrante de la subred del nivel Business.
  3. Permita el tráfico entrante de la propia subred del nivel de la base de datos. Esta regla permite la comunicación entre las máquinas virtuales de la base de datos, lo cual es necesario para la replicación y la conmutación por error de esta.
  4. Permita el tráfico RDP (puerto 3389) desde la subred de JumpBox. Esta regla permite a los administradores conectarse al nivel de base de datos desde JumpBox.

Cree las reglas 2 – 4 con una prioridad más alta que la primera regla para que puedan invalidarla.

Grupos de disponibilidad AlwaysOn de SQL Server

Se recomiendan los grupos de disponibilidad AlwaysOn para alta disponibilidad de SQL Server. Antes de Windows Server 2016, los grupos de disponibilidad AlwaysOn requerían un controlador de dominio y todos los nodos del grupo de disponibilidad debían estar en el mismo dominio de AD.

Otros niveles se conectan a la base de datos a través de una escucha de grupo de disponibilidad. La escucha permite a un cliente SQL conectarse sin conocer el nombre de la instancia física de SQL Server. Las máquinas virtuales que acceden a la base de datos deben estar unidas al dominio. El cliente (en este caso, otro nivel) utiliza DNS para resolver el nombre de la red virtual de la escucha en direcciones IP.

Configure el grupo de disponibilidad AlwaysOn de SQL Server como sigue:

  1. Cree un clúster de clústeres de conmutación por error de Windows Server (WSFC), un grupo de disponibilidad AlwaysOn de SQL Server y una réplica principal. Para más información, consulte Introducción a Grupos de disponibilidad AlwaysOn.

  2. Cree un equilibrador de carga interno con una dirección IP privada estática.

  3. Cree una escucha de grupo de disponibilidad y asigne el nombre DNS de la escucha a la dirección IP del equilibrador de carga interno.

  4. Cree una regla del equilibrador de carga para el puerto de escucha de SQL Server (puerto TCP 1433 de forma predeterminada). La regla del equilibrador de carga debe habilitar la IP flotante, también denominada Direct Server Return. Esto causa que la máquina virtual responda directamente al cliente, lo que permite establecer una conexión directa con la réplica principal.

    Nota

    Cuando la IP flotante está habilitada, el número de puerto de front-end debe ser el mismo que el número de puerto de back-end en la regla del equilibrador de carga.

Cuando un cliente SQL intenta conectarse, el equilibrador de carga enruta la solicitud de conexión a la réplica principal. Si se produce una conmutación por error a otra réplica, el equilibrador de carga enruta automáticamente las nuevas solicitudes a una nueva réplica principal. Para más información, consulte Configuración de un equilibrador de carga para Grupos de disponibilidad AlwaysOn de SQL Server.

Durante una conmutación por error, se cierran las conexiones de cliente existentes. Una vez completada la conmutación por error, las conexiones nuevas se enrutarán a la nueva réplica principal.

Si la aplicación realiza significativamente más lecturas que escrituras, puede descargar algunas de las consultas de solo lectura en una réplica secundaria. Consulte Usar un agente de escucha para conectarse a una réplica secundaria de solo lectura (enrutamiento de solo lectura).

Para probar la implementación, fuerce una conmutación por error manual del grupo de disponibilidad.

JumpBox

Al ejecutar máquinas virtuales en una red virtual privada, como en esta arquitectura, es necesario acceder a las máquinas virtuales para la instalación de software, la aplicación de revisiones, etc. Sin embargo, hacer que estas máquina puedan acceder a la red pública de Internet no es una buena idea porque aumenta considerablemente la superficie de ataque. En su lugar, se usa un JumpBox como capa de acceso intermedio.

Anteriormente, una máquina virtual administrada por el cliente podría usarse como JumpBox. En ese escenario, se aplican las siguientes recomendaciones:

  • No permita el acceso mediante RDP desde la red pública de Internet a las máquinas virtuales que ejecutan la carga de trabajo de la aplicación. En su lugar, todo el acceso RDP a estas máquinas virtuales se debe realizar a través de JumpBox. Un administrador inicia sesión en JumpBox y, después, en la otra máquina virtual desde JumpBox. JumpBox permite el tráfico RDP desde Internet, pero solo desde direcciones IP conocidas y seguras.
  • JumpBox tiene unos requisitos de rendimiento mínimos, por lo que puede seleccionar un pequeño tamaño de máquina virtual. Cree una dirección IP pública para JumpBox. Coloque JumpBox en la misma red virtual que las demás máquinas virtuales, pero en una subred de administración independiente.
  • Para proteger JumpBox, agregue una regla de grupo de seguridad de red que permita las conexiones RDP solo desde un conjunto seguro de direcciones IP públicas. Configure el NSG para las demás subredes, a fin de permitir el tráfico RDP de la subred de administración.

En el caso de una máquina virtual administrada por el cliente, se aplican todas estas reglas. Sin embargo, la recomendación actual es usar Azure Bastion, una solución de JumpBox administrada que permite el acceso HTML5 a RDP o SSH detrás de protección de Azure AD. Se trata de una solución mucho más sencilla que, en última instancia, tiene un costo total de propiedad (TCO) menor para el cliente.

Consideraciones sobre escalabilidad

Conjuntos de escalado

Para los niveles web y de empresa, considere la posibilidad de usar conjuntos de escalado de máquinas virtuales, en lugar de implementar máquinas virtuales independientes. Los conjuntos de escalado facilitan la implementación y administración de un conjunto de máquinas virtuales idénticas y el escalado automático de dichas máquinas en función de sus métricas de rendimiento. A medida que aumenta la carga en las máquinas virtuales, se agregan más máquinas virtuales automáticamente al equilibrador de carga. Considere la posibilidad de usar conjuntos de escalado si necesita escalar horizontalmente las máquinas virtuales de inmediato o si necesita realizar el escalado automático.

Hay dos maneras básicas de configurar máquinas virtuales implementadas en un conjunto de escalado:

  • Use extensiones para configurar la máquina virtual después de implementarla. Con este método, las nuevas instancias de máquina virtual pueden tardar más en iniciarse que una máquina virtual sin extensiones.

  • Implemente un disco administrado con una imagen de disco personalizada. Esta opción puede ser más rápida de implementar. Sin embargo, requiere que la imagen esté actualizada.

Para más información, consulte Consideraciones de diseño para conjuntos de escalado.

Sugerencia

Cuando utilice cualquier solución de escalado automático, pruébela con antelación con cargas de trabajo de nivel de producción.

Límites de suscripción

Cada suscripción de Azure tiene límites predeterminados establecidos, incluido un número máximo de máquinas virtuales por región. Puede aumentar el límite si rellena una solicitud de soporte técnico. Para más información, consulte Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

Application Gateway

Application Gateway admite el modo de capacidad fija o el modo de escalado automático. El modo de capacidad fija es útil para escenarios con cargas de trabajo coherentes y predecibles. Considere la posibilidad de usar el modo de escalado automático para cargas de trabajo con tráfico variable. Para obtener más información, consulte Escalabilidad automática y Application Gateway v2 con redundancia de zona.

Consideraciones sobre disponibilidad

Las zonas de disponibilidad proporcionan la mejor resistencia dentro de una sola región. Si necesita incluso más disponibilidad, considere la replicación de la aplicación entre dos regiones y use Azure Traffic Manager para la conmutación por error. Para más información, consulte Aplicación de n niveles para varias regiones para obtener alta disponibilidad.

No todas las regiones admiten zonas de disponibilidad y no todos los tamaños de máquina virtual se admiten en todas las zonas. Ejecute el siguiente comando de la CLI de Azure para buscar las zonas admitidas para cada tamaño de máquina virtual dentro de una región:

az vm list-skus --resource-type virtualMachines --zone false --location <location> \
    --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table

Si implementa esta arquitectura en una región que no admite zonas de disponibilidad, coloque las máquinas virtuales para cada nivel dentro de un conjunto de disponibilidad. Las máquinas virtuales del mismo conjunto de disponibilidad se implementan en varios servidores físicos, grupos de proceso, unidades de almacenamiento y conmutadores de red para la redundancia. Los conjuntos de escalado usan automáticamente grupos de selección de ubicación, que actúan como un conjunto de disponibilidad implícito.

Al realizar implementaciones en zonas de disponibilidad, use la SKU estándar de Azure Load Balancer y la SKU v2 de Application Gateway. Estas SKU admiten la redundancia entre zonas. Para más información, consulte:

Una sola implementación de Application Gateway puede ejecutar varias instancias de la puerta de enlace. En el caso de cargas de trabajo de producción, ejecute al menos dos instancias.

Sondeos de estado

Application Gateway y Load Balancer usan sondeos de mantenimiento para supervisar la disponibilidad de las instancias de máquina virtual.

  • Application Gateway siempre usa un sondeo HTTP.
  • Load Balancer puede probar HTTP o TCP. Por lo general, si una máquina virtual ejecuta un servidor HTTP, use un sondeo HTTP. De lo contrario, use TCP.

Si un sondeo no puede acceder a una instancia dentro del período de tiempo de expiración, la puerta de enlace o el equilibrador de carga deja de enviar tráfico a esa máquina virtual. El sondeo continúa realizando comprobaciones y devolverá la máquina virtual al grupo de back-end si la máquina virtual vuelve a estar disponible.

Los sondeos HTTP envían una solicitud GET HTTP a una ruta de acceso determinada y escuchan una respuesta HTTP 200. Puede ser la ruta de acceso raíz ("/") o un punto de conexión de supervisión de mantenimiento que implementa alguna lógica personalizada para comprobar el mantenimiento de la aplicación. El punto de conexión debe permitir solicitudes HTTP anónimas.

Para más información sobre los sondeos de estado, consulte:

Para conocer las consideraciones sobre el diseño de un punto de conexión de sondeo de estado, consulte Patrón Health Endpoint Monitoring.

Consideraciones sobre el costo

Puede usar la calculadora de precios de Azure para calcular los costos. Estas son algunas otras consideraciones.

Conjuntos de escalado de máquinas virtuales

Los conjuntos de escalado de máquinas virtuales están disponibles en todos los tamaños de máquina virtual Windows. Solo se le cobrará por las máquinas virtuales de Azure que implemente y por los recursos de infraestructura subyacente adicionales que haya consumido, como el almacenamiento y las redes. No hay cargos incrementales por el servicio de conjuntos de escalado de máquinas virtuales.

Para las opciones de precios de las máquinas virtuales únicas, consulte Precios de máquinas virtuales con Windows.

Servidor SQL

Si elige Azure SQL DB, puede ahorrar costos porque no es necesario configurar un grupo de disponibilidad Always On y equipos de controlador de dominio. Hay varias opciones de implementación, desde una base de datos única hasta una instancia administrada o grupo elástico. Para más información, consulte Precios de Azure SQL.

Para ver las opciones de precios de las máquinas virtuales de SQL Server, consulte Precios de máquinas virtuales SQL.

Equilibradores de carga

Se le cobrará solo el número de reglas de equilibrio de carga y de salida configuradas. Las reglas NAT de entrada son gratuitas. Cuando se configuran reglas, no se cobra por hora la instancia de Standard Load Balancer.

Para más información, consulte la sección acerca de los costos del artículo sobre elmarco de buena arquitectura de Microsoft Azure.

Consideraciones sobre la seguridad

Las redes virtuales son un límite de aislamiento del tráfico de Azure. De manera predeterminada, las máquinas virtuales de una red virtual no se pueden comunicar directamente con las máquinas virtuales de otra red virtual. Sin embargo, puede conectar explícitamente las redes virtuales mediante el emparejamiento de red virtual.

NSG. Use los grupos de seguridad de red para restringir el tráfico desde y hacia Internet. Para más información, consulte Servicios en la nube de Microsoft y seguridad de red.

DMZ. Considere la posibilidad de agregar una aplicación virtual de red (NVA) para crear una red perimetral entre la red de Internet y la red virtual de Azure. NVA es un término genérico para una aplicación virtual que puede realizar tareas relacionadas con la red, como firewall, inspección de paquetes, auditoría y enrutamiento personalizado. Para más información, consulte Implementación de una red perimetral entre Internet y Azure.

Cifrado. Cifre los datos confidenciales en reposo y use Azure Key Vault para administrar las claves de cifrado de la base de datos. Key Vault puede almacenar las claves de cifrado en módulos de seguridad de hardware (HSM). Para más información, consulte Configuración de la integración de Azure Key Vault para SQL Server en máquinas virtuales de Azure. También se recomienda almacenar los secretos de aplicación como, por ejemplo, las cadenas de conexión de base de datos, en Key Vault.

DDoS Protection. De forma predeterminada, la plataforma Azure proporciona protección básica contra DDoS. El objetivo de dicha es proteger la infraestructura de Azure en su conjunto. Aunque la protección básica contra DDoS se habilita automáticamente, se recomienda usar DDoS Protection Estándar. Para detectar las amenazas, la protección estándar usa un ajuste que se puede adaptar en función de los patrones de tráfico de red de la aplicación, lo que le permite aplicar mitigaciones frente a ataques de denegación de servicio distribuido que podrían pasar desapercibidas para las directivas de DDoS para toda la infraestructura. La protección estándar también proporciona alertas, telemetría y análisis a través de Azure Monitor. Para más información, consulte Azure DDoS Protection: procedimientos recomendados y arquitecturas de referencia.

Consideraciones sobre DevOps

En esta arquitectura, se usan [plantillas de bloques de creación de Azure] [azbb-template] para aprovisionar los recursos de Azure y sus dependencias. Puesto que todos los recursos y sus dependencias se encuentran en la misma red virtual, están aislados en la misma carga de trabajo básica, lo que facilita la asociación de los recursos específicos de la carga de trabajo a un equipo, para que el equipo pueda administrar de forma independiente todos los aspectos de esos recursos. Este aislamiento permite que DevOps realice la integración continua y la entrega continua (CI/CD).

Además, puede usar distintas plantillas de implementación e integrarlas con Azure DevOps Services para aprovisionar entornos diferentes en minutos; por ejemplo, para replicar escenarios similares a la producción o entornos de prueba de carga solo cuando sea necesario y ahorrar costos.

En este escenario, las máquinas virtuales se configuran mediante el uso de extensiones de máquina virtual, ya que ofrecen la posibilidad de instalar cierto software adicional, como los agentes de protección contra malware y de seguridad. Las extensiones de máquina virtual se instalan y ejecutan solo en el momento de creación de la máquina virtual. Esto significa que, si el sistema operativo se configura incorrectamente en una etapa posterior, requerirá una intervención manual para devolverlo a su estado correcto.

En esta arquitectura, se usan herramientas de administración de configuración, en particular, Desired State Configuration (DSC), para configurar Active Directory y un grupo de disponibilidad Always On de SQL Server.

Considere la posibilidad de usar Azure Monitor para analizar y optimizar el rendimiento de la infraestructura, así como supervisar y diagnosticar problemas de red sin iniciar sesión en las máquinas virtuales. Application Insights es en realidad uno de los componentes de Azure Monitor, que proporciona métricas y registros completos para comprobar el estado de todo el entorno de Azure. Azure Monitor le ayudará a realizar un seguimiento del estado de la infraestructura.

Asegúrese de supervisar no solo los elementos de proceso que admiten el código de aplicación, sino también la plataforma de datos (en particular las bases de datos), ya que un bajo rendimiento de la capa de datos de una aplicación podría tener consecuencias graves.

Para probar el entorno de Azure en el que se ejecutan las aplicaciones, debe realizar un control de versiones e implementarse a través de los mismos mecanismos que el código de la aplicación. Después, se puede probar y validar mediante los paradigmas de prueba de DevOps.

Para más información, consulte la sección de Excelencia operativa en Marco de buena arquitectura de Azure.

Implementación de la solución

Hay disponible una implementación de esta arquitectura de referencia en GitHub. La implementación completa puede tardar un máximo de una hora, lo que incluye la ejecución de los scripts para configurar AD DS, el clúster de conmutación por error de Windows Server y el grupo de disponibilidad de SQL Server.

Si especifica una región que admite zonas de disponibilidad, las máquinas virtuales se implementan en zonas de disponibilidad. De lo contrario, las máquinas virtuales se implementan en conjuntos de disponibilidad. Para una lista de las regiones que admiten zonas de disponibilidad, consulte Compatibilidad de servicios por región.

Requisitos previos

  1. Clone, bifurque o descargue el archivo zip del repositorio de GitHub de arquitecturas de referencia.

  2. Instale la CLI de Azure 2.0.

  3. Instale Node y NPM.

  4. Instale el paquete de npm de bloques de creación de Azure.

    npm install -g @mspnp/azure-building-blocks
    
  5. Desde un símbolo del sistema, un símbolo del sistema de Bash o un símbolo del sistema de PowerShell, inicie sesión en su cuenta de Azure como se indica a continuación:

    az login
    

Pasos de implementación

  1. Vaya a la carpeta virtual-machines\n-tier-windows del repositorio de GitHub de las arquitecturas de referencia.

  2. Abra el archivo n-tier-windows.json .

  3. En el archivo n-tier-windows.json, busque todas las instancias de [replace-with-password] y [replace-with-safe-mode-password], y reemplácelas por una contraseña segura. Guarde el archivo.

    Nota

    Si cambia el nombre de usuario del administrador, también debe actualizar los bloques extensions en el archivo JSON.

  4. Ejecute el siguiente comando para implementar la arquitectura.

    azbb -s <your subscription_id> -g <resource_group_name> -l <location> -p n-tier-windows.json --deploy
    
  5. Una vez finalizada la implementación, abra Azure Portal y navegue hasta el grupo de recursos. Busque la cuenta de almacenamiento que comienza por "sqlcw". Se trata de una cuenta de almacenamiento que se usará para el testigo en la nube del clúster. Navegue hasta la cuenta de almacenamiento, seleccione Claves de acceso y copie el valor de key1. Copie también el nombre de la cuenta de almacenamiento.

  6. Abra el archivo n-tier-windows-sqlao.json .

  7. En el archivo n-tier-windows-sqlao.json, busque todas las instancias de [replace-with-password] y [replace-with-sql-password], y reemplácelas por una contraseña segura.

    Nota

    Si cambia el nombre de usuario del administrador, también debe actualizar los bloques extensions en el archivo JSON.

  8. En el archivo n-tier-windows-sqlao.json, busque todas las instancias de [replace-with-storageaccountname] y [replace-with-storagekey], y reemplácelas por los valores del paso 5. Guarde el archivo.

  9. Ejecute el comando siguiente para configurar Always On de SQL Server.

    azbb -s <your subscription_id> -g <resource_group_name> -l <location> -p n-tier-windows-sqlao.json --deploy
    

Pasos siguientes