Centro de datos virtual: Una perspectiva de la red

Las aplicaciones que se migren desde el entorno local se pueden beneficiar de la infraestructura segura y rentable de Azure, incluso con cambios mínimos en las aplicaciones. Las empresas podrían querer adaptar sus arquitecturas para mejorar la agilidad y aprovechar las funcionalidades de Azure.

Microsoft Azure ofrece servicios y una infraestructura a gran escala con funcionalidades y confiabilidad de nivel empresarial. Estos servicios y esta infraestructura ofrecen muchas opciones de conectividad híbrida, lo que permite a los clientes acceder a ellos mediante Internet o una conexión de red privada. Los partners de Microsoft también pueden proporcionar funcionalidades mejoradas al ofrecer servicios de seguridad y aplicaciones virtuales optimizados para su ejecución en Azure.

Los clientes pueden usar Azure para ampliar su infraestructura a la nube sin problemas y crear arquitecturas de varios niveles.

¿Qué es un centro de datos virtual?

La nube comenzó como plataforma para hospedar aplicaciones orientadas al público. Las empresas reconocieron el valor de la nube y comenzaron a migrar las aplicaciones de línea de negocio internas. Estas aplicaciones trajeron más consideraciones de seguridad, confiabilidad, rendimiento y costo que requerían mayor flexibilidad al prestar servicios en la nube. La nueva infraestructura y los servicios de redes se diseñaron para proporcionar flexibilidad. Las nuevas características proporcionan escalado elástico, recuperación ante desastres y otras consideraciones.

En un principio, las soluciones en la nube se diseñaron para hospedar aplicaciones únicas y relativamente aisladas en el espectro público, lo cual funcionó bien durante unos años. A medida que las ventajas de las soluciones en la nube se hicieron obvias, muchas cargas de trabajo a gran escala se hospedaron en la nube. Abordar los problemas de seguridad, confiabilidad, rendimiento y costo es fundamental para la implementación y el ciclo de vida del servicio en la nube.

En el ejemplo de diagrama de implementación en la nube a continuación, el cuadro rojo resalta una brecha de seguridad. El recuadro amarillo muestra una oportunidad para optimizar las aplicaciones virtuales de red en las cargas de trabajo.

Los centros de datos virtuales ayudan a lograr la escala necesaria para las cargas de trabajo empresariales. La escala debe abordar los desafíos presentados al ejecutar aplicaciones a gran escala en la nube pública.

Una implementación de centro de datos virtual incluye más que las cargas de trabajo de una aplicación en la nube. También proporciona servicios de red, seguridad, administración, DNS y Active Directory. A medida que las empresas migran más cargas de trabajo a Azure, tenga en cuenta la infraestructura y los objetos que admiten estas cargas de trabajo. Una buena administración de recursos ayuda a evitar el aumento de las "islas de cargas de trabajo" administradas por separado con flujos de datos, modelos de seguridad y desafíos de cumplimiento independientes.

El concepto de centro de datos virtual proporciona recomendaciones y diseños de alto nivel para implementar una colección de entidades independientes, pero relacionadas. A menudo, estas entidades tienen funciones auxiliares, características e infraestructura comunes. Visualizar las cargas de trabajo como un centro de datos virtual ayuda a comprender el costo reducido de las economías de escala. También ayuda con la seguridad optimizada a través de la centralización del flujo de datos y componentes, así como operaciones, el administración y auditorías de cumplimiento más fáciles.

Nota

Un centro de datos virtual no es un servicio específico de Azure. En su lugar, se combinan varias características y funcionalidades de Azure para satisfacer sus necesidades. Un centro de datos virtual es una forma de pensar en sus cargas de trabajo y en el uso de Azure para optimizar los recursos y funcionalidades en la nube. Ofrece un enfoque modular para la prestación de servicios de TI en Azure, al mismo tiempo que se respetan los roles y las responsabilidades organizativas de la empresa.

Un centro de datos virtual ayuda a las empresas a implementar cargas de trabajo y aplicaciones en Azure en los siguientes escenarios:

• Hospedaje de varias cargas de trabajo relacionadas.
• Migración de cargas de trabajo desde un entorno local a Azure.
• Implementación de requisitos de seguridad y acceso compartido o centralizado para las cargas de trabajo.
• Combinación de DevOps y TI centralizada adecuada para una gran empresa.

¿Quién debe implementar un centro de datos virtual?

Los clientes que decidan adoptar Azure pueden beneficiarse de la eficacia de configurar un conjunto de recursos que pueden usar todas las aplicaciones. Dependiendo del tamaño, hasta las aplicaciones individuales pueden beneficiarse del uso de los patrones y componentes que se utilizan para crear una implementación de un centro de datos virtual.

Algunas organizaciones tienen equipos o departamentos centralizados para TI, redes, seguridad o cumplimiento normativo. La implementación de un centro de datos virtual puede ayudar a aplicar puntos de directiva, responsabilidades independientes y a garantizar la coherencia de los componentes comunes subyacentes. Los equipos de aplicaciones pueden mantener la libertad y el control adecuados para sus requisitos.

Las organizaciones con un enfoque de DevOps también pueden usar los conceptos del centro de datos virtual para proporcionar paquetes autorizados de recursos de Azure. Este método garantiza que los grupos de DevOps tengan control total dentro de esa agrupación, ya sea en el nivel de la suscripción o en los grupos de recursos de una suscripción común. Al mismo tiempo, los límites de red y seguridad permanecen conformes. El cumplimiento se define mediante una directiva centralizada en la red del centro y un grupo de recursos administrados centralmente.

Consideraciones para la implementación de un centro de datos virtual

Al diseñar un centro de datos virtual, tenga en cuenta los siguientes asuntos centrales:

Servicios de identidad y directorio

Los servicios de identidad y directorio son funcionalidades clave de los centros de datos tanto locales como en la nube. La identidad cubre todos los aspectos del acceso y autorización a los servicios de una implementación del centro de datos virtual. Para garantizar que solo los usuarios y procesos autorizados tengan acceso a los recursos de Azure, Azure usa varios tipos de credenciales para la autenticación, incluidas contraseñas de cuentas, claves criptográficas, firmas digitales y certificados. La autenticación multifactor de Microsoft Entra proporciona una capa adicional de seguridad para acceder a los servicios de Azure. Una autenticación segura con una variedad de opciones de verificación sencillas (llamada telefónica, mensaje de texto o notificación de aplicación móvil) permite a los clientes elegir el método que prefieran.

Las empresas de gran tamaño deben definir procesos de administración de identidades que describan la administración de identidades individuales, su autenticación, autorización, roles y privilegios dentro y fuera de su centro de datos virtual. Los objetivos de este proceso deben mejorar la seguridad y productividad, a la vez que reducir los costos, el tiempo de inactividad y las tareas manuales repetitivas.

Puede que las organizaciones empresariales requieran una combinación exigente de servicios para las diferentes líneas de negocio. Los empleados tienen con frecuencia distintos roles cuando se involucran en proyectos diferentes. Un centro de datos virtual requiere buena cooperación entre distintos equipos, cada uno con definiciones de rol específicas, para realizar una buena gobernanza de los sistemas en ejecución. La matriz de responsabilidades, acceso y derechos puede ser compleja. La administración de identidades en el centro de datos virtual se implementa a través de Microsoft Entra ID y el control de acceso basado en rol de Azure (RBAC de Azure).

Un servicio de directorio es una infraestructura de información compartida para buscar, gestionar, administrar y organizar los elementos cotidianos y los recursos de red. Estos recursos pueden incluir volúmenes, carpetas, archivos, impresoras, usuarios, grupos, dispositivos y otros objetos. El servidor de directorio considera cada recurso de la red como un objeto. La información sobre un recurso se almacena como una colección de atributos asociada a ese recurso u objeto.

Todos los servicios empresariales en línea de Microsoft dependen de Microsoft Entra ID para el inicio de sesión y otras necesidades de identidad. Microsoft Entra ID es una solución en la nube de administración de acceso e identidades completa y de alta disponibilidad que combina una administración de acceso a aplicaciones, gobernanza de identidades avanzada y servicios de directorio fundamentales. Microsoft Entra ID se puede integrar con Active Directory local a fin de habilitar el inicio de sesión único para todas las aplicaciones basadas en la nube y hospedadas localmente. Los atributos de usuario de Active Directory local se pueden sincronizar automáticamente con Microsoft Entra ID.

