Modos de conectividad y requisitos
En este artículo se describen los modos de conectividad disponibles para los servicios de datos habilitados para Azure Arc y sus respectivos requisitos.
Modos de conectividad
Hay varias opciones para el grado de conectividad desde el entorno de los servicios de datos habilitados para Azure Arc a Azure. A medida que los requisitos varían en función de la directiva empresarial, las normativas gubernamentales o la disponibilidad de la conectividad de red con Azure, puede elegir entre los siguientes modos de conectividad.
Los servicios de datos habilitados para Azure Arc le ofrecen la opción de conectarse a Azure con dos modos de conectividad diferentes:
- Conexión directa
- Conexión indirecta
El modo de conectividad le proporciona la flexibilidad de elegir la cantidad de datos que se envían a Azure y el modo en que los usuarios interactúan con el controlador de datos de Arc. En función del modo de conectividad elegido, sería posible que alguna funcionalidad de los servicios de datos habilitados para Azure Arc no esté disponible.
Lo más importante es que si los servicios de datos habilitados para Azure Arc están conectados directamente a Azure, los usuarios pueden usar las API de Azure Resource Manager, la CLI de Azure y Azure Portal para operar los servicios de datos de Azure Arc. La experiencia en el modo Conectado directamente es muy parecida a como se haría con cualquier otro servicio de Azure, con el aprovisionamiento y desaprovisionamiento, el escalado, la configuración, etc., mediante Azure Portal. Si los servicios de datos habilitados para Azure Arc están conectados indirectamente a Azure, Azure Portal es una vista de solo lectura. Podrá ver el inventario de las instancias administradas de SQL y los servidores de PostgreSQL que ha implementado, así como sus detalles. Sin embargo, no podrá realizar acciones sobre ellos en Azure Portal. En el modo de conexión indirecta, todas las acciones se deben realizar de forma local mediante Azure Data Studio, la CLI apropiada o herramientas nativas de Kubernetes, como kubectl.
Además, Microsoft Entra ID y el control de acceso basado en rol de Azure solo se pueden usar en el modo de conexión directa, ya que hay una dependencia de una conexión continua y directa con Azure para proporcionar esta funcionalidad.
Algunos servicios conectados a Azure solo están disponibles cuando se puede acceder directamente a ellos, como Container Insights y la copia de seguridad en Blob Storage.
| Conexión indirecta | Conexión directa | Nunca conectado | |
|---|---|---|---|
| Descripción | El modo de conexión indirecta ofrece la mayoría de los servicios de administración de forma local en su entorno sin conexión directa con Azure. Se debe enviar una cantidad mínima de datos a Azure solo para fines de inventario y facturación. Se exporta a un archivo y se carga en Azure al menos una vez al mes. No se requiere ninguna conexión directa ni continua con Azure. Algunas características y servicios que requieren una conexión a Azure no estarán disponibles. | El modo de conexión directa ofrece todos los servicios disponibles cuando se puede establecer una conexión directa con Azure. Las conexiones siempre se inician desde su entorno a Azure y usan puertos y protocolos estándar como HTTPS/443. | No se pueden enviar datos a Azure ni recibirlos de ningún modo. |
| Disponibilidad actual | Disponible | Disponible | No se admite actualmente. |
| Casos de uso típicos | Centros de datos locales que no permiten la conectividad dentro o fuera de la región de datos del centro de datos debido a las directivas de cumplimiento normativo o de la empresa o a las preocupaciones con respecto a ataques externos o filtración de datos. Ejemplos típicos: instituciones financieras, atención sanitaria, gobierno. Ubicaciones de sitios perimetrales en las que el sitio perimetral normalmente no tiene conectividad a Internet. Ejemplos típicos: aplicaciones para petróleo o gas o campos militares. Ubicaciones de sitios perimetrales que tienen conectividad intermitente con períodos largos de interrupciones. Ejemplos típicos: estadios, barcos de crucero. |
Organizaciones que usan nubes públicas. Ejemplos típicos: Azure, AWS o Google Cloud. Ubicaciones de sitios perimetrales donde hay normalmente conectividad a Internet y está permitida. Ejemplos típicos: tiendas minoristas, fabricación. Centros de datos corporativos con directivas más permisivas para la conectividad entre la región de datos del centro de datos e Internet. Ejemplos típicos: empresas no reguladas, pequeñas y medianas empresas |
Entornos verdaderamente "aislados" en los que ningún dato puede entrar ni salir del entorno de datos bajo ninguna circunstancia. Ejemplos típicos: instalaciones confidenciales del gobierno. |
| Cómo se envían los datos a Azure | Hay tres opciones para la forma en la que se pueden enviar a Azure los datos de inventario y facturación: 1) los datos se exportan fuera de la región de datos mediante un proceso automatizado que tiene conectividad con la región de datos segura y con Azure. 2) los datos se exportan fuera de la región de datos mediante un proceso automatizado dentro de la región de datos, se copian automáticamente en una región menos segura y un proceso automatizado en la región menos segura carga los datos en Azure. 3) un usuario exporta manualmente los datos dentro de la región segura, los saca manualmente de la región segura y los carga manualmente en Azure. Las dos primeras opciones son un proceso continuo automatizado que se puede programar para ejecutarse con frecuencia, por lo que hay un retraso mínimo en la transferencia de datos a Azure, sujeto solo a la conectividad disponible con Azure. |
Los datos se envían automáticamente y continuamente a Azure. | Los datos nunca se envían a Azure. |
Disponibilidad de características según el modo de conectividad
| Característica | Conexión indirecta | Conexión directa |
|---|---|---|
| Alta disponibilidad automática | Compatible | Compatible |
| Aprovisionamiento de autoservicio | Compatible Use Azure Data Studio, la CLI apropiada o las herramientas nativas de Kubernetes como Helm, kubectl o oc, o utilice el aprovisionamiento GitOps de Kubernetes habilitado por Azure Arc. |
Compatible Además de las opciones de creación del modo de conexión indirecta, también puede crear lo que necesite mediante Azure Portal, las API de Azure Resource Manager, la CLI de Azure o plantillas de ARM. |
| Escalabilidad elástica | Compatible | Compatible |
| Facturación | Compatible Los datos de facturación se exportan periódicamente y se envían a Azure. |
Compatible Los datos de facturación se envían automáticamente y continuamente a Azure y se reflejan casi en tiempo real. |
| Gestión del inventario | Compatible Los datos de inventario se exportan periódicamente y se envían a Azure. Use herramientas de cliente como Azure Data Studio, la CLI de datos de Azure o kubectl para ver y administrar el inventario de forma local. |
Compatible Los datos de inventario se envían automáticamente y continuamente a Azure y se reflejan casi en tiempo real. Como tal, puede administrar el inventario directamente desde Azure Portal. |
| Actualizaciones y revisiones automáticas | Compatible El controlador de datos debe tener acceso directo a Microsoft Container Registry (MCR) o se deben extraer de MCR las imágenes de contenedor e insertarlas en un registro de contenedor privado local al que el controlador de datos tenga acceso. |
Compatible |
| Copia de seguridad y restauración automáticas | Compatible Copias de seguridad y restauración locales automáticas. |
Compatible Además de la copia de seguridad y restauración locales automatizadas, puede enviar de forma opcional copias de seguridad a Azure Blob Storage para la retención a largo plazo y fuera del sitio. |
| Supervisión | Compatible Supervisión local con los paneles de Grafana y Kibana. |
Compatible Además de los paneles de supervisión locales, puede opcionalmente enviar datos de supervisión y registros a Azure Monitor para la supervisión a escala de varios sitios en un solo lugar. |
| Autenticación | Use el nombre de usuario y la contraseña locales para el controlador de datos y la autenticación del panel. Use inicios de sesión de SQL y Postgres o Active Directory (AD no se admite actualmente) para la conectividad con instancias de base de datos. Use los proveedores de autenticación de Kubernetes para la autenticación en la API de Kubernetes. | Además de o en lugar de los métodos de autenticación para el modo conectado indirectamente, puede usar opcionalmente Microsoft Entra ID. |
| Control de acceso basado en rol (RBAC) | Use RBAC de Kubernetes en la API de Kubernetes. Use RBAC de SQL y Postgres para las instancias de base de datos. | Puede usar Microsoft Entra ID y Azure RBAC. |
Requisitos de conectividad
Algunas funcionalidades requieren una conexión a Azure.
Toda la comunicación con Azure se inicia siempre desde su entorno. Esto es así incluso para las operaciones que un usuario inicia en Azure Portal. En ese caso, hay una tarea que se pone en cola en Azure. Un agente de su entorno inicia la comunicación con Azure para ver qué tareas hay en la cola, ejecuta las tareas e informa del estado, la finalización o el error a Azure.
| Tipo de datos | Dirección | Obligatorio/opcional | Costos adicionales | Modo requerido | Notas |
|---|---|---|---|---|---|
| Imágenes de contenedor | Microsoft Container Registry -> Cliente | Obligatorio | No | Indirecto o directo | Las imágenes de contenedor son el método para distribuir el software. En un entorno que se puede conectar a Microsoft Container Registry (MCR) a través de Internet, las imágenes de contenedor se pueden extraer directamente de MCR. Si el entorno de implementación no tenga conectividad directa, puede extraer las imágenes de MCR e insertarlas en un registro de contenedor privado en el entorno de implementación. En el momento de la creación, puede configurar el proceso de creación para que se realice la extracción desde el registro de contenedor privado en lugar de MCR. Esto también se aplica a las actualizaciones automatizadas. |
| Inventario de recursos | Entorno del cliente -> Azure | Obligatorio | No | Indirecto o directo | En Azure se mantiene un inventario de los controladores de datos y las instancias de base de datos (PostgreSQL y SQL) con fines de facturación y también con el fin de crear un inventario de todos los controladores de datos e instancias de base de datos en un único lugar, lo que es especialmente útil si tiene más de un entorno con servicios de datos de Azure Arc. El inventario se actualiza en Azure a medida que las instancias se aprovisionan o se desaprovisionan y se escalan o se reducen horizontal y verticalmente. |
| Datos de telemetría de facturación | Entorno del cliente -> Azure | Obligatorio | No | Indirecto o directo | Se debe enviar a Azure la utilización de las instancias de base de datos con fines de facturación. |
| Supervisión de datos y registros | Entorno del cliente -> Azure | Opcionales | Es posible en función del volumen de datos (consulte Precios de Azure Monitor). | Indirecto o directo | Es posible que desee enviar los registros y datos de supervisión recopilados localmente a Azure Monitor para agregar los datos de varios entornos en un solo lugar y usar servicios de Azure Monitor como las alertas, utilizar los datos en Azure Machine Learning, etc. |
| Control de acceso basado en rol de Azure (Azure RBAC) | Entorno del cliente -> Azure -> Entorno del cliente | Opcionales | No | Solo directo | Si desea usar Azure RBAC, la conectividad con Azure debe estar establecida en todo momento. Si no desea usar Azure RBAC, puede usar RBAC de Kubernetes local. |
| Microsoft Entra ID (futuro) | Entorno del cliente -> Azure -> Entorno del cliente | Opcionales | Quizás, pero es posible que ya esté pagando por Microsoft Entra ID | Solo directo | Si desea usar Microsoft Entra ID para la autenticación, la conectividad con Azure debe estar establecida en todo momento. Si no desea usar Microsoft Entra ID para la autenticación, puede usar los Servicios de federación de Active Directory (AD FS) sobre Active Directory. Pendiente de la disponibilidad en el modo de conexión directa |
| Copia de seguridad y restauración | Entorno del cliente -> Entorno del cliente | Obligatorio | No | Directa o indirecta | El servicio de copia de seguridad y restauración se puede configurar para que apunte a clases de almacenamiento local. |
| Copia de seguridad de Azure - Retención a largo plazo (en un futuro) | Entorno del cliente -> Azure | Opcionales | Sí, para Azure Storage | Solo directo | Es posible que desee enviar copias de seguridad que se realizan localmente a Azure Backup para la retención a largo plazo y fuera del sitio de las copias de seguridad y devolverlas al entorno local para su restauración. |
| Aprovisionamiento y cambios de configuración desde Azure Portal | Entorno del cliente -> Azure -> Entorno del cliente | Opcionales | No | Solo directo | El aprovisionamiento y los cambios de configuración se pueden realizar localmente mediante Azure Data Studio o la CLI apropiada. En el modo conectado directamente, también puede aprovisionar y realizar cambios de configuración desde Azure Portal. |
Detalles sobre las direcciones de Internet, los puertos, el cifrado y la compatibilidad con servidores proxy
| Servicio | Puerto | URL | Dirección | Notas |
|---|---|---|---|---|
| Gráfico de Helm (solo modo conectado directo) | 443 | arcdataservicesrow1.azurecr.io |
Salida | Aprovisiona el programa previo del controlador de datos de Azure Arc y los objetos de nivel de clúster, como definiciones de recursos personalizados, roles de clúster y enlaces de rol de clúster, se extrae de una instancia de Azure Container Registry. |
| API de Azure Monitor 1 | 443 | *.ods.opinsights.azure.com*.oms.opinsights.azure.com*.monitoring.azure.com |
Salida | Azure Data Studio y la CLI de Azure se conectan a las API de Azure Resource Manager para enviar y recuperar datos de Azure para algunas características. Consulte API de Azure Monitor. |
| Servicio de procesamiento de datos de Azure Arc 1 | 443 | *.<region>.arcdataservices.com 2 |
Salida |
1 Requisito depende del modo de implementación:
- Para el modo directo, el pod del controlador en el clúster de Kubernetes debe tener conectividad saliente a los puntos de conexión para enviar los registros, las métricas, el inventario y la información de facturación a Azure Monitor/Data Processing Service.
- Para el modo indirecto, la máquina que se ejecuta
az arcdata dc uploaddebe tener la conectividad saliente con Azure Monitor y el servicio de procesamiento de datos.
2 Para las versiones de extensión hasta el 13 de febrero de 2024 (incluido ese día), use san-af-<region>-prod.azurewebsites.net.
API de Azure Monitor
La conectividad desde Azure Data Studio al servidor de API de Kubernetes usa el cifrado y la autenticación de Kubernetes que haya establecido. Cada usuario que usa Azure Data Studio o la CLI debe tener una conexión autenticada a la API de Kubernetes para realizar muchas de las acciones relacionadas con los servicios de datos habilitados para Azure Arc.
Requisitos de red adicionales
Además, el puente de recursos requiere puntos de conexión de Kubernetes habilitados para Arc.