Recomendaciones para diseñar redundancia

  • Artículo

Se aplica a esta recomendación de lista de comprobación de confiabilidad de Azure Well-Architected Framework:

RE:05 Agregue redundancia en distintos niveles, especialmente para flujos críticos. Aplique redundancia al proceso, los datos, la red y otros niveles de infraestructura de acuerdo con los objetivos de confiabilidad identificados.

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

En esta guía se describen las recomendaciones para agregar redundancia a través 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

Término Definición
Redundancia Implementación de varias instancias idénticas de un componente de carga de trabajo.
Persistencia políglota Concepto de uso de diferentes tecnologías de almacenamiento por la misma aplicación o solución para aprovechar las mejores funcionalidades de cada componente.
Coherencia de datos La medida de cómo sincronizar o no sincronizar un conjunto de datos determinado se encuentra en varios almacenes.
Creación de particiones Proceso de dividir físicamente los datos en almacenes de datos independientes.
Partición Una estrategia de creación de particiones de base de datos horizontal que admite varias instancias de almacenamiento con un esquema común. Los datos no se replican en todas las instancias.

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, podría 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 resulta 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 eficiencia del rendimiento, distribuya la carga entre varios nodos redundantes para asegurarse de que cada nodo funciona de forma óptima. En el contexto de la confiabilidad, cree una capacidad de reserva para absorber errores o errores de funcionamiento que afecten a uno o varios nodos. Asegúrese de que la capacidad de reserva pueda absorber los 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 con un uso del 60 % y se produce un error en un nodo, el nodo restante corre el riesgo de sobrecargarse porque no puede funcionar en un 120 %. Distribuya la carga con otro nodo para asegurarse de que se mantienen los objetivos de rendimiento y confiabilidad.

Inconvenientes:

  • Más redundancia de carga de trabajo equivale a más costos. Considere detenidamente la posibilidad de agregar redundancia y revisar periódicamente la arquitectura para asegurarse de que administra los costos, especialmente cuando se usa el sobreaprovisionamiento. Al usar el sobreaprovisionamiento como estrategia de resistencia, equilibre el proceso con una estrategia de escalado bien definida para minimizar las ineficiencias de costos.
  • Puede haber inconvenientes en el rendimiento al crear 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.
  • Es posible que diferentes flujos dentro de la misma carga de trabajo tengan 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-activo de varias regiones le ayuda a lograr el mayor nivel de confiabilidad posible, pero es significativamente más caro que un diseño activo-pasivo. La decisión de las regiones geográficas adecuadas se convierte 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.

Stamps 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 Stamps de implementación para asegurarse de implementar la carga de trabajo de forma repetible y escalable. Los stamps 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 stamp como una unidad de escalado que puede duplicar para escalar la carga de trabajo horizontalmente o para realizar implementaciones azul-verde. Diseñe la carga de trabajo con stamps de implementación para optimizar la implementación activa-activa o activa-pasiva para la resistencia y la carga de administración. 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 en regiones de Azure

Tanto si implementa un diseño activo-activo como activo-pasivo, aproveche las zonas de disponibilidad dentro de las regiones activas para optimizar completamente la resistencia. Muchas regiones de Azure proporcionan varias zonas de disponibilidad, que son grupos separados de centros de datos dentro de una región. En función del servicio de Azure, puede aprovechar las ventajas de las zonas de disponibilidad mediante la implementación de elementos de la carga de trabajo de forma redundante entre zonas o anclar elementos a zonas específicas. Para obtener más información, consulte Recomendaciones para usar regiones y zonas de disponibilidad.

Guía de nivel de infraestructura

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 sobre la que debe tener control 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 Azure Virtual Machine Scale Sets 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 solicitudes pueden eliminarse, generar 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.

  • Sobreaprovisionar recursos críticos para mitigar los 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 de IaaS manualmente o a través de la automatización en cada zona o región de disponibilidad en la que pretende implementar la solución. Algunos servicios paaS tienen funcionalidades integradas que se replican automáticamente entre regiones y zonas de disponibilidad.

Recursos de datos

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

  • Tenga en cuenta 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, según sea compatible con 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 simplemente datos de aplicación persistentes. También contienen registros de aplicación, eventos, mensajes y memorias caché.

  • Tenga en cuenta los requisitos de coherencia de 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 apareen 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.

  • Particione los datos de 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 Segregación de responsabilidades de comandos y consultas (CQRS) para separar los modelos de datos de lectura y escritura y de solo lectura. 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 conocer las funcionalidades de redundancia específicas de los servicios de datos con estado, consulte Vínculos relacionados.

Redes

  • 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 crear 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 escalado horizontal.

  • Asegúrese de que la aplicación 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, podría 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:

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.

  • En 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 la 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 reequilibrada para aprovechar las ventajas de la zona saludable. 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íbrida 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 resoluciones privadas.

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:

Diagrama que muestra la arquitectura de la implementación de referencia.

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

Lista de comprobación de confiabilidad

Consulte el conjunto completo de recomendaciones.

Lista de comprobación de confiabilidad