Cada departamento o grupo de usuarios o servicios específico del servicio de directorio debe tener los permisos mínimos necesarios para administrar sus propios recursos dentro de una implementación del centro de datos virtual. La estructura de permisos requiere un equilibrio. Demasiados permisos pueden disminuir el rendimiento y muy pocos permisos o permisos flexibles pueden aumentar los riesgos de seguridad. El control de acceso basado en roles de Azure (RBAC de Azure) le ayuda a abordar este problema, ya que ofrece una administración detallada del acceso a los recursos de una implementación de un centro de datos virtual.

Infraestructura de seguridad

Por infraestructura de seguridad se entiende la segregación del tráfico del segmento de red virtual específico de una implementación de un centro de datos virtual. Esta infraestructura especifica cómo se controlan la entrada y la salida en la implementación de un centro de datos virtual. Azure se basa en una arquitectura multiinquilino que impide el tráfico no autorizado y no intencionado entre implementaciones. Esto se hace mediante el aislamiento de red virtual, listas de control de acceso, equilibradores de carga, filtros IP y directivas de flujo de tráfico. La traducción de direcciones de red (NAT) se usa para separar el tráfico de red interno del tráfico externo.

El tejido de Azure asigna recursos de infraestructura para las cargas de trabajo del inquilino y administra las comunicaciones a y desde las máquinas virtuales (VM). El hipervisor de Azure fuerza la separación de la memoria y el proceso entre las máquinas virtuales y enruta de forma segura el tráfico de red a los SO invitado de cada inquilino.

Conectividad a la nube

Un centro de datos virtual necesita conectividad con redes externas para ofrecer servicios a los clientes, partners y usuarios internos. Esta necesidad de conectividad no solo sucede en Internet, sino en las redes y centros de datos locales.

Los clientes controlan los servicios que pueden acceder a la red pública de Internet y que se pueden acceder desde ella. Este acceso se controla mediante Azure Firewall o cualquier otro tipo de aplicaciones de red virtual (NVA), directivas de enrutamiento personalizadas mediante rutas definidas por el usuario y filtrado de redes mediante grupos de seguridad de red. Se recomienda que todos los recursos a los que se puede acceder desde Internet estén protegidos por Azure DDoS Protection.

Es posible que las empresas necesiten conectar su centro de datos virtual a centros de datos locales u otros recursos. Esta conectividad entre las redes de Azure y las locales es un aspecto fundamental del diseño de una arquitectura eficaz. Las empresas tienen dos formas distintas de crear esta interconexión: pasar por Internet o mediante conexiones directas privadas.

Una VPN de sitio a sitio de Azure conecta las redes locales a su centro de datos virtual en Azure. El vínculo se establece mediante conexiones cifradas seguras (túneles IPsec). Las conexiones VPN de sitio a sitio de Azure son flexibles, rápidas de crear y, por lo general, no requieren ninguna otra adquisición de hardware. En función de los protocolos estándar del sector, la mayoría de los dispositivos de red actuales pueden crear conexiones VPN a Azure a través de Internet o de rutas de conectividad existentes.

ExpressRoute habilita las conexiones privadas entre el centro de datos virtual y las redes locales. Las conexiones ExpressRoute no se realizan sobre una conexión a Internet pública, ofrecen una mayor confiabilidad, seguridad y velocidades mayores (hasta 100 Gbps) con una latencia menor. ExpressRoute proporciona las ventajas de las reglas de cumplimiento asociadas a las conexiones privadas. Con ExpressRoute Direct puede conectarse directamente a los enrutadores de Microsoft a 10 o 100 Gbps.

La implementación de conexiones ExpressRoute implica normalmente tomar contacto con un proveedor de servicios de ExpressRoute (donde ExpressRoute Direct es la excepción). Para clientes que necesitan comenzar rápidamente, es habitual usar inicialmente una VPN de sitio a sitio para establecer la conectividad entre el centro de datos virtual y los recursos locales. Una vez que se complete la interconexión física con su proveedor de servicios, migre la conectividad a su conexión de ExpressRoute.

Para muchas conexiones VPN o de ExpressRoute, Azure Virtual WAN es un servicio de red que ofrece conectividad automatizada y optimizada entre ramas mediante Azure. Virtual WAN permite conectar y configurar los dispositivos de rama para comunicarse con Azure. La conexión y configuración se pueden realizar manualmente o mediante los dispositivos de proveedores preferidos mediante un partner de Virtual WAN. El uso de dispositivos de proveedores preferidos permite la administración de la configuración, facilita el uso y simplifica la conectividad. El panel integrado de Azure WAN proporciona información instantánea para solucionar problemas que puede ayudarle a ahorrar tiempo y le ofrece una manera fácil de ver la conectividad de sitio a sitio y a gran escala. Virtual WAN también proporciona servicios de seguridad con una instancia opcional de Azure Firewall y Firewall Manager en su centro de Virtual WAN.

Conectividad dentro de la nube

Las instancias de Azure Virtual Network y el emparejamiento de redes virtuales son los componentes básicos de conexión en red de un centro de datos virtual. Una red virtual garantiza un límite de aislamiento para los recursos del centro de datos virtual. El emparejamiento permite la intercomunicación entre distintas redes virtuales dentro de la misma región de Azure, entre regiones e, incluso, entre redes en distintas suscripciones. Los flujos de tráfico se pueden controlar dentro y entre redes virtuales pueden controlarse mediante conjuntos de reglas de seguridad especificadas en grupos de seguridad de red, directivas de firewall (Azure Firewall o aplicaciones virtuales de red) y rutas personalizadas definidas por el usuario.

Las redes virtuales son puntos de anclaje para la integración de productos de Azure de plataforma como servicio (PaaS), como Azure Storage, Azure SQL y otros servicios públicos integrados que tienen puntos de conexión públicos. Con puntos de conexión de servicio y Azure Private Link, puede integrar sus servicios públicos con la red privada. Incluso puede convertir en privados sus servicios públicos, pero disfrutar de las ventajas de los servicios PaaS administrados por Azure.

Introducción al centro de datos virtual

Topologías

Un centro de datos virtual se puede crear con una de estas topologías de alto nivel, según sus necesidades y requisitos de escala:

En una topología plana, todos los recursos se implementan en una única red virtual. Las subredes permiten el control y la segregación del flujo.

En una topología de malla, el emparejamiento de red virtual conecta todas las redes virtuales directamente entre sí.

Una topología de emparejamiento de tipo hub-and-spoke es adecuada para aplicaciones distribuidas y equipos con responsabilidades delegadas.

Una topología de Azure Virtual WAN puede admitir escenarios de sucursales a gran escala y servicios WAN globales.

La topología de emparejamiento en estrella tipo hub-and-spoke y la topología de Azure Virtual WAN usan ambas un diseño de estrella tipo hub-and-spoke, que es óptima para la comunicación, los recursos compartidos y la directiva de seguridad centralizada. Los centros se crean mediante un centro de emparejamiento de red virtual (etiquetado como Hub Virtual Network en el diagrama) o un centro de Virtual WAN (etiquetado como Azure Virtual WAN en el diagrama). Azure Virtual WAN está diseñada para comunicaciones de rama a rama y de rama a Azure a gran escala, o para evitar las complejidades de la creación de todos los componentes de forma individual en un centro de emparejamiento de red virtual. En algunos casos, es posible que sus requisitos exijan un diseño de centro de emparejamiento de red virtual, como la necesidad de aplicaciones virtuales de red en el centro.

En las topologías de hub-and-spoke, el centro (hub) es la zona de red central que controla e inspecciona todo el tráfico entre las diferentes zonas: Internet, local y los radios (spokes). La topología de hub-and-spoke ayuda al Departamento de TI a aplicar directivas de seguridad de forma centralizada. También reduce la posibilidad de exposición y de configuración incorrecta.

