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 Apache Cassandra en Linux para la capa de datos.
Architecture
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
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 del nivel web al nivel de empresa.
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 la Protección de red contra DDoS de Azure, 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
Base de datos Apache Cassandra. Proporciona alta disponibilidad en el nivel de datos, al habilitar la replicación y la conmutación por error.
OpsCenter. Implemente una solución de supervisión como DataStax OpsCenter para supervisar el clúster de Cassandra.
Jumpbox. También se denomina host bastión. 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 grupo de seguridad de red que permite el tráfico remoto solo desde direcciones IP públicas que se encuentren en una lista segura. El NSG debe permitir el tráfico de Protocolo de escritorio remoto (RDP).
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 obtener recomendaciones sobre cómo configurar las máquinas virtuales, consulte Ejecución de una máquina virtual Linux 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 de [enrutamiento entre dominios sin clase (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 obtener más información sobre el diseño de redes virtuales y subredes, consulte Planeación y diseño de redes virtuales de Azure.
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 a cada máquina virtual una dirección IP privada. Los clientes se conectan mediante la dirección IP 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, cree una regla que 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.
Grupos de seguridad de red
Use reglas NSG para restringir el tráfico entre los niveles. Por ejemplo, en la arquitectura de tres niveles mostrada anteriormente, el nivel web no se comunica directamente con el nivel de base de datos. Para exigir esto, el nivel de base de datos debe bloquear el tráfico entrante desde la subred del nivel Web.
- Deniegue todo el tráfico entrante de la red virtual. (Use la etiqueta
VIRTUAL_NETWORKde la regla). - Permita el tráfico entrante de la subred del nivel Business.
- 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.
- Permita el tráfico SSH (puerto 22) desde la subred de JumpBox. Esta regla permite a los administradores conectarse al nivel de base de datos desde JumpBox.
Cree las reglas 2 a 4 con una prioridad más alta que la primera regla para que puedan invalidarla.
Cassandra
Se recomienda DataStax Enterprise para casos de producción, pero estas recomendaciones se aplican a cualquier edición de Cassandra. Para obtener más información sobre cómo ejecutar DataStax en Azure, consulte la Guía de implementación de DataStax Enterprise Deployment para Azure.
Configure los nodos en el modo de reconocimiento del bastidor. Asigne los dominios de error a los bastidores en el archivo cassandra-rackdc.properties.
No se necesita un equilibrador de carga delante del clúster. El cliente se conecta directamente a un nodo del clúster.
Los scripts de implementación de esta arquitectura usan la resolución de nombres para inicializar el nodo de inicialización para la comunicación dentro del clúster (propagación). Para habilitar la resolución de nombres, la implementación crea una zona DNS privada de Azure con registros A para los nodos de Cassandra. En función de los scripts de inicialización, quizá pueda usar la dirección IP estática en su lugar.
Nota
Azure DNS privado se encuentra actualmente en su versión preliminar pública.
JumpBox
No permita el acceso mediante SSH 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 SSH a estas máquinas virtuales debe realizarse 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 SSH 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 SSH 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 SSH de la subred de administración.
Consideraciones
Escalabilidad
Conjuntos de escalado
Para los niveles web y de empresa, considere la posibilidad de usar Virtual Machine Scale Sets, en lugar de implementar máquinas virtuales independientes en un conjunto de disponibilidad. 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.
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 las 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.
Eficiencia del rendimiento
Para obtener el mejor rendimiento de Cassandra en las máquinas virtuales de Azure, consulte las recomendaciones de Ejecución de Apache Cassandra en máquinas virtuales de Azure.
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.
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 con la misma disponibilidad se implementan en varios servidores físicos, grupos de proceso, unidades de almacenamiento y conmutadores de red para 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:
- Load Balancer estándar y zonas de disponibilidad
- Escalabilidad automática y Application Gateway con redundancia de zona v2
- ¿Cómo admite Application Gateway la alta disponibilidad y la escalabilidad?
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.
Clúster de Cassandra
En el caso del clúster de Cassandra. los escenarios de conmutación por error dependen tanto de los niveles de coherencia que use la aplicación como del número de réplicas. Para ver los niveles de coherencia y el uso en Cassandra, consulte Configuración de la coherencia de datos y Cassandra: ¿Cuántos nodos se han hablado con Quorum? La disponibilidad de los datos en Cassandra viene determinada por el nivel de coherencia utilizado por la aplicación y el mecanismo de replicación. Para más información sobre la replicación en Cassandra, consulte Explicación de la replicación de datos en bases de datos NoSQL.
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:
- Sondeos de estado de Load Balancer
- Información general sobre la supervisión de estado de Application Gateway
Para conocer las consideraciones sobre el diseño de un punto de conexión de sondeo de estado, consulte Patrón Health Endpoint Monitoring.
Optimización de costos
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 Linux. Solo se le cobrará por las máquinas virtuales de Azure que implemente, así como por los recursos de infraestructura subyacente adicionales que haya consumido, como el almacenamiento y las redes. No hay cargos adicionales por el servicio de Virtual Machine Scale Sets.
Para las opciones de precios de las máquinas virtuales únicas, consulte Precios de máquinas virtuales Linux.
Equilibradores de carga
Se le cobrará solo el número de reglas de equilibrio de carga y de salida configuradas. Las reglas de traducción de direcciones de red de entrada (NAT) 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.
Seguridad
Las redes virtuales son un límite de aislamiento del tráfico de Azure. Las máquinas virtuales de una red virtual no se pueden comunicar directamente con las máquinas virtuales de una red virtual diferente. Las máquinas virtuales que se encuentran en la misma red virtual se pueden comunicar entre sí, a menos que se creen grupos de seguridad de red (NSG) para restringir el tráfico. Para más información, consulte Servicios en la nube de Microsoft y seguridad de red.
Para el tráfico entrante de Internet, las reglas del equilibrador de carga definen qué tráfico puede alcanzar el back-end. Sin embargo, las reglas del equilibrador de carga no son compatibles con las listas seguras de IP, por lo que si desea agregar determinadas direcciones IP públicas a una lista segura, agregue un NSG a la subred.
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). 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 DDoS Protection básica. El objetivo de dicha es proteger la infraestructura de Azure en su conjunto. Aunque DDoS Protection básica se habilita automáticamente, se recomienda usar la Protección de red contra DDoS de Azure. Para detectar las amenazas, la Protección de red 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 de red 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.
Excelencia operativa
Dado que todos los recursos principales y sus dependencias están en la misma red virtual de esta arquitectura, están aislados en la misma carga de trabajo básica. Ese hecho facilita la asociación de recursos específicos de la carga de trabajo a un equipo de DevOps para que este pueda administrar todos los aspectos de esos recursos de forma independiente. Este aislamiento permite que los equipos y servicios de DevOps realicen 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 Apache Cassandra. En concreto, la extensión de script personalizada permite la descarga y ejecución de código arbitrario en una máquina virtual, lo que permite personalizar de forma ilimitada el sistema operativo de una máquina virtual de Azure. 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. Puede usar las herramientas de administración de configuración para solucionar este problema.
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 implementarlo 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 Excelencia operativa en Marco de buena arquitectura de Microsoft Azure.