Requisitos e modos de conectividade
Este artigo descreve os modos de conectividade disponíveis para os serviços de dados habilitados para Azure Arc e seus respectivos requisitos.
Modos de conectividade
Há várias opções para o grau de conectividade do seu ambiente de serviços de dados habilitados para Azure Arc com o Azure. Conforme os seus requisitos variam de acordo com a política empresarial, a regulamentação governamental ou a disponibilidade de conectividade de rede com o Azure, você pode escolher entre os modos de conectividade a seguir.
Os serviços de dados habilitados para o Azure Arc fornecem a opção conexão com o Azure em dois modos de conectividade diferentes:
- Conectado diretamente
- Conectado indiretamente
O modo de conectividade fornece flexibilidade para escolher a quantidade de dados enviada para o Azure e como os usuários interagem com o Controlador de Dados do Arc. Dependendo do modo de conectividade escolhido, algumas funcionalidades dos serviços de dados habilitados para Azure Arc podem ou não estar disponíveis.
Importante: se os serviços de dados habilitados para Azure Arc 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 de conexão direta é muito parecida com o uso de qualquer outro serviço do Azure com provisionamento/desprovisionamento, escala, configuração e assim por diante no portal do Azure. Se os serviços de dados habilitados para Azure Arc estiverem indiretamente conectados ao Azure, o portal do Azure terá uma exibição somente leitura. Você poderá ver o inventário de instâncias gerenciadas de SQL e servidores do PostgreSQL que você implantou e os detalhes sobre eles, mas não poderá agir sobre eles no portal do Azure. No modo conectado indiretamente, todas as ações precisam ser executadas localmente usando o Azure Data Studio, a CLI apropriada ou as ferramentas nativas do Kubernetes, como kubectl.
Além disso, o Microsoft Entra ID e o Controle de Acesso Baseado em Função do Azure podem ser usados apenas no modo de conexão direta, pois eles dependem de uma conexão direta e contínua ao Azure para fornecer essa funcionalidade.
Alguns serviços anexados ao Azure só estão disponíveis quando podem ser acessados diretamente, como os Insights de Contêiner e o backup no armazenamento de blobs.
| Conectado indiretamente | Conectado diretamente | Nunca conectado | |
|---|---|---|---|
| Descrição | O modo conectado indiretamente oferece a maioria dos serviços de gerenciamento localmente no seu ambiente sem conexão direta com o Azure. Uma quantidade mínima de dados precisa ser enviada para o Azure apenas para fins de inventário e cobrança. Eles são exportados para um arquivo e carregados no Azure pelo menos uma vez por mês. Nenhuma conexão direta ou contínua ao 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 oferecerá todos os serviços disponíveis quando uma conexão direta puder ser estabelecida com o Azure. As conexões são sempre iniciadas do seu ambiente para o Azure e usam portas padrão e protocolos como HTTPS/443. | Nenhum dado pode ser enviado de ou para o Azure de nenhuma forma. |
| Disponibilidade atual | Disponível | Disponível | Não há suporte no momento. |
| Casos de uso típicos | Data centers locais que não permitem a conectividade dentro ou fora da região de dados do data center devido a políticas de conformidade regulatória ou empresariais ou por preocupações sobre ataques externos ou exfiltração dos dados. Exemplos típicos: instituições financeiras, serviços de saúde, governo. Locais do site de borda em que o site de borda normalmente não tem conectividade com a Internet. Exemplos típicos: aplicativos militares ou plataforma de petróleo/gás. Locais de site de borda que têm conectividade intermitente com longos períodos de interrupções. Exemplos típicos: estádios, cruzeiros. |
Organizações que estão usando nuvens públicas. Exemplos típicos: Azure, AWS ou Google Cloud. Locais de site de borda em que a conectividade com a Internet normalmente está presente e é permitida. Exemplos típicos: lojas de varejo, fabricação. Data centers corporativos com políticas mais permissivas de conectividade de/para a região de dados do datacenter com a Internet. Exemplos típicos: empresas não regulamentadas, empresas de pequeno/médio porte |
Ambientes verdadeiramente "lacrados" em que nenhum dado, em nenhuma circunstância, pode sair ou entrar do ambiente de dados. Exemplos típicos: instalações ultrassecretas do governo. |
| Como os dados são enviados para o Azure | Há três opções de como os dados de cobrança e de 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 na região de dados, são automaticamente copiados 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 na região segura, extraídos manualmente da região segura e carregados manualmente no Azure. As duas primeiras opções são processos contínuos automatizados que podem ser agendados para execuções frequentes a fim de que o atraso na transferência de dados para o Azure seja mínimo e sujeito somente à conectividade disponível com o Azure. |
Os dados são enviados de modo automático e contínuo para o Azure. | Os dados nunca são enviados para o Azure. |
Disponibilidade de recursos por modo de conectividade
| Recurso | Conectado indiretamente | Conectado diretamente |
|---|---|---|
| Alta disponibilidade automática | Com suporte | Com suporte |
| Provisionamento de autoatendimento | Com suporte Use o Azure Data Studio, a CLI apropriada ou ferramentas nativas do Kubernetes como o Helm, kubectlou oc, ou use o provisionamento GitOps do Kubernetes habilitado para Azure Arc. |
Com suporte Além das opções de criação de modo conectado indiretamente, você também pode criar por meio do portal do Azure, das APIs d Azure Resource Manager, da CLI do Azure ou dos modelos do ARM. |
| Escalabilidade elástica | Com suporte | Com suporte |
| Billing | Com suporte Os dados de cobrança são exportados periodicamente e enviados para o Azure. |
Com suporte Os dados de cobrança são enviados de modo automático e contínuo ao Azure e exibidos quase em tempo real. |
| Gerenciamento de estoque | Com suporte 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 o kubectl, para exibir e gerenciar o inventário localmente. |
Com suporte Os dados de inventário são enviados de modo automático e contínuo ao Azure e exibidos quase em tempo real. Assim, você pode gerenciar o inventário diretamente no portal do Azure. |
| Atualizações automáticas e aplicação de patch | Com suporte O controlador de dados precisa ter acesso direto ao MCR (Microsoft Container Registry) ou as imagens de contêiner precisam ser extraídas do MCR e enviadas por push para um registro de contêiner privado local ao qual o controlador de dados tem acesso. |
Com suporte |
| Backup e restauração automáticos | Com suporte Backup e restauração locais automáticos. |
Com suporte 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. |
| Monitoring | Com suporte Monitoramento local usando os painéis do Grafana e do Kibana. |
Com suporte Além dos painéis de monitoramento locais, opcionalmente, você pode enviar dados e logs de monitoramento para Azure Monitor para monitoramento em escala de vários sites em um local. |
| Autenticação | Use o nome de usuário/senha local para o controlador de dados e a autenticação do painel. Use os logons do SQL e do Postgres ou o Active Directory (não há suporte para o AD no momento) para obter conectividade com as instâncias de banco de dados. Use os provedores de autenticação Kubernetes para autenticação na API do Kubernetes. | Além de usar os métodos de autenticação do modo de conexão indireta ou em vez de usá-los, você pode, opcionalmente, usar o Microsoft Entra ID. |
| RBAC (controle de acesso baseado em função) | Use o RBAC do Kubernetes na API do Kubernetes. Use o RBAC do SQL e do Postgres para instâncias de banco de dados. | Você pode usar o Microsoft Entra ID e o RBAC do Azure. |
Requisitos de conectividade
Algumas funcionalidades exigem uma conexão com o Azure.
Toda a comunicação com o Azure é sempre iniciada no seu ambiente. Isso se aplica mesmo a operações iniciadas por um usuário no portal do Azure. Nesse caso, há realmente uma tarefa, que é enfileirada no Azure. Um agente no 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 para o Azure.
| Tipo de dados | Direção | Obrigatório/Opcional | Custos adicionais | Modo exigido | Observações |
|---|---|---|---|---|---|
| Imagens de contêiner | Microsoft Container Registry -> Cliente | Obrigatório | Não | Indireto ou direto | As imagens de contêiner são o método para distribuir o software. Em um ambiente que pode se conectar ao MCR (Microsoft Container Registry) pela Internet, as imagens de contêiner podem ser extraídas diretamente do MCR. Caso o ambiente de implantação não tenha conectividade direta, você pode efetuar pull das 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 efetuar pull do registro de contêiner privado em vez do MCR. Isso também se aplica a atualizações automatizadas. |
| Inventário de recursos | Ambiente do cliente -> Azure | Obrigatório | Não | Indireto ou direto | Um inventário de controladores de dados e de instâncias de banco de dados (PostgreSQL e SQL) é mantido no Azure para fins de cobrança e também para a criação de um inventário de todos os controladores de dados e instâncias de banco de dados em um só lugar, que será especialmente útil se você tiver mais de um ambiente com os serviços de dados do Azure Arc. Conforme as instâncias são provisionadas, desprovisionadas, escaladas/reduzidas horizontalmente, escaladas/reduzidas verticalmente, o inventário é atualizado no Azure. |
| Dados de telemetria de cobrança | Ambiente do cliente -> Azure | Obrigatório | Não | Indireto ou direto | A utilização de instâncias de banco de dados precisa ser enviada ao Azure para fins de cobrança. |
| Dados e logs de monitoramento | Ambiente do cliente -> Azure | Opcional | Talvez, dependendo do volume de dados (confira Preço do Azure Monitor) | Indireto ou direto | Talvez você queira enviar os logs e os dados de monitoramento coletados localmente para o Azure Monitor para agregar os dados de vários ambientes em um só local e também para usar serviços do Azure Monitor como alertas, usar os dados no Azure Machine Learning etc. |
| RBAC do Azure (Controle de Acesso Baseado em Função do Azure) | Ambiente do cliente -> Azure -> Ambiente do cliente | Opcional | Não | Somente direto | Se você quiser usar o RBAC do Azure, precisará estar conectado ao Azure em todos os momentos. Se você não quiser usar o RBAC do Azure, o RBAC do Kubernetes local poderá ser usado. |
| Microsoft Entra ID (futuro) | Ambiente do cliente -> Azure -> Ambiente do cliente | Opcional | Talvez, mas talvez você já esteja pagando pelo Microsoft Entra ID | Somente direto | Se você quiser usar o Microsoft Entra ID para autenticação, a conectividade precisará estar sempre estabelecida com o Azure. Se não quiser usar o Microsoft Entra ID para autenticação, você poderá usar o AD FS (Serviços de Federação do Active Directory) por meio do Active Directory. Disponibilidade pendente no modo conectado diretamente |
| Backup e restauração | Ambiente do cliente -> Ambiente do cliente | Obrigatório | Não | Direto ou indireto | 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, no armazenamento do Azure | Somente direto | Talvez você queira enviar backups que são realizados localmente para o Backup do Azure para retenção externa de longo prazo dos backups e trazê-los de volta para o ambiente local para restauração. |
| Provisionamento e alterações de configuração do portal do Azure | Ambiente do cliente -> Azure -> Ambiente do cliente | Opcional | Não | Somente direto | O provisionamento e as alterações de configuração podem ser feitas localmente usando o Azure Data Studio ou a CLI apropriada. No modo de conexão direta, você também poderá provisionar e fazer alterações na configuração no portal do Azure. |
Detalhes sobre suporte ao servidor proxy, endereços da Internet, portas e criptografia
| Serviço | Porta | URL | Direção | Observações |
|---|---|---|---|---|
| Gráfico do Helm ( somente modo de conexão direta) | 443 | arcdataservicesrow1.azurecr.io |
Saída | Provisiona o bootstrapper do controlador de dados do Azure Arc e os objetos de nível de cluster, como definições de recursos personalizadas, funções de cluster e vinculações de função de cluster, e é retirado de um Registro de Contêiner do Azure. |
| APIs do Azure Monitor 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 de alguns recursos. Consulte APIs do Azure Monitor. |
| Serviço de processamento de dados do Azure Arc 1 | 443 | *.<region>.arcdataservices.com 2 |
Saída |
1 O requisito depende do modo de implantação:
- Para o modo direto, o pod do controlador no cluster do Kubernetes precisa ter conectividade de saída com os pontos de extremidade para enviar os logs, as métricas, o inventário e as informações de cobrança para o Azure Monitor/Serviço de Processamento de Dados.
- Para o modo indireto, o computador que executa
az arcdata dc uploadprecisa ter conectividade de saída com o Azure Monitor e o Serviço de Processamento de Dados.
2 Para as versões de extensão até e incluindo a de 13 de fevereiro de 2024, use san-af-<region>-prod.azurewebsites.net.
APIs do Azure Monitor
A conectividade do Azure Data Studio com o servidor de API do Kubernetes usa a criptografia e a autenticação do Kubernetes que você estabeleceu. Cada usuário que está usando o Azure Data Studio ou a CLI precisa ter uma conexão autenticada com a API do Kubernetes para executar muitas das ações relacionadas aos serviços de dados habilitados para Azure Arc.
Requisitos de rede adicionais
Além disso, a ponte de recursos requer pontos de extremidade do Kubernetes habilitados para Arc.