Confiabilidade no Azure Data Explorer

Azure Data Explorer é um serviço de análise para ingestão, armazenamento e consulta de grandes volumes de dados com baixa latência. Normalmente, ele é usado para cargas de trabalho de log analytics, telemetria e série temporal que exigem consultas rápidas em conjuntos de dados grandes.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Azure Data Explorer resiliente a várias possíveis interrupções e problemas, incluindo falhas transitórias, falhas na zona de disponibilidade e falhas em toda a região. Ele também descreve as opções de backup e restauração e resiliência à manutenção do serviço e destaca as principais informações sobre o SLA (contrato de nível de serviço) do Azure Data Explorer.

Recomendações de implantação de produção para confiabilidade

Para cargas de trabalho de produção, recomendamos que você execute as seguintes etapas para melhorar a confiabilidade do cluster do Azure Data Explorer:

  • Implantar um cluster completo. O Azure Data Explorer fornece clusters gratuitos para fins de avaliação. Para cargas de trabalho de produção, implante um cluster completo.

  • Habilite o suporte à zona de disponibilidade. O Azure Data Explorer dá suporte a zonas de disponibilidade. Quando você habilita o suporte à zona de disponibilidade, o serviço distribui nós de computação em várias zonas de disponibilidade e armazena dados usando ZRS (armazenamento com redundância de zona). Essa configuração melhora a resiliência a falhas de zona de disponibilidade.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

O principal recurso que você implanta é um cluster, que representa a infraestrutura necessária para ingerir, armazenar e consultar seus dados. Com um cluster, você cria bancos de dados e esses bancos de dados contêm tabelas.

Diagrama de um cluster que contém dois bancos de dados, cada um com um conjunto de tabelas.

Os clusters executam a ingestão para recuperar dados de outras fontes de dados e carregá-los em uma tabela no cluster. Em seguida, você pode consultar dados usando a sintaxe KQL (Kusto Query Language). Os clusters também têm um conjunto de operações de gerenciamento que você pode executar.

Arquitetura física

Um cluster do Azure Data Explorer tem duas camadas primárias aplicáveis à sua configuração de confiabilidade:

  • Camada de computação: o Azure Data Explorer é uma plataforma de computação distribuída e pode ter de dois a muitos nós de máquina virtual (VMs), dependendo da escala e do tipo de função do nó. Os nós lidam com o trabalho de processamento de consultas e ingestão de dados. Você não vê nem gerencia diretamente as VMs do nó. A plataforma gerencia automaticamente a criação de instâncias, o monitoramento da integridade e a substituição de nós com problemas. Quando você configura seu cluster para usar várias zonas de disponibilidade, os nós são distribuídos entre datacenters diferentes.

  • Camada de armazenamento: O Azure Data Explorer usa o Armazenamento do Azure como sua camada de persistência durável. O armazenamento fornece automaticamente tolerância a falhas, com a configuração padrão oferecendo LRS (armazenamento com redundância local) em um datacenter. Três réplicas são mantidas de forma persistente. Se uma réplica for perdida durante o uso, outra será implantada sem interrupção. Quando você configura seu cluster para usar várias zonas de disponibilidade, as réplicas são distribuídas entre datacenters diferentes.

Diagrama que mostra um cluster Azure Data Explorer com uma arquitetura lógica de duas camadas.

Para obter mais informações, consulte como o Azure Data Explorer funciona.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Para criar resiliência a falhas transitórias ao usar o Azure Data Explorer, siga estas práticas:

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

O Azure Data Explorer dá suporte a dois tipos de configuração de zona de disponibilidade:

  • Com redundância de zona (recomendado): Quando você habilita zonas de disponibilidade em seu cluster, os nós do cluster são distribuídos por várias zonas. A Microsoft gerencia a distribuição de nós entre as zonas de disponibilidade selecionadas e lida com a detecção e a resposta a falhas na zona de disponibilidade. Um cluster com redundância de zona é resiliente a uma interrupção de zona de disponibilidade.

    Quando você configura seu cluster para ser com redundância de zona, o Armazenamento ZRS replica de forma síncrona pelo menos três cópias de seus dados em várias zonas de disponibilidade.

    Diagrama de um cluster Azure Data Explorer, com nós de computação e armazenamento espalhados por várias zonas.

  • Zonal: Opcionalmente, você pode selecionar uma única zona ao habilitar zonas de disponibilidade em seu cluster. Microsoft coloca todos os nós de computação nessa zona. Essa configuração é um cluster zonal (zona única). Um cluster zonal pode reduzir a latência para cargas de trabalho extraordinariamente sensíveis à latência porque todos os nós de computação são executados na mesma zona, mas não fornece resiliência a interrupções de zona.

    Importante

    A anexação a uma única zona de disponibilidade só é recomendada quando a latência entre zonas é muito alta para suas necessidades e depois de verificar se a latência não atende aos seus requisitos. Por si só, um recurso zonal não fornece resiliência a uma interrupção de zona de disponibilidade. Para melhorar a resiliência de um recurso zonal, você precisa implantar explicitamente recursos separados em várias zonas de disponibilidade e configurar o roteamento e o failover de tráfego. Para obter mais informações, consulte recursos zonais e resiliência de zona.

    Sua seleção de zona só se aplica aos nós de computação. Para um cluster zonal, os dados de armazenamento continuam a usar o LRS e podem ser armazenados em uma zona diferente dos nós de computação.

    Diagrama que mostra um cluster Azure Data Explorer que usa uma única zona de disponibilidade.

