Azure Arc: administración de recursos híbridos

La mayoría de las organizaciones operan en un entorno híbrido: algunas cargas de trabajo se ejecutan en Azure, otras en servidores locales y otras en proveedores de nube diferentes. Administrar estos entornos dispares con herramientas independientes crea silos operativos: políticas, supervisión y controles de acceso diferentes. Azure Arc resuelve este problema al ampliar el plano de administración de Azure a cualquier infraestructura, lo que le permite administrar recursos locales y multinube mediante el mismo portal de Azure, la CLI, las políticas y RBAC que utiliza para los recursos nativos de Azure.

Azure Arc es un conjunto de tecnologías que proyecta recursos que no son de Azure en Azure Resource Manager (ARM), de modo que aparecen como recursos de Azure con identificadores de recurso. Actualmente, Arc admite: servidores (máquinas virtuales Windows/Linux locales o de otras nubes), clústeres de Kubernetes (cualquier Kubernetes conforme con CNCF), instancias de SQL Server, servicios de datos de Azure (SQL Managed Instance y PostgreSQL en Arc), y máquinas virtuales de VMware vSphere y Azure Stack HCI.

Para incorporar un servidor Windows o Linux a Arc, debe instalar el agente Azure Connected Machine en el servidor. El agente registra la máquina en ARM y mantiene una conexión saliente persistente con Azure (no se requieren puertos entrantes). Después del registro, el servidor aparece en el portal de Azure, en Azure Arc > Servers, con un identificador de recurso ARM completo. Desde el portal puede generar un script de incorporación interactivo o automatizado que incluya los datos de su suscripción y grupo de recursos.

Una vez habilitado Arc en un servidor, puede asignarle definiciones de Azure Policy igual que a una máquina virtual nativa de Azure. Por ejemplo, puede auditar si el agente de Log Analytics está instalado, exigir que se apliquen líneas base de seguridad específicas de Windows o implementar automáticamente el agente de Defender for Cloud. Las asignaciones de directivas en el ámbito de un grupo de administración o una suscripción evalúan automáticamente todos los servidores habilitados para Arc en ese ámbito, lo que proporciona una vista unificada del cumplimiento en entornos locales y en la nube.

Los servidores habilitados para Arc pueden enviar registros y métricas a Azure Monitor mediante Azure Monitor Agent (AMA). Debe crear una regla de recopilación de datos (DCR) que especifique qué contadores de rendimiento y registros de eventos se recopilarán y a qué espacio de trabajo de Log Analytics se enviarán. La misma DCR puede dirigirse tanto a servidores habilitados para Arc como a máquinas virtuales nativas de Azure, lo que proporciona una configuración de supervisión coherente. Una vez que comienzan a fluir los datos, las mismas consultas KQL y reglas de alerta que utiliza para las máquinas virtuales de Azure también funcionan con los servidores de Arc.

Al habilitar Microsoft Defender for Servers en un servidor habilitado para Arc, se instala el agente de Defender for Endpoint y se proporciona la misma protección contra amenazas, análisis de vulnerabilidades y recomendaciones de seguridad que reciben las máquinas virtuales en la nube. Esto resulta especialmente valioso para máquinas con Windows Server 2012 y 2019 locales que no pueden usar productos de seguridad nativos de la nube sin Arc. La puntuación de seguridad de Defender for Cloud refleja todos los recursos, tanto los de Azure como los administrados por Arc, lo que le proporciona una vista unificada.

Azure Arc-enabled Kubernetes incorpora a Azure cualquier clúster de Kubernetes conforme con CNCF (local, GKE, EKS o Rancher). Los agentes de Arc se instalan mediante un gráfico de Helm, tras lo cual el clúster aparece en ARM. Desde Azure puede implementar aplicaciones mediante GitOps (Flux o Argo CD administrados por Azure), aplicar Azure Policy para Kubernetes (OPA Gatekeeper) y consultar el estado del clúster en Azure Monitor. El plano de control se ejecuta en el propio clúster; Azure solo recibe el estado y la telemetría, no acceso completo al servidor de API.

GitOps es un patrón de implementación en el que el estado deseado de las cargas de trabajo de Kubernetes se define en un repositorio de Git, y un agente del clúster reconcilia continuamente el estado del clúster para que coincida con el del repositorio. Con Kubernetes habilitado para Arc, se configura en Azure un recurso FluxConfiguration que apunta al repositorio de Git. El operador de Flux del clúster extrae los manifiestos del repositorio y los aplica, lo que permite implementar aplicaciones de forma declarativa, auditable y automatizada en cualquier número de clústeres desde una única fuente de verdad en Git.

Azure Arc-enabled SQL Server incorpora instancias locales de SQL Server (2012–2022) a ARM. Entre sus ventajas se incluyen: Azure Extended Security Updates (ESU) gratuitas cuando se conecta a Arc (para SQL Server 2012/2014, cuyo soporte estándar ya finalizó), detección de amenazas con Microsoft Defender for SQL, autenticación de Entra ID para SQL local e integración con Azure Monitor para las métricas de rendimiento de la base de datos. Arc no modifica el funcionamiento de SQL Server; solo añade capacidades de administración.

Azure Arc resource bridge es un dispositivo virtual ligero que se implementa en un entorno de VMware vSphere o Azure Stack HCI. Crea una conexión de administración que le permite ver, iniciar, detener y cambiar el tamaño de las máquinas virtuales de VMware desde el portal de Azure sin migrarlas. Esto resulta especialmente útil para las organizaciones que comienzan su recorrido hacia la nube y desean estandarizar las herramientas de administración en Azure mientras ejecutan máquinas virtuales localmente. También puede aplicar directivas de Arc y supervisar estas máquinas virtuales con Azure Monitor mediante la conexión del puente de recursos.

El agente Azure Connected Machine y la incorporación de Kubernetes a Arc son gratuitos. Se aplican cargos por servicios específicos de valor añadido: Defender for Servers, la ingesta de datos del agente de Azure Monitor y los servicios de datos habilitados para Arc (SQL Managed Instance y PostgreSQL). Los únicos requisitos previos para incorporar un servidor son que tenga acceso HTTPS saliente a los puntos de conexión de Azure (o que use un proxy), un sistema operativo compatible (Windows Server 2008 R2 o posterior, o muchas distribuciones de Linux) y una suscripción de Azure con el proveedor de recursos Microsoft.HybridCompute registrado.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) tratados en esta lección.

En esta lección ha aprendido que Azure Arc amplía el plano de administración de Azure a servidores locales, clústeres de Kubernetes e instancias de SQL Server al proyectarlos en ARM; que el agente Azure Connected Machine incorpora servidores utilizando únicamente conectividad HTTPS saliente; y que GitOps con Flux permite implementar aplicaciones de forma declarativa en clústeres de Kubernetes habilitados para Arc. A continuación, exploraremos Azure ExpressRoute y VPN Gateway para establecer conectividad privada entre los entornos locales y Azure.