Recomendaciones para diseñar redundancia

Se aplica a esta recomendación de lista de comprobación de confiabilidad del marco de trabajo bien diseñado de Azure:

Guías relacionadas: Diseño | multirregional de alta disponibilidad Mediante zonas de disponibilidad y regiones

En esta guía se describen las recomendaciones para agregar redundancia a lo largo de flujos críticos en diferentes capas de carga de trabajo, lo que optimiza la resistencia. Cumpla los requisitos de los objetivos de confiabilidad definidos aplicando los niveles adecuados de redundancia a los niveles de proceso, datos, redes y otras capas de infraestructura. Aplique esta redundancia para proporcionar a la carga de trabajo una base sólida y confiable en la que basarse. Al compilar la carga de trabajo sin redundancia de infraestructura, existe un alto riesgo de tiempo de inactividad prolongado debido a posibles errores.

Definiciones

Estrategias de diseño principales

En el contexto de confiabilidad, use redundancia para contener problemas que afecten a un único recurso y asegúrese de que esos problemas no afecten a la confiabilidad de todo el sistema. Use la información que identificó sobre los flujos críticos y los objetivos de confiabilidad para tomar decisiones informadas necesarias para la redundancia de cada flujo.

Por ejemplo, puede tener varios nodos de servidor web que se ejecutan a la vez. La importancia del flujo que admiten podría requerir que todas ellas tengan réplicas listas para aceptar el tráfico si hay un problema que afecta a todo el grupo, por ejemplo, una interrupción regional. Como alternativa, dado que los problemas a gran escala son poco frecuentes y es costoso implementar un conjunto completo de réplicas, puede implementar un número limitado de réplicas para que el flujo funcione en un estado degradado hasta que resuelva el problema.

Al diseñar la redundancia en el contexto de la eficacia del rendimiento, distribuya la carga entre varios nodos redundantes para asegurarse de que cada nodo funciona de forma óptima. En el contexto de confiabilidad, cree una capacidad de reserva para absorber errores o mal funcionamientos que afecten a uno o varios nodos. Asegúrese de que la capacidad de reserva puede absorber errores durante todo el tiempo necesario para recuperar los nodos afectados. Teniendo en cuenta esta distinción, ambas estrategias deben trabajar conjuntamente. Si distribuye el tráfico entre dos nodos para el rendimiento y ambos se ejecutan en un 60 % de uso y se produce un error en un nodo, el nodo restante corre el riesgo de sobrecargarse porque no puede funcionar en un 120 %. Extienda la carga con otro nodo para asegurarse de que se mantienen los objetivos de rendimiento y confiabilidad.

Desventajas:

• Más redundancia de carga de trabajo equivale a más costos. Considere cuidadosamente la posibilidad de agregar redundancia y revisar periódicamente la arquitectura para asegurarse de que administra los costos, especialmente cuando se usa el sobreaprovisionamiento. Cuando se usa el sobreaprovisionamiento como estrategia de resistencia, equilibre con una estrategia de escalado bien definida para minimizar las ineficacias de costos.

• Puede haber inconvenientes en el rendimiento cuando se crea en un alto grado de redundancia. Por ejemplo, los recursos que se distribuyen entre zonas de disponibilidad o regiones pueden afectar al rendimiento porque tiene que enviar tráfico a través de conexiones de alta latencia entre recursos redundantes, como servidores web o instancias de base de datos.

• Los distintos flujos dentro de la misma carga de trabajo pueden tener requisitos de confiabilidad diferentes. Los diseños de redundancia específicos del flujo pueden introducir complejidad en el diseño general.

Diseño de arquitectura redundante

