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 más adecuados para sus requisitos empresariales. El artículo recomienda un enfoque de diseño de star norte 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? ¿El recurso debe sobrevivir o compartir la duración con todo el sistema o la región, o debería ser temporal? |
| State | ¿Qué impacto tendrá el estado persistente en esta capa en cuanto a confiabilidad o capacidad de administración? |
| 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 escalado | ¿Cuál es el rendimiento esperado para ese recurso? ¿Cuánta escala proporciona el recurso para ajustarse a esa demanda? |
| Disponibilidad y 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 una capacidad localizada o un problema de disponibilidad? |
Importante
Este artículo forma parte de la serie de cargas de trabajo críticas de Azure Well-Architected . Si no está familiarizado con esta serie, se recomienda empezar con lo que es una carga de trabajo crítica?
Algunos recursos se comparten globalmente mediante los recursos implementados dentro de cada región. Los 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 |
|---|---|
| Período de duración | 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. |
| State | Dado que estos recursos existen durante al menos la duración 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 los recursos regionales u otros recursos con baja latencia y la coherencia deseada. |
| Dependencias | Los recursos deben evitar dependencias en los recursos regionales porque su falta de disponibilidad puede ser una causa de error global. Por ejemplo, los certificados o secretos guardados en un único almacén podrían tener un impacto global si se produce un error en la región en la que se encuentra el almacén. |
| Límites de escalado | A menudo, estos recursos son instancias singleton del sistema y deben poder escalar de forma que puedan controlar el rendimiento del sistema en su conjunto. |
| Disponibilidad y recuperación ante desastres | Los recursos regionales y de stamp 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. |
La marca contiene la aplicación y los recursos que participan en la realización de transacciones empresariales. Normalmente, un stamp se corresponde a una implementación en una región de Azure. Aunque una región puede tener más de un stamp.
| 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. Esta naturaleza efímera es necesaria para proporcionar más resistencia, escala y proximidad a los usuarios. |
| State | Dado que los sellos son efímeros y se destruirán con cada implementación, un sello debe ser sin estado tanto como sea posible. |
| Cobertura | Pueden comunicarse con los recursos regionales y globales. Sin embargo, se debe evitar la comunicación con otras regiones u otros stamps. |
| Dependencias | Los recursos de stamp deben ser independientes. Se espera que tengan dependencias regionales y globales, pero no deben depender de los componentes de otros sellos de la misma región u otras regiones. |
| Límites de escalado | El rendimiento se establece mediante las pruebas. El rendimiento general del stamp está limitado al recurso con menor rendimiento. El rendimiento del stamp debe calcular el alto nivel de demanda causado por una conmutación por error a otra marca. |
| Disponibilidad y recuperación ante desastres | Debido a la naturaleza temporal de los stamps, la recuperación ante desastres se lleva a cabo mediante la reimplementación del stamp. 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 |
|---|---|
| Período de duración | Los recursos comparten la duración de la región y sobreviven a los recursos de stamp. |
| State | El estado almacenado en una región no puede vivir más allá de la duración de la región. Si se debe compartir el estado entre regiones, considere la posibilidad de usar un almacén de datos global. |
| Cobertura | No es necesario distribuir globalmente los recursos. Se debe evitar la comunicación directa con otras regiones a toda costa. |
| Dependencias | Los recursos pueden tener dependencias en los recursos globales, pero no en los recursos de stamp, ya que los stamps están diseñados para ser de corta duración. |
| Límites de escalado | Determine el límite de escala de los recursos regionales mediante la combinación de todos los sellos de la región. |
Estos ejemplos de línea base sirven como la arquitectura de star 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 bien diseñadas: Contenedorización.
Si acaba de iniciar el recorrido crítico, 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 amplía 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 de base teniendo en cuenta App Services como tecnología de hospedaje de aplicaciones principal, 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 de diseño clave 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 aplicaciones críticas.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de