Se você não habilitar zonas de disponibilidade, o cluster será nonzonal, o que significa que o Azure seleciona a zona de disponibilidade para cada nó e seus dados. Se qualquer zona de disponibilidade na região tiver uma interrupção, poderá afetar os nós, os dados ou ambos do cluster. Não recomendamos uma configuração nonzonal porque ela não fornece proteção contra interrupções de zona de disponibilidade.

Requisitos

  • Suporte à região: O suporte à zona de disponibilidade está disponível em regiões do Azure que dão suporte a zonas de disponibilidade.

    No entanto, alguns tipos e tamanhos de nó de computação só estão disponíveis em regiões específicas ou zonas específicas dentro de uma região.

  • Clusters completos: O suporte à zona de disponibilidade está disponível com clusters completos. Ele não está disponível com clusters gratuitos.

Considerações

Seleção de zona: Para nós de computação, você escolhe quais zonas de disponibilidade usar. Microsoft gerencia o posicionamento da zona de armazenamento e as réplicas de armazenamento podem estar em zonas diferentes dos nós de computação.

Custo

Habilitar o suporte à zona de disponibilidade gera custos extras para o ZRS, que é cobrado a uma taxa mais alta do que o LRS. Para obter mais informações, consulte os preços do Armazenamento do Azure.

Nós de computação são cobrados na mesma taxa, independentemente de você usar ou não o suporte à zona de disponibilidade. Para obter mais informações, leia Preços do Azure Data Explorer.

Configurar o suporte à zona de disponibilidade

  • Crie um novo cluster com suporte à zona de disponibilidade. Você pode habilitar o suporte à zona de disponibilidade ao criar um novo cluster Azure Data Explorer. Para obter mais informações, consulte Criar um cluster e um banco de dados.

    Quando você cria um cluster com suporte a zonas de disponibilidade ao usar o portal do Azure, ele tem redundância de zona automaticamente, e a Microsoft seleciona as zonas.

    Para selecionar zonas por conta própria ou para criar um cluster zonal, use outra abordagem de implantação, como APIs do Azure Resource Manager ou Bicep. Para a maioria das situações, crie um cluster com redundância de zona e use todas as zonas na região.

    Observação

    Quando você seleciona quais zonas de disponibilidade usar, na verdade está selecionando a zona de disponibilidade lógica. Se você implantar outros componentes de carga de trabalho em uma assinatura de Azure diferente, eles poderão usar um número de zona de disponibilidade lógica diferente para acessar a mesma zona de disponibilidade física. Para obter mais informações, confira Zonas de disponibilidade físicas e lógicas.

  • Habilitar zonas de disponibilidade em um cluster existente (versão prévia). Você pode migrar um cluster nonzonal existente para usar zonas de disponibilidade. Esta capacidade está em pré-visualização. Para obter mais informações, consulte Migrar seu cluster para dar suporte a várias zonas de disponibilidade.

  • Reconfigure zonas de disponibilidade em um cluster existente (versão prévia). Você pode alterar as zonas usadas para um cluster. Esta capacidade está em pré-visualização. Para obter mais informações, consulte Migrar seu cluster para dar suporte a várias zonas de disponibilidade.

  • Desabilite o suporte à zona de disponibilidade em um cluster existente. Depois que um cluster é configurado com zonas de disponibilidade, você não pode alterar o cluster para não usar zonas de disponibilidade.

  • Verifique a configuração da zona de disponibilidade para clusters. Use a propriedade de status da zona do cluster (a propriedade zoneStatus da API REST) para verificar a configuração da zona de disponibilidade de um cluster. Um valor de Zonal indica que o cluster usa zonas de disponibilidade, mas isso não significa que o cluster esteja em execução em uma única zona.

    Para determinar se um cluster é zonal ou redundante entre zonas, use a propriedade zones. Se a lista de zonas tiver uma zona listada, o cluster será zonal (zona única). Se ele tiver várias zonas listadas, tem redundância de zona.

Planejamento e gerenciamento de capacidade

Quando uma zona de disponibilidade não está disponível, todos os nós nessa zona podem ficar temporariamente indisponíveis, o que reduz a capacidade de computação do cluster até que a zona se recupere.

Se o cluster não puder tolerar a perda de capacidade, considere o excesso de provisionamento do cluster. Essa abordagem permite que a solução tolere alguma perda de capacidade e continue a funcionar sem desempenho degradado. No entanto, quando você superprovisiona seu cluster, seu cluster pode ter um número desequilibrado de nós distribuídos entre as zonas.

Distribuição de instâncias entre zonas

A camada de computação do cluster usa uma abordagem de melhor esforço para distribuir instâncias uniformemente entre as zonas selecionadas.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando você configura um cluster para suporte à zona de disponibilidade e todas as zonas estão operacionais.

  • Operação entre zonas: Durante a operação normal, o Azure Data Explorer usa todos os nós de computação disponíveis para ingestão, processamento de consultas e outras operações. O trabalho é distribuído entre nós de rede, independentemente das suas zonas de disponibilidade.

  • Replicação de dados entre zonas: O comportamento de replicação de dados entre zonas depende da configuração da zona de disponibilidade usada pelo cluster.

    • Com redundância de zona: Os dados são replicados de forma síncrona entre zonas de disponibilidade usando o Armazenamento ZRS, que fornece um alto nível de consistência de dados e minimiza o risco de perda de dados durante uma falha de zona.

    • Zonal: Os dados são armazenados com o Armazenamento com Redundância Local (LRS), o que significa que as três cópias podem estar em uma única zona de disponibilidade.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando você configura um cluster para suporte à zona de disponibilidade e há uma interrupção em uma das zonas.

  • Detecção e resposta: A responsabilidade pela detecção e resposta depende da configuração da zona de disponibilidade usada pelo cluster.

    • Zona com redundância: A Microsoft detecta falhas nas zonas de disponibilidade e gerencia a resposta para o Azure Data Explorer. Você não precisa fazer nada para iniciar um failover de zona.

    • Zonal: Você é responsável por detectar falhas nas zonas de disponibilidade que seu cluster usa. Você também é responsável pelas ações que você decidir iniciar, como alternar para um segundo cluster que você criou anteriormente em uma zona de disponibilidade diferente.

  • Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. No entanto, você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Service Health para notificar você sobre problemas.

  • Solicitações ativas: Solicitações ativas que dependem de recursos de computação ou armazenamento na zona com falha podem ser encerradas e devem ser repetidas pelo cliente. Verifique se os aplicativos estão preparados seguindo as diretrizes de tratamento de falhas transitórias.

  • Perda de dados esperada: A perda de dados esperada depende da configuração da zona de disponibilidade usada pelo cluster.

    • Com redundância de zona: Nenhuma perda de dados é esperada durante uma interrupção de zona de disponibilidade porque os dados são replicados de forma síncrona entre zonas.

    • Zonal: Os dados não estão disponíveis até que a zona se recupere. Em caso improvável de uma perda permanente de uma zona que contém todas as suas réplicas de armazenamento, os dados podem ser perdidos de forma permanente.

  • Tempo de inatividade esperado: O tempo de inatividade esperado depende da configuração da zona de disponibilidade usada pelo cluster.

    • Com redundância de zona: Uma breve interrupção de serviço pode ocorrer enquanto o tráfego é direcionado para zonas de disponibilidade saudáveis. Verifique se os aplicativos estão preparados seguindo as diretrizes de tratamento de falhas transitórias.

    • Zonal: Os nós de computação do cluster não estão disponíveis até que a zona de disponibilidade se recupere. Você também pode não conseguir acessar os dados do cluster durante uma falha de zona.

  • Redistribuição: O comportamento de redirecionamento de tráfego depende da configuração da zona de disponibilidade usada pelo cluster.

    • Com redundância de zona: O Azure Data Explorer roteia novas solicitações para recursos de computação e armazenamento nas zonas saudáveis restantes.

    • Zonal: Seu cluster fica indisponível até que a zona de disponibilidade se recupere.

Recuperação de zona

Quando a zona de disponibilidade com falha é recuperada, a Microsoft recria os nós de cluster e as réplicas de armazenamento nessa zona e restaura a distribuição de tráfego normal em todas as zonas. Você não precisa tomar nenhuma ação.