El centro a menudo contiene componentes de los servicios comunes que consumen los radios. Los ejemplos siguientes son servicios centrales comunes:

• La infraestructura de Active Directory de Windows es necesaria para la autenticación de usuarios de terceros que acceden desde redes que no son de confianza antes de obtener acceso a las cargas de trabajo del radio (spoke). Incluye los Servicios de federación de Active Directory (AD FS) relacionados.
• Se usa un servicio de Sistema de nombres de dominio (DNS) para resolver los nombres de la carga de trabajo en los radios para acceder a los recursos locales y en Internet si no se usa Azure DNS.
• Se usa una infraestructura de clave pública (PKI) para implementar el inicio de sesión único en las cargas de trabajo.
• Control de flujo del tráfico TCP y UDP entre las zonas de red de los radios e Internet.
• Control de flujo entre los radios y el entorno local.
• Si es necesario, control de flujo entre un radio y otro.

Un centro de datos virtual reduce el costo total, ya que utiliza la infraestructura del centro compartida entre varios radios.

El rol de cada radio puede ser el hospedaje de diferentes tipos de cargas de trabajo. Los radios (spokes) también proporcionan un enfoque modular para implementaciones repetibles de las mismas cargas de trabajo. Entre los ejemplos se incluyen el desarrollo y las pruebas, las pruebas de aceptación de usuario, la preproducción y la producción. Los radios también pueden segregar y habilitar varios grupos dentro de su organización. Los grupos DevOps son un buen ejemplo de lo que pueden hacer los radios. Dentro de un radio, es posible implementar una carga de trabajo básica o cargas de trabajo de varios niveles complejas con control de tráfico entre los niveles.

Límites de la suscripción y múltiples concentradores

Importante

En función del tamaño de las implementaciones de Azure, puede que necesite una estrategia de varios centros. Al diseñar la estrategia de centro y radios, pregúntese: "¿puede este diseño escalarse para usar otra red virtual del centro en esta región?" y "¿puede este diseño escalarse para dar cabida a varias regiones?". Es mucho mejor planear un diseño que se escale y no necesitarlo, que no planearlo y necesitarlo.

Cuándo escalar a un centro secundario (o más) depende de varios factores, en general en función de límites inherentes a la escala. Asegúrese de revisar los límites de la suscripción, de la red virtual y de las máquinas virtuales al diseñar para el escalado.

En Azure, todos los componentes, de cualquier tipo, se implementan en una suscripción de Azure. El aislamiento de componentes de Azure en distintas suscripciones de Azure puede satisfacer los requisitos de diferentes líneas de negocio, como la configuración de niveles diferenciados de acceso y autorización.

Una única implementación de centro de datos virtual puede escalarse verticalmente a un gran número de radios. Aunque, al igual que pasa con todos los sistemas de TI, hay límites en las plataformas. La implementación de un centro se enlaza a una suscripción de Azure concreta, que tiene restricciones y límites (por ejemplo, un número máximo de emparejamientos de red virtual. Para más información, consulte Suscripción de Azure y límites de servicio, cuotas y restricciones). En los casos en los que los límites puedan ser un problema, la arquitectura se puede escalar verticalmente más, extiendo el modelo desde un único centro-radios a un clúster de centros y radios. Se pueden conectar varios centros de una o más regiones de Azure mediante el emparejamiento de red virtual, ExpressRoute, Virtual WAN o VPN de sitio a sitio.

La introducción de varios centros aumenta el costo y el esfuerzo de administración del sistema. Solo se justifica por motivos de escalabilidad, límites del sistema, redundancia, replicación regional para el rendimiento del usuario final o recuperación ante desastres. En escenarios que requieran múltiples concentradores, todos los concentradores deben procurar ofrecer el mismo conjunto de servicios para facilitar la operativa.

Interconexión entre los radios

En un solo radio, o en un diseño de red plano, es posible implementar cargas de trabajo complejas en varios niveles. Las configuraciones de varios niveles se pueden implementar utilizando subredes, una para cada nivel o aplicación, en la misma red virtual. El control y filtrado del tráfico se realizan mediante grupos de seguridad de red y rutas definidas por el usuario.

Un arquitecto podría querer implementar una carga de trabajo de varios niveles entre varias redes virtuales. Con el emparejamiento de redes virtuales, los radios pueden conectarse a otros radios en el mismo centro o en centros diferentes. Un ejemplo típico de este escenario es el caso en el que los servidores de procesamiento de la aplicación están en un radio o red virtual. La base de datos se implementa en un radio o red virtual diferente. En este caso, es fácil interconectar los radios con el emparejamiento de redes virtuales, que evita el tránsito a través del centro. Complete una meticulosa revisión de la arquitectura y la seguridad para asegurarse de que, aunque se omita el centro, no se omiten puntos de seguridad o de auditoría importantes que podrían existir solo en el centro.

Los radios también pueden estar conectados a un radio que actúe como centro. Este enfoque crea una jerarquía de dos niveles. El radio del nivel superior (nivel 0) se convierten en el centro de radios inferiores (nivel 1) en la jerarquía. Los radios de una implementación de VDC son necesarios para reenviar el tráfico al centro de conectividad central. A continuación, el tráfico puede transitar hacia su destino en la red local o en la red pública de Internet. Una arquitectura con dos niveles de centros de conectividad presenta un enrutamiento complejo que anula las ventajas de una relación simple concentrador-radio.

Aunque Azure permite topologías complejas, uno de los principios básicos del concepto de centro de datos virtual es la repetibilidad y simplicidad. Para minimizar el esfuerzo de administración, el diseño simple en estrella tipo hub-and-spoke es la arquitectura de referencia recomendada para un centro de datos virtual.

Componentes

El centro de datos virtual se compone de cuatro tipos de componentes básicos: Infraestructura, redes perimetrales, cargas de trabajo y supervisión.

Cada tipo de componente consta de varias características de Azure y recursos. La implementación del centro de datos virtual se compone de instancias de varios tipos de componentes y múltiples variaciones del mismo tipo de componente. Por ejemplo, puede tener muchas instancias de cargas de trabajo diferentes, separadas lógicamente, que representan las distintas aplicaciones. Estos distintos tipos de componentes e instancias se usan para crear el centro de datos virtual.

La arquitectura conceptual de alto nivel anterior del centro de datos virtual muestra distintos tipos de componentes utilizados en distintas zonas de la topología en estrella tipo hub-and-spoke. El diagrama muestra los componentes de la infraestructura en distintas partes de la arquitectura.

Como procedimiento recomendado en general, los derechos de acceso y privilegios pueden estar basados en grupos. Trabajar con grupos, en lugar de con usuarios individuales, facilita el mantenimiento de directivas de acceso, ya que proporciona una manera coherente de administrarlo en varios equipos, lo que ayuda a minimizar los errores de configuración. Asignar y quitar usuarios de los grupos adecuados ayuda a mantener actualizados los privilegios de un usuario específico.

Cada grupo de roles puede tener un prefijo único en sus nombres. Este prefijo facilita la identificación de la carga de trabajo a la que está asociado un grupo. Por ejemplo, una carga de trabajo que hospeda un servicio de autenticación podría tener grupos denominados AuthServiceNetOps, AuthServiceSecOps, AuthServiceDevOps y AuthServiceInfraOps. Los roles centralizados o los roles no relacionados con un servicio concreto, podrían estar precedidos de Corp. Por ejemplo: CorpNetOps.

Muchas organizaciones usan una variación de los grupos siguientes para proporcionar un desglose mayor de los roles:

• El equipo de TI central llamado Corp tiene los derechos de propiedad para controlar los componentes de la infraestructura. Ejemplos de redes y seguridad. El grupo debe tener el rol de colaborador en la suscripción, el control del centro y derechos de colaborador de la red en los radios. Las grandes organizaciones suelen dividir estas responsabilidades de administración entre varios equipos. Ejemplos: un grupo CorpNetOps de operaciones de red con atención exclusiva a las redes, y un grupo CorpSecOps de operaciones de seguridad responsable del firewall y la directiva de seguridad. En este caso específico, deben crearse dos grupos diferentes para la asignación de estos roles personalizados.
• El grupo de desarrollo y pruebas llamado AppDevOps tiene la responsabilidad de implementar las cargas de trabajo de aplicaciones o servicios. Este grupo adopta el rol de colaborador de la máquina Virtual para las implementaciones de IaaS y uno o varios roles de colaborador de PaaS. Para más información, consulte Roles integrados en Azure. Opcionalmente, el equipo de desarrollo y pruebas podría necesitar tener visibilidad de las directivas de seguridad (grupos de seguridad de red) y de las directivas de enrutamiento (rutas definidas por el usuario) en el centro o en un radio concreto. Además de los roles de colaborador para las cargas de trabajo, este grupo también necesitaría el rol de lector de red.
• El grupo de operaciones y mantenimiento llamado CorpInfraOps o AppInfraOps tiene la responsabilidad de administrar las cargas de trabajo en producción. Este grupo debe ser un colaborador de la suscripción en las cargas de trabajo en las suscripciones de producción. Algunas organizaciones también pueden evaluar si necesitan un grupo de equipo de soporte técnico de escalación con el rol de colaborador en la suscripción de producción y en la suscripción del centro principal. El otro grupo corrige los posibles problemas de configuración en el entorno de producción.

El centro de datos virtual está diseñado de forma que los grupos del equipo de TI central que administran el centro tienen grupos correspondientes en el nivel de carga de trabajo. Además de la administración de los recursos del centro, el equipo de TI central puede controlar el acceso externo y los permisos de nivel superior en la suscripción. Además, los grupos de cargas de trabajo pueden controlar los recursos y los permisos de su red virtual con independencia del equipo TI central.

Las particiones de los centros de datos virtuales están creadas para que puedan hospedar de forma segura varios proyectos en líneas de negocios (LOB) diferentes. Todos los proyectos requieren diferentes entornos aislados (desarrollo, UAT y producción). El uso de suscripciones de Azure independientes para cada uno de estos entornos puede proporcionar un aislamiento natural.

El diagrama anterior muestra la relación entre los proyectos de una organización, los usuarios, grupos y los entornos donde se implementan los componentes de Azure.

Normalmente, en TI, un entorno (o nivel) es un sistema en el que se implementan y ejecutan varias aplicaciones. Las empresas grandes usan un entorno de desarrollo (en el que se realizan y se prueban los cambios) y un entorno de producción (el que utilizan los usuarios finales). Dichos entornos están separados y a menudo hay varios entornos de ensayo entre ellos, para permitir la implementación por fases (lanzamiento), la realización de pruebas y la reversión si surgen problemas. Las arquitecturas de implementación varían considerablemente, aunque normalmente siguen el proceso básico de comenzar en un desarrollo (DEV) y terminar en producción (PROD).

Una arquitectura común para estos tipos de entornos de varios niveles incluye DevOps para el desarrollo y las pruebas, UAT para el almacenamiento provisional y entornos de producción. Las organizaciones pueden usar uno o varios inquilinos de Microsoft Entra para definir el acceso y los derechos para estos entornos. El diagrama anterior muestra un caso en el que se usan dos inquilinos diferentes de Microsoft Entra: uno para DevOps y UAT y otro exclusivamente para producción.

La presencia de inquilinos de Microsoft Entra diferentes refuerza la separación entre entornos. El mismo grupo de usuarios, como el equipo de TI central, necesita autenticarse mediante el uso de un URI diferente para acceder a un inquilino distinto de Microsoft Entra. Esto permite al equipo modificar los roles o permisos de los entornos de DevOps o de producción de un proyecto. La presencia de una autenticación de usuario diferente para acceder a diferentes entornos reduce posibles interrupciones y otros problemas causados por errores humanos.

Tipo de componente: infraestructura

Este tipo de componente es en el que reside la mayor parte de la infraestructura de soporte. También es donde los equipos de TI central, seguridad y cumplimiento dedican la mayor parte de su tiempo.

Los componentes de la infraestructura proporcionan una interconexión para los distintos componentes de una implementación de un centro de datos virtual y están presentes tanto en el centro de conectividad como en los radios. Normalmente se asigna la responsabilidad de administrar y mantener los componentes de infraestructura al equipo de TI central o al de seguridad.

Una de las tareas principales del equipo de infraestructura de TI es garantizar la coherencia de los esquemas de direcciones IP en toda la empresa. El espacio de direcciones IP privadas asignado a una implementación de un centro de datos virtual debe ser coherente y NO superponerse con las direcciones IP privadas asignadas a las redes locales.

Aunque el uso de NAT en los enrutadores locales perimetrales o en entornos de Azure puede evitar conflictos de direcciones IP, agrega complicaciones a los componentes de infraestructura. La simplicidad de administración es uno de los principales objetivos del centro de datos virtual. No se recomienda el uso de NAT para controlar los problemas de IP, aunque sea una solución válida.

Los componentes de infraestructura tienen la siguiente funcionalidad:

• Servicios de identidades y directorios: el acceso a cada tipo de recurso en Azure se controla mediante una identidad que se almacena en un servicio de directorio. El servicio de directorio almacena no solo la lista de usuarios, sino también los derechos de acceso a los recursos en una suscripción de Azure específica. Estos servicios pueden existir en la nube, o se pueden sincronizar con la identidad local almacenada en Active Directory.
• Redes virtuales: las redes virtuales son uno de los componentes principales del centro de datos virtual y le permiten crear un límite de aislamiento de tráfico en la plataforma de Azure. Una red virtual se compone de uno o varios segmentos de red virtual, cada uno con un prefijo de red IP específico (una subred, ya sea IPv4 o doble pila IPv4/IPv6). La red virtual define un área de perímetro interno en el que las máquinas virtuales de IaaS y los servicios de PaaS pueden establecer comunicaciones privadas. Las máquinas virtuales (y los servicios PaaS) de una red virtual no se pueden comunicar directamente con las de una red virtual diferente. Esto es cierto incluso si el mismo cliente crea ambas redes virtuales, en la misma suscripción. El aislamiento consiste en una propiedad fundamental que garantiza que las máquinas virtuales del cliente y la comunicación sigan siendo privadas en una red virtual. Para cuando se quiera la conectividad entre redes, las siguientes características describen cómo se puede lograr.
• Emparejamiento de red virtual: la característica fundamental usada para crear la infraestructura de un centro de datos virtual es el emparejamiento de red virtual, que conecta dos redes virtuales de la misma región. Esta conexión se produce a través de la red del centro de datos de Azure o mediante la red troncal mundial de Azure entre regiones.
• Puntos de conexión de servicio de red virtual: los puntos de conexión de servicio amplían el espacio de direcciones privadas de una red virtual para incluir el espacio de PaaS. También amplían la identidad de la red virtual a los servicios de Azure a través de una conexión directa. Los puntos de conexión permiten proteger los recursos de servicio de Azure críticos para las redes virtuales.
• Private Link: Azure Private Link le permite acceder a los servicios PaaS de Azure (por ejemplo, Azure Storage, Azure Cosmos DB y Azure SQL Database) y a los servicios de partners o clientes hospedados en Azure mediante un punto de conexión privado de la red virtual. El tráfico entre la red virtual y el servicio atraviesa la red troncal de Microsoft, eliminando la exposición a la red pública de Internet. También puede crear su propio servicio Private Link en la red virtual y enviarlo de forma privada a los clientes. La experiencia de configuración y consumo con Azure Private Link es coherente en los servicios compartidos de PaaS de Azure, de propiedad del cliente y de asociados.
• Rutas definidas por el usuario: el tráfico en una red virtual se enruta de forma predeterminada en función de la tabla de enrutamiento del sistema. Una ruta definida por el usuario es una tabla de enrutamiento personalizada que los administradores de red pueden asociar a una o varias subredes para reemplazar el comportamiento de la tabla de enrutamiento del sistema y definir una ruta de comunicación en una red virtual. La presencia de rutas definidas por el usuario garantiza que el tráfico del radio transite a través de máquinas virtuales personalizadas concretas o de aplicaciones virtuales de red y equilibradores de carga presentes tanto en el centro como en los radios.
• Grupos de seguridad de red: un grupo de seguridad de red es una lista de reglas de seguridad que actúan como filtro de tráfico de los orígenes de IP, destinos de IP, protocolos, puertos de origen de IP y puertos de destino de IP (también denominado tupla de cinco de capa 4). El grupo de seguridad de red se puede aplicar a una subred, una NIV virtual asociada a una VM de Azure, o a ambas. Los grupos de seguridad de red son esenciales para implementar un control de flujo correcto en el centro y en los radios. El nivel de seguridad que permite el grupo de seguridad de red está en función de los puertos que abra y de su finalidad. Los clientes pueden aplicar más filtros por máquina virtual con firewalls basados en host, como iptables o el Firewall de Windows.
• DNS: DNS proporciona resolución de nombres para los recursos de un centro de centros de datos virtual. Azure proporciona servicios DNS tanto para la resolución de nombres públicos como privados. Las zonas privadas proporcionan la resolución de nombres dentro de una red virtual y entre redes virtuales distintas. Las zonas privadas pueden abarcar redes virtuales de la misma región, y entre regiones y suscripciones. Azure DNS proporciona un servicio de hospedaje de dominios DNS que permite resolver nombres mediante la infraestructura de Microsoft Azure (resolución pública). Al hospedar dominios en Azure, puede administrar los registros DNS con las mismas credenciales, API, herramientas y facturación que con los demás servicios de Azure.
• Administración de grupos de administración, suscripciones y grupos de recursos. Una suscripción define un límite natural para crear varios grupos de recursos en Azure. Esta separación puede ser para la función, la segregación de roles o la facturación. Los recursos de una suscripción se ensamblan juntos en contenedores lógicos llamados grupos de recursos. El grupo de recursos representa un grupo lógico para organizar los recursos de un centro de datos virtual. Si la organización tiene muchas suscripciones, es posible que necesite una forma de administrar con eficacia el acceso, las directivas y el cumplimiento para esas suscripciones. Los grupos de administración de Azure proporcionan un nivel de ámbito por encima de las suscripciones. Las suscripciones se organizan en contenedores, conocidos como grupos de administración, y las condiciones de gobernanza se aplican a los grupos de administración. Todas las suscripciones dentro de un grupo de administración heredan automáticamente las condiciones que se aplican al grupo de administración. Para ver estas tres características en una vista de jerarquía, consulte Organización de los recursos en Cloud Adoption Framework.
• Control de acceso basado en rol de Azure (RBAC de Azure): RBAC de Azure puede asignar roles y derechos organizativos para acceder a recursos específicos de Azure. Esto le permite restringir a los usuarios a solo un determinado subconjunto de acciones. Si va a sincronizar Microsoft Entra ID con una instancia de Active Directory local, puede usar los mismos grupos de Active Directory en Azure que usa en el entorno local. Con RBAC de Azure, puede conceder acceso mediante la asignación del rol adecuado a usuarios, grupos y aplicaciones dentro del ámbito correspondiente. El ámbito de una asignación de roles puede ser una suscripción de Azure, un grupo de recursos o un único recurso. RBAC de Azure permite la herencia de permisos. Un rol asignado en un ámbito principal también concede acceso a los elementos secundarios dentro del mismo. Con RBAC de Azure, puede segregar tareas y conceder a los usuarios únicamente el nivel de acceso que necesitan para realizar sus trabajos. Por ejemplo, un empleado puede administrar máquinas virtuales en una suscripción, mientras que otro puede administrar bases de datos de SQL Server en la misma suscripción.

Tipo de componente: Redes perimetrales

Los componentes de una red perimetral (en ocasiones denominada red DMZ) conectan sus redes locales o físicas del centro de datos, junto con toda conectividad a Internet. Normalmente, el perímetro requiere una inversión de tiempo considerable de los equipos de red y de seguridad.

Los paquetes entrantes pueden fluir a través de las aplicaciones de seguridad del centro antes de llegar a los servicios y servidores back-end en los radios. Entre los ejemplos se incluyen el firewall, IDS e IPS. Antes de abandonar la red, los paquetes enlazados a Internet desde las cargas de trabajo también pueden fluir a través de las aplicaciones de seguridad de la red perimetral. Este flujo permite la aplicación de directivas, las inspecciones y las auditorías.

Los componentes de una red perimetral incluyen:

• Redes virtuales, rutas definidas por el usuario y grupos de seguridad de red
• Aplicaciones virtuales de red
• Equilibrador de carga de Azure
• Azure Application Gateway con firewall de aplicaciones web (WAF)
• Direcciones IP públicas.
• Azure Front Door con firewall de aplicaciones web (WAF)
• Azure Firewall y Azure Firewall Manager
• DDoS Protection estándar

Normalmente, los equipos de TI central y de seguridad son responsables de la definición de requisitos y el funcionamiento de las redes perimetrales.

El diagrama anterior muestra el cumplimiento de dos perímetros con acceso a Internet y a una red local, ambos residentes en el centro de DMZ. En el centro de DMZ, la red perimetral a Internet se puede escalar verticalmente para admitir muchas líneas de negocio, mediante varias granjas de firewalls de aplicaciones web (WAF) o instancias de Azure Firewall. El centro también permite la conectividad local a través de VPN o ExpressRoute, según sea necesario.

Nota:

En el diagrama anterior, en DMZ Hub, muchas de las características siguientes se pueden agrupar en un centro de Azure Virtual WAN (por ejemplo, redes virtuales, rutas definidas por el usuario, grupos de seguridad de red, puertas de enlace de VPN, puertas de enlace de ExpressRoute, instancias de Azure Load Balancer, instancias de Azure Firewall, Firewall Manager y DDOS). El uso de centros de Azure Virtual WAN puede facilitar la creación de la red virtual del centro y del centro de datos virtual, ya que Azure controla automáticamente la mayor parte de la complejidad de ingeniería cuando se implementa un centro de Azure Virtual WAN.

Redes virtuales. El centro se suele crear en una red virtual con varias subredes que hospedan diferentes tipos de servicios. Estos servicios filtran e inspeccionan el tráfico de Internet a través de Azure Firewall, NVA, WAF e instancias de Azure Application Gateway.

Rutas definidas por el usuario. Con las rutas definidas por el usuario, los clientes pueden implementar firewalls, IDS o IPS y otras aplicaciones virtuales. También pueden enrutar el tráfico de red a través de estas aplicaciones de seguridad para la aplicación de directivas de límites de seguridad, auditoría e inspección. Las rutas definidas por el usuario pueden crearse en el centro y los radios para garantizar que el tráfico transita a través de VM personalizadas específicas, aplicaciones virtuales de red y equilibradores de carga utilizados en una implementación de un centro de datos virtual. Para garantizar que el tráfico generado desde máquinas virtuales del radio transita a las aplicaciones virtuales correctas, es necesario establecer una ruta definida por el usuario en las subredes del radio. Esto se hace estableciendo la dirección IP de front-end del equilibrador de carga interno como el próximo salto. El equilibrador de carga interno distribuye el tráfico interno a las aplicaciones virtuales (grupo de back-end de equilibradores de carga).

Azure Firewall es un servicio de seguridad de red administrado que protege los recursos de Azure Virtual Network. Se trata de un firewall administrado con estado, con alta disponibilidad y escalabilidad en la nube. Puede crear, aplicar y registrar directivas de aplicaciones y de conectividad de red a nivel central en suscripciones y redes virtuales. Azure Firewall usa una dirección IP pública estática para los recursos de red virtual. Esto permite que los firewalls externos identifiquen el tráfico que procede de su red virtual. El servicio está totalmente integrado con Azure Monitor para los registros y análisis.

Si usa la topología de Azure Virtual WAN, Azure Firewall Manager es un servicio de administración de seguridad que proporciona una directiva de seguridad central y administración de rutas para perímetros de seguridad basados en la nube. Funciona con el centro de Azure Virtual WAN, un recurso administrado por Microsoft que le permite crear fácilmente arquitecturas en estrella tipo hub-and-spoke. Cuando las directivas de seguridad y enrutamiento están asociadas a un centro, se conoce como centro virtual protegido.

Aplicaciones virtuales de red. En el centro, la red perimetral con acceso a Internet se administra normalmente a través de una instancia de Azure Firewall o una granja de firewalls o mediante un firewall de aplicaciones web (WAF).

