Esta arquitectura de referencia proporciona instrucciones para implementar una carga de trabajo crítica que usa servicios compartidos centralizados, necesita conectividad local y se integra con otras cargas de trabajo de una empresa. Esta guía está pensada para un propietario de carga de trabajo que forma parte de un equipo de aplicaciones de la organización.
Es posible que se encuentre en esta situación cuando la organización quiera implementar la carga de trabajo en una zona de aterrizaje de aplicación de Azure que hereda el grupo de administración corporativa. Se espera que la carga de trabajo se integre con recursos compartidos aprovisionados previamente en la zona de aterrizaje de la plataforma Azure, administrados por equipos centralizados.
Importante
¿Qué es una zona de aterrizaje de Azure? Una zona de aterrizaje de aplicación es una suscripción de Azure en la que se ejecuta la carga de trabajo. Está conectada a los recursos compartidos de la organización. A través de esa conexión, tiene acceso a la infraestructura básica necesaria para ejecutar la carga de trabajo, como redes, administración de acceso a identidades, directivas y supervisión. Las zonas de aterrizaje de la plataforma son una colección de varias suscripciones, cada una con una función específica. Por ejemplo, la suscripción de conectividad proporciona una resolución DNS centralizada, conectividad local y aplicaciones virtuales de red (NVA) que están disponibles para su uso por parte de los equipos de aplicaciones.
Como propietario de la carga de trabajo, se beneficia al delegar la administración de recursos compartidos a equipos centrales y concentrar los esfuerzos en el desarrollo de cargas de trabajo. La organización se beneficia al aplicar una gobernanza coherente y amortizar los costos entre varias cargas de trabajo.
Se recomienda encarecidamente entender bien el concepto de zona de aterrizaje de Azure.
En este enfoque, la confiabilidad máxima es una responsabilidad compartida entre el usuario y el equipo de la plataforma. Los componentes administrados de forma centralizada deben ser totalmente de confianza para que una carga de trabajo crítica funcione según lo previsto. Debe existir una relación de confianza con el equipo de la plataforma para que los problemas de falta de disponibilidad en los servicios centralizados, que afectan a la carga de trabajo, se mitiguen en el nivel de plataforma. Sin embargo, el equipo es responsable de impulsar los requisitos con el equipo de la plataforma para lograr sus objetivos.
Esta arquitectura se basa en la arquitectura de línea base crítica con controles de red. Se recomienda que se familiarice con la arquitectura de línea de base antes de continuar con este artículo.
Nota:
La guía está respaldada por una implementación de ejemplo de nivel de producción que muestra el desarrollo de aplicaciones críticas en Azure. Esta implementación se puede usar como base para el desarrollo de soluciones adicionales como el primer paso hacia la producción.
Estrategias de diseño principales
Aplicación de estas estrategias sobre la línea de base crítica:
Ruta crítica
No es necesario que todos los componentes de la arquitectura sean de igual confianza. La ruta crítica incluye los componentes que deben mantenerse en funcionamiento para que la carga de trabajo no experimente tiempo de inactividad o se vea deteriorado el rendimiento. Mantener esa ruta limpia minimizará los puntos de error.
Ciclo de vida de los componentes
Tenga en cuenta el ciclo de vida de los componentes críticos puesto que influye en el objetivo de lograr un tiempo de inactividad cercano a cero. Los componentes pueden ser recursos efímeros o de corta duración, que se pueden crear y destruir en función de la necesidad; o bien, recursos no efímeros o de larga duración que comparten la duración con el sistema o la región.
Dependencias externas
Minimice las dependencias externas en componentes y procesos, puesto que puede introducir puntos de error. La arquitectura tiene recursos que son propiedad de varios equipos fuera de su equipo. Esos componentes (si son críticos) están en el ámbito de esta arquitectura.
Topología de la suscripción
Las zonas de aterrizaje de Azure no implican una topología de suscripción única. Planee la superficie de suscripción de antemano con el equipo de la plataforma para adaptarse a los requisitos de confiabilidad de la carga de trabajo en todos los entornos.
Observabilidad autónoma en la ruta crítica
Se recomienda disponer de recursos de supervisión dedicados que permitan al equipo consultar rápidamente su recopilación de datos (especialmente la ruta crítica) y llevar a cabo correcciones.
Architecture
Descargue un archivo Visio de esta arquitectura.
Los componentes de esta arquitectura son los mismos que los de la arquitectura de línea base crítica con controles de red. Las descripciones son cortas para una mayor brevedad. Si necesita más información, consulte los artículos enlazados. Para obtener documentación del producto sobre los servicios de Azure, consulte Recursos relacionados.
Recursos globales
Estos recursos residen en las suscripciones de la zona de aterrizaje de la aplicación. Los recursos globales no son efímeros y comparten la duración del sistema. Los servicios de Azure y la configuración siguen siendo los mismos que los recursos globales de línea de base.
Recursos de redes regionales
Estos recursos residen en las suscripciones de la zona de aterrizaje de la plataforma y en las de la zona de aterrizaje de la aplicación. La arquitectura de línea de base implementa todos los recursos que pertenecen al usuario. Sin embargo, en esta arquitectura, los recursos de red se proporcionan a través de la suscripción de conectividad y se aprovisionan como parte de la zona de aterrizaje de la plataforma.
En este artículo, consulte la sección Red virtual del centro de conectividad regional.
Recursos de marcas regionales
Estos recursos residen en las suscripciones de la zona de aterrizaje de la aplicación. Estos recursos no comparten nada con otros recursos, excepto los recursos globales.
La mayoría de los servicios de Azure y la configuración siguen siendo los mismos que los de la arquitectura de marcas de línea de base, excepto los recursos de red, que el equipo de la plataforma aprovisiona previamente.
En este artículo, consulte la sección Red virtual de radio regional.
Recursos externos
La carga de trabajo interactúa con los recursos locales. Algunos de ellos se encuentran en la ruta crítica de la carga de trabajo, por ejemplo, una base de datos local. Estos recursos y la comunicación con ellos se tienen en cuenta en el Acuerdo de Nivel de Servicio (SLA) compuesto general de la carga de trabajo. Toda la comunicación se realiza a través de la suscripción de conectividad. Hay otros recursos externos a los que puede llegar la carga de trabajo, pero no se consideran críticos.
Recursos de canalización de implementación
Las canalizaciones de compilación y versión para una aplicación crítica deben automatizarse completamente para garantizar una manera coherente de implementar una marca validada. Estos recursos siguen siendo los mismos que los de la canalización de implementación de línea de base.
Recursos de supervisión regional
Estos recursos residen en las suscripciones de la zona de aterrizaje de la aplicación. Los datos de supervisión de los recursos globales y regionales se almacenan de forma independiente. Los servicios de Azure y la configuración siguen siendo los mismos que los recursos de supervisión de línea de base.
En este artículo, consulte la sección Consideraciones de supervisión.
Recursos de administración
Para obtener acceso al clúster de proceso privado y a otros recursos, esta arquitectura usa agentes de compilación privados e instancias de máquinas virtuales de jump box. Azure Bastion proporciona acceso seguro a los jump box. Los recursos dentro de las marcas siguen siendo los mismos que los recursos de administración de línea de base.
Consideraciones sobre redes
En este diseño, la carga de trabajo se implementa en la zona de aterrizaje de la aplicación y necesita conectividad con los recursos federados en la zona de aterrizaje de la plataforma. El propósito podría ser acceder a los recursos locales, controlar el tráfico de salida, etc.
Topología de red
El equipo de la plataforma escoge la topología de red para toda la organización. En esta arquitectura se asume la topología en estrella tipo hub-and-spoke. Una alternativa podría ser Azure Virtual WAN.
Red virtual del centro regional
La suscripción de conectividad contiene una red virtual de centro con recursos, que toda la organización comparte. Estos recursos son propiedad del equipo de la plataforma que también los mantiene.
Desde una perspectiva crítica, esta red no es efímera y estos recursos se encuentran en la ruta crítica.
| Recurso de Azure | Propósito |
|---|---|
| Información técnica de ExpressRoute | Proporciona conectividad privada desde el entorno local a la infraestructura de Azure. |
| Azure Firewall | Actúa como la NVA que inspecciona y restringe el tráfico de salida. |
| DNS de Azure | Proporciona resolución de nombres entre locales. |
| VPN Gateway | Conecta las ramas remotas de la organización a través de la red pública de Internet a la infraestructura de Azure. También actúa como una alternativa de conectividad de copia de seguridad para agregar resistencia. |
Los recursos se aprovisionan en cada región y se emparejan con la red virtual de radio (se describe a continuación). Asegúrese de entender bien y aceptar las actualizaciones de NVA, reglas de firewall, reglas de enrutamiento, conmutación por error de ExpressRoute a VPN Gateway, infraestructura DNS, etc.
Nota:
Una ventaja clave en el uso del centro federado es que la carga de trabajo se puede integrar con otras cargas de trabajo en Azure o entre locales recorriendo los centros de red administrados por la organización. Este cambio también reduce los costos operativos porque una parte de la responsabilidad se desplaza al equipo de la plataforma.
Red virtual de radio regional
La zona de aterrizaje de la aplicación tiene al menos dos redes virtuales de Azure aprovisionadas previamente, por región, a las que hacen referencia las marcas regionales. Estas redes no son efímeras. Una atiende el tráfico de producción y la otra tiene como destino la implementación de vNext. Este enfoque le ofrece la capacidad de realizar prácticas de implementaciones de confianza y seguras.
Red virtual de operaciones
El tráfico operativo está aislado en una red virtual independiente. Esta red virtual no es efímera y el usuario es el propietario. Esta arquitectura mantiene el mismo diseño que la arquitectura de línea de base con controles de red.
No hay emparejamiento entre la red de operaciones y la red de radio. Toda la comunicación es a través de vínculos privados.
Responsabilidades compartidas
Entender perfectamente qué equipo es responsable de cada elemento de diseño de la arquitectura. Estas son algunas áreas clave.
Planeación de direcciones IP
Una vez que haya estimado el tamaño necesario para ejecutar la carga de trabajo, trabaje con el equipo de la plataforma para que puedan aprovisionar la red correctamente.
Equipo de plataforma
Proporcione direcciones distintas para las redes virtuales que participan en emparejamientos. Las direcciones superpuestas, por ejemplo, de redes locales y de carga de trabajo, pueden provocar interrupciones.
Asigne espacios de direcciones IP lo suficientemente grandes como para contener los recursos de tiempo de ejecución e implementaciones, controlar las conmutaciones por error y admitir escalabilidad.
La red virtual y los emparejamientos aprovisionados previamente deben ser capaces de admitir el crecimiento esperado de la carga de trabajo. Debe evaluar ese crecimiento con el equipo de la plataforma con regularidad. Para más información, consulte Conectividad a Azure.
Subred de red de radios regionales
Es responsable de asignar subredes en la red virtual regional. Las subredes y los recursos en estos son efímeros. El espacio de direcciones debe ser lo suficientemente grande como para dar cabida al crecimiento potencial.
Subred de puntos de conexión privados Una vez que el tráfico llega a la red virtual, la comunicación con los servicios PaaS dentro de la red se restringe mediante puntos de conexión privados, al igual que la arquitectura de línea de base con controles de red. Estos puntos de conexión se colocan en una subred dedicada. Las direcciones IP privadas a los puntos de conexión privados se asignan desde esa subred.
Subred del clúster Los requisitos de escalabilidad de la carga de trabajo influyen en la cantidad de espacio de direcciones que se debe asignar para las subredes. A medida que los nodos y pods de AKS se escalan horizontalmente, las direcciones IP se asignan desde esta subred.
Segmentación de red
Mantenga la segmentación adecuada para que un acceso no autorizado no ponga en peligro la confiabilidad de la carga de trabajo.
Esta arquitectura usa grupos de seguridad de red (NSG) para restringir el tráfico entre subredes y la suscripción de conectividad. Los grupos de seguridad de red usan ServiceTags para los servicios admitidos.
Equipo de plataforma
Aplique el uso de grupos de seguridad de red mediante directivas de administrador de red de Azure.
Tenga en cuenta el diseño de la carga de trabajo. No hay tráfico directo entre las marcas. Tampoco hay flujos de transferencia de datos entre regiones. Si se necesitan esas rutas de acceso, el tráfico debe fluir a través de la suscripción de conectividad.
Evite que el tráfico de centro de conectividad innecesario procedente de otras cargas de trabajo entre en la carga de trabajo crítica.
Tráfico de salida de marcas regionales
Todo el tráfico saliente de cada red de radio regional se enruta a través del Azure Firewall centralizado en la red de centro regional. Actúa como el próximo salto que inspecciona y, a continuación, permite o deniega el tráfico.
Equipo de plataforma
Creación de UDR para esa ruta personalizada.
Asigne directivas de Azure que impedirán que el equipo de la aplicación cree subredes que no tengan la nueva tabla de rutas.
Conceda permisos adecuados de control de acceso basado en rol (RBAC) al equipo de la aplicación para que puedan ampliar las rutas en función de los requisitos de la carga de trabajo.
Redundancia de red de varias regiones
Las cargas de trabajo críticas deben implementarse en varias regiones para resistir interrupciones regionales. Trabaje con el equipo de la plataforma para asegurarse de que la infraestructura es de confianza.
Equipo de plataforma
Implemente recursos de red centralizados por región. La metodología de diseño crítica requiere aislamiento regional.
Trabaje con el equipo de aplicaciones para descubrir dependencias regionales ocultas para que un recurso de plataforma degradado en una región no afecte a las cargas de trabajo de otra región.
Resolución DNS
La suscripción de conectividad proporciona zonas DNS privadas. Sin embargo, ese enfoque centralizado podría no tener en cuenta las necesidades de DNS que podrían ser específicas del caso de uso del usuario. Se recomiendo aprovisionar zonas DNS propias y vincular a la marca regional. Si el equipo de la aplicación no tiene DNS, la administración de vínculos privados se convierte en un desafío para los recursos globales, como Azure Cosmos DB.
Equipo de plataforma
Delegue las zonas de Azure DNS privado al equipo de la aplicación para cubrir sus casos de uso.
Para la red del centro de conectividad regional, establezca el valor de los servidores DNS en Predeterminado (proporcionado por Azure) para admitir zonas DNS privadas administradas por el equipo de la aplicación.
Consideraciones sobre el diseño del entorno
Colocar cargas de trabajo en entornos independientes para producción, producción previa y desarrollo, es una práctica general. A continuación, se indican algunas consideraciones clave.
¿Cómo se mantiene el aislamiento?
El entorno de producción debe estar aislado de otros entornos. Los entornos inferiores también deben mantener un nivel de aislamiento. Se recomienda evitar compartir recursos propiedad de la aplicación entre entornos.
Se requiere un entorno de producción para los recursos globales, regionales y de marca que pertenecen al equipo de la aplicación. Los entornos de producción previa, como el almacenamiento provisional y la integración, son necesarios para garantizar que la aplicación se prueba en un entorno que simula la producción, tanto como sea posible. El entorno de desarrollo debe ser una versión de producción reducida verticalmente.
¿Cuál es el ciclo de vida esperado?
Los entornos de producción previa se pueden destruir una vez completadas las pruebas de validación. Se recomienda que los entornos de desarrollo compartan la duración de una característica y se destruyan cuando se complete el desarrollo. Estas acciones se realizan mediante la automatización de la integración continua y la implementación continua (CI/CD).
¿Cuáles son los inconvenientes?
Tenga en cuenta los inconvenientes entre el aislamiento de entornos, la complejidad de administración y la optimización de costos.
Sugerencia
Todos los entornos deben depender de instancias de producción de recursos externos, incluidos los recursos de plataforma. Por ejemplo, un centro regional de producción en la suscripción de conectividad. Podrá minimizar la diferencia entre entornos de producción y producción previa.
Topología de suscripción para la infraestructura de carga de trabajo
El equipo de plataforma proporciona suscripciones. En función del número de entornos, solicitará varias suscripciones para una sola carga de trabajo. En función del tipo de entorno, es posible que algunos entornos necesiten suscripciones dedicadas, mientras que otros entornos se pueden consolidar en una suscripción.
Independientemente, trabaje con el equipo de plataforma para diseñar una topología que cumpla el objetivo de confiabilidad general de la carga de trabajo. Hay ventajas en compartir los recursos proporcionados por la plataforma entre entornos de la misma suscripción, ya que reflejará el entorno de producción.
Nota:
El uso de varias suscripciones para contener los entornos puede lograr el nivel de aislamiento necesario. Las suscripciones de zona de aterrizaje se heredan del mismo grupo de administración. Por lo tanto, se garantiza la coherencia con la producción para pruebas y validación.
Suscripción de producción
Puede haber límites de recursos en la suscripción que se le ha proporcionado. Si coloca todos esos recursos en una suscripción, puede alcanzar esos límites. En función de las unidades de escalado y la escala esperada, considere un modelo más distribuido. Por ejemplo,
Una suscripción que contiene tanto agentes de compilación de Azure DevOps como recursos globales.
Una suscripción por región. Contiene los recursos regionales, los recursos de marca y los jump box de las marcas regionales.
Esta es una topología de suscripción de ejemplo que se usa en esta arquitectura.
Suscripción de producción previa
Necesita al menos una suscripción. Puede ejecutar varios entornos independientes, aun así, se recomienda tener varios entornos en suscripciones dedicadas. Esta suscripción también puede estar sujeta a límites de recursos, como la suscripción de producción, descrita anteriormente.
Suscripción de desarrollo
Necesita al menos una suscripción. Esta suscripción puede estar sujeta a límites de recursos si ejecuta todos los entornos independientes. Por lo tanto, puede solicitar varias suscripciones. Se recomienda tener entornos individuales en sus suscripciones dedicadas.
Intente hacer coincidir la topología de producción tanto como sea posible.
Consideraciones de la implementación
Las implementaciones que no funcionan o las versiones erróneas son causas habituales de interrupciones de aplicación. Haga pruebas de forma exhaustiva en la aplicación (y en las nuevas características) como parte del ciclo de vida de la aplicación. Al implementar la carga de trabajo en una zona de aterrizaje, deberá integrar el diseño con los recursos y la gobernanza proporcionados por la plataforma.
Consulte Cargas de trabajo críticas diseñadas correctamente: Implementación y pruebas.
La infraestructura de implementación
La confiabilidad de la infraestructura de implementación, como los agentes de compilación y su red, suele ser tan importante como los recursos de entorno de ejecución de la carga de trabajo.
Esta arquitectura usa agentes de compilación privados para evitar el acceso no autorizado que puede afectar a la disponibilidad de la aplicación.
Se recomienda mantener el aislamiento entre los recursos de implementación. Debe enlazarse una infraestructura de implementación a las suscripciones de carga de trabajo para ese entorno. Si usa varios entornos en suscripciones de producción previa, cree una separación adicional limitando el acceso solo a esos entornos individuales. Los recursos de implementación por región se pueden considerar para que la infraestructura de implementación sea más de confianza.
Implementación sin tiempo de inactividad
Las actualizaciones de la aplicación pueden provocar interrupciones. La aplicación de implementaciones coherentes aumentará la confiabilidad. Se recomiendan estos enfoques:
- Tener canalizaciones de implementación totalmente automatizadas.
- Implementar actualizaciones en entornos de producción previa en una marca limpia.
Para obtener más información, consulte Directrices de pruebas e implementación críticas.
En la arquitectura de línea de base, esas estrategias se implementan al desaprovisionar y al anular la marca con cada actualización. En este diseño, no es posible llevar a cabo el desaprovisionamiento completo porque el equipo de la plataforma es propietario de algunos recursos. Por lo tanto, se ha cambiado el modelo de implementación.
Modelo de implementación
La arquitectura de línea de base usa el modelo Blue-Green para implementar actualizaciones de aplicaciones. Las nuevas marcas con cambios se implementan junto con las marcas existentes. Después de trasladar el tráfico a la nueva marca, se destruye la marca existente.
En este caso, la red virtual emparejada especificada no es efímera. La marca no puede crear la red virtual ni el emparejamiento en el centro regional. Tendrá que volver a usar esos recursos en cada implementación.
El modelo de valor controlado puede lograr una implementación segura con la opción de revertir. En primer lugar, se implementa una nueva marca con cambios de código. La canalización de implementación hace referencia a la red virtual aprovisionada previamente y asigna subredes, implementa recursos y agrega puntos de conexión privados. A continuación, desplaza el tráfico a estas subredes en esta red virtual aprovisionada previamente.
Cuando la marca existente ya no es necesaria, la canalización elimina todos los recursos de marca, excepto los recursos propiedad de la plataforma. Se conserva la red virtual, la configuración de diagnóstico, el emparejamiento, el espacio de direcciones IP, la configuración de DNS y el control de acceso basado en rol (RBAC). En este punto, la marca está en un estado limpio y lista para la siguiente implementación.
Directivas de Azure de DINE (deploy-if-not-exists)
Es posible que las zonas de aterrizaje de aplicaciones de Azure tengan directivas de Azure DINE (deploy-if-not-exists). Estas comprobaciones garantizan que los recursos implementados cumplan los estándares corporativos en las zonas de aterrizaje de la aplicación, incluso cuando son propiedad del equipo de la aplicación. Es posible que haya una discrepancia entre la implementación y la configuración final del recurso.
Comprenda el impacto de todas las directivas de DINE que se aplicarán a los recursos. Si hay cambios en la configuración de recursos, incorpore la intención de las directivas en las implementaciones declarativas al principio del ciclo de desarrollo de la carga de trabajo. De lo contrario, puede haber un desfase que conduzca a diferencias entre el estado deseado y el estado implementado.
Administración de acceso a suscripciones de implementación
Trate los límites de suscripción como límites de seguridad para limitar el radio de explosión. Las amenazas pueden afectar a la confiabilidad de la carga de trabajo.
Equipo de plataforma
- Otorgue a los equipos de aplicación autorización para operaciones con permisos en el ámbito de la suscripción de la zona de aterrizaje de la aplicación.
Si ejecuta varias implementaciones dentro de una sola suscripción, ambas implementaciones se verán afectadas por una vulneración. Se recomienda ejecutar implementaciones en suscripciones dedicadas. Cree entidades de servicio por entorno para mantener la separación lógica.
La entidad de servicio debe proporcionar autonomía sobre los recursos de carga de trabajo. Además, debe tener restricciones que impidan la manipulación excesiva de los recursos de la plataforma dentro de la suscripción.
Consideraciones sobre supervisión
La plataforma de zona de aterrizaje de Azure proporciona recursos de observabilidad compartidos como parte de las suscripciones de administración. El equipo de operaciones centralizadas anima a los equipos de aplicación a usar el modelo federado. Sin embargo, en el caso de las cargas de trabajo críticas, no se recomienda un único almacén de observabilidad centralizado porque puede ser un único punto de error. Las cargas de trabajo críticas también generan datos de telemetría que podrían no ser aplicables o accionables para los equipos de operaciones centralizadas.
Por lo tanto, se recomienda encarecidamente un enfoque autónomo para la supervisión. Los operadores de carga de trabajo son, en última instancia, responsables de la supervisión y deben tener acceso a todos los datos que representan el estado general.
La arquitectura de línea de base sigue ese enfoque y continúa en esta arquitectura de referencia. Azure Log Analytics y Azure Application Insights se implementan de forma regional y global para supervisar los recursos en esos ámbitos. La agregación de registros, la creación de paneles y las alertas está en el ámbito del equipo. Aprovecha las funcionalidades de Azure Diagnostics que envían métricas y registros a varios receptores para admitir los requisitos de la plataforma para la recopilación de métricas de registro.
Modelo de estado
La metodología de diseño crítica requiere un modelo de estado del sistema. Al definir una puntuación de mantenimiento general, incluya los flujos de zona de aterrizaje de la plataforma en el ámbito de los que depende la aplicación. Compile consultas de registro, estado y alertas para realizar una supervisión entre áreas de trabajo.
Equipo de plataforma
Conceda receptores de registro de lectura y consulta de control de acceso basado en rol (RBAC) para recursos de plataforma pertinentes que se usan en la ruta crítica de la aplicación crítica.
Admita el objetivo organizativo de confiabilidad hacia la carga de trabajo crítica al conceder al equipo de la aplicación permisos suficientes para realizar las operaciones.
En esta arquitectura, el modelo de mantenimiento incluye registros y métricas de recursos aprovisionados en la suscripción de conectividad. Si extiende este diseño para llegar a un recurso local, como una base de datos, el modelo de mantenimiento debe incluir conectividad de red a ese recurso, además de límites de seguridad, como aplicaciones virtuales de red en Azure y el entorno local. Esta información es importante para determinar rápidamente la causa principal y corregir el impacto en la confiabilidad. Por ejemplo, ¿el error se produjo al intentar enrutar a la base de datos o hubo un problema con la base de datos?
Consulte Cargas de trabajo críticas diseñadas correctamente: Modelado de estado.
Integración con las reglas y directivas proporcionadas por la plataforma
La suscripción de la zona de aterrizaje de la aplicación hereda las directivas de Azure, las reglas de administrador de red de Azure y otros controles del grupo de administración. El equipo de plataforma proporciona esos límites de protección.
En el caso de las implementaciones, no dependa exclusivamente de las directivas proporcionadas por la plataforma, ya que:
- No están diseñados para cubrir las necesidades de las cargas de trabajo individuales.
- Las directivas y reglas pueden actualizarse o quitarse fuera del equipo, por lo que pueden afectar a la confiabilidad.
Se recomienda encarecidamente crear y asignar directivas de Azure dentro de las implementaciones. Este esfuerzo puede dar lugar a una duplicación, pero es aceptable, teniendo en cuenta el posible impacto en la confiabilidad del sistema. Si hay cambios en las directivas de la plataforma, las directivas de carga de trabajo seguirán en vigor localmente.
Equipo de plataforma
- Involucre al equipo de aplicaciones en el proceso de administración de cambios de las directivas a medida que evolucionan.
- Tenga en cuenta las directivas que usa el equipo de la aplicación. Evalúe si se deben agregar al grupo de administración.
Implementación de esta arquitectura
Los aspectos de red de esta arquitectura se implementan en la implementación conectada crítica.
Nota:
La implementación conectada está pensada para ilustrar una carga de trabajo crítica que se basa en los recursos de la organización, se integra con otras cargas de trabajo y usa servicios compartidos. La implementación supone que ya existe una suscripción de conectividad.
Pasos siguientes
Revise el área de diseño de redes y conectividad en el Marco de buena arquitectura de Microsoft Azure.
Recursos relacionados
Además de los servicios de Azure usados en la arquitectura de línea de base, estos servicios son importantes para esta arquitectura.