Para dar suporte a este exemplo trabalhado, a empresa fictícia "Contoso" será usada com uma Plataforma de Dados do Azure baseada em Arquiteturas de Referência da Microsoft.
A Contoso implementou a seguinte arquitetura fundamental do Azure, que é um subconjunto do design da Zona de Desembarque Empresarial .
Os números nas descrições a seguir correspondem ao diagrama anterior acima.
- Inscrição empresarial - a principal inscrição empresarial principal da Contoso no Azure reflete o seu contrato comercial com a Microsoft, a sua estrutura de conta organizacional e as subscrições do Azure disponíveis. Ele fornece a base de faturamento para assinaturas e como o patrimônio digital é administrado.
- Gerenciamento de identidade e acesso – Os componentes necessários para fornecer serviços de identidade, autenticação, acesso a recursos e autorização no patrimônio do Azure da Contoso.
- Grupo de gerenciamento e organização de assinatura - Uma hierarquia de grupo escalável alinhada aos recursos principais da plataforma de dados, permitindo a operacionalização em escala usando segurança e governança gerenciadas centralmente, onde as cargas de trabalho têm separação clara. Os grupos de gerenciamento fornecem um escopo de governança acima das assinaturas.
- Subscrição de gestão - Uma subscrição dedicada para as várias funções de nível de gestão necessárias para suportar a plataforma de dados.
- Assinatura de conectividade - Uma assinatura dedicada para as funções de conectividade da plataforma de dados, permitindo identificar serviços nomeados, determinar roteamento e comunicação seguros entre e entre serviços internos e externos.
- Subscrição da zona de aterragem – Subscrições um-para-muitos para aplicações nativas do Azure, aplicações online, cargas de trabalho e recursos internos e externos
- Plataforma DevOps - A plataforma DevOps que suporta todo o património do Azure. Esta plataforma contém a base de código, o repositório de controle do código-fonte e os pipelines de CI/CD, permitindo implantações automatizadas de infraestrutura como código (IaC).
Nota
Muitos clientes ainda mantêm uma grande pegada de infraestrutura como serviço (IaaS). Para fornecer recursos de recuperação em IaaS, o principal componente a ser adicionado é a recuperação do Site do Azure. O Site Recovery orquestrará e automatizará a replicação de VMs do Azure entre regiões, máquinas virtuais locais e servidores físicos para o Azure e máquinas locais para um datacenter secundário.
Dentro dessa estrutura fundamental, a Contoso implementou os seguintes elementos para dar suporte às suas necessidades de business intelligence empresarial, alinhadas às orientações do Analytics de ponta a ponta com o Azure Synapse.
Plataforma de dados da Contoso
O fluxo de trabalho é lido da esquerda para a direita, seguindo o fluxo de dados:
- Fontes de dados - As fontes ou tipos de dados que a plataforma de dados pode consumir.
- Ingest - A capacidade da Plataforma de ingerir dados de várias fontes de estrutura e velocidade variáveis. Este design reflete uma arquitetura Lambda.
- Loja - A capacidade de armazenar dados em escala com segurança que foram ingeridos na plataforma.
- Processo - A capacidade da Plataforma de processar dados, tornando-os "adequados à finalidade" para processos a jusante, como limpeza, padronização e modelagem. O pré-processamento de dados normalmente garante que eles estejam em uma "posição e uma condição, prontos para uso".
- Enrich - A capacidade de aprimorar os dados processados na plataforma por meio de estatística, aprendizado de máquina ou outras técnicas de modelagem ou serviços de IA do Azure pré-criados.
- Servir - A capacidade da Plataforma de moldar e apresentar dados para consumo a jusante.
- Consumidores de dados - Os indivíduos, aplicações ou processos a jusante que consomem dados dos vários pontos de contacto de serviço das plataformas.
- Descobrir e governar - As capacidades da Plataforma para controlar os dados que contém e garantir que são indexados, detetáveis/pesquisáveis, bem descritos, com toda a linhagem, e são transparentes para os seus utilizadores finais e processos de consumo.
- Plataforma - A base sobre a qual a plataforma é construída, ou seja, as fundações do Azure da Contoso, conforme descrito acima.
Nota
Para muitos clientes, o nível conceitual da arquitetura de referência da plataforma de dados usada será alinhado, mas a implementação física pode variar. Por exemplo, os processos ELT (extrair, carregar, transformar) podem ser executados por meio do Azure Data Factory e a modelagem de dados pelo SQL Server do Azure. Para resolver essa preocupação, a seção Stateful vs stateless components abaixo fornecerá orientação.
Para a Plataforma de Dados, a Contoso selecionou as camadas de serviço de produção recomendadas mais baixas para todos os componentes e optou por adotar uma estratégia de recuperação de desastres (DR) "Reimplantar em caso de desastre" com base em uma abordagem de minimização de custos operacionais.
As seções a seguir fornecerão uma compreensão básica do processo de DR e das alavancas disponíveis para os clientes melhorarem essa postura.
As tabelas a seguir apresentam um detalhamento de cada serviço e componente do Azure usado na plataforma Contoso – Data, com opções para aprimoramento de DR.
Nota
As seções abaixo são organizadas por serviços stateful vs stateless.
ID do Microsoft Entra, incluindo direitos de função
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: Premium P1
- Opções de aumento de DR: a resiliência do Microsoft Entra faz parte de sua oferta de software como serviço (SaaS).
- Observações
Azure Key Vault
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: N/A
- Opções de atualização de DR: N/A, Coberto como parte do serviço do Azure.
Cofre dos Serviços de Recuperação
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: padrão (armazenamento com redundância geográfica (GRS))
- Opções de elevação de DR: Habilitar a restauração entre regiões cria a restauração de dados na região secundária emparelhada.
- Observações
- Embora o armazenamento com redundância local (LRS) e o armazenamento com redundância de zona (ZRS) estejam disponíveis, ele requer atividades de configuração da configuração padrão.
Azure DevOps
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: Serviços de DevOps
- Opções de aumento de DR: o serviço de DevOps e a resiliência de dados fazem parte de sua oferta de SaaS.
- Observações
- O DevOps Server como oferta local continuará sendo responsabilidade do cliente pela recuperação de desastres.
- Se serviços de terceiros (SonarCloud, Jfrog Artifactory, Jenkins build servers, por exemplo) forem usados, eles continuarão sendo responsabilidade do cliente pela recuperação de um desastre.
- Se as VMs IaaS forem usadas na cadeia de ferramentas de DevOps, elas continuarão sendo responsabilidade do cliente pela recuperação de um desastre.
Subscrições
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: N/A
- Opções de atualização de DR: N/A, Coberto como parte do serviço do Azure.
Grupos de Gestão
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: N/A
- Opções de atualização de DR: N/A, Coberto como parte do serviço do Azure.
Azure Monitor
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: N/A
- Opções de atualização de DR: N/A, Coberto como parte do serviço do Azure.
Cost Management
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: N/A
- Opções de atualização de DR: N/A, Coberto como parte do serviço do Azure.
Microsoft Defender para Cloud
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: N/A
- Opções de atualização de DR: N/A, Coberto como parte do serviço do Azure.
Azure DNS
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: Zona Única - Pública
- Opções de elevação DR: N/A, DNS é altamente disponível por design.
Observador de rede
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: N/A
- Opções de atualização de DR: N/A, Coberto como parte do serviço do Azure.
Redes virtuais, incluindo sub-redes, rota definida pelo usuário (UDR) e grupos de segurança de rede (NSG)
- Responsabilidade pela recuperação de componentes: Contoso
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: N/A
- Opções de aumento de DR: as VNETs podem ser replicadas na região secundária emparelhada.
Azure Firewall
- Responsabilidade pela recuperação de componentes: Contoso
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: padrão
- Opções de atualização de DR: o Firewall do Azure é altamente disponível por design e pode ser criado com Zonas de Disponibilidade para maior disponibilidade.
Azure DDoS
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: Proteção de rede DDoS
- Opções de atualização de DR: N/A, Coberto como parte do serviço do Azure.
Circuito ExpressRoute
- Responsabilidade pela recuperação de componentes: Contoso, parceiro de conectividade e Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: parceiro de conectividade e Microsoft
- Seleção de SKU da Contoso: padrão
- Opções de elevação de DR:
- O ExpressRoute pode ser aprimorado para usar emparelhamento privado, oferecendo um serviço com redundância geográfica.
- O ExpressRoute também tem designs de alta disponibilidade (HA) disponíveis.
- A conexão VPN site a site pode ser usada como backup para a Rota Expressa.
- Observações
- A Rota Expressa tem redundância incorporada, com cada circuito consistindo em duas conexões com dois roteadores de borda Microsoft Enterprise (MSEEs) em um local de Rota Expressa a partir da borda de rede do provedor/cliente de conectividade.
- O circuito premium da Rota Expressa permitirá o acesso a todas as regiões do Azure globalmente.
Gateway de VPN
- Responsabilidade pela recuperação de componentes: Contoso
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: Zona Única - VpnGw1
- Opções de atualização de DR: um gateway VPN pode ser implantado em uma zona de disponibilidade com as SKUs VpnGw#AZ para fornecer um serviço redundante de zona.
Balanceador de Carga do Azure
- Responsabilidade pela recuperação de componentes: Contoso
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: padrão
- Opções de elevação de DR:
- Um balanceador de carga pode ser configurado para redundância de zona dentro de uma região com zonas de disponibilidade. Nesse caso, o caminho de dados sobreviverá enquanto uma zona dentro da região permanecer íntegra.
- Dependendo da região primária, um balanceador de carga entre regiões pode ser implantado para uma implantação altamente disponível e inter-regional.
- Observações
- O Azure Traffic Manager é um balanceador de carga de tráfego baseado em DNS. Este serviço suporta a distribuição de tráfego para aplicações públicas nas regiões globais do Azure. Esta solução fornecerá proteção contra uma interrupção regional dentro de um projeto de alta disponibilidade.
Conta de armazenamento: Azure Data Lake Gen2
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: LRS
- Opções de aumento de DR: as contas de armazenamento têm uma ampla gama de opções de redundância de dados, desde redundância de região primária até redundância de região secundária.
- Observações
- O GRS é recomendado para aumentar a redundância, fornecendo uma cópia dos dados na região emparelhada.
Hubs de Eventos do Azure
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: padrão
- Opções de elevação de DR: um namespace de hub de eventos pode ser criado com zonas de disponibilidade habilitadas. Essa resiliência pode ser estendida para cobrir uma interrupção completa da região com a recuperação de desastres geográficos.
- Observações
- Por design, a recuperação de desastres geográficos dos Hubs de Eventos não replica dados, portanto, há várias considerações a ter em mente para failover e fallback.
Azure IoT Hubs
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: padrão
- Opções de elevação de DR:
- A resiliência do Hub IoT pode ser aumentada por uma implementação de HA inter-regional.
- A Microsoft fornece as seguintes orientações para opções de HA/DR.
- Observações
- O Hub IoT fornece failover iniciado pela Microsoft e failover manual replicando dados para a região emparelhada para cada hub IoT.
- O Hub IoT fornece HA Intrarregião e usará automaticamente uma zona de disponibilidade se criada em um conjunto predefinido de regiões do Azure.
Azure Stream Analytics
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: padrão
- Opções de aumento de DR: embora o Azure Stream Analytics seja uma oferta de plataforma como serviço (PaaS) totalmente gerenciada, ele não fornece failover geográfico automático. A redundância geográfica pode ser alcançada implantando trabalhos idênticos do Stream Analytics em várias regiões do Azure.
Azure Machine Learning
- Responsabilidade pela recuperação de componentes: Contoso e Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: Uso Geral, instâncias da Série D
- Opções de elevação de DR:
- O Azure Machine Learning depende de vários serviços do Azure, alguns dos quais são provisionados na assinatura do cliente. Como tal, o cliente continua a ser responsável pela configuração de alta disponibilidade destes serviços.
- A resiliência pode ser aumentada por meio de uma implantação multirregional.
- Observações:
- O Aprendizado de Máquina do Azure em si não fornece failover automático ou recuperação de desastre.
Power BI
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: Power BI Pro
- Opções de aumento de DR: N/A, a resiliência do Power BI faz parte de sua oferta de SaaS.
- Observações
- O Power BI reside na locação do Office365, não na do Azure.
- O Power BI usa as Zonas de Disponibilidade do Azure para proteger relatórios, aplicativos e dados do Power BI contra falhas no datacenter.
- No caso de falha regional, o Power BI fará failover para uma nova região, geralmente no mesmo local geográfico, conforme observado na Central de Confiabilidade da Microsoft.
BD do Cosmos para o Azure
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: Gravação de região única com backup periódico
- Opções de elevação de DR:
- As contas de uma única região podem perder disponibilidade após uma interrupção regional. A resiliência pode ser aumentada para uma única região de gravação e pelo menos uma segunda região (de leitura) e habilitar o failover gerenciado pelo serviço.
- É recomendável que as contas do Azure Cosmos DB usadas para cargas de trabalho de produção habilitem o failover automático. Na ausência dessa configuração, a conta sofrerá perda de disponibilidade de gravação durante toda a duração da interrupção da região de gravação, pois o failover manual não terá êxito devido à falta de conectividade da região.
- Observações
- Para proteger contra perda de dados em uma região, o Azure Cosmos DB fornece dois modos - de backup diferentes: Periódico e Contínuo.
- Os failovers regionais são detetados e tratados no cliente do Azure Cosmos DB. Eles não exigem nenhuma alteração do aplicativo.
- As diretrizes a seguir descrevem o impacto de uma interrupção de região com base na configuração do Cosmos DB.
Compartilhamento de Dados do Azure
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: N/A
- Opções de elevação de DR: a resiliência do Compartilhamento de Dados do Azure pode ser aumentada pela implantação de HA em uma região secundária.
Microsoft Purview
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: N/A
- Opções de elevação DR: N/A
- Observações
- Desde outubro de 2024, o Microsoft Purview não oferece suporte à continuidade de negócios automatizada e recuperação de desastres (BCDR). Até que o suporte seja adicionado, o cliente é responsável por todas as atividades de backup e restauração.
Sinapse do Azure: Pipelines
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: Gen2 otimizada computada
- Opções de elevação de DR: N/A, a resiliência Synapse faz parte de sua oferta de SaaS usando o recurso de failover automático.
- Observações
- Se forem usados Pipelines de Dados Auto-Hospedados, eles continuarão sendo responsabilidade do cliente pela recuperação de um desastre.
Azure Synapse: Data Explorer Pools
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: Otimizado Computado, Pequeno (4 núcleos)
- Opções de elevação de DR: N/A, a resiliência Synapse faz parte de sua oferta de SaaS.
- Observações
- As zonas de disponibilidade são habilitadas por padrão para o Synapse Data Explorer , quando disponível.
Azure Synapse: Spark Pools
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: Otimizado Computado, Pequeno (4 núcleos)
- Opções de elevação de DR: N/A, a resiliência Synapse faz parte de sua oferta de SaaS.
- Observações
- Atualmente, o Azure Synapse Analytics só dá suporte à recuperação de desastres para pools SQL dedicados e não oferece suporte para pools do Apache Spark.
Azure Synapse: Pools SQL dedicados e sem servidor
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Contoso
- Seleção de SKU da Contoso: Gen2 otimizada computada
- Opções de elevação de DR: N/A, a resiliência Synapse faz parte de sua oferta de SaaS.
- Observações
- O Azure Synapse Analytics tira instantâneos automaticamente ao longo do dia para criar pontos de restauração que ficam disponíveis por sete dias.
- O Azure Synapse Analytics executa um backup geográfico padrão uma vez por dia em um datacenter emparelhado. O objetivo de ponto de recuperação (RPO) para um restauro geográfico é de 24 horas.
- Se forem usados Pipelines de Dados Auto-Hospedados, eles continuarão sendo a responsabilidade do cliente na recuperação de um desastre.
Serviços de IA do Azure (anteriormente Serviços Cognitivos)
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: pague conforme o uso
- Opções de atualização de DR: N/A, as APIs para serviços de IA são hospedadas por data centers gerenciados pela Microsoft.
- Observações
- Se os serviços de IA tiverem sido implantados por meio de contêineres Docker implantados pelo cliente, a recuperação continuará sendo responsabilidade do cliente.
Azure AI Search (anteriormente Pesquisa Cognitiva)
- Responsabilidade pela recuperação de componentes: Microsoft
- Responsabilidade pela recuperação da carga de trabalho/configuração: Microsoft
- Seleção de SKU da Contoso: Standard S1
- Opções de elevação de DR:
- A Pesquisa de IA pode ser elevada a um design de HA usando réplicas em zonas de disponibilidade e regiões.
- Vários serviços em regiões separadas podem ampliar ainda mais a resiliência.
- Observações
- No AI Search, a continuidade de negócios (e a recuperação de desastres) é alcançada por meio de vários serviços de AI Search.
- Não há nenhum mecanismo integrado para recuperação de desastres. Se o serviço contínuo for necessário durante uma falha catastrófica, a recomendação é ter um segundo serviço em uma região diferente e implementar uma estratégia de replicação geográfica para garantir que os índices sejam totalmente redundantes em todos os serviços.
A velocidade da inovação no pacote de produtos da Microsoft e no Azure, em particular, significa que o conjunto de componentes que usamos para este exemplo trabalhado evoluirá rapidamente. Para evitar o fornecimento de orientações obsoletas e estender essa orientação a componentes não explicitamente cobertos neste documento, a seção abaixo fornece algumas instruções com base na classificação de estado de grão grosso.
Um componente/serviço pode ser descrito como stateful se for projetado para lembrar eventos anteriores ou interações do usuário. Apátrida significa que não há registro de interações anteriores, e cada solicitação de interação deve ser tratada com base inteiramente nas informações que vêm com ela.
Para um cenário de DR que exige reimplantação:
- Os componentes/serviços que são "sem monitoração de estado", como o Azure Functions e os pipelines do Azure Data Factory, podem ser reimplantados a partir do controle do código-fonte com pelo menos um teste de fumaça para validar a disponibilidade antes de serem introduzidos no sistema mais amplo.
- Componentes/serviços que são "stateful", como o Banco de Dados SQL do Azure e contas de armazenamento, exigem mais atenção.
- Ao adquirir o componente, uma decisão importante será selecionar o recurso de redundância de dados. Essa decisão normalmente se concentra em um compromisso entre disponibilidade e durabilidade com custos operacionais.
- Os armazenamentos de dados também precisarão de uma estratégia de backup de dados. A funcionalidade de redundância de dados do armazenamento subjacente reduz esse risco para alguns projetos, enquanto outros, como bancos de dados SQL, precisarão de um processo de backup separado.
- Se necessário, o componente pode ser reimplantado a partir do controle do código-fonte com uma configuração validada por meio de um teste de fumaça.
- Um armazenamento de dados reimplantado deve ter seu conjunto de dados reidratado. A reidratação pode ser realizada por meio de redundância de dados (quando disponível) ou de um conjunto de dados de backup. Quando a reidratação tiver sido concluída, deve ser validada quanto à sua exatidão e completude.
- Dependendo da natureza do processo de backup, os conjuntos de dados de backup podem exigir validação antes de serem aplicados. Corrupção ou erros do processo de backup podem resultar em um backup anterior sendo usado no lugar da versão mais recente disponível.
- Qualquer delta entre o carimbo de data/hora do componente e a data atual deve ser resolvido executando ou reproduzindo os processos de ingestão de dados a partir desse ponto.
- Uma vez que o conjunto de dados do componente esteja atualizado, ele pode ser introduzido no sistema mais amplo.
Esta seção contém diretrizes de alta disponibilidade (HA) e DR para outros componentes e serviços de dados importantes do Azure.
- Azure Databricks - DR guidance pode ser encontrado na documentação do produto.
- As diretrizes do Azure Analysis Services - HA podem ser encontradas na documentação do produto.
- Base de Dados do Azure para MySQL
- SQL
Agora que você aprendeu sobre a arquitetura do cenário, você pode aprender sobre os detalhes do cenário.