Las diferentes líneas de negocio normalmente utilizan diversas aplicaciones web, que tienden a sufrir varias vulnerabilidades y puntos débiles potenciales. Los firewalls de aplicaciones web son un tipo especial de producto que se usa para detectar ataques contra las aplicaciones web y HTTP/HTTPS con mayor eficacia que un firewall genérico. En comparación con la tecnología de firewall tradicional, los WAF tienen un conjunto de características específicas para proteger los servidores web internos frente a amenazas.

Una instancia de Azure Firewall o un firewall de aplicación virtual de red usan un plano de administración común, con un conjunto de reglas de seguridad para proteger las cargas de trabajo hospedadas en los radios y controlar el acceso a las redes locales. Azure Firewall tiene escalabilidad integrada, mientras que los firewalls de aplicación virtual de red se pueden escalar manualmente detrás de un equilibrador de carga. En general, una granja de firewalls tiene menos software especializado en comparación con un WAF, pero tiene un ámbito más amplio de aplicación para filtrar e inspeccionar cualquier tipo de tráfico de entrada y salida. Si se usa un enfoque de aplicación virtual de red, se pueden encontrar e implementar desde Azure Marketplace.

Es recomendable que use un conjunto de instancias de Azure Firewall o de aplicaciones virtuales de red para el tráfico que se origina en Internet. Use otro para el tráfico que se origina en el entorno local. Utilizar únicamente un conjunto de firewalls para ambos es un riesgo de seguridad, ya que no proporciona ningún perímetro de seguridad entre los dos conjuntos de tráfico de red. El uso de capas de firewalls independientes reduce la complejidad de la comprobación de las reglas de seguridad y deja claro qué reglas se corresponden con cada solicitud de red entrante.

Azure Load Balancer ofrece un servicio de nivel 4 (TCP/UDP) de alta disponibilidad que puede distribuir el tráfico entrante entre instancias del servicio definidas en un conjunto de carga equilibrada. El tráfico enviado al equilibrador de carga desde los puntos de conexión de front-end (puntos de conexión de direcciones IP públicas o privadas) se puede redistribuir con o sin traducción de direcciones a un conjunto de grupos de direcciones IP de back-end (como aplicaciones virtuales de red o máquinas virtuales).

Azure Load Balancer puede sondear el mantenimiento de las distintas instancias de servidor. Cuando una instancia no puede responder a un sondeo, el equilibrador de carga deja de enviar tráfico a las instancias incorrectas. En un centro de datos virtual se implementa un equilibrador de carga externo en el centro y en los radios. En el centro, el equilibrador de carga se usa para enrutar de forma eficaz el tráfico entre instancias de firewall. En los radios, los equilibradores de carga se usan para administrar el tráfico de la aplicación.

Azure Front Door (AFD) es una plataforma de aceleración de aplicaciones web de alta disponibilidad y escalable de Microsoft, con equilibrador de carga HTTP global, protección de aplicaciones y red de entrega de contenido. Al ejecutarse en más de cien ubicaciones en el perímetro de la red global de Microsoft, AFD permite crear, operar y escalar horizontalmente una aplicación web dinámica y contenido estático. AFD proporciona a la aplicación un rendimiento de usuario final de primer orden, una automatización de mantenimiento de marca/regional unificada, una automatización de BCDR, una información de cliente/usuario unificada, un almacenamiento en caché y una información detallada de servicios.

La plataforma ofrece:

• Acuerdos de Nivel de Servicio (SLA) de rendimiento, confiabilidad y soporte técnico.
• Certificaciones de cumplimiento.
• Prácticas de seguridad auditables desarrolladas, dirigidas y compatibles de forma nativa con Azure.

Azure Front Door también ofrece un firewall de aplicaciones web (WAF), que protege las aplicaciones web de las vulnerabilidades y exposiciones más habituales.

Azure Application Gateway es una aplicación virtual dedicada que proporciona un controlador de entrega de aplicaciones administrado. Ofrece diversas funcionalidades de equilibrio de carga de nivel 7 para la aplicación. Le permite optimizar el rendimiento de las granjas de servidores web al traspasar la carga de la terminación SSL con mayor actividad de la CPU a Application Gateway. También dispone de otras funcionalidades de enrutamiento de nivel 7, como la distribución round robin del tráfico entrante, la afinidad de sesiones basada en cookies, el enrutamiento basado en rutas de acceso URL y la capacidad de hospedar varios sitios web detrás de una única instancia de Application Gateway. También se proporciona un firewall de aplicaciones web (WAF) como parte de la SKU de WAF de Application Gateway. Esta SKU proporciona protección a las aplicaciones web frente a vulnerabilidades web y vulnerabilidades de seguridad comunes. Application Gateway puede configurarse como una puerta de enlace orientada a Internet, una puerta de enlace solo para uso interno o una combinación de las dos.

Direcciones IP públicas. Algunas características de Azure le permiten asociar los puntos de conexión de servicio a una dirección IP pública de modo que pueda accederse al recurso desde Internet. Este punto de conexión usa NAT para enrutar el tráfico a la dirección interna y el puerto de la red virtual de Azure. Esta ruta es la vía principal para que el tráfico externo pase a la red virtual. Las direcciones IP públicas se pueden configurar para determinar qué tráfico se pasa y cómo y a dónde se traslada en la red virtual.

Azure DDoS Protection ofrece más funcionalidades de mitigación, en comparación con el nivel de servicio básico, que se ajustan específicamente a los recursos de Azure Virtual Network. DDoS Protection es sencillo de habilitar y no requiere ningún cambio en la aplicación. Las directivas de protección se ajustan a través de la supervisión del tráfico dedicado y los algoritmos de Machine Learning. Las directivas se aplican a direcciones IP públicas asociadas a recursos implementados en redes virtuales. Entre los ejemplos se incluyen instancias de Azure Load Balancer, Azure Application Gateway y Azure Service Fabric. Los registros generados por el sistema casi en tiempo real están disponibles a través de las vistas de Azure Monitor durante un ataque y para el historial. Se puede agregar protección en la capa de aplicación mediante el firewall de aplicaciones web de Azure Application Gateway. Se proporciona protección para direcciones IP públicas de Azure IPv4 e IPv6.

La topología de hub-and-spoke usa el emparejamiento de red virtual y las rutas definidas por el usuario para enrutar el tráfico correctamente.

En el diagrama, la ruta definida por el usuario garantiza que el tráfico fluya del radio al firewall antes de pasar al entorno local a través de la puerta de enlace de ExpressRoute (si la directiva de firewall permite ese flujo).

Tipo de componente: supervisión

Los componentes de supervisión proporcionan visibilidad y alertas sobre todos los demás tipos de componente. Todos los equipos pueden tener acceso a la supervisión de los componentes y servicios a los que tienen acceso. Si tiene equipos de soporte técnico o de operaciones centralizados, necesitan un acceso integrado a los datos que proporcionan estos componentes.

Azure ofrece diferentes tipos de servicios de registro y supervisión para realizar un seguimiento del comportamiento de los recursos hospedados en Azure. La gobernanza y el control de las cargas de trabajo en Azure no se basa solo en recopilar datos de registro, sino también en la posibilidad de desencadenar acciones basándose en eventos específicos notificados.

Azure Monitor. Azure incluye varios servicios que realizan individualmente una tarea o un rol específico en el espacio de supervisión. Juntos, estos servicios ofrecen una solución completa para recopilar, analizar y actuar en función de los registros generados por el sistema desde las aplicaciones y los recursos de Azure que las admiten. También pueden servir para supervisar recursos locales críticos a fin de proporcionar un entorno de supervisión híbrido. Conocer las herramientas y los datos que están disponibles es el primer paso para desarrollar una estrategia de supervisión completa para las aplicaciones.

Hay dos tipos fundamentales de registros en Azure Monitor:

