Estrategias de desarrollo y patrones de aplicación para SQL Server en Azure Virtual Machines

Se aplica a:SQL Server en VM de Azure

Nota:

Azure tiene dos modelos de implementación diferentes para crear recursos y trabajar con ellos: Resource Manager y el clásico. En este artículo se trata el uso de ambos modelos, pero Microsoft recomienda que la mayoría de las nuevas implementaciones usen el modelo del Administrador de recursos.

Información general

La determinación de qué patrón, o patrones, de aplicación se deben usar para las aplicaciones basadas en SQL Server en un entorno de Azure es una decisión de diseño importante y requiere una comprensión perfecta de cómo funciona SQL Server con cada uno de los componentes de la infraestructura de Azure. Con SQL Server en los servicios de infraestructura de Azure, es posible migrar, mantener y supervisar fácilmente las aplicaciones existentes de SQL Server compiladas en Windows Server en máquinas virtuales de Azure.

El objetivo de este artículo es proporcionar a los desarrolladores y arquitectos de soluciones una base para la buena arquitectura y diseño de aplicaciones, que pueden seguir al migrar las aplicaciones existentes a Azure, así como al desarrollar nuevas aplicaciones en Azure.

Para cada patrón de aplicación, encontrará un escenario local, su respectiva solución habilitada para la nube y las recomendaciones técnicas relacionadas. Además, el artículo describe estrategias de desarrollo específicas de Azure para que pueda diseñar sus aplicaciones correctamente. Dada la gran cantidad de patrones de aplicación posibles, se recomienda que los arquitectos y desarrolladores elijan el más apropiado para sus aplicaciones y usuarios.

Colaboradores técnicos: Luis Carlos Vargas Herring y Madhan Arumugam Ramakrishnan

Revisores técnicos: Corey Sanders, Drew McDaniel, Narayan Annamalai, Nir Mashkowski, Sanjay Mishra, Silvano Coriani, Stefan Schackow, Tim Hickey, Tim Wieman y Xin Jin

Introducción

Puede desarrollar muchos tipos de aplicaciones de n niveles. Para ello, es preciso separar los componentes de las diferentes capas de aplicación en equipos distintos, así como en componentes independientes. Por ejemplo, puede colocar la aplicación cliente y los componentes de las reglas de negocios en una máquina, el nivel de front-end web y el nivel de acceso a datos en otra máquina y un nivel de base de datos back-end en otra máquina. Este tipo de estructura ayuda a aislar cada nivel del resto. Si cambia el lugar de procedencia de los datos, no es preciso cambiar la aplicación web o cliente, solo los componentes del nivel de acceso a datos.

Las aplicaciones de n niveles típicas incluyen el nivel de presentación, el nivel de empresa y el nivel de datos:

Nivel	Descripción
Presentación	El nivel de presentación (nivel de web y nivel de front-end) es la capa en la que los usuarios interactúan con las aplicaciones.
Business	El nivel de empresa (nivel intermedio) es la capa que el nivel de presentación y el nivel de datos usan para comunicarse entre sí e incluye la funcionalidad principal del sistema.
Data	Básicamente, el nivel de datos es el servidor que almacena los datos de una aplicación (por ejemplo, un servidor que ejecuta SQL Server).

Las capas de aplicación describen las agrupaciones lógicas de la funcionalidad y componentes de una aplicación; mientras que los niveles describen la distribución física de los componentes y funcionalidad en servidores físicos, equipos, redes o ubicaciones remotas independientes. Las capas de una aplicación pueden residir en el mismo equipo físico (el mismo nivel) o pueden estar distribuidas en equipos independientes (n niveles), y los componentes de cada capa se comunican con los de las restantes capas a través de interfaces bien definidas. El término nivel hace referencia a los patrones de distribución física, como dos niveles, tres niveles y n niveles. Un patrón de aplicación de dos niveles contiene dos niveles de aplicación: servidor de aplicaciones y servidor de bases de datos. La comunicación directa se produce entre el servidor de aplicaciones y el servidor de bases de datos. El servidor de aplicaciones contiene componentes del nivel de web y del nivel de empresa. En el patrón de aplicación de tres niveles, hay tres niveles de aplicación: servidor web, servidor de aplicaciones, que contiene el nivel de lógica empresarial y los componentes de acceso a datos del nivel de empresa, y servidor de base de datos. La comunicación entre el servidor web y el servidor de bases de datos se produce sobre el servidor de aplicaciones. Para obtener información detallada sobre los niveles y las capas de aplicación, consulte la guía de arquitectura de aplicaciones de Microsoft.

Antes de empezar a leer este artículo, debe tener conocimientos sobre los conceptos básicos de SQL Server y Azure. Para obtener más información, consulte Libros en pantalla de SQL Server, SQL Server en Azure Virtual Machines y Azure.com.

Este artículo describe varios patrones de aplicación que pueden ser apropiados tanto para aplicaciones sencillas como para aplicaciones empresariales de gran complejidad. Antes entrar en el detalle de cada patrón, es aconsejable que se familiarice con los servicios de almacenamiento de datos disponibles en Azure, como Azure Storage, Azure SQL Database y SQL Server en una máquina virtual de Azure. Para tomar las mejores decisiones de diseño para sus aplicaciones, es preciso que sepa a la perfección cuándo usar cada uno de los servicios de almacenamiento de datos.

Elija SQL Server en Azure Virtual Machines cuando:

• Necesite control sobre SQL Server y Windows. Por ejemplo, aquí se podrían incluir la versión de SQL Server, las revisiones especiales, la configuración del rendimiento, etc.

• Necesite compatibilidad total con SQL Server y quiera migrar las aplicaciones existentes a Azure tal y como están.

