Documentación sobre confiabilidad de Azure

  • Artículo

La confiabilidad consta de dos principios: resistencia y disponibilidad. El objetivo de la resistencia es evitar errores y, si siguen apareciendo, devolver la aplicación a un estado de funcionamiento completo. El objetivo de la disponibilidad es proporcionar acceso coherente a la aplicación o carga de trabajo. Es importante planear la confiabilidad proactiva en función de los requisitos de la aplicación.

Azure incluye servicios de confiabilidad integrados que puede usar y administrar en función de sus necesidades empresariales. Tanto si se trata de un único error de nodo de hardware, un error de nivel de bastidor, una interrupción del centro de datos o una interrupción regional a gran escala, Azure proporciona soluciones que mejoran la confiabilidad. Por ejemplo, los conjuntos de disponibilidad garantizan que las máquinas virtuales implementadas en Azure se distribuyan entre varios nodos de hardware aislados en un clúster. Las zonas de disponibilidad protegen las aplicaciones y los datos de los clientes frente a errores del centro de datos en varias ubicaciones físicas dentro de una región. Las regiones y las zonas de disponibilidad son fundamentales para el diseño de aplicaciones y la estrategia de resistencia, y se analizan con más detalle más adelante en este artículo.

La documentación de confiabilidad de Azure ofrece instrucciones de confiabilidad para los servicios de Azure. Esta guía incluye información sobre la compatibilidad con zonas de disponibilidad, la guía de recuperación ante desastres y la disponibilidad de los servicios.

Para obtener instrucciones detalladas de confiabilidad específicas del servicio, incluidas las zonas de disponibilidad, la recuperación ante desastres o la alta disponibilidad, consulte Introducción a la guía de confiabilidad específica del servicio de Azure.

Para obtener información sobre los principios de confiabilidad y confiabilidad y la arquitectura en los servicios de Microsoft Azure, consulte Microsoft Azure Well-Architected Framework: Reliability.

Requisitos de fiabilidad

El nivel de confiabilidad necesario para cualquier solución de Azure depende de varias consideraciones. El Acuerdo de Nivel de Servicio de disponibilidad y latencia y otros requisitos empresariales rigen las opciones de arquitectura y el nivel de resistencia, y deben tenerse en cuenta antes que nada. Los requisitos de disponibilidad van desde el tiempo de inactividad aceptable (y cuánto le cuesta a su empresa) hasta la cantidad de dinero y de tiempo que puede invertir de forma realista en hacer que una aplicación ofrezca alta disponibilidad.

La creación de sistemas confiables en Azure es una responsabilidad compartida. Microsoft es responsable de la confiabilidad de la plataforma en la nube, incluidos sus centros de datos y red globales. Los clientes y asociados de Azure deben responsabilizarse de la resistencia de sus aplicaciones en la nube a través de los procedimientos recomendados de arquitectura basados en los requisitos de cada carga de trabajo. Aunque Azure se esfuerza continuamente por lograr la máxima resistencia posible en el Acuerdo de Nivel de Servicio para la plataforma en la nube, debe definir sus propios Acuerdos de Nivel de Servicio de destino para cada carga de trabajo de la solución. Un Acuerdo de Nivel de Servicio permite evaluar si la arquitectura cumple con los requisitos empresariales. A medida que se esfuerza por obtener mayores porcentajes de tiempo de actividad garantizado del Acuerdo de Nivel de Servicio, aumenta el costo y la complejidad para lograr aumentar la disponibilidad. Un tiempo de actividad del 99,99 % se traduce en unos 5 minutos de tiempo de inactividad total al mes. ¿Valen la pena la complejidad y el costo adicionales para alcanzar ese porcentaje? La respuesta depende de los requisitos empresariales individuales. Al decidir los compromisos finales del Acuerdo de Nivel de Servicio, comprenda los Acuerdos de Nivel de Servicio que admite Microsoft. Cada servicio de Azure tiene su propio Acuerdo de Nivel de Servicio.

Diagram showing the shared responsibility model for Azure business continuity.

En el modelo local tradicional, toda la responsabilidad de administrar, desde el hardware para el proceso, el almacenamiento y las redes a la aplicación, depende de usted. Debe planear varios tipos de errores y cómo tratarlos mediante la creación de una estrategia de recuperación ante desastres. Con IaaS, el proveedor de servicios en la nube es responsable de la resistencia de la infraestructura principal, incluido el almacenamiento, las redes y el proceso. A medida que pasa de IaaS a PaaS y, a continuación, a SaaS, encontrará que es responsable de menos y que el proveedor de servicios en la nube es responsable de más.  

Para obtener más información sobre los principios de confiabilidad, consulte Documentación de confiabilidad del marco de buena arquitectura.  

Creación de sistemas confiables

Debe definir los requisitos de confiabilidad de la aplicación al principio del planeamiento. Si sabe qué aplicaciones no necesitan una alta disponibilidad del 100 % durante determinados períodos de tiempo, puede optimizar los costos durante esos períodos no críticos. Identifique el tipo de errores que puede experimentar una aplicación y el efecto potencial de cada error. Un plan de recuperación debe cubrir todos los servicios críticos al finalizar la estrategia de recuperación en el componente individual y en el nivel general de la aplicación. Diseñe la estrategia de recuperación para protegerse frente a errores de nivel de aplicación, región y zona. Realice pruebas del entorno de aplicación de un extremo a otro para medir la confiabilidad de la aplicación y la recuperación frente a errores inesperados.