• Las métricas son valores numéricos que describen algún aspecto de un sistema en un momento dado. Son ligeras y capaces de admitir escenarios de tiempo casi real. En muchos recursos de Azure, los datos recopilados por Azure Monitor aparecen directamente en la página de información general de Azure Portal. Como ejemplo, eche un vistazo a cualquier máquina virtual y verá varios gráficos en los que aparecen métricas de rendimiento. Seleccione cualquiera de los gráficos para abrir los datos en el explorador de métricas de Azure Portal, lo que le permitirá crear gráficos con los valores de diversas métricas a lo largo del tiempo. Puede ver los gráficos de forma interactiva o anclarlos a un panel para verlos con otras visualizaciones.

• Los registros contienen distintos tipos de datos organizados en grupos de registros, donde cada tipo tiene diferentes conjuntos de propiedades. Los eventos y seguimientos se almacenan como registros junto con los datos de rendimiento, que se pueden combinar todos para su análisis. Los datos de registro recopilados por Azure Monitor se pueden analizar con consultas para recuperar, consolidar y analizar rápidamente los datos recopilados. Los registros se almacenan y se consultan desde Log Analytics. Puede crear y probar consultas mediante Log Analytics en Azure Portal y después analizar los datos directamente mediante estas herramientas o guardar las consultas para usarlas con las visualizaciones o las reglas de alertas.

Azure Monitor puede recopilar datos de diversos orígenes. Puede pensar en supervisar datos para las aplicaciones en niveles que abarcan desde la aplicación, pasando por el sistema operativo y los servicios en los que se basa, hasta la propia plataforma de Azure. Azure Monitor recopila datos de cada uno de los siguientes niveles:

• Datos de supervisión de aplicaciones: datos sobre el rendimiento y la funcionalidad del código que se ha escrito, independientemente de la plataforma.
• Datos de supervisión del sistema operativo invitado: datos sobre el sistema operativo en el que se ejecuta la aplicación. Este sistema operativo se puede ejecutar en Azure, en otra nube o en el entorno local.
• Supervisión de recursos con DMV: datos sobre el funcionamiento de un recurso de Azure.
• Datos de supervisión de la suscripción de Azure: datos sobre el funcionamiento y la administración de una suscripción de Azure, y sobre el estado y el funcionamiento del propio Azure.
• Datos de supervisión del inquilino de Azure: datos sobre el funcionamiento de los servicios de Azure en el nivel del inquilino, como Microsoft Entra ID.
• Orígenes personalizados: También se pueden incluir los registros enviados desde orígenes locales. Algunos ejemplos incluyen los eventos de servidores locales o la salida syslog de dispositivos de red.

Los datos de supervisión solo resultan útiles si aportan una mayor visibilidad sobre el funcionamiento del entorno informático. Azure Monitor cuenta con varias características y herramientas que proporcionan valiosa información sobre las aplicaciones y los recursos de los que dependen. Las características y las soluciones de supervisión, como Application Insights y Azure Monitor para contenedores, proporcionan información exhaustiva sobre diferentes aspectos de la aplicación y determinados servicios de Azure.

Las soluciones de supervisión de Azure Monitor son conjuntos empaquetados de lógica que proporcionan información sobre una determinada aplicación o servicio. Incluyen la lógica para recopilar datos de supervisión para la aplicación o servicio, consultas para analizar esos datos y vistas para su visualización. Las soluciones de supervisión están disponibles en Microsoft y partners, y ofrecen herramientas de supervisión para distintos servicios de Azure y otras aplicaciones.

Con dicha recopilación de datos enriquecidos, es importante tomar medidas proactivas sobre los eventos que ocurren en el entorno, especialmente cuando las consultas manuales solas no bastarán. Las alertas de Azure Monitor informan de manera proactiva los estados críticos e intentan aplicar acciones correctivas. Las reglas de alertas basadas en métricas proporcionan alertas casi en tiempo real basadas en valores numéricos. Las reglas de alertas basadas en registros permiten una lógica compleja entre datos de varios orígenes. Las reglas de alertas de Azure Monitor utilizan grupos de acciones, que contienen diferentes conjuntos de destinatarios y acciones que pueden compartirse entre varias reglas. En función de los requisitos, los grupos de acciones pueden usar webhooks para que las alertas inicien acciones externas o se integren en las herramientas de Administración de servicios de TI.

Azure Monitor también permite la creación de paneles personalizados. Los paneles de Azure permiten combinar distintos tipos de datos, como métricas y registros, en un único panel de Azure Portal. Si lo desea, también compartir el panel con otros usuarios de Azure. Los elementos que componen Azure Monitor pueden agregarse a un panel de Azure, así como a la salida de cualquier consulta de registro o gráfico de métricas. Por ejemplo, puede crear un panel que combine diferentes iconos que muestren un gráfico de métricas, una tabla de registros de actividad, un gráfico de uso de Application Insights y la salida de una consulta de registro.

Por último, los datos de Azure Monitor son un origen nativo para Power BI. Power BI es un servicio de análisis empresarial que proporciona visualizaciones interactivas entre varios orígenes de datos. También es un medio eficaz de poner los datos a disposición de otras personas de la organización y externas. Puede configurar Power BI para que los datos de registro se importen automáticamente desde Azure Monitor y utilizar estas otras adicionales.

Azure Network Watcher proporciona herramientas para supervisar, diagnosticar, ver las métricas y habilitar o deshabilitar los registros de los recursos en una red virtual de Azure. Es un servicio polifacético, lo que permite las funcionalidades siguientes y muchas más:

• Supervisión de la comunicación entre una máquina virtual y un punto de conexión.
• Visualización de recursos de una red virtual y sus relaciones.
• Diagnóstico de problemas de filtrado del tráfico de red hacia o desde una máquina virtual.
• Diagnóstico de problemas de enrutamiento de red desde una máquina virtual.
• Diagnóstico de conexiones de salida desde una máquina virtual.
• Captura de paquetes hacia y desde una máquina virtual.
• Diagnóstico de problemas con conexiones y una puerta de enlace de una red virtual.
• Determinación de latencias relativas entre las regiones de Azure y los proveedores de acceso a Internet.
• Visualización de las reglas de seguridad para una interfaz de red.
• Visualización de métricas de red.
• Análisis del tráfico hacia y desde un grupo de seguridad de red.
• Visualización de registros de diagnóstico de recursos de red.

Tipo de componente: Cargas de trabajo

Los componentes de carga de trabajo son donde residen los servicios y aplicaciones reales. Es donde los equipos de desarrollo de aplicaciones dedican la mayor parte de su tiempo.

Las posibilidades de cargas de trabajo son infinitas. Estos son solo algunos de los tipos posibles de cargas de trabajo:

Aplicaciones internas: Las aplicaciones de línea de negocio son críticas para las operaciones empresariales. Estas aplicaciones tienen algunas características comunes:

• Interactivas: Se especifican los datos y se devuelven resultados o informes.
• Orientadas a datos: Uso intensivo de datos con acceso frecuente a bases de datos o a otros almacenamientos.
• Integradas: Integración de ofertas con otros sistemas dentro o fuera de la organización.

Sitios web accesibles para clientes (accesibles desde Internet o internamente): La mayoría de las aplicaciones de Internet son sitios web. Azure puede ejecutar un sitio web a través de una máquina virtual IaaS o una sitio de Azure Web Apps (PaaS). Azure Web Apps se integra en las redes virtuales para implementar aplicaciones web en una zona de red de radios. Los sitios web a los que se accede internamente no necesitan exponer un punto de conexión de Internet pública, ya que se puede acceder a los recursos a través de direcciones privadas enrutables sin conexión a Internet desde la red virtual privada.

Análisis de macrodatos: cuando sea necesario escalar los datos verticalmente a volúmenes mayores, es posible que las bases de datos relacionales no funcionen correctamente bajo la carga extrema o la naturaleza no estructurada de los datos. Azure HDInsight es un servicio de análisis, de código abierto, espectro completo y administrado en la nube para empresas. Puede usar marcos de código abierto como Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm y R. HDInsight. Esto admite la implementación en una red virtual basada en la ubicación, que se puede implementar en un clúster de un radio del centro de datos virtual.

Eventos y mensajería: Azure Event Hubs es una plataforma de streaming de macrodatos y un servicio de ingesta de eventos. Puede recibir y procesar millones de eventos por segundo. Ofrece retención de tiempo configurable y baja latencia, lo que permite ingerir grandes cantidades de datos en Azure y leerlos desde varias aplicaciones. Una única transmisión puede admitir canalizaciones en tiempo real y basadas en lotes.