• Desee aprovechar las funcionalidades del entorno de Azure, pero Azure SQL Database no admite todas las características que requiere la aplicación. Esto puede incluir las siguientes áreas:

  • Tamaño de base de datos: en el momento en que se actualizó este artículo, SQL Database admitía bases de datos de hasta 1 TB de datos. Si la aplicación requiere más de 1 TB de datos y no desea implementar soluciones de particionamiento personalizadas, se recomienda usar SQL Server en una máquina virtual de Azure. Para ver la información más reciente, consulte Scaling Out Azure SQL Database (Escalado horizontal de bases de datos de Azure SQL Database), este artículo sobre el modelo de compra basado en DTU y este artículo sobre el modelo de compra basado en núcleo virtual (versión preliminar).
  • Cumplimiento de normas HIPAA: los clientes del sector sanitario y los fabricantes de software independientes (ISV) pueden elegir SQL Server en Azure Virtual Machines, en lugar de Azure SQL Database, porque el primero está cubierto por el contrato de asociación comercial (BAA) para HIPAA. Para información sobre el cumplimiento, consulte Centro de confianza de Microsoft Azure: conformidad.
  • Características de nivel de instancia: actualmente, SQL Database no admite las características que se encuentran fuera de la base de datos (por ejemplo, servidores vinculados, trabajos de agente, FileStream, Service Broker, etc.). Para más información, consulte Instrucciones y limitaciones de Azure SQL Database.

Un nivel (simple): una sola máquina virtual

En este patrón de aplicación, se implementa la aplicación y la base de datos de SQL Server en una máquina virtual de independiente de Azure. La misma máquina virtual contiene la aplicación web/cliente, los componentes empresariales, la capa de acceso a datos y el servidor de bases de datos. La presentación, la empresa y el código de acceso a los datos están separados lógicamente, pero están ubicados físicamente en un servidor individual. La mayoría de los clientes comienzan con este patrón de aplicación y, a continuación, lo escalan horizontalmente mediante la adición de más roles web o máquinas virtuales a su sistema.

Este patrón de aplicación resulta útil cuando:

• Desee realizar una migración sencilla a la plataforma Azure para evaluar si la plataforma responde a los requisitos de la aplicación.
• Desee mantener todos los niveles de aplicación hospedados en la misma máquina virtual del mismo centro de datos de Azure para reducir la latencia entre niveles.
• Desee aprovisionar rápidamente entornos de prueba y desarrollo durante periodos breves.
• Desee realizar varias pruebas de esfuerzo con cargas de trabajo distintas, pero al mismo tiempo no se desea poseer y mantener muchas máquinas físicas continuamente.

El siguiente diagrama muestra un escenario local sencillo y cómo puede implementar su solución habilitada para la nube en una sola máquina virtual de Azure.

Implementación de la capa de empresa (lógica de negocios y componentes de acceso a datos) en el mismo nivel físico que la capa de presentación puede maximizar el rendimiento de la aplicación, a menos deba usar un nivel independiente por problemas de escalabilidad o seguridad.

Dado que es un patrón muy común con el que empezar, puede que el siguiente artículo sobre la migración le resulte útil para mover los datos a la VM de SQL Server: Guía de migración: de SQL Server a SQL Server en Azure Virtual Machines.

Tres niveles (simple): varias máquinas virtuales

En este patrón de aplicación, se implementa una aplicación de nivel 3 en Azure, para lo que debe colocar cada nivel de aplicación en una máquina virtual distinta. Esto proporciona un entorno flexible para escenarios fáciles de escalado vertical y horizontal. Cuando una máquina virtual contiene la aplicación web/cliente, la otra aloja los componentes empresariales y la tercera hospeda el servidor de bases de datos.

Este patrón de aplicación resulta útil cuando:

• Desee realizar una migración de aplicaciones de base de datos complejas a Azure Virtual Machines.
• Desee hospedar distintos niveles de aplicación en diferentes regiones. Por ejemplo, puede haber compartido bases de datos que se implementan en varias regiones con fines informativos.
• Desee mover aplicaciones empresariales de plataformas virtualizadas locales a Azure Virtual Machines. Para obtener información detallada sobre las aplicaciones empresariales, consulte qué es una aplicación empresarial.
• Desee aprovisionar rápidamente entornos de prueba y desarrollo durante periodos breves.
• Desee realizar varias pruebas de esfuerzo con cargas de trabajo distintas, pero al mismo tiempo no se desea poseer y mantener muchas máquinas físicas continuamente.

El diagrama siguiente muestra cómo se puede colocar una sencilla aplicación de tres niveles en Azure colocando cada capa de aplicación en una máquina virtual distinta.

En este patrón de aplicación, hay solo una máquina virtual en cada nivel. Si tiene varias máquinas virtuales en Azure, se recomienda configurar una red virtual. Azure Virtual Network crea un límite de seguridad de confianza y también permite que las máquinas virtuales se comuniquen entre sí a través de la dirección IP privada. Además, asegúrese siempre de que todas las conexiones de Internet solo van al nivel de presentación. Al seguir este patrón de aplicación, administre las reglas del grupo de seguridad de red para controlar el acceso. Para más información, consulte Permitir el acceso a la máquina virtual mediante Azure Portal.

En el diagrama, los protocolos de Internet puede ser TCP, UDP, HTTP o HTTPS.

Nota:

La configuración de una red virtual en Azure es gratuita. Sin embargo, se cobrará la puerta de enlace de VPN que se conecta a local. Este cargo se basa en la cantidad de tiempo en que la conexión esté aprovisionada y disponible.

Dos niveles y tres niveles con escalado horizontal del nivel de presentación