Tenga en cuenta dos enfoques al diseñar una arquitectura redundante: activo-activo o activo-pasivo. Elija su enfoque en función de la importancia del flujo de usuario y del flujo del sistema que admiten los componentes de infraestructura. En términos de confiabilidad, un diseño activo-activo en varias regiones le ayuda a lograr el mayor nivel de confiabilidad posible, pero es significativamente más caro que un diseño activo-pasivo. Decidir las regiones geográficas adecuadas se convierten en la siguiente opción crítica. También puede usar estos enfoques de diseño para una sola región mediante zonas de disponibilidad. Para obtener más información, consulte Recomendaciones para el diseño de varias regiones de alta disponibilidad.

Sellos de implementación y unidades de escala

Tanto si implementa en un modelo activo-activo como activo-pasivo, siga el patrón de diseño De stamps de implementación para asegurarse de implementar la carga de trabajo de forma repetible y escalable. Los sellos de implementación son las agrupaciones de recursos necesarios para entregar la carga de trabajo a un subconjunto determinado de los clientes. Por ejemplo, el subconjunto podría ser un subconjunto regional o un subconjunto con todos los mismos requisitos de privacidad de datos que la carga de trabajo. Piense en cada marca como una unidad de escala que se puede duplicar para escalar la carga de trabajo horizontalmente o para realizar implementaciones azules y verdes. Diseñe la carga de trabajo con stamps de implementación para optimizar la implementación activa-activa o activa-pasiva para la carga de administración y resistencia. También es importante planear el escalado horizontal de varias regiones para superar posibles restricciones de capacidad de recursos temporales en una región.

Zonas de disponibilidad dentro de las regiones de Azure

Tanto si implementa un diseño activo-activo como activo-pasivo, aproveche las ventajas de las zonas de disponibilidad dentro de las regiones activas para optimizar completamente la resistencia. Muchas regiones de Azure proporcionan varias zonas de disponibilidad, que están separadas por grupos de centros de datos dentro de una región. Según el servicio de Azure, puede aprovechar las ventajas de las zonas de disponibilidad mediante la implementación de elementos de la carga de trabajo con redundancia entre zonas o anclaje de elementos a zonas específicas. Para obtener más información, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.

Implementación de la redundancia de zona para los recursos de proceso

• Elija el servicio de proceso adecuado para la carga de trabajo. En función del tipo de carga de trabajo que diseñe, puede haber varias opciones disponibles. Investigue los servicios disponibles y comprenda qué tipos de cargas de trabajo funcionan mejor en un servicio de proceso determinado. Por ejemplo, las cargas de trabajo de SAP suelen ser más adecuadas para los servicios de proceso de infraestructura como servicio (IaaS). Para una aplicación en contenedor, determine la funcionalidad específica que necesita tener control sobre para determinar si se debe usar Azure Kubernetes Service (AKS) o una solución de plataforma como servicio (PaaS). La plataforma en la nube administra completamente un servicio PaaS.

• Use las opciones de proceso de PaaS si los requisitos lo permiten. Azure administra completamente los servicios PaaS, lo que reduce la carga de administración y se crea un grado documentado de redundancia.

• Use Conjuntos de escalado de máquinas virtuales de Azure si necesita implementar máquinas virtuales (VM). Con Virtual Machine Scale Sets, puede distribuir automáticamente el proceso uniformemente entre zonas de disponibilidad.

• Mantenga la capa de proceso limpia de cualquier estado porque los nodos individuales que atienden las solicitudes se pueden eliminar, producir errores o reemplazarse en cualquier momento.

• Use servicios con redundancia de zona siempre que sea posible para proporcionar una mayor resistencia sin aumentar la carga operativa.

• Aprovisionamiento excesivo de recursos críticos para mitigar errores de instancias redundantes, incluso antes de que comiencen las operaciones de escalado automático, por lo que el sistema sigue funcionando después de un error de componente. Calcule el efecto aceptable de un error al incorporar el sobreaprovisionamiento en el diseño de redundancia. Al igual que con el proceso de toma de decisiones de redundancia, los objetivos de confiabilidad y las decisiones de compensación financiera determinan la medida en que agrega capacidad de reserva con sobreaprovisionamiento. El sobreaprovisionamiento se refiere específicamente al escalado horizontal, lo que significa agregar instancias adicionales de un tipo de recurso de proceso determinado, en lugar de aumentar las funcionalidades de proceso de cualquier instancia única. Por ejemplo, si cambia una máquina virtual de una SKU de nivel inferior a una SKU de nivel superior.

