Partilhar via

Fiabilidade no Azure Databricks

O Azure Databricks é uma plataforma colaborativa baseada em dados e IA baseada no Apache Spark, otimizada para o Microsoft Azure. Proporciona um ambiente unificado para cargas de trabalho de big data e IA e combina o melhor do Databricks e do Azure para simplificar a engenharia de dados, ciência de dados e aprendizagem automática.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para oferecer 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 o Azure Databricks mantém a resiliência face a várias potenciais falhas e problemas e como pode configurar a resiliência para satisfazer os seus requisitos. A orientação abrange falhas transitórias, interrupções em zonas de disponibilidade, interrupções regionais e manutenção de serviços. Este artigo também descreve como usar backups para recuperar de outros problemas e destaca informações chave sobre o acordo de nível de serviço (SLA) do Azure Databricks.

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

Para saber como implementar o Azure Databricks para suportar os requisitos de fiabilidade da sua solução e como a fiabilidade afeta outros aspetos da sua arquitetura, consulte as melhores práticas de arquitetura para Azure Databricks.

Visão geral da arquitetura de confiabilidade

Deve compreender a fiabilidade de cada componente principal no Azure Databricks:

  • O plano de controlo é um conjunto de serviços sem estado que gere metadados do espaço de trabalho, acesso do utilizador, agendamento de tarefas e gestão de clusters. Estes serviços são suportados por bases de dados replicadas entre zonas de disponibilidade em regiões suportadas.

  • A raiz do Databricks File System (DBFS ) é uma conta de armazenamento que o Azure Databricks provisiona automaticamente quando cria um espaço de trabalho Azure Databricks na sua conta cloud. Recomendamos que não armazene dados na root do DBFS e que desative esta conta de armazenamento, se possível.

  • O armazenamento do Catálogo Unity inclui uma ou mais contas de armazenamento que armazenam os seus dados do Catálogo Unity na sua conta cloud. Para mais informações, consulte a visão geral do Catálogo Unity.

  • O plano de cálculo executa cargas de processamento de dados utilizando clusters de máquinas virtuais (VMs). O plano de computação trata falhas transitórias e substitui automaticamente nós falhados sem intervenção do utilizador. Pode escolher entre vários tipos de recursos computacionais. Para mais informações, veja Computar.

    A disponibilidade do espaço de trabalho depende da disponibilidade do plano de controlo, mas os clusters de computação podem continuar a processar trabalhos mesmo durante interrupções no plano de controlo.

Resiliência a falhas transitórias

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

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

Pode controlar reintegrações de tarefas dentro dos trabalhos do Lakeflow para ajudar a recuperar de erros transitórios.

Para aplicações que se executam no Azure Databricks, implemente lógica de retentativa com retração exponencial ao conectar-se a serviços externos ou serviços Azure, como Storage, Azure SQL Database ou Azure Event Hubs. O Databricks Runtime inclui resiliência incorporada para muitos serviços Azure, mas o código da sua aplicação deve lidar com falhas transitórias específicas de cada serviço.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

O Azure Databricks suporta redundância de zonas para cada componente:

  • Plano de controlo: Nas regiões que suportam zonas de disponibilidade, o plano de controlo circula em múltiplas zonas de disponibilidade. O plano de controlo trata automaticamente as falhas de zona, com impacto mínimo e sem necessidade de intervenção do utilizador.

    Os dados do espaço de trabalho do plano de controlo são armazenados em bases de dados. Nas regiões que suportam zonas de disponibilidade, as bases de dados são replicadas por várias zonas da região. As contas de armazenamento que armazenam imagens do Databricks Runtime também são redundantes dentro da região. Todas as regiões têm contas de armazenamento secundárias que são usadas quando a conta principal está fora de serviço.

  • Raiz DBFS: Em regiões que suportam zonas de disponibilidade, pode configurar a conta de armazenamento da raiz do DBFS para usar armazenamento redundante por zona (ZRS). Em regiões emparelhadas que suportam zonas de disponibilidade, pode opcionalmente usar armazenamento redundante de zonas geográficas (GZRS).

  • Plano de computação: O Databricks suporta distribuição automática de zonas para recursos de computação, o que significa que os seus recursos estão distribuídos por múltiplas zonas de disponibilidade. Esta distribuição ajuda as suas cargas de trabalho de produção a alcançar resiliência face a interrupções em zonas.

    Quando usas computação serverless, não selecionas explicitamente zonas para o teu cálculo. O Databricks gere a seleção de zonas das VMs e a substituição das VMs que possam ser perdidas devido a falhas de zona.

Requerimentos

