Modos e requisitos de conectividade
Este artigo descreve os modos de conectividade disponíveis para serviços de dados habilitados para Azure Arc e seus respetivos requisitos.
Modos de conectividade
Há várias opções para o grau de conectividade do seu ambiente de serviços de dados habilitado para ArcGIS do Azure com o Azure. Como seus requisitos variam com base na política de negócios, na regulamentação governamental ou na disponibilidade de conectividade de rede para o Azure, você pode escolher entre os seguintes modos de conectividade.
Os serviços de dados habilitados para o Azure Arc oferecem a opção de se conectar ao Azure em dois modos de conectividade diferentes:
- Diretamente conectado
- Ligado indiretamente
O modo de conectividade oferece a flexibilidade de escolher a quantidade de dados que é enviada para o Azure e como os usuários interagem com o Arc Data Controller. Dependendo do modo de conectividade escolhido, algumas funcionalidades dos serviços de dados habilitados para Arco do Azure podem ou não estar disponíveis.
É importante ressaltar que, se os serviços de dados habilitados para Arco do Azure estiverem diretamente conectados ao Azure, os usuários poderão usar as APIs do Azure Resource Manager, a CLI do Azure e o portal do Azure para operar os serviços de dados do Azure Arc. A experiência no modo conectado diretamente é muito parecida com a forma como você usaria qualquer outro serviço do Azure com provisionamento/desprovisionamento, dimensionamento, configuração e assim por diante, tudo no portal do Azure. Se os serviços de dados habilitados para Arco do Azure estiverem conectados indiretamente ao Azure, o portal do Azure será um modo de exibição somente leitura. Você pode ver o inventário de instâncias gerenciadas SQL e servidores PostgreSQL implantados e os detalhes sobre eles, mas não pode agir sobre eles no portal do Azure. No modo conectado indiretamente, todas as ações devem ser executadas localmente usando o Azure Data Studio, a CLI apropriada ou ferramentas nativas do Kubernetes, como kubectl.
Além disso, a ID do Microsoft Entra e o Controle de Acesso Baseado em Função do Azure podem ser usados no modo conectado diretamente somente porque há uma dependência de uma conexão contínua e direta com o Azure para fornecer essa funcionalidade.
Alguns serviços anexados ao Azure só estão disponíveis quando podem ser acessados diretamente, como Insights de Contêiner e backup para armazenamento de blob.
| Ligado indiretamente | Diretamente conectado | Nunca ligado | |
|---|---|---|---|
| Descrição | O modo conectado indiretamente oferece a maioria dos serviços de gerenciamento localmente em seu ambiente sem conexão direta com o Azure. Uma quantidade mínima de dados deve ser enviada ao Azure apenas para fins de inventário e cobrança. Ele é exportado para um arquivo e carregado no Azure pelo menos uma vez por mês. Nenhuma conexão direta ou contínua com o Azure é necessária. Alguns recursos e serviços que exigem uma conexão com o Azure não estarão disponíveis. | O modo conectado diretamente oferece todos os serviços disponíveis quando uma conexão direta pode ser estabelecida com o Azure. As conexões são sempre iniciadas do seu ambiente para o Azure e usam portas e protocolos padrão, como HTTPS/443. | Nenhum dado pode ser enviado de ou para o Azure de qualquer forma. |
| Disponibilidade atual | Disponível | Disponíveis | Não suportado atualmente. |
| Casos de uso típicos | Data centers locais que não permitem conectividade dentro ou fora da região de dados do data center devido a políticas de conformidade regulatória ou de negócios ou por preocupações com ataques externos ou exfiltração de dados. Exemplos típicos: instituições financeiras, cuidados de saúde, governo. Locais de site de borda onde o site de borda normalmente não tem conectividade com a Internet. Exemplos típicos: petróleo/gás ou aplicações em campos militares. Locais de presença que têm conectividade intermitente com longos períodos de interrupções. Exemplos típicos: estádios, navios de cruzeiro. |
Organizações que estão usando nuvens públicas. Exemplos típicos: Azure, AWS ou Google Cloud. Locais de presença onde a conectividade com a Internet normalmente está presente e é permitida. Exemplos típicos: lojas de varejo, manufatura. Data centers corporativos com políticas mais permissivas para conectividade de/para sua região de dados do datacenter para a Internet. Exemplos típicos: empresas não regulamentadas, pequenas/médias empresas |
Ambientes verdadeiramente "air-gapped" onde nenhum dado em nenhuma circunstância pode vir ou sair do ambiente de dados. Exemplos típicos: instalações governamentais ultrassecretas. |
| Como os dados são enviados para o Azure | Há três opções de como os dados de faturamento e inventário podem ser enviados para o Azure: 1) Os dados são exportados para fora da região de dados por um processo automatizado que tem conectividade com a região de dados segura e o Azure. 2) Os dados são exportados para fora da região de dados por um processo automatizado dentro da região de dados, copiados automaticamente para uma região menos segura, e um processo automatizado na região menos segura carrega os dados no Azure. 3) Os dados são exportados manualmente por um usuário dentro da região segura, retirados manualmente da região segura e carregados manualmente no Azure. As duas primeiras opções são um processo contínuo automatizado que pode ser agendado para ser executado com frequência, portanto, há um atraso mínimo na transferência de dados para o Azure, sujeito apenas à conectividade disponível para o Azure. |
Os dados são enviados automática e continuamente para o Azure. | Os dados nunca são enviados para o Azure. |
Disponibilidade de recursos por modo de conectividade
| Funcionalidade | Ligado indiretamente | Diretamente conectado |
|---|---|---|
| Alta disponibilidade automática | Suportado | Suportado |
| Provisionamento de autoatendimento | Suportado Use o Azure Data Studio, a CLI apropriada ou ferramentas nativas do Kubernetes, como Helm, kubectlou oc, ou use o provisionamento do Kubernetes GitOps habilitado para Azure Arc. |
Suportado Além das opções de criação do modo conectado indiretamente, você também pode criar por meio do portal do Azure, das APIs do Azure Resource Manager, da CLI do Azure ou dos modelos ARM. |
| Escalabilidade elástica | Suportado | Suportado |
| Faturação | Suportado Os dados de cobrança são exportados periodicamente e enviados para o Azure. |
Suportado Os dados de faturação são enviados automática e continuamente para o Azure e refletidos quase em tempo real. |
| Gestão de inventário | Suportado Os dados de inventário são exportados periodicamente e enviados para o Azure. Use ferramentas de cliente como o Azure Data Studio, a CLI de Dados do Azure ou kubectl para exibir e gerenciar o inventário localmente. |
Suportado Os dados de inventário são enviados automática e continuamente para o Azure e refletidos quase em tempo real. Como tal, pode gerir o inventário diretamente a partir do portal do Azure. |
| Atualizações e patches automáticos | Suportado O controlador de dados deve ter acesso direto ao Microsoft Container Registry (MCR) ou as imagens de contêiner precisam ser extraídas do MCR e enviadas para um registro de contêiner local e privado ao qual o controlador de dados tenha acesso. |
Suportado |
| Backup e restauração automáticos | Suportado Backup e restauração locais automáticos. |
Suportado Além do backup e restauração locais automatizados, você pode , opcionalmente , enviar backups para o armazenamento de blobs do Azure para retenção externa de longo prazo. |
| Monitorização | Suportado Monitoramento local usando painéis Grafana e Kibana. |
Suportado Além dos painéis de monitoramento locais, você pode , opcionalmente , enviar dados e logs de monitoramento para o Azure Monitor para monitoramento em escala de vários sites em um só lugar. |
| Autenticação | Use o nome de usuário/senha local para autenticação do controlador de dados e do painel. Use logons SQL e Postgres ou Ative Directory (AD não é suportado no momento) para conectividade com instâncias de banco de dados. Use provedores de autenticação do Kubernetes para autenticação na API do Kubernetes. | Além ou em vez dos métodos de autenticação para o modo conectado indiretamente, você pode , opcionalmente , usar o Microsoft Entra ID. |
| Controle de acesso baseado em função (RBAC) | Use o RBAC do Kubernetes na API do Kubernetes. Use SQL e Postgres RBAC para instâncias de banco de dados. | Você pode usar o Microsoft Entra ID e o Azure RBAC. |
Requisitos de conectividade
Algumas funcionalidades requerem uma ligação ao Azure.
Toda a comunicação com o Azure é sempre iniciada a partir do seu ambiente. Isso é verdadeiro mesmo para operações iniciadas por um usuário no portal do Azure. Nesse caso, há efetivamente uma tarefa, que é enfileirada no Azure. Um agente em seu ambiente inicia a comunicação com o Azure para ver quais tarefas estão na fila, executa as tarefas e relata o status/conclusão/falha no Azure.
| Tipo de dados | Direção | Obrigatório/Opcional | Custos Adicionais | Modo Necessário | Notas |
|---|---|---|---|---|---|
| Imagens de contêiner | Microsoft Container Registry -> Cliente | Obrigatório | Não | Indireta ou direta | Imagens de contêiner são o método para distribuir o software. Em um ambiente que pode se conectar ao Microsoft Container Registry (MCR) pela Internet, as imagens de contêiner podem ser extraídas diretamente do MCR. Se o ambiente de implantação não tiver conectividade direta, você poderá extrair as imagens do MCR e enviá-las por push para um registro de contêiner privado no ambiente de implantação. No momento da criação, você pode configurar o processo de criação para extrair do registro de contêiner privado em vez de MCR. Isso também se aplica a atualizações automatizadas. |
| Inventário de recursos | Ambiente do cliente -> Azure | Obrigatório | Não | Indireta ou direta | Um inventário de controladores de dados, instâncias de banco de dados (PostgreSQL e SQL) é mantido no Azure para fins de cobrança e também para fins de criação de um inventário de todos os controladores de dados e instâncias de banco de dados em um só lugar, o que é especialmente útil se você tiver mais de um ambiente com os serviços de dados do Azure Arc. À medida que as instâncias são provisionadas, desprovisionadas, dimensionadas/in, dimensionadas para cima/para baixo, o inventário é atualizado no Azure. |
| Dados de telemetria de faturamento | Ambiente do cliente -> Azure | Obrigatório | Não | Indireta ou direta | A utilização de instâncias de banco de dados deve ser enviada ao Azure para fins de cobrança. |
| Monitoramento de dados e logs | Ambiente do cliente -> Azure | Opcional | Talvez dependendo do volume de dados (consulte os preços do Azure Monitor) | Indireta ou direta | Talvez você queira enviar os dados e logs de monitoramento coletados localmente para o Azure Monitor para agregar dados em vários ambientes em um só lugar e também usar os serviços do Azure Monitor, como alertas, usando os dados no Azure Machine Learning, etc. |
| Controle de acesso baseado em função do Azure (Azure RBAC) | Ambiente do cliente -> Azure -> Ambiente do cliente | Opcional | Não | Apenas direto | Se você quiser usar o RBAC do Azure, a conectividade deve ser estabelecida com o Azure em todos os momentos. Se você não quiser usar o RBAC do Azure, o RBAC do Kubernetes local pode ser usado. |
| Microsoft Entra ID (Futuro) | Ambiente do cliente -> Azure -> Ambiente do cliente | Opcional | Talvez, mas você já pode estar pagando pelo Microsoft Entra ID | Apenas direto | Se você quiser usar o Microsoft Entra ID para autenticação, a conectividade deve ser estabelecida com o Azure em todos os momentos. Se não quiser usar o Microsoft Entra ID para autenticação, você pode usar os Serviços de Federação do Ative Directory (ADFS) sobre o Ative Directory. Disponibilidade pendente no modo conectado diretamente |
| Backup e restauro | Ambiente do cliente -> Ambiente do cliente | Obrigatório | Não | Direta ou indireta | O serviço de backup e restauração pode ser configurado para apontar para classes de armazenamento locais. |
| Backup do Azure - retenção de longo prazo (Futuro) | Ambiente do cliente -> Azure | Opcional | Sim para armazenamento do Azure | Apenas direto | Talvez você queira enviar backups que são levados localmente para o Backup do Azure para retenção externa de backups de longo prazo e trazê-los de volta ao ambiente local para restauração. |
| Alterações de provisionamento e configuração do portal do Azure | Ambiente do cliente -> Azure -> Ambiente do cliente | Opcional | Não | Apenas direto | As alterações de provisionamento e configuração podem ser feitas localmente usando o Azure Data Studio ou a CLI apropriada. No modo conectado diretamente, você também pode provisionar e fazer alterações de configuração no portal do Azure. |
Detalhes sobre endereços de internet, portas, criptografia e suporte ao servidor proxy
| Serviço | Porta | URL | Direção | Notas |
|---|---|---|---|---|
| Gráfico de leme (somente no modo de conexão direta) | 443 | arcdataservicesrow1.azurecr.io |
Saída | Provisiona o bootstrapper do controlador de dados do Azure Arc e objetos de nível de cluster, como definições de recursos personalizadas, funções de cluster e associações de função de cluster, são extraídos de um Registro de Contêiner do Azure. |
| Azure monitor APIs 1 | 443 | *.ods.opinsights.azure.com*.oms.opinsights.azure.com*.monitoring.azure.com |
Saída | O Azure Data Studio e a CLI do Azure se conectam às APIs do Azure Resource Manager para enviar e recuperar dados de e para o Azure para alguns recursos. Consulte Azure Monitor APIs. |
| Serviço de processamento de dados do Azure Arc 1 | 443 | *.<region>.arcdataservices.com 2 |
De Saída |
1 O requisito depende do modo de implantação:
- Para o modo direto, o pod controlador no cluster Kubernetes precisa ter conectividade de saída com os pontos de extremidade para enviar os logs, métricas, inventário e informações de cobrança para o Azure Monitor/Serviço de Processamento de Dados.
- Para o modo indireto, a máquina que é executada
az arcdata dc uploadprecisa ter a conectividade de saída com o Azure Monitor e o Serviço de Processamento de Dados.
2 Para versões de extensão até 13 de fevereiro de 2024, inclusive, use san-af-<region>-prod.azurewebsites.net.
Azure Monitor APIs
A conectividade do Azure Data Studio com o servidor de API do Kubernetes usa a autenticação e a criptografia do Kubernetes que você estabeleceu. Cada usuário que está usando o Azure Data Studio ou a CLI deve ter uma conexão autenticada com a API do Kubernetes para executar muitas das ações relacionadas aos serviços de dados habilitados para Arco do Azure.
Requisitos de rede adicionais
Além disso, a ponte de recursos requer pontos de extremidade Kubernetes habilitados para Arc.