La siguiente lista de comprobación cubre el ámbito del planeamiento de confiabilidad.

Planeación de la confiabilidad
Defina los objetivos de disponibilidad y recuperación para satisfacer los requisitos empresariales.
Diseñe las características de confiabilidad de las aplicaciones en función de los requisitos de disponibilidad.
Adapte las plataformas de aplicaciones y de datos para que cumplan los requisitos de confiabilidad.
Configure las rutas de conexión para promover la disponibilidad.
Use las zonas de disponibilidad y el planeamiento de recuperación ante desastres cuando proceda para mejorar la confiabilidad y optimizar los costos.
Asegúrese de que la arquitectura de la aplicación sea resistente a los errores.
Sepa qué ocurre si no se cumplen los requisitos del Acuerdo de Nivel de Servicio.
Identifique posibles puntos de error en el sistema; el diseño de la aplicación debe tolerar errores de dependencia mediante la implementación de la interrupción del circuito.
Compile aplicaciones que funcionen en ausencia de sus dependencias.

RTO y RPO

Dos métricas importantes a tener en cuenta son el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) ya que hacen referencia a la recuperación ante desastres.  Para obtener más información sobre los requisitos de diseño funcionales y no funcionales, consulte Requisitos funcionales y no funcionales del marco de buena arquitectura.

  • Objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable que una aplicación puede no estar disponible después de un incidente.

  • Objetivo de punto de recuperación (RPO) es la duración máxima de la pérdida de datos que es aceptable durante un desastre.

El RTO y el RPO son requisitos no funcionales de un sistema y los deben dictar las necesidades empresariales. Para obtener estos valores, es una buena idea realizar una evaluación de riesgos y comprender claramente los costos derivados de un tiempo de inactividad o una pérdida de datos.  

Regiones y zonas de disponibilidad

Las regiones y las zonas de disponibilidad son una parte importante de la ecuación de confiabilidad. Las regiones cuentan con varias zonas de disponibilidad separadas físicamente. Estas zonas de disponibilidad están conectadas por una red de alto rendimiento con menos de 2 ms de latencia entre zonas físicas. La latencia baja le ayuda a sincronizar los datos y a mantenerlos accesibles cuando las cosas van mal. Puede usar esta infraestructura estratégicamente a medida que diseña una infraestructura de aplicaciones y datos que replique y entregue automáticamente servicios ininterrumpidos entre zonas y entre regiones.

Los servicios de Microsoft Azure admiten zonas de disponibilidad y están habilitados para impulsar las operaciones en la nube con una alta disponibilidad óptima, a la vez que respaldan las necesidades de la estrategia de continuidad empresarial y recuperación entre regiones.

Para el planeamiento de la recuperación ante desastres, las regiones emparejadas con otras regiones ofrecen replicación entre regiones y proporcionan protección mediante la replicación asincrónica de datos entre otras regiones de Azure. Las regiones sin un par siguen directrices de residencia de datos y ofrecen alta disponibilidad con zonas de disponibilidad y almacenamiento con redundancia local o con redundancia de zona. Los clientes deberán planear su recuperación ante desastres entre regiones en función de sus necesidades de RTO/RPO.

Elija la mejor región para sus necesidades en función de las consideraciones técnicas y normativas: funcionalidades del servicio, residencia de datos, requisitos de cumplimiento y latencia, y comience a mejorar su estrategia de confiabilidad. Para obtener más información, consulte Regiones y zonas de disponibilidad de Azure.

Dependencias del servicio de Azure

Los servicios de Microsoft Azure están disponibles globalmente para impulsar las operaciones en la nube a un nivel óptimo.

Los servicios de Azure que se implementan en regiones de Azure se indican en la página de productos de Infraestructura global de Azure. Para conocer mejor las regiones y Availability Zones en Azure, consulte Regiones y Availability Zones en Azure.

Los servicios de Azure se crean para lograr confiabilidad, que incluye alta disponibilidad y recuperación ante desastres. No hay ningún servicio que dependa de un único centro de datos lógico (para evitar puntos de error únicos). Los servicios no regionales que se enumeran en productos de Infraestructura global de Azure son servicios para los que no hay ninguna dependencia en una región específica de Azure. Los servicios no regionales se implementan en dos o más regiones y, si hay un error regional, la instancia del servicio en otra región sigue atendiendo a los clientes. Algunos servicios no regionales permiten a los clientes especificar la región en la que se implementará la máquina virtual (VM) subyacente en la que se ejecuta el servicio. Por ejemplo, Azure Virtual Desktop permite a los clientes especificar la ubicación de la región donde reside la máquina virtual. Todos los servicios de Azure que almacenan datos de cliente permiten al cliente especificar las regiones concretas en las que se almacenarán los datos. La excepción es Microsoft Entra ID, que tiene ubicación geográfica (como Europa o Norteamérica). Para obtener más información acerca de la residencia del almacenamiento de datos, consulte el mapa de residencia de datos.

Si necesita comprender las dependencias entre los servicios de Azure para diseñar mejor sus aplicaciones y servicios, puede ponerse en contacto con el representante de ventas o clientes de Microsoft para solicitar la documentación de dependencias de los servicios de Azure. En este documento se enumeran las dependencias de los servicios de Azure, incluidas las dependencias de los principales servicios internos comunes, como los de plano de control. Para obtener esta documentación, debe ser un cliente de Microsoft y tener el acuerdo de confidencialidad (NDA) adecuado con Microsoft.

Pasos siguientes