Metodología de diseño para cargas de trabajo críticas en Azure
La creación de una aplicación crítica en cualquier plataforma en la nube requiere una gran experiencia técnica e inversión en ingeniería, especialmente porque hay una complejidad significativa asociada a:
- Descripción de la plataforma en la nube,
- Elegir los servicios y la composición adecuados,
- Aplicación de la configuración correcta del servicio,
- Operacionalización de los servicios utilizados y
- Alinearse constantemente con los procedimientos recomendados y las hojas de ruta de servicio más recientes.
Esta metodología de diseño se esfuerza por proporcionar una ruta de diseño fácil de seguir para ayudar a navegar por esta complejidad e informar a las decisiones de diseño necesarias para generar una arquitectura de destino óptima.
1: Diseño para requisitos empresariales
No todas las cargas de trabajo críticas tienen los mismos requisitos. Espere que las consideraciones de revisión y las recomendaciones de diseño proporcionadas por esta metodología de diseño produzcan diferentes decisiones de diseño y desventajas para diferentes escenarios de aplicación.
Selección de un nivel de confiabilidad
La confiabilidad es un concepto relativo y para que cualquier carga de trabajo sea adecuadamente confiable, debe reflejar los requisitos empresariales que lo rodean. Por ejemplo, una carga de trabajo crítica con un objetivo de nivel de servicio (SLO) de disponibilidad del 99,999 % requiere un nivel de confiabilidad mucho mayor que otra carga de trabajo menos crítica con un SLO del 99,9 %.
Esta metodología de diseño aplica el concepto de niveles de confiabilidad expresados como SLO de disponibilidad para informar de las características de confiabilidad necesarias. En la tabla siguiente se capturan los presupuestos de errores permitidos asociados a los niveles de confiabilidad comunes.
| Nivel de confiabilidad (SLO de disponibilidad) | Tiempo de inactividad permitido (semana) | Tiempo de inactividad permitido (mes) | Tiempo de inactividad permitido (año) |
|---|---|---|---|
| 99,9 % | 10 minutos, 4 segundos | 43 minutos, 49 segundos | 8 horas, 45 minutos, 56 segundos |
| 99,95 % | 5 minutos, 2 segundos | 21 minutos, 54 segundos | 4 horas, 22 minutos, 58 segundos |
| 99,99% | 1 minutos | 4 minutos 22 segundos | 52 minutos, 35 segundos |
| 99,999 % | 6 segundos | 26 segundos | 5 minutos, 15 segundos |
| 99.9999% | <1 segundo | 2 segundos | 31 segundos |
Importante
Esta metodología de diseño considera que el SLO de disponibilidad es más que un tiempo de actividad simple, sino un nivel coherente de servicio de aplicación en relación con un estado de aplicación correcto conocido.
Como ejercicio inicial, se recomienda a los lectores seleccionar un nivel de confiabilidad de destino al determinar cuánto tiempo de inactividad es aceptable? En última instancia, la búsqueda de un nivel de confiabilidad determinado tendrá un efecto significativo en la ruta de diseño y las decisiones de diseño abarcadas, lo que dará lugar a una arquitectura de destino diferente.
En esta imagen se muestra cómo los distintos niveles de confiabilidad y los requisitos empresariales subyacentes influyen en la arquitectura de destino para una implementación de referencia conceptual, especialmente en relación con el número de implementaciones regionales y las tecnologías globales utilizadas.
para la
El objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO) son aspectos críticos a la hora de determinar la confiabilidad necesaria. Por ejemplo, si se esfuerza por lograr un RTO de aplicación de menos de un minuto, es probable que las estrategias de recuperación basadas en copias de seguridad o una estrategia de implementación activa-pasiva no sean suficientes.
2: Evaluar las áreas de diseño mediante los principios de diseño
En el núcleo de esta metodología se encuentra una ruta de diseño crítica formada por:
- Principios básicos de diseño
- Área de diseño fundamental con decisiones de diseño muy relacionadas y dependientes.
El impacto de las decisiones tomadas en cada área de diseño reverberará entre otras áreas de diseño y decisiones de diseño. Revise las consideraciones y recomendaciones proporcionadas para comprender mejor las consecuencias de las decisiones abarcadas, lo que puede producir inconvenientes en áreas de diseño relacionadas.
Por ejemplo, para definir una arquitectura de destino, es fundamental determinar cómo supervisar mejor el estado de la aplicación en los componentes clave. Se recomienda encarecidamente revisar el área de diseño de modelado de estado mediante las recomendaciones descritas para ayudar a tomar decisiones.
3: Implementación de la primera aplicación crítica
Consulte estas arquitecturas de referencia que describen las decisiones de diseño basadas en esta metodología.
Arquitectura de línea base de una aplicación accesible desde Internet
Arquitectura de línea base de una aplicación accesible desde Internet con controles de red
Sugerencia
La arquitectura está respaldada por la implementación de Mission-Critical Online que ilustra las recomendaciones de diseño.
Artefactos de nivel de producción Todos los artefactos técnicos están listos para su uso en entornos de producción con todos los aspectos operativos de un extremo a otro considerados.
Basado en experiencias reales Todas las decisiones técnicas se guían por experiencias de clientes de Azure y lecciones aprendidas de la implementación de esas soluciones.
Alineación de la hoja de ruta de Azure Las arquitecturas de referencia críticas tienen su propia hoja de ruta que está alineada con las hojas de ruta del producto de Azure.
4: Integración de la carga de trabajo en zonas de aterrizaje de Azure
Las suscripciones de zona de aterrizaje de Azure proporcionan una infraestructura compartida para las implementaciones empresariales que necesitan una gobernanza centralizada.
Es fundamental evaluar qué caso de uso de conectividad requiere la aplicación crítica. Las zonas de aterrizaje de Azure admiten dos arquetipos principales separados en distintos ámbitos del grupo de administración: Online o Corp. como se muestra en esta imagen.
Suscripción en línea
Una carga de trabajo crítica funciona como una solución independiente, sin conectividad directa de red corporativa con el resto de la arquitectura de la zona de aterrizaje de Azure. La aplicación se protegerá aún más a través de la gobernanza basada en directivas y se integrará automáticamente con el registro de plataforma centralizado a través de la directiva.
La arquitectura de línea base y la implementación de Mission-Critical Online se alinean con el enfoque en línea.
Suscripción corp.
Cuando se implementa en una suscripción corp. una carga de trabajo crítica depende de la zona de aterrizaje de Azure para proporcionar recursos de conectividad. Este enfoque permite la integración con otras aplicaciones y servicios compartidos. Deberá diseñar en torno a algunos recursos fundamentales, que existirán por adelantado como parte de la plataforma de servicio compartido. Por ejemplo, la marca de implementación regional ya no debe abarcar una Virtual Network efímera o una zona de Azure DNS privado, ya que estas existirán en la suscripción corp.
Para empezar a trabajar con este caso de uso, se recomienda la arquitectura de línea base en una arquitectura de referencia de zona de aterrizaje de Azure.
Sugerencia
La arquitectura anterior está respaldada por la implementación conectada de Mission-Critical .
5: Implementación de un entorno de aplicación de espacio aislado
En paralelo a las actividades de diseño, se recomienda encarecidamente establecer un entorno de aplicación de espacio aislado mediante las implementaciones de referencia de Mission-Critical.
Esto proporciona oportunidades prácticas para validar las decisiones de diseño mediante la replicación de la arquitectura de destino, lo que permite evaluar rápidamente la incertidumbre de diseño. Si se aplica correctamente con la cobertura de requisitos representativa, la mayoría de los problemas problemáticos probablemente dificultan el progreso se pueden descubrir y abordar posteriormente.
6: evoluciona continuamente con las hojas de ruta de Azure
Las arquitecturas de aplicación establecidas con esta metodología de diseño deben seguir evolucionando en consonancia con las hojas de ruta de la plataforma Azure para admitir la sostenibilidad optimizada.
Paso siguiente
Revise los principios de diseño para escenarios de aplicaciones críticas.