Creación de servicios de aplicación resistentes
La organización le pide cumplir con los requisitos de recuperación y, al mismo tiempo, mantener a raya los costos y la complejidad en la medida de lo posible.
En esta unidad, aprenderá cómo los clústeres de disponibilidad y la redundancia geográfica pueden ayudarle a crear resistencia en las aplicaciones. Aprenderá qué factores intervienen en las conmutaciones por error y en las conmutaciones por recuperación de las aplicaciones. Al final de la unidad, entenderá por qué y cómo debe implementar una estrategia de supervisión y notificación.
Adición de redundancia geográfica de las aplicaciones
Independientemente de lo que ocurra en la infraestructura que las hospeda, debe conseguir que las aplicaciones se mantengan en ejecución. Los desastres naturales y otros problemas pueden provocar que un área geográfica entera se quede sin suministro o sin acceso a Internet. Para responder a estos problemas correctamente y mantener las aplicaciones en ejecución, debe asegurarse de que se haya implementado la redundancia geográfica. Pero la redundancia geográfica puede ser costosa si no se hace correctamente.
Para que las aplicaciones locales tengan redundancia geográfica, puede usar Azure. La ventaja de ejecutar una infraestructura redundante para las aplicaciones en Azure es que no es responsable de mantener y proteger una ubicación física (junto con los costos asociados).
Con Azure se puede agregar redundancia a las aplicaciones en regiones que podrían estar en el otro extremo del mundo sin tener que controlar ningún tipo de mantenimiento. Si el mantenimiento se realiza automáticamente, puede obtener redundancia geográfica de forma más sencilla y rentable.
Mediante una conexión VPN de sitio a sitio, la red local se puede extender a una red virtual donde se ejecute una réplica de la infraestructura en otra región dentro de Azure. Azure Traffic Manager puede ayudarlo a supervisar el estado de la red local. Si algo sucede en la ubicación local, se puede usar la infraestructura de réplica de Azure que se encuentre en una región distinta.
De igual modo, la redundancia geográfica también se puede configurar en las aplicaciones que se ejecutan dentro de Azure. Por ejemplo, si las aplicaciones se ejecutan en un grupo de máquinas virtuales de Azure en una red virtual, esta misma configuración se puede replicar en otra región para conseguir redundancia geográfica.
A través del emparejamiento de redes virtuales, dos redes virtuales independientes se conectan y se tratan como una sola. El tráfico de estas dos redes no atraviesa la red pública de Internet ni una puerta de enlace. Los recursos pueden conectarse directamente a otros recursos como si estuvieran en la misma red.
En este caso, Traffic Manager vigila ambas regiones supervisando el estado de cada punto de conexión y, Si algo ocurre en la región primaria, Traffic Manager enruta la demanda a la región secundaria.
Adición de clústeres de alta disponibilidad
Los clústeres de alta disponibilidad ayudan a garantizar que las cargas de trabajo estén siempre disponibles y en ejecución con un tiempo de inactividad mínimo. Puede usar clústeres de alta disponibilidad en cualquiera de los siguientes tipos de arquitectura:
Arquitectura activo-activo: puede distribuir y equilibrar la carga de la demanda entre varios nodos, como dos máquinas virtuales de Azure idénticas. Estas máquinas virtuales de Azure se pueden ejecutar al mismo tiempo y compartir la demanda existente. La demanda también se puede distribuir entre estos nodos según diferentes métodos de enrutamiento.
El diagrama siguiente es un ejemplo general de un clúster activo-activo.
Arquitectura activo-pasivo: puede ejecutar máquinas virtuales de Azure en las que un nodo esté activo y en uso, y el otro, pasivo y sin usar. El nodo pasivo se usa únicamente cuando se produzca un error en el nodo activo.
En un escenario activo-activo, los nodos se ejecutan de forma simultánea. En este escenario tiene más costos de ejecución a diario, si las máquinas tienen las mismas especificaciones que las máquinas de un clúster activo-pasivo.
Los clústeres activo-pasivo pueden ser más rentables que un clúster activo-activo. Como el nodo pasivo no atiende activamente a las solicitudes de los usuarios, es posible que tenga menos costos de licencia de software y de recursos. Sin embargo, como solo se ejecuta el nodo activo de un clúster activo-pasivo, esta configuración no es tan flexible a la hora de satisfacer la demanda fluctuante como la de un clúster activo-activo.
Los recursos como los conjuntos de disponibilidad de Azure contribuyen a lograr una alta disponibilidad a través de varios nodos. Si algo (como un error de hardware o una interrupción de la red) afecta a un equipo, habrá otra máquina disponible para que todo siga en funcionamiento.
También se pueden usar Azure Virtual Machine Scale Sets para crear un clúster activo-activo y ejecutar máquinas que se escalen o reduzcan verticalmente en respuesta directa a la demanda. Azure Load Balancer, gracias a sus reglas para puertos de alta disponibilidad, también puede ayudarle a usar clústeres activo-activo o activo-pasivo en las máquinas.
Conmutación por error y conmutación por recuperación de las aplicaciones
La organización tiene una infraestructura para las aplicaciones que se ejecutan de forma local. Debe ayudar a garantizar que su organización satisfaga los requisitos de cumplimiento y logre los objetivos de continuidad empresarial. Al usar Azure Site Recovery y Traffic Manager juntos, se puede conmutar por error a Azure y, luego, conmutar por recuperación para hacer que las aplicaciones se sigan ejecutando.
Si se produce un error, el tráfico del cliente se puede redirigir sin problemas a una infraestructura creada en Azure. Use Traffic Manager para crear un perfil y establecer un método de enrutamiento por prioridad. Después, debe crear dos puntos de conexión: uno para el entorno local y otro para el entorno que quiera configurar en Azure.
Dado que normalmente ejecuta en un entorno local y necesita otro en Azure solo para conmutar por error, puede establecer las dos prioridades siguientes:
- Prioridad 1 para el entorno local
- Prioridad 2 para su entorno en Azure
El establecimiento de estas prioridades es lo que indica a Traffic Manager cómo enrutar el tráfico entre ambos entornos. Traffic Manager sigue enrutando el tráfico al entorno local hasta que observe que el punto de conexión ya no está en buen estado. En ese caso, redirige el tráfico al segundo entorno, en Azure.
Azure Site Recovery empieza a ejecutar las máquinas virtuales en Azure solo si se desencadena una conmutación por error. Si se produce un desastre, se puede usar Azure Site Recovery para iniciar una conmutación por error desde el entorno local al entorno de Azure.
Traffic Manager le permite establecer la frecuencia de sondeo con la que se supervisan los puntos de conexión. Traffic Manager se configura para supervisar el estado de los puntos de conexión cada 30 segundos en el caso de los sondeos regulares y en intervalos de 10 segundos en los sondeos más rápidos.
Una vez finalizada una conmutación por error, los clientes se dirigen de forma transparente al nuevo punto de conexión en Azure. Cuando se haya solucionado el problema que ha provocado la conmutación por error, se puede usar Azure Site Recovery para volver a conmutar por recuperación al entorno local. Traffic Manager continúa sondeando el estado del punto de conexión local y, cuando identifique que el punto de conexión vuelve a estar en un estado correcto, dirigirá el tráfico de vuelta al entorno local.
