Este explorador ya no se admite.
Actualice a Microsoft Edge para aprovechar las características y actualizaciones de seguridad más recientes, y disponer de soporte técnico.
En este artículo se presenta un patrón clave para arquitecturas críticas en Azure. Aplique este patrón al iniciar el proceso de diseño y, a continuación, seleccione los componentes que sean más adecuados para sus requisitos empresariales. El artículo recomienda un enfoque de diseño de brújula e incluye otros ejemplos con componentes tecnológicos comunes.
Se recomienda evaluar las áreas de diseño clave, definir los flujos críticos de usuario y sistema que usan los componentes subyacentes y desarrollar una matriz de recursos de Azure y su configuración, teniendo en cuenta las siguientes características.
| Característica | Consideraciones |
|---|---|
| Período de duración | ¿Cuál es la duración esperada del recurso, en relación con otros recursos de la solución? ¿Debe el recurso sobrevivir o tener la misma duración que todo el sistema o región, o debería ser temporal? |
| Estado | ¿Qué impacto tendrá el estado persistente en esta capa en cuanto a confiabilidad o manejabilidad? |
| Cobertura | ¿Es necesario distribuir globalmente el recurso? ¿El recurso puede comunicarse con otros recursos, ubicados globalmente o dentro de esa región? |
| Dependencias | ¿Cuáles son las dependencias de otros recursos? |
| Límites de escala | ¿Cuál es el rendimiento esperado para ese recurso? ¿Cuánta escala proporciona el recurso para ajustarse a esa demanda? |
| Disponibilidad o recuperación ante desastres | ¿Cuál es el impacto en la disponibilidad de un desastre en esta capa? ¿Provocaría una interrupción sistémica o solo un problema de disponibilidad o capacidad localizada? |
Importante
Este artículo forma parte de la serie de Cargas de trabajo críticas diseñadas correctamente de Azure. Si no está familiarizado con esta serie, se recomienda empezar con ¿qué es una carga de trabajo crítica?
Algunos recursos se comparten globalmente mediante recursos implementados dentro de cada región. Algunos ejemplos comunes son los recursos que se usan para distribuir el tráfico entre varias regiones, almacenar el estado permanente de toda la aplicación y supervisar los recursos para ellos.
| Característica | Consideraciones |
|---|---|
| Duración de vida | Se espera que estos recursos sean de larga vida (no efímeros). Su duración abarca la vida del sistema o más tiempo. A menudo, los recursos se administran con actualizaciones locales del plano de datos y el plano de control, suponiendo que admitan operaciones de actualización sin tiempo de inactividad. |
| Estado | Dado que estos recursos existen durante al menos la vigencia del sistema, esta capa suele ser responsable de almacenar el estado global y replicado geográficamente. |
| Cobertura | Los recursos deben distribuirse y replicarse globalmente en las regiones que hospedan esos recursos. Se recomienda que estos recursos se comuniquen con recursos regionales u otros recursos con baja latencia y la coherencia deseada. |
| Dependencias | Los recursos deben evitar las dependencias de los recursos regionales porque su falta de disponibilidad puede ser una causa de error global. Por ejemplo, los certificados o secretos guardados en una única bóveda podrían tener un impacto global si se produce un fallo regional donde se encuentra la bóveda. |
| Límites de escala | A menudo, estos recursos son instancias singleton en el sistema y deben poder escalar de forma que puedan controlar el rendimiento del sistema en su conjunto. |
| Disponibilidad o recuperación ante desastres | Los recursos regionales y de sellos pueden usar recursos globales. Es fundamental que los recursos globales estén configurados con alta disponibilidad y recuperación ante desastres para el estado de todo el sistema. |
El sello contiene la aplicación y los recursos que participan en la ejecución de transacciones comerciales. Normalmente, un sello corresponde a una implementación en una región de Azure. Aunque una región puede tener más de un sello.
| Característica | Consideraciones |
|---|---|
| Período de duración | Se espera que los recursos tengan un período de vida corto (efímero) con la intención de que se puedan agregar y quitar dinámicamente mientras los recursos regionales fuera del stamp se continúan conservando. La naturaleza efímera es necesaria para proporcionar más resistencia, escala y proximidad a los usuarios. |
| Estado | Dado que los sellos son efímeros y se destruirán con cada implementación, un sello no debe tener estado siempre que sea posible. |
| Cobertura | Puede comunicarse con recursos regionales y globales. Sin embargo, se debe evitar la comunicación con otras regiones u otros sellos. |
| Dependencias | Los recursos de stamp deben ser independientes. Se espera que tengan dependencias regionales y globales, pero no deben depender de componentes de otros sellos en las mismas regiones u otras regiones. |
| Límites de escala | El rendimiento se establece mediante pruebas. El rendimiento general del stamp está limitado al recurso con menor rendimiento. El rendimiento del sello debe estimar el alto nivel de demanda causado por una conmutación por error a otro sello. |
| Disponibilidad o recuperación ante desastres | Debido a la naturaleza temporal de los sellos, la recuperación ante desastres se realiza mediante la reimplementación de la marca. Si los recursos están en un estado incorrecto, se puede destruir y volver a implementar el stamp en su conjunto. |
Un sistema puede tener recursos que se implementan en la región, pero pueden sobrevivir a los recursos de stamp. Por ejemplo, los recursos de observabilidad que supervisan los recursos en el nivel regional, incluidos los sellos.
| Característica | Consideración |
|---|---|
| Duración de vida | Los recursos comparten la duración de la región y sobreviven a los recursos de stamp. |
| Estado | El estado almacenado en una región no puede perdurar más allá de la duración de la región. Si el estado debe compartirse entre regiones, considere la posibilidad de usar un almacén de datos global. |
| Cobertura | Los recursos no necesitan distribuirse globalmente. La comunicación directa con otras regiones debe evitarse a todo costo. |
| Dependencias | Los recursos pueden tener dependencias en los recursos globales, pero no en los recursos de sello porque los sellos están diseñados para ser de corta duración. |
| Límites de escala | Determina el límite de escala de los recursos regionales combinando todas las estampillas de la región. |
Estos ejemplos de línea de base sirven como la arquitectura de estrella norte recomendada para aplicaciones críticas. La línea base recomienda encarecidamente la contenedorización y el uso de un orquestador de contenedores para la plataforma de aplicaciones. La línea base usa Azure Kubernetes Service (AKS).
Consulte Cargas de trabajo críticas diseñadas correctamente: Contenedorización.
Si acaba de iniciar su recorrido de misión crítica, use esta arquitectura como referencia. Se accede a la carga de trabajo a través de un punto de conexión público y no requiere conectividad de red privada con otros recursos de la empresa.
Esta arquitectura se basa en la arquitectura de línea base. El diseño se extiende para proporcionar controles de red estrictos para evitar el acceso público no autorizado desde Internet a los recursos de carga de trabajo.
Esta arquitectura es adecuada si va a implementar la carga de trabajo en una configuración empresarial en la que se requiere la integración dentro de una organización más amplia. La carga de trabajo usa servicios compartidos centralizados, necesita conectividad local e se integra con otras cargas de trabajo dentro de la empresa. Se implementa en una suscripción de zona de aterrizaje de Azure que hereda del grupo de administración Corp.
Esta arquitectura amplía la referencia de línea base considerando App Services como tecnología principal de hospedaje de aplicaciones, lo que proporciona un entorno fácil de usar para las implementaciones de contenedores.
Se recomienda usar la guía de diseño proporcionada para navegar por las decisiones clave de diseño para alcanzar una solución óptima. Para obtener información, consulte ¿Cuáles son las áreas de diseño clave?
Revise los procedimientos recomendados para diseñar escenarios de aplicación críticos.