Puede implementar un servicio de mensajería en la nube altamente confiable entre aplicaciones y servicios mediante Azure Service Bus. Este ofrece mensajería asincrónica entre cliente y servidor, además de mensajería estructurada de tipo FIFO (primero en entrar, primero en salir) y funcionalidades de publicación y suscripción.

Estos ejemplos apenas arañan la superficie de los tipos de cargas de trabajo que puede crear en Azure. Se puede crear todo desde una aplicación básica web y SQL hasta lo más novedoso en IoT, macrodatos, aprendizaje automático, inteligencia artificial, etc.

Alta disponibilidad: varios centros de datos virtuales

Hasta ahora, este artículo se ha centrado en el diseño de un único centro de datos virtual, y en él se describen los componentes básicos y las arquitecturas que contribuyen a su resistencia. Las características de Azure, como Azure Load Balancer, las aplicaciones virtuales de red, las zonas de disponibilidad, los conjuntos de disponibilidad, los conjuntos de escalado y otras funcionalidades que le ayudan a incluir niveles de SLA sólidos en los servicios de producción.

Sin embargo, dado que un centro de datos virtual normalmente se implementa en una sola región, puede ser vulnerable a cualquier interrupción que afecte a toda la región. Los clientes que requieran alta disponibilidad deben proteger los servicios a través de implementaciones del mismo proyecto en dos implementaciones de centros de datos virtuales (o más) ubicadas en regiones diferentes.

Además de los aspectos del acuerdo de nivel de servicio, varios escenarios comunes se benefician de la ejecución de varios centros de datos virtuales:

• Presencia regional o global de los usuarios finales o partners.
• Requisitos de recuperación ante desastres.
• Un mecanismo para desviar el tráfico entre centros de datos para la carga o el rendimiento.

Presencia regional y global

Existen centros de datos de Azure en muchas regiones de todo el mundo. Si selecciona varios centros de datos de Azure, tenga en cuenta dos factores relacionados: distancias geográficas y latencia. Para optimizar la experiencia del usuario, evalúe la distancia entre cada centro de datos virtual, así como la distancia entre cada centro de datos virtual y los usuarios finales.

Una región de Azure que hospeda su centro de datos virtual debe cumplir los requisitos normativos de la jurisdicción legal en la que opere su organización.

Recuperación ante desastres

El diseño de un plan de recuperación ante desastres depende de los tipos de cargas de trabajo y de la capacidad para sincronizar el estado dichas cargas entre diferentes implementaciones de centros de datos virtuales. Idealmente, la mayoría de los clientes quieren un mecanismo de conmutación por error rápido, y este requisito puede necesitar la sincronización de los datos de las aplicaciones entre las implementaciones que se ejecutan en distintas implementaciones de centros de datos virtuales. Sin embargo, al diseñar los planes de recuperación ante desastres, es importante tener en cuenta que a la mayoría de las aplicaciones les afecta la latencia que puede provocar dicha sincronización de datos.

La sincronización y la supervisión del latido de las aplicaciones en diferentes implementaciones de centros de datos virtuales exige comunicación a través de la red. Varias implementaciones de centros de datos virtuales de diferentes regiones se pueden conectar mediante:

• Comunicación de centro a centro, integrada en los centros de Azure Virtual WAN entre regiones de la misma Virtual WAN.
• Emparejamiento de red virtual para conectar centros de diferentes regiones.
• Emparejamiento privado de ExpressRoute cuando los centros en cada una de las implementaciones de centros de datos virtuales están conectados al mismo circuito de ExpressRoute.
• Varios circuitos de ExpressRoute conectados a través de la red troncal corporativa y varias implementaciones de centros de datos virtuales conectadas a los circuitos de ExpressRoute.
• Conexiones VPN de sitio a sitio entre la zona del concentrador de las implementaciones de los centros de datos virtuales de cada región de Azure.

Normalmente, los centros de Virtual WAN, el emparejamiento de red virtual o las conexiones de ExpressRoute se prefieren para la conectividad de red, ya que tienen mayor ancho de banda y niveles de latencia coherentes al pasar por la red troncal de Microsoft.

Ejecute pruebas de calificación de red para verificar la latencia y el ancho de banda de dichas conexiones y decidir si la replicación de datos sincrónica o asincrónica es adecuada en función del resultado. También es importante sopesar estos resultados teniendo en cuenta el objetivo de tiempo de recuperación óptimo (RTO).

Recuperación ante desastres: desvío del tráfico de una región a otra

Tanto Azure Traffic Manager como Azure Front Door comprueban periódicamente el mantenimiento del servicio de los puntos de conexión de escucha en distintas implementaciones de centros de datos virtuales. Si se produce un error en esos puntos de conexión, Azure Traffic Manager y Azure Front Door enrutan automáticamente al siguiente centro de datos virtual más cercano. Traffic Manager usa medidas de usuario en tiempo real y DNS para enrutar a los usuarios al l más cercano (o próximamente al más cercano durante el error). Azure Front Door es un proxy inverso en más de 100 sitios perimetrales de la red troncal de Microsoft, con difusión por proximidad para enrutar a los usuarios al punto de conexión de escucha más cercano.

Resumen

El enfoque de centro de datos virtual para la migración es crear una arquitectura escalable que optimiza el uso de recursos de Azure, reduce los costos y simplifica la gobernanza del sistema. El centro de datos virtual suele basarse en topologías en estrella tipo hub-and-spoke (mediante el emparejamiento de red virtual o los centros de Virtual WAN). Los servicios compartidos comunes que se proporcionan en el centro y las aplicaciones y cargas de trabajo específicas se implementan en los radios. El centro de datos virtual también coincide con la estructura de roles de la empresa, en la que diferentes departamentos, como TI Central, DevOps, operaciones y mantenimiento, funcionan conjuntamente, aunque cumplan con sus roles específicos. El centro de datos virtual permite migrar las cargas de trabajo locales existentes a Azure, pero también proporciona muchas ventajas para las implementaciones nativas en la nube.

Referencias

Obtenga más información sobre las funcionalidades de Azure que se describen en este documento.

Características de red
Azure Virtual Network
Grupos de seguridad de red
Puntos de conexión de servicio
Private Link
Rutas definidas por el usuario
Aplicaciones virtuales de red
Direcciones IP públicas
DNS de Azure

Equilibrio de carga
Azure Front Door
Azure Load Balancer (capa 4)
Application Gateway (capa 7)
Azure Traffic Manager

Conectividad
Emparejamiento de redes virtuales
Red privada virtual
Virtual WAN
ExpressRoute
ExpressRoute Direct

Identidad
Microsoft Entra ID
Autenticación multifactor de Microsoft Entra
Control de acceso basado en rol
Roles integrados en los recursos de Azure

Supervisión
Network Watcher
Azure Monitor
Log Analytics

procedimientos recomendados
Grupo de administración
Administración de suscripciones
Administración de grupos de recursos
Límites de la suscripción de Azure

Seguridad
Azure Firewall
Firewall Manager
Application Gateway con WAF
Front Door con WAF
Azure DDoS

Otros servicios de Azure
Almacenamiento de Azure
SQL de Azure
Azure Web Apps
Azure Cosmos DB
HDInsight
Event Hubs
Service Bus
Azure IoT
Azure Machine Learning

Pasos siguientes

• Obtenga más información sobre el emparejamiento de red virtual, la tecnología básica de las topologías en estrella tipo hub-and-spoke.
• Implemente Microsoft Entra ID para usar el control de acceso basado en rol de Azure.
• Desarrolle un modelo de administración de recursos y suscripciones mediante un control de acceso basado en roles de Azure que se adapte a la estructura, los requisitos y las directivas de su organización. La actividad más importante es el planeamiento. Analice de qué manera las reorganizaciones, las fusiones, las nuevas líneas de productos y otras consideraciones afectarán a los modelos iniciales, con el fin asegurarse de que pueda escalar para satisfacer las necesidades y el crecimiento futuros.