En este patrón de aplicación, se implementa una aplicación de base de datos de dos o tres niveles en Azure Virtual Machines, y cada nivel de la aplicación se coloca en una máquina virtual distinta. Además, el escalado horizontal del nivel de presentación se debe a un aumento de las solicitudes entrantes del cliente.

Este patrón de aplicación resulta útil cuando:

• Desee mover aplicaciones empresariales de plataformas virtualizadas locales a Azure Virtual Machines.
• Desee escalar horizontalmente el nivel de presentación debido a un aumento de las solicitudes entrantes del cliente.
• Desee aprovisionar rápidamente entornos de prueba y desarrollo durante periodos breves.
• Desee realizar varias pruebas de esfuerzo con cargas de trabajo distintas, pero al mismo tiempo no se desea poseer y mantener muchas máquinas físicas continuamente.
• Desee poseer un entorno de infraestructuras que se pueda escalar o reducir verticalmente a petición.

El diagrama siguiente muestra cómo se pueden colocar las capas de aplicación en varias máquinas virtuales de Azure mediante el escalado horizontal del nivel de presentación debido al mayor volumen de solicitudes entrantes del cliente. Como muestra el diagrama, el Equilibrador de carga de Azure es el responsable de distribuir el tráfico entre las distintas máquinas virtuales, así como de determinar el servidor web al que se va a realizar la conexión. La existencia de varias instancias en los servidores web detrás de un equilibrador de carga garantiza la alta disponibilidad del nivel de presentación.

Prácticas recomendadas para patrones de dos, tres o n niveles que tienen varias máquinas virtuales en un solo nivel

Se recomienda colocar las máquinas virtuales que pertenecen al mismo nivel en el mismo servicio en la nube y en el mismo conjunto de disponibilidad. Por ejemplo, coloque un conjunto de servidores web en CloudService1 y AvailabilitySet1 y un conjunto de servidores de bases de datos en CloudService2 y AvailabilitySet2. Un conjunto de disponibilidad de Azure le permite colocar los nodos de alta disponibilidad en dominios de error independientes y dominios de actualización.

Para sacar provecho de varias instancias de máquina virtual de un nivel, es preciso configurar el Equilibrador de carga de Azure entre los niveles de la aplicación. Para configurarlo en cada nivel, cree un extremo de carga equilibrada en las máquinas virtuales de cada uno de los niveles por separado. En el caso de un nivel concreto, cree primero las máquinas virtuales en el mismo servicio en la nube. De esta forma, se asegurará de que tengan la misma dirección IP virtual pública. A continuación, cree un extremo en una de las máquinas virtuales de dicho nivel. Seguidamente, asigne el mismo extremo a las demás máquinas virtuales de ese nivel para equilibrar la carga. Al crear un conjunto de carga equilibrada, el tráfico se distribuye entre varias máquinas virtuales y también se permite que el Equilibrador de carga determine qué nodo se debe conectar cuando se produzca un error en un nodo de la máquina virtual de back-end. Por ejemplo, la existencia de varias instancias en los servidores web detrás de un equilibrador de carga garantiza la alta disponibilidad del nivel de presentación.

Un procedimiento recomendado es asegurarse siempre de que todas las conexiones a Internet van primero al nivel de presentación. La capa de presentación obtiene acceso al nivel de empresa y, a continuación, éste accede al nivel de datos. Para obtener más información sobre cómo permitir el acceso a la capa de presentación, vea Habilitación del acceso externo a la máquina virtual mediante el Azure Portal.

Tenga en cuenta que en Azure el Equilibrador de carga funciona de manera similar a los equilibradores de carga de un entorno local. Para obtener más información, consulte Equilibrio de carga para servicios de infraestructura de Azure.

Además, se recomienda configurar una red privada para las máquinas virtuales mediante Azure Virtual Network. Esto les permite comunicarse entre sí a través de la dirección IP privada. Para obtener más información, consulte Información general sobre redes virtuales.

Dos niveles y tres niveles con escalado horizontal del nivel de empresa

En este patrón de aplicación, se implementa una aplicación de base de datos de dos o tres niveles en Azure Virtual Machines, y cada nivel de la aplicación se coloca en una máquina virtual distinta. Además, puede distribuir los componentes del servidor de aplicaciones en varias máquinas virtuales debido a la complejidad de la aplicación.

Este patrón de aplicación resulta útil cuando:

• Desee mover aplicaciones empresariales de plataformas virtualizadas locales a Azure Virtual Machines.
• Desee distribuir los componentes del servidor de aplicaciones en varias máquinas virtuales debido a la complejidad de la aplicación.
• Desee mover aplicaciones de LOB (línea de negocio) locales pesadas de lógica de negocios a Azure Virtual Machines. Las aplicaciones de LOB son un conjunto de aplicaciones informáticas críticas que son vitales para el funcionamiento de una empresa, como la contabilidad, los recursos humanos (HR), las nóminas, la administración de la cadena de suministro y las aplicaciones de planeación de recursos.
• Desee aprovisionar rápidamente entornos de prueba y desarrollo durante periodos breves.
• Desee realizar varias pruebas de esfuerzo con cargas de trabajo distintas, pero al mismo tiempo no se desea poseer y mantener muchas máquinas físicas continuamente.
• Desee poseer un entorno de infraestructuras que se pueda escalar o reducir verticalmente a petición.