• Implemente los servicios iaaS manualmente o a través de la automatización en cada zona o región de disponibilidad en la que quiera implementar la solución. Algunos servicios paaS tienen funcionalidades integradas que se replican automáticamente entre regiones y zonas de disponibilidad.

Implementación de la redundancia de zona para los recursos de datos

• Determine si es necesaria la replicación de datos sincrónica o asincrónica para la funcionalidad de la carga de trabajo. Para ayudarle a determinar esta determinación, consulte Recomendaciones para usar regiones y zonas de disponibilidad.

• Considere la tasa de crecimiento de los datos. Para planear la capacidad, planee el crecimiento de los datos, la retención de datos y el archivado para asegurarse de que se cumplen los requisitos de confiabilidad a medida que aumenta la cantidad de datos de la solución.  

• Distribuya los datos geográficamente, como admite el servicio, para minimizar el efecto de los errores localizados geográficamente.

• Replique los datos entre regiones geográficas para proporcionar resistencia a interrupciones regionales y errores catastróficos.

• Automatice la conmutación por error después de un error de instancia de base de datos. Puede configurar la conmutación por error automatizada en varios servicios de datos PaaS de Azure. La conmutación por error automatizada no es necesaria para los almacenes de datos que admiten escrituras en varias regiones, como Azure Cosmos DB. Para obtener más información, consulte Recomendaciones para diseñar una estrategia de recuperación ante desastres.

• Use el mejor almacén de datos para los datos. Adopte la persistencia poliglot o las soluciones que usan una combinación de tecnologías de almacén de datos. Los datos incluyen más que solo datos persistentes de la aplicación. También contienen registros de aplicación, eventos, mensajes y memorias caché.

• Considere los requisitos de coherencia de los datos y use la coherencia final cuando los requisitos lo permitan. Cuando se distribuyen los datos, use la coordinación adecuada para aplicar garantías de coherencia sólidas. La coordinación puede reducir el rendimiento y hacer que los sistemas se acoplan estrechamente, lo que puede hacer que sean más frágiles. Por ejemplo, si una operación actualiza dos bases de datos, en lugar de colocarla en un único ámbito de transacción, es mejor si el sistema puede dar cabida a la coherencia final.

• Creación de particiones de datos para disponibilidad. La creación de particiones de base de datos mejora la escalabilidad y también puede mejorar la disponibilidad. Si una partición deja de funcionar, las demás particiones siguen siendo accesibles. Un error en una partición solo interrumpe un subconjunto de las transacciones totales.

• Si el particionamiento no es una opción, puede usar el patrón De segregación de responsabilidades de comandos y consultas (CQRS) para separar los modelos de datos de solo lectura y escritura. Agregue más instancias de base de datos de solo lectura redundantes para proporcionar más resistencia.  

• Comprenda las funcionalidades de replicación y redundancia integradas de los servicios de plataforma con estado que usa. Para obtener funcionalidades de redundancia específicas de los servicios de datos con estado, consulte Vínculos relacionados.

Implementación de redundancia de zona para recursos de red

• Decida una topología de red confiable y escalable. Use un modelo en estrella tipo hub-and-spoke o un modelo de Azure Virtual WAN para ayudarle a organizar la infraestructura en la nube en patrones lógicos que facilitan el diseño de redundancia para compilar y escalar.

• Seleccione el servicio de red adecuado para equilibrar y redirigir las solicitudes dentro o entre regiones. Use los servicios de equilibrio de carga globales o con redundancia de zona cuando sea posible para cumplir los objetivos de confiabilidad.