Testar falhas em zonas

As opções de teste para falhas de zona dependem da configuração da zona de disponibilidade usada pelo cluster.

  • Zone-redundante: Microsoft gerencia totalmente o failover e a recuperação da zona de disponibilidade para Azure Data Explorer. Você não precisa iniciar nem validar processos de falha de zona de disponibilidade.

  • Zonal: Para simular parcialmente a perda de todos os nós de computação durante uma interrupção de zona, você pode parar o cluster. Use esta abordagem para validar partes dos seus próprios processos de detecção de indisponibilidade de zona e failover.

Resiliência a falhas em toda a região

Um cluster do Azure Data Explorer é implantado em uma única região do Azure. Se essa região ficar indisponível, o cluster e seus dados não estarão disponíveis.

Soluções de várias regiões personalizadas para resiliência

Para minimizar o impacto nos negócios de uma interrupção de região, implante clusters Azure Data Explorer separados em várias regiões. Cada cluster é independente. Você é responsável pelo gerenciamento de cada cluster e pela coordenação de replicação de dados, roteamento de tráfego e failover entre regiões.

Você pode decidir entre diferentes tipos de configurações de cluster de várias regiões, que dão suporte a diferentes níveis de tempo de recuperação, potencial perda de dados, esforço e custo. Selecione as regiões do Azure para cada cluster que atendam aos seus requisitos de latência e de residência de dados. Para obter mais informações sobre configurações e padrões de cluster de várias regiões que você pode seguir, confira a visão geral da continuidade dos negócios e da recuperação de desastres.

Backup e restauração

Para a maioria das soluções, você não deve depender exclusivamente de backups. Em vez disso, use as outras funcionalidades descritas neste guia para dar suporte aos seus requisitos de resiliência. No entanto, os backups protegem contra alguns riscos que outras abordagens não protegem. Para obter mais informações, consulte O que são redundância, replicação e backup?.

O Azure Data Explorer não fornece uma funcionalidade nativa de backup e restauração. Se você precisar fazer backup de seus dados, considere as seguintes abordagens:

  • Exportação contínua exporta periodicamente dados para armazenamento externo e oferece exportação exatamente uma vez para tipos de dados compatíveis.

  • A exportação de dados para o armazenamento em nuvem dá suporte à exportação manual de dados para o armazenamento externo.

  • Ingestão de dados não processados no Azure Data Explorer a partir de uma fonte upstream, como um data lake, que você pode fazer backup separadamente.

Resiliência à exclusão acidental

O Azure Data Explorer inclui vários mecanismos para ajudá-lo a proteger contra exclusão acidental de clusters, bancos de dados, tabelas e tabelas externas:

  • Exclusão acidental de cluster ou banco de dados: A exclusão acidental do cluster ou do banco de dados é uma ação irrecuperável. Evite a perda de dados habilitando um bloqueio de exclusão no recurso de cluster ou banco de dados.

  • Exclusão acidental da tabela: Os usuários que têm permissões de administrador de tabelas ou superiores têm permissão para descartar tabelas. Se um desses usuários excluir acidentalmente uma tabela, você poderá recuperá-la usando o comando undo drop table. Para que esse comando seja bem-sucedido, primeiro você deve habilitar a propriedade de recuperação na política de retenção.

  • Exclusão acidental de tabela externa:tabelas externas são entidades de esquema de consulta Kusto que fazem referência a dados armazenados fora do banco de dados. A exclusão de uma tabela externa exclui apenas os metadados da tabela. Você pode recuperá-lo executando o comando de criação de tabela novamente.

    Para o Armazenamento de Blobs do Azure e tabelas externas do Azure Data Lake, use a funcionalidade de exclusão reversível (soft delete) para proteger contra a exclusão ou substituição acidental de um blob por um período de tempo configurado pelo usuário.

Resiliência à manutenção do serviço

O Azure Data Explorer aplica regularmente atualizações de serviço e executa a manutenção de rotina. A plataforma do Azure manipula essas atividades automaticamente enquanto permanece dentro dos níveis de disponibilidade especificados no SLA. Verifique se seus aplicativos estão preparados para perda ocasional de conectividade durante a manutenção do serviço seguindo as diretrizes transitórias de tratamento de falhas.

Para saber mais sobre a manutenção planejada futura, use Integridade do Serviço do Azure.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Para ser qualificado para o SLA de disponibilidade do Azure Data Explorer, seu aplicativo precisa lidar com falhas transitórias repetindo solicitações com falha.

Conteúdo relacionado

  • Last updated on