El siguiente diagrama muestra un escenario local y su solución con la nube habilitada. En este escenario, coloque los niveles de aplicación en varias máquinas virtuales en Azure mediante el escalado horizontal del nivel de empresa, que contiene el nivel de lógica de negocios y los componentes de acceso a datos. Como muestra el diagrama, el Equilibrador de carga de Azure es el responsable de distribuir el tráfico entre las distintas máquinas virtuales, así como de determinar el servidor web al que se va a realizar la conexión. La existencia de varias instancias en los servidores de aplicaciones detrás de un equilibrador de carga garantiza la alta disponibilidad del nivel de empresa. Para obtener más información, consulte Prácticas recomendadas para patrones de dos, tres o n niveles que tienen varias máquinas virtuales en un solo nivel.

2 niveles y 3 niveles con escalabilidad horizontal de los niveles de presentación y de empresa, y HADR

En este patrón de aplicación, se implementa la aplicación de base de datos de dos o tres niveles en Azure Virtual Machines mediante la distribución de los componentes del nivel de presentación (servidor web) y del nivel de empresa (servidor de aplicaciones) en varias máquinas virtuales. Además, implementa soluciones de alta disponibilidad y recuperación ante desastres (HADR) para las bases de datos en Azure Virtual Machines.

Este patrón de aplicación resulta útil cuando:

• Desee mover aplicaciones empresariales de plataformas virtualizadas locales a Azure mediante la implementación de las capacidades de recuperación ante desastres y alta disponibilidad de SQL Server.
• Desee escalar horizontalmente el nivel de presentación y el nivel de empresa debido al aumento del volumen de solicitudes de cliente entrantes y a la complejidad de la aplicación.
• Desee aprovisionar rápidamente entornos de prueba y desarrollo durante periodos breves.
• Desee realizar varias pruebas de esfuerzo con cargas de trabajo distintas, pero al mismo tiempo no se desea poseer y mantener muchas máquinas físicas continuamente.
• Desee poseer un entorno de infraestructuras que se pueda escalar o reducir verticalmente a petición.

El siguiente diagrama muestra un escenario local y su solución con la nube habilitada. En este escenario, escale horizontalmente los componentes del nivel de presentación y del nivel de empresa en varias máquinas virtuales en Azure. Además, implemente técnicas de recuperación ante desastres y alta disponibilidad (HADR) para bases de datos de SQL Server en Azure.

Mediante la ejecución de varias copias de una aplicación en distintas máquinas virtuales asegúrese de que equilibra automáticamente la carga de solicitudes entre ellas. Cuando tenga varias máquinas virtuales, tiene que asegurarse de que se puede obtener acceso a todas ellas y que se ejecutan en un momento específico. Si configura el equilibrio de carga, Azure Load Balancer realiza un seguimiento del mantenimiento de las máquinas virtuales y dirige correctamente las llamadas entrantes a los nodos de VM correctos que funcionen. Para obtener información acerca de cómo configurar el equilibrio de carga de las máquinas virtuales, consulte Equilibrio de carga para servicios de infraestructura de Azure. La existencia de varias instancias en los servidores web y de aplicaciones detrás de un equilibrador de carga garantiza la alta disponibilidad de los niveles de presentación y de empresa.

Prácticas recomendadas para patrones de aplicación que requieren HADR de SQL

Al configurar las soluciones de alta disponibilidad y recuperación ante desastres de SQL Server en Azure Virtual Machines, es obligatorio configurar una red virtual para las máquinas virtuales mediante Azure Virtual Network. Las máquinas virtuales de una red virtual tienen una dirección IP privada estable incluso después de un tiempo de inactividad del servicio, por lo que puede evitar el tiempo de actualización necesario para la resolución de nombres DNS. Además, la red virtual le permite ampliar la red local a Azure y crea un límite de seguridad de confianza. Por ejemplo, si la aplicación tiene restricciones de dominio corporativo (como autenticación de Windows o Active Directory), es preciso configurar Azure Virtual Network.

La mayoría de los clientes, que ejecutan código de producción en Azure, conservan las replicas principal y secundaria en Azure.

Para obtener información completa y tutoriales sobre las técnicas de alta disponibilidad y recuperación ante desastres, consulte Alta disponibilidad y recuperación ante desastres para SQL Server en Azure Virtual Machines.

Dos y tres niveles con Azure Virtual Machines y Cloud Services

En este patrón de aplicación, se implementa una aplicación de dos o tres niveles en Azure mediante Azure Cloud Services (roles web y de trabajo: plataforma como servicio (PaaS)) y Azure Virtual Machines (infraestructura como servicio (IaaS)). El uso de Azure Cloud Services para los niveles de presentación y de empresa, y SQL Server en Azure Virtual Machines para el nivel de datos, es beneficioso para la mayoría de las aplicaciones que se ejecutan en Azure. El motivo es que el hecho de que una instancia de proceso se ejecute en Cloud Services facilita la administración, implementación, supervisión y escalado horizontal.

Con Cloud Services, Azure mantiene automáticamente la infraestructura, realiza un mantenimiento periódico, aplica parches a los sistemas operativos e intenta recuperarse de los errores de hardware y del servicio. Cuando la aplicación necesita escalado horizontal, hay disponibles opciones de escalado horizontal manual y automático para el proyecto del servicio en la nube mediante el aumento o disminución del número de instancias o máquinas virtuales que se usa la aplicación. Además, se puede usar Visual Studio local para implementar la aplicación en un proyecto de servicio en la nube en Azure.

En resumen, si no desea tener numerosas tareas administrativas para el nivel de presentación o empresa, y la aplicación no requiere una configuración compleja del software o del sistema operativo, use Azure Cloud Services. Si Azure SQL Database no admite todas las características que busca, use SQL Server en una máquina virtual de Azure para el nivel de datos. La ejecución de una aplicación en Azure Cloud Services y el almacenamiento de datos en Azure Virtual Machines combina las ventajas de ambos servicios. Para obtener una comparación detallada, consulte la sección de este tema Comparación de las estrategias de desarrollo de Azure.