• Asegúrese de que ha asignado suficiente espacio de direcciones IP en las redes virtuales y subredes para tener en cuenta el uso planeado, incluidos los requisitos de escalabilidad horizontal.

• Asegúrese de que la aplicación se puede escalar dentro de los límites de puerto de la plataforma de hospedaje de aplicaciones elegida. Si una aplicación inicia varias conexiones TCP o UDP salientes, puede agotar todos los puertos disponibles y provocar un rendimiento deficiente de la aplicación.

• Elija SKU y configure los servicios de red que pueden cumplir los requisitos de ancho de banda y disponibilidad. El rendimiento de una puerta de enlace de VPN varía en función de su SKU. La compatibilidad con la redundancia de zona solo está disponible para algunas SKU del equilibrador de carga.

• Asegúrese de que el diseño para controlar DNS se ha creado con un enfoque en la resistencia y admite la infraestructura redundante.

Facilitación de Azure

La plataforma Azure le ayuda a optimizar la resistencia de la carga de trabajo y a agregar redundancia mediante:

• Proporcionar redundancia integrada con muchas soluciones PaaS y software como servicio (SaaS), algunas de las cuales son configurables.

• Le permite diseñar e implementar redundancia dentro de la región mediante zonas de disponibilidad e redundancia entre regiones.

• Ofrece servicios de equilibrio de carga compatibles con réplicas, como App de Azure lication Gateway, Azure Front Door y Azure Load Balancer.

• Ofrece soluciones de replicación geográfica implementadas fácilmente, como la replicación geográfica activa para Azure SQL Database. Implemente la distribución global y la replicación transparente mediante Azure Cosmos DB. Azure Cosmos DB ofrece dos opciones para controlar las escrituras en conflicto. Elija la mejor opción para la carga de trabajo.

• Ofrece funcionalidades de restauración a un momento dado para muchos servicios de datos PaaS.

• Mitigación del agotamiento de puertos a través de Azure NAT Gateway o Azure Firewall.

Facilitación de Azure específica de DNS

• Para escenarios de resolución de nombres internos, use zonas privadas de Azure DNS, que tienen redundancia de zona integrada y redundancia geográfica. Para más información, consulte Resistencia de la zona privada de Azure DNS.

• Para escenarios de resolución de nombres externos, use zonas públicas de Azure DNS, que tienen redundancia de zona integrada y redundancia geográfica.

• Los servicios dns de Azure públicos y privados son servicios globales que son resistentes a interrupciones regionales porque los datos de zona están disponibles globalmente.

• Para escenarios de resolución de nombres híbridos entre entornos locales y en la nube, use la resolución privada de Azure DNS. Este servicio admite redundancia de zona si la carga de trabajo se encuentra en una región que admite zonas de disponibilidad. Una interrupción de toda la zona no requiere ninguna acción durante la recuperación de zona. El servicio se recupera automáticamente y se reequilibrada para aprovechar las ventajas de la zona correcta. Para más información, consulte Resistencia en la resolución privada de Azure DNS.

• Para eliminar un único punto de error y lograr una resolución de nombres híbridas más resistente entre regiones, implemente dos o más solucionadores privados de Azure DNS en distintas regiones. La conmutación por error de DNS, en un escenario de reenvío condicional, se logra mediante la asignación de una resolución como servidor DNS principal. Asigne el otro solucionador en otra región como servidor DNS secundario. Para más información, consulte Configuración de la conmutación por error de DNS mediante solucionadores privados.

Ejemplo

Para obtener un ejemplo de una implementación con redundancia de varias regiones, consulte Aplicación web con redundancia de zona de alta disponibilidad de línea base.

En el diagrama siguiente se muestra otro ejemplo:

Vínculos relacionados

Para más información sobre la redundancia, consulte los siguientes recursos:

• Guía de regiones de Azure
• Redundancia de Azure Storage
• Almacenamiento con redundancia de zona
• Replicación geográfica activa de Azure SQL Database
• Configuración de la replicación entre dos instancias administradas

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.