Para utilizar o suporte de zonas de disponibilidade no Azure Databricks, precisa dos seguintes requisitos:

  • Apoio regional: O suporte para zonas de disponibilidade do Azure Databricks está disponível em todas as regiões Azure que suportam o Azure Databricks e fornecem zonas de disponibilidade. Para uma lista de regiões que suportam Azure Databricks, consulte Produtos disponíveis por região. Para uma lista completa de regiões que suportam zonas de disponibilidade, consulte regiões Azure que suportam zonas de disponibilidade.

  • Replicação de armazenamento: Configure contas de armazenamento de espaço de trabalho para usar ZRS ou GZRS (quando disponível).

  • Capacidade de computação: Assegure que existe capacidade de computação suficiente em várias zonas da sua região-alvo. O Azure Databricks distribui automaticamente os nós do cluster entre zonas, mas deve verificar se os tipos de instância selecionados estão disponíveis em todas as zonas de destino.

Considerações

O Azure Databricks distribui automaticamente os nós do cluster entre zonas de disponibilidade. A distribuição depende da capacidade disponível em cada zona. Durante períodos de alta procura, os nós de um cluster podem estar concentrados em menos zonas. Quando se usa computação serverless, o Azure Databricks gere a seleção de VMs por zonas e a substituição de VMs que possam ser perdidas devido a falhas de zona.

Custo

A distribuição por zonas não afeta os custos de computação porque pagas pelo mesmo número de VMs independentemente da sua disponibilidade na zona. Para mais informações, consulte preços de cálculo do Azure Databricks.

A redundância padrão para a conta de armazenamento gerido, ou raiz DBFS, é o armazenamento geo-redundante (GRS). Mudar para ZRS ou GZRS pode afetar os custos de armazenamento. Para obter mais informações, consulte Preços do Armazenamento de Blob do Azure.

Configurar o suporte à zona de disponibilidade

  • Plano de controlo: O plano de controlo suporta automaticamente redundância de zonas em regiões que têm zonas de disponibilidade. Não precisas de configurar nada.

  • Raiz DBFS: Pode configurar redundância de zonas para armazenamento da raiz DBFS ao criar um novo espaço de trabalho ou ao modificar um já existente.

    • Criar novo espaço de trabalho com armazenamento DBFS Root redundante por zona: Quando crias um novo espaço de trabalho Azure Databricks, podes opcionalmente configurar a conta de armazenamento associada para usar ZRS ou GZRS em vez do GRS predefinido. Para mais informações, consulte Alterar opções de redundância de armazenamento de espaço de trabalho.

    • Ativar redundância de zona no armazenamento raiz do DBFS: Para espaços de trabalho existentes, pode alterar a configuração de redundância da conta de armazenamento do espaço de trabalho para ZRS ou GZRS. Para mais informações sobre como ativar a redundância de zonas, consulte Alterar definições de replicação para uma conta de armazenamento.

  • Plano de computação: Os nós do cluster são distribuídos automaticamente entre as zonas de disponibilidade. Não é necessária configuração do cliente para a distribuição de zonas.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando um espaço de trabalho está configurado com suporte a zonas de disponibilidade e todas as zonas de disponibilidade estão operacionais.

  • Replicação de dados entre zonas: A replicação de dados para armazenamento em espaços de trabalho ocorre de forma síncrona entre zonas quando a raiz do DBFS utiliza uma conta ZRS ou GZRS. Esta abordagem assegura uma forte consistência com impacto mínimo no desempenho.

  • Encaminhamento do tráfego entre zonas: O Azure Databricks distribui automaticamente os nós do cluster entre zonas durante a criação do cluster. O serviço equilibra a carga de cálculo entre zonas enquanto mantém a localidade dos dados para um desempenho ótimo.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando um espaço de trabalho está configurado com suporte a zonas de disponibilidade e há uma falha na zona de disponibilidade.

  • Deteção e resposta: A Microsoft deteta automaticamente falhas de zona e inicia procedimentos de resposta. Não precisas tomar nenhuma ação para um failover ao nível da zona.

  • Notificação: A Microsoft não o notifica automaticamente quando uma zona está inativa. Mas pode usar a página de estado do Azure Databricks para ver uma visão geral de todos os serviços principais do Azure Databricks. Também pode subscrever atualizações de estado em componentes individuais do serviço e receber um alerta quando o estado do serviço a que subscreve muda.

  • Pedidos ativos: Clusters em execução podem perder nós na zona afetada. O gestor do cluster solicita automaticamente nós de substituição das zonas restantes. Se o nó do driver for perdido, o cluster e a tarefa reiniciam completamente.

  • Perda de dados esperada:

    • Plano de controlo: Não espere perda de dados durante uma interrupção de zona.

    • Raiz DBFS: Os dados do espaço de trabalho permanecem disponíveis se usarem configurações de armazenamento ZRS ou GZRS.

    • Plano de computação: Os dados armazenados em cache nas VMs são efémeros. Qualquer dado perdido das VMs durante uma falha de zona é recuperado do armazenamento. Se o nó do driver for perdido, o trabalho reinicia e recalcula os resultados.

  • Tempo de inatividade esperado:

    • Plano de controlo: O plano de controlo do Databricks realiza automaticamente a mudança para zonas saudáveis em cerca de 15 minutos.

    • Raiz DBFS: Não há previsão de interrupção para contas de armazenamento que usem ZRS ou GZRS.

    • Plano de computação: Se os nós forem perdidos porque as suas VMs residem na zona de disponibilidade afetada, o gestor do cluster Azure solicita nós de substituição ao fornecedor de computação Azure. Se as zonas saudáveis restantes tiverem capacidade suficiente para satisfazer o pedido, o fornecedor de computação retira nós das zonas saudáveis para substituir os nós perdidos. Este processo pode demorar vários minutos.

      Se o nó driver for perdido devido à falha da zona, todo o cluster reinicia, o que pode causar tempos de recuperação mais longos em comparação com a perda de nós de trabalho. Planeie este comportamento nas suas estratégias de agendamento e monitorização do trabalho.

      Podes usar serverless ou conjuntos de instâncias para reduzir este tempo.

  • Redirecionamento de tráfego:

    • Plano de controlo: O plano de controlo do Databricks realiza um failover automático para zonas saudáveis em cerca de 15 minutos.

    • Raiz DBFS: O Azure Storage redireciona automaticamente os pedidos para clusters de armazenamento em zonas saudáveis.

    • Plano de computação: O gestor de clusters comuta automaticamente para nós em zonas saudáveis.