En este patrón de aplicación, el nivel de presentación incluye un rol web, que es un componente de Cloud Services que se ejecuta en el entorno de ejecución de Azure y se personaliza para la programación de aplicaciones web que admiten IIS y ASP.NET. El nivel de empresa o back-end incluye un rol de trabajo, que es un componente de Cloud Services que se ejecuta en el entorno de ejecución de Azure y es útil para el desarrollo generalizado, y puede realizar un procesamiento en segundo plano en un rol web. El nivel de base de datos reside en una máquina virtual de SQL Server en Azure. La comunicación entre el nivel de presentación y el nivel de base de datos se establece directamente o a través de los componentes del nivel de empresa: rol de trabajo.

Este patrón de aplicación resulta útil cuando:

• Desee mover aplicaciones empresariales de plataformas virtualizadas locales a Azure mediante la implementación de las capacidades de recuperación ante desastres y alta disponibilidad de SQL Server.
• Desee poseer un entorno de infraestructuras que se pueda escalar o reducir verticalmente a petición.
• Azure SQL Database no admite todas las características que necesitan la aplicación o la base de datos.
• Desee realizar varias pruebas de esfuerzo con cargas de trabajo distintas, pero al mismo tiempo no se desea poseer y mantener muchas máquinas físicas continuamente.

El siguiente diagrama muestra un escenario local y su solución con la nube habilitada. En este escenario, el nivel de presentación se coloca en los roles web, el nivel de empresa en los roles de trabajo y el nivel de datos en máquinas virtuales de Azure. La ejecución de varias copias de la capa de presentación en distintos roles web garantiza el equilibro de carga de las solicitudes entre ellas. Al combinar Azure Cloud Services con Azure Virtual Machines, es aconsejable configurar también Azure Virtual Network. Con Azure Virtual Network puede tener direcciones IP privadas estables y persistentes dentro del mismo servicio en la nube. Una vez que se define una red virtual para las máquinas virtuales y los servicios en la nube, pueden empezar a comunicarse entre sí a través de la dirección IP privada. Además, tener máquinas virtuales y roles de web y trabajo de Azure en la misma Azure Virtual Network proporciona una conectividad más segura y baja latencia. Para obtener más información, consulte Cálculo de las opciones de hospedaje proporcionadas por Azure.

Como muestra el diagrama, el Equilibrador de carga de Azure distribuye el tráfico entre varias máquinas virtuales y determina el servidor web o el servidor de aplicaciones al que se realiza la conexión. La existencia de varias instancias en los servidores web y de aplicaciones detrás de un equilibrador de carga garantiza la alta disponibilidad de los niveles de presentación y de empresa. Para obtener más información, consulte Prácticas recomendadas para patrones de aplicación que requieren HADR de SQL.

Otro enfoque para implementar este patrón de aplicación es usar un rol web consolidado que contenga componentes tanto del nivel de presentación como del nivel de empresa, como se muestra en el siguiente diagrama. Este patrón de aplicación es útil para aplicaciones que requieren diseño con estado. Puesto que Azure proporciona nodos de proceso sin estado en los roles web y de trabajo, se recomienda implementar una lógica para almacenar el estado de la sesión mediante una de las siguientes tecnologías: Azure Caching, Azure Table Storage o Azure SQL Database.

Patrón con Azure Virtual Machines, Azure SQL Database y Azure App Service (Web Apps)

El objetivo principal de este patrón de aplicación es mostrarle cómo combinar los componentes de infraestructura como servicio (IaaS) de Azure con los componentes de plataforma como servicio (PaaS) de Azure en una solución. Este patrón se centra en Azure SQL Database para el almacenamiento de datos relacionales. No incluye SQL Server en una máquina virtual de Azure, que forma parte de la infraestructura de Azure como oferta de servicio.

En este patrón de aplicación, se implementa una aplicación de base de datos en Azure mediante la colocación de los niveles de presentación y de empresa en la misma máquina virtual y la obtención de acceso a una base de datos en los servidores de Azure SQL Database (SQL Database). El nivel de presentación mediante se puede implementar con soluciones web tradicionales basadas en IIS. O bien se puede implementar un nivel combinado de presentación y de empresa con Azure App Service.

Este patrón de aplicación resulta útil cuando:

• Ya se dispone de un servidor de SQL Database configurado en Azure y se desea probar la aplicación rápidamente.
• Desee probar las capacidades del entorno de Azure.
• Desee aprovisionar rápidamente entornos de prueba y desarrollo durante periodos breves.
• Los componentes de acceso a datos y lógica de negocios pueden ser independientes dentro de una aplicación web.

El siguiente diagrama muestra un escenario local y su solución con la nube habilitada. En este escenario, los niveles de aplicación se colocan en una única máquina virtual en Azure y se accede a los datos en Azure SQL Database.

Si elige implementar un nivel de aplicación y web combinado mediante el uso de Azure Web Apps, se recomienda que mantenga el nivel intermedio o nivel de aplicación como bibliotecas de vínculos dinámicos (DLL) en el contexto de una aplicación web.

Además, para obtener más información acerca de las técnicas de programación, consulte las recomendaciones que se proporcionan en la sección Comparación de las estrategias de desarrollo web de Azure , que encontrará al final de este artículo.

Patrón de aplicación híbrido de n niveles

En el patrón de aplicación híbrido de n niveles, la aplicación se implementa en varios niveles distribuidos entre local y Azure. Por lo tanto, se crea un sistema híbrido flexible y reusable, que se puede modificar o en el que se puede agregar un nivel específico sin cambiar los demás. Para expandir la red corporativa a la nube, se usa el servicio Azure Virtual Network.

Este patrón de aplicación híbrido resulta útil cuando:

• Desee crear aplicaciones que se ejecuten parcialmente en la nube y parcialmente en local.
• Desee migrar algunos los elementos de una aplicación local existente, o todos ellos, a la nube.
• Desee mover aplicaciones empresariales de plataformas virtualizadas locales a Azure.
• Desee poseer un entorno de infraestructuras que se pueda escalar o reducir verticalmente a petición.
• Desee aprovisionar rápidamente entornos de prueba y desarrollo durante periodos breves.
• Desee realizar copias de seguridad de una forma rentable de las aplicaciones de base de datos empresariales.

El siguiente diagrama muestra un patrón de aplicación híbrido de n niveles que abarca la instalación local y Azure. Como se muestra en el diagrama, la infraestructura local incluye un controlador de dominio de Active Directory Domain Services que permite realizar la autenticación y autorización de usuarios. Tenga en cuenta que el diagrama muestra un escenario en el que algunas partes del nivel de datos se encuentran en un centro de datos local, mientras otras se encuentran en Azure. En función de las necesidades de la aplicación, puede implementar otros escenarios híbridos. Por ejemplo, puede mantener el nivel de presentación y el nivel de empresa en un entorno local y el nivel de datos en Azure.

En Azure, puede usar Microsoft Entra ID (anteriormente llamado Azure Active Directory) para la administración de identidades y acceso, o bien puede integrar una Active Directory local existente con el de Microsoft Entra ID. Como se muestra en el diagrama, los componentes del nivel de empresa pueden autenticar a varios orígenes de datos, includos SQL Server en máquinas virtuales de Azure a través de una dirección IP interna privada, a SQL Server local a través de Azure Virtual Network o a Azure SQL Database con las tecnologías de proveedor de datos .NET Framework. En este diagrama, Azure SQL Database es un servicio de almacenamiento de datos opcional.

En el patrón de aplicación híbrido de n niveles, se puede implementar el siguiente flujo de trabajo en el orden especificado:

1. Identifique las aplicaciones de base de datos de empresa que deben moverse a la nube, para lo que debe usar Microsoft Assessment and Planning (MAP) Toolkit. MAP Toolkit recopila datos de rendimiento y de inventario de los equipos que está considerando para la virtualización y ofrece recomendaciones sobre la capacidad y el planeamiento de la evaluación.

2. Planee los recursos y la configuración necesarios en la plataforma Azure, como cuentas de almacenamiento y máquinas virtuales.

3. Configure la conectividad de red entre la red corporativa local y Azure Virtual Network. Para configurar la conexión entre la red corporativa local y una máquina virtual de Azure, use uno de los dos métodos siguientes:

   1. Establezca una conexión entre local y Azure a través de extremos públicos en una máquina virtual de Azure. Este método ofrece una configuración sencilla y permite usar autenticación de SQL Server en la máquina virtual. Además, configure las reglas del grupo de seguridad de red para controlar el tráfico público a la VM. Para más información, consulte Permitir el acceso a la máquina virtual mediante Azure Portal.

   2. Establezca una conexión entre local y Azure a través de un túnel de la red privada virtual (VPN) de Azure. Este método permite extender las directivas del dominio a una máquina virtual de Azure. Además, puede configurar las reglas del firewall y usar la autenticación de Windows en la máquina virtual. En la actualidad, Azure admite VPN segura de sitio a sitio y conexiones VPN de punto a sitio:

      • Con una conexión segura de sitio a sitio puede establecer conectividad de red entre una red local y una red virtual de Azure. Se recomienda para conectar un entorno de centro de datos local a Azure.
      • Con una conexión segura de punto a sitio puede establecer conectividad de red entre una red virtual de Azure y los equipos individuales, independientemente de dónde se encuentren. Se recomienda principalmente para desarrollo y pruebas.

      Para información sobre cómo conectarse a SQL Server en Azure, consulte Conexión a una máquina virtual de SQL Server en Azure.

4. Configure las alertas y trabajos programados que realizan las copias de seguridad de los datos locales en un disco de una máquina virtual de Azure. Para obtener más información, consulte Copia de seguridad y restauración de SQL Server con Azure Blob Storage y Copia de seguridad y restauración de SQL Server en VM de Azure.

5. Según las necesidades de la aplicación, puede implementar uno de los tres escenarios comunes siguientes:

   1. Puede mantener el servidor web, el servidor de aplicaciones e información no confidencial en un servidor de bases de datos de Azure, pero mantener la información confidencial de forma local.
   2. Puede mantener el servidor web y el servidor de aplicaciones de forma local, pero el servidor de bases de datos en una máquina virtual de Azure.
   3. Puede mantener el servidor de bases de datos, el servidor web y el servidor de aplicaciones de forma local, pero las réplicas de las bases de datos en una máquina virtual de Azure. Esta configuración permite a los servidores de web o a las aplicaciones de informes locales obtener acceso a las réplicas de las bases de datos de Azure. Por consiguiente, se puede conseguir reducir la carga de trabajo de una base de datos local. Se recomienda implementar este escenario tanto para cargas de trabajo en que se realiza mucha lectura como para fines de desarrollo. Para obtener información sobre la creación de réplicas de bases de datos en Azure, consulte la información sobre los grupos de disponibilidad Always On en Alta disponibilidad y recuperación ante desastres para SQL Server en Azure Virtual Machines.

Comparación de las estrategias de desarrollo web de Azure

Para implementar y distribuir en Azure una aplicación de niveles múltiples basada en SQL Server, puede usar uno de los dos métodos de programación siguientes:

• Configurar un servidor web tradicional (IIS - Internet Information Services) en Azure y acceder a las bases de datos de SQL Server en Azure Virtual Machines.
• Implementar un servicio en la nube en Azure. Después, asegúrese de que este servicio en la nube puede acceder a las bases de datos de SQL Server en Azure Virtual Machines. Los servicios en la nube pueden incluir varios roles web y de trabajo.

La tabla siguiente proporciona una comparación entre el desarrollo web tradicional con Azure Cloud Services y Azure Web Apps por una parte y SQL Server en Azure Virtual Machines por otra. La tabla incluye Azure Web Apps, ya que SQL Server se puede usar en una máquina virtual de Azure como origen de datos de Azure Web Apps a través de su dirección IP virtual pública o su nombre DNS.

	Desarrollo web tradicional en Azure Virtual Machines	Servicios en la nube en Azure	Hospedaje web con Azure Web Apps
Migración de aplicaciones desde el entorno local	Las aplicaciones existentes tal cual.	Las aplicaciones necesitan roles web y de trabajo.	Las aplicaciones existentes tal cual, pero adecuadas para aplicaciones web independientes y servicios web que requieren una escalabilidad rápida.
Desarrollo e implementación	Visual Studio, WebMatrix, Visual Web Developer, Web Deploy, FTP, TFS, Administrador de IIS y PowerShell.	Visual Studio, SDK de Azure, TFS y PowerShell. Cada servicio en la nube tiene dos entornos en los que se pueden implementar el paquete y la configuración del servicio: almacenamiento provisional y producción. Puede implementar un servicio en la nube en el entorno de ensayo para probarlo antes de pasar a producción.	Visual Studio, WebMatrix, Visual Web Developer, FTP, GIT, BitBucket, CodePlex, DropBox, GitHub, Mercurial, TFS, Web Deploy y PowerShell.
Administración y configuración	El usuario es el responsable de las tareas administrativas de la aplicación, los datos, las reglas del firewall, la red virtual y el sistema operativo.	El usuario es el responsable de las tareas administrativas de la aplicación, los datos, las reglas del firewall y la red virtual.	El usuario es el responsable solo de las tareas administrativas de la aplicación y los datos.
Alta disponibilidad y recuperación ante desastres (HADR)	Se recomienda colocar las máquinas virtuales en el mismo conjunto de disponibilidad y en el mismo servicio en la nube. El hecho de mantener las máquinas virtuales en el mismo conjunto de disponibilidad permite a Azure colocar los nodos de alta disponibilidad en dominios de error independientes y dominios de actualización. Del mismo modo, mantener las máquinas virtuales en el mismo servicio en la nube permite el equilibrio de carga y las máquinas virtuales pueden comunicarse directamente entre sí a través de la red local de un centro de datos de Azure. El usuario es el responsable de implementar una solución de alta disponibilidad y recuperación ante desastres para SQL Server en Azure Virtual Machines con el fin de evitar que haya tiempos de inactividad. Para conocer las tecnologías compatibles con HADR, consulte Alta disponibilidad y recuperación ante desastres para SQL Server en Azure Virtual Machines. Usted es el responsable de la copia de seguridad de sus propios datos y la aplicación. Azure puede mover las máquinas virtuales si se produce un error en el equipo host del centro de datos debido a problemas de hardware. Además, podría haber un tiempo de inactividad planeado de la máquina virtual cuando el equipo host se actualiza por motivos de seguridad o para realizar actualizaciones del software. Por lo tanto, se recomienda mantener al menos dos máquinas virtuales en cada nivel de aplicación para garantizar la disponibilidad continua. Azure no proporciona SLA para máquinas virtuales individuales.	Azure administra los errores debidos al hardware subyacente o al software del sistema operativo. Para garantizar la alta disponibilidad de la aplicación, se recomienda implementar varias instancias de un rol web o de trabajo. Para más información, consulte el artículo sobre el contrato de nivel de servicio de Cloud Services, Virtual Machines, y Virtual Network. Usted es el responsable de la copia de seguridad de sus propios datos y la aplicación. En el caso de las bases de datos que residen en una base de datos de SQL Server de una máquina virtual de Azure, el usuario es el responsable de implementar una solución de alta disponibilidad y recuperación ante desastres para evitar los tiempos de inactividad. Para conocer las tecnologías HDAR compatibles, consulte Alta disponibilidad y recuperación ante desastres para SQL Server en Azure Virtual Machines. Creación de reflejo de la base de datos de SQL Server: uso con Azure Cloud Services (roles web y de trabajo). Las máquinas virtuales de SQL Server y un proyecto de servicio en la nube pueden estar en la misma instancia de Azure Virtual Network. Si la máquina virtuales de SQL Server no está en la misma red virtual, necesitará crear un alias de SQL Server para enrutar la comunicación a la instancia de SQL Server. Además, el nombre de alias debe coincidir con el nombre de SQL Server.	La alta disponibilidad se hereda de los roles de trabajo de Azure, de Azure Blob Storage y de Azure SQL Database. Por ejemplo, Azure Storage mantiene tres réplicas de todos los datos de los blobs, tablas y cola. En cualquier momento, Azure SQL Database mantiene tres réplicas de los datos en ejecución (una réplica principal y dos réplicas secundarias). Para más información, consulte Azure Storage y Azure SQL Database. Al usar SQL Server en una máquina virtual de Azure como origen de datos para Azure Web Apps, tenga en cuenta que Azure Web Apps no es compatible con Azure Virtual Network. En otras palabras, todas las conexiones de Azure Web Apps a máquinas virtuales de SQL Server en Azure deben atravesar los extremos públicos de máquinas virtuales. Esto puede provocar algunas limitaciones en escenarios de alta disponibilidad y recuperación ante desastres. Por ejemplo, la aplicación de cliente de Azure Web Apps que se conecta a VM de SQL Server con la creación de reflejo de base de datos no podría conectarse al nuevo servidor principal, ya que la creación de reflejo de base de datos requiere que se configure Azure Virtual Network entre máquinas virtuales host de SQL Server en Azure. Por tanto, el uso de la creación de reflejo de la base de datos de SQL Server con Azure Web Apps no se admite actualmente. Grupos de disponibilidad Always On de SQL Server: cuando use Azure Web Apps con máquinas virtuales de SQL Server en Azure, puede configurar grupos de disponibilidad Always On. Sin embargo, debe configurar el agente de escucha del grupo de disponibilidad Always On para enrutar la comunicación a la réplica principal a través de puntos de conexión públicos de carga equilibrada.
Conectividad entre entornos	Puede usar Azure Virtual Network para conectarse a entornos locales.	Puede usar Azure Virtual Network para conectarse a entornos locales.	Se admite Azure Virtual Network.
Escalabilidad	El escalado vertical está disponible mediante el aumento del tamaño de las máquinas virtuales o la incorporación de más discos. Para obtener más información sobre los tamaños de máquina virtual, consulte Tamaños de máquina virtual en Azure. Para el servidor de base de datos: El escalado horizontal está disponible a través de técnicas de particionamiento de base de datos y grupos de disponibilidad Always On de SQL Server. Para cargas de trabajo de lectura intensivas, puede usar grupos de disponibilidad Always On en varios nodos secundarios, así como replicación de SQL Server. Para cargas de trabajo de escritura intensivas, puede implementar datos de particionamiento horizontal entre varios servidores físicos para proporcionar escalado horizontal de la aplicación. Además, puede implementar el escalado horizontal mediante SQL Server con enrutamiento dependiente de datos. Con el enrutamiento dependiente de los datos (DDR), necesitará implementar el mecanismo de creación de particiones en la aplicación cliente, normalmente en la capa del nivel de empresa, para enrutar las solicitudes de base de datos a varios nodos de SQL Server. El nivel de empresa contiene asignaciones para ver cómo se particionan los datos y qué nodo contiene los datos. Puede escalar las aplicaciones que ejecutan máquinas virtuales. Para obtener más información, consulte Escalado de una aplicación. Nota importante: la función Escalabilidad automática de Azure permite aumentar o reducir automáticamente el número de máquinas virtuales que usa la aplicación. Esta función garantiza que la experiencia del usuario final no se ve afectada negativamente durante los períodos de máxima actividad y que las máquinas virtuales se apagan cuando la demanda sea baja. Se recomienda no configurar la opción de escalado automático para el servicio en la nube si este incluye máquinas virtuales de SQL Server. Esto se debe a que la función de escalado automático permite a Azure activar una máquina virtual cuando el uso de la CPU en dicha máquina virtual es superior a un umbral y apagar una máquina virtual cuando el uso de la CPU no llega a dicho umbral. La función de escalado automático es útil para las aplicaciones sin estado, como servidores web, donde cualquier máquina virtual puede administrar la carga de trabajo sin ninguna referencia a los estados anteriores. Sin embargo, la función de escalado automático no es útil para las aplicaciones con estado, como SQL Server, donde solo una instancia permite escribir en la base de datos.	El escalado vertical está disponible mediante el uso de varios roles web y de trabajo. Para más información sobre los tamaños de máquina virtual para roles web y roles de trabajo, consulte Tamaños de Cloud Services. Al usar Cloud Services, se pueden definir varios roles para distribuir el procesamiento y conseguir un escalado flexible de la aplicación. Cada servicio en la nube incluye uno o varios roles web o roles de trabajo, cada uno con sus propios archivos de aplicación y configuración. Para escalar verticalmente un servicio en la nube, aumente el número de instancias de rol (máquinas virtuales) que se implementan para un rol, mientras que para reducirlo verticalmente, debe reducir el número de instancias de rol. Para más información, consulte Modelos de ejecución de Azure. El escalado horizontal está disponible gracias al soporte técnico integrado de alta disponibilidad de Azure a través de Cloud Services, Virtual Machines y el Acuerdo de Nivel de Servicio de red virtual, y Load Balancer. En una aplicación de niveles múltiples, se recomienda conectar la aplicación de roles web y de trabajo a las máquinas virtuales del servidor de bases de datos a través de Azure Virtual Network. Además, Azure proporciona equilibro de carga para las máquinas virtuales en el mismo servicio en la nube, lo que significa que distribuye las solicitudes de usuario entre ellas. Las máquinas virtuales conectadas de esta forma se pueden comunicar directamente entre ellas a través de la red local dentro de un centro de datos de Azure. La función Escalado automático en Azure Portal, así como las horas de programación. Para más información, consulte Procedimiento para configurar el escalado automático para un servicio en la nube en el Portal.	Escalado y reducción verticales: se puede aumentar o disminuir el tamaño de la instancia (VM) reservada para su sitio web. Escalado horizontal: puede agregar más instancias reservadas (máquinas virtuales) para el sitio web. La función Escalado automático en el Portal, así como las horas de programación. Para obtener más información, consulte Escalado de Web Apps.

Para más información sobre cuál de estos métodos de programación elegir, consulte Azure App Service, Virtual Machines, Service Fabric, and Cloud Services comparison (Comparación entre Azure App Service, Virtual Machines, Service Fabric y Cloud Services).

Paso siguiente

Para obtener más información sobre cómo ejecutar SQL Server en Azure Virtual Machines, consulte Introducción a SQL Server en Azure Virtual Machines.