Recuperação de zona

Quando a zona de disponibilidade falhada recupera, o Azure Databricks retoma automaticamente as operações normais em todas as zonas. O gestor de cluster pode reequilibrar a distribuição dos nós durante as criações subsequentes de nós, mas os nós existentes continuam a funcionar nas suas zonas atuais até serem terminados.

Não precisa de tomar qualquer ação para operações de failback. A distribuição normal das zonas recomeça para novas implementações de clusters.

Teste de falhas de zona

O Azure Databricks é um serviço gerido onde a Microsoft gere o failover de zona automaticamente e realiza testes regulares de zona reduzida. Não precisas de testar cenários de falha de zona para o serviço em si.

Para as suas aplicações que correm em Azure Databricks, teste a resiliência do trabalho simulando falhas de nós de driver e monitorizando o comportamento de reinício do cluster. Valide que os seus trabalhos de processamento de dados são capazes de lidar com reinícios de clusters e retomar a partir dos checkpoints apropriados.

Resiliência a falhas em toda a região

O Azure Databricks é um serviço de região única. Se a região não estiver disponível, o seu espaço de trabalho também está indisponível. Se precisar de implementações multi-região, consulte o Azure Databricks para recuperação de desastres.

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

O Azure Databricks não oferece capacidades multi-região integradas. Para proteção abrangente de cargas de trabalho analíticas em várias regiões, deve implementar a sua própria abordagem.

Soluções típicas multi-região envolvem dois ou mais espaços de trabalho. Pode escolher entre várias estratégias, incluindo arquiteturas ativa-passiva e ativa-ativa.

Para escolher uma arquitetura, considere os seguintes fatores:

  • A importância da carga de trabalho para o seu negócio
  • A duração potencial de uma interrupção (horas ou possivelmente um dia inteiro)
  • O esforço necessário para tornar o espaço de trabalho totalmente operacional
  • O esforço necessário para restaurar ou falhar de volta à região primária

Para cargas de trabalho que requerem proteção multi-região, consulte Azure Databricks recuperação de desastres.

Backup e recuperação

O Azure Databricks faz backup automático das bases de dados como parte das operações geridas do serviço. Este processo inclui conteúdo do caderno, definições de tarefas, configurações de cluster e definições de controlo de acesso.

Observação

Se ocorrer uma falha de zona, o Azure Databricks não espera perda de dados.

Recomendamos que armazene os seus dados no Unity Catalog. Podes replicar dados através de replicação de armazenamento ou clonagem delta.

As capacidades de backup e restauro ao nível do espaço de trabalho não estão diretamente disponíveis. Planeie procedimentos de recreação no espaço de trabalho que incluam restaurar configurações, utilizadores e controlos de acesso dos seus processos de sincronização.

Resiliência à manutenção de serviços

O Azure Databricks realiza manutenção automática da plataforma para aplicar atualizações de segurança, implementar novas funcionalidades e melhorar a fiabilidade do serviço. Pode configurar as janelas de manutenção do seu cluster para reduzir a probabilidade de a manutenção afetar as suas cargas de trabalho de produção. Para obter mais informações, consulte Atualização automática de cluster.

Contrato de nível de serviço

O contrato de nível de serviço (SLA) para serviços do 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 Acordos de Nível de Serviço (SLAs) para serviços online.

Conteúdo relacionado

  • Last updated on