Confiabilidade no Azure Databricks

O Azure Databricks é uma plataforma colaborativa de dados e IA baseada no Apache Spark otimizada para o Microsoft Azure. Ele fornece 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, a ciência de dados e o aprendizado de máquina.

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 o Azure Databricks mantém a resiliência contra várias possíveis interrupções e problemas e como você pode configurar a resiliência para atender às suas necessidades. As diretrizes abordam falhas transitórias, interrupções de zona de disponibilidade, interrupções de região e manutenção do serviço. Este artigo também descreve como usar backups para se recuperar de outros problemas e realça as principais informações sobre o SLA (contrato de nível de serviço) do Azure Databricks.

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

Para saber como implantar o Azure Databricks para dar suporte aos requisitos de confiabilidade da solução e como a confiabilidade afeta outros aspectos de sua arquitetura, consulte as práticas recomendadas de arquitetura para o Azure Databricks.

Visão geral da arquitetura de confiabilidade

Você deve entender a confiabilidade de cada componente primário no Azure Databricks:

• O plano de controle é uma coleção de serviços sem estado que gerencia metadados de workspace, acesso do usuário, agendamento de trabalho e gerenciamento de cluster. Esses serviços são apoiados por bancos de dados replicados entre zonas de disponibilidade em regiões com suporte.

• A raiz do DBFS (Databricks File System) é uma conta de armazenamento que o Azure Databricks provisiona automaticamente quando você cria um workspace do Azure Databricks em sua conta de nuvem. Recomendamos que você não armazene dados na raiz DBFS e desabilite essa conta de armazenamento, se possível.

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

• O plano de computação executa cargas de trabalho de processamento de dados usando clusters de VMs (máquinas virtuais). O plano de computação lida com falhas transitórias e substitui automaticamente nós com falha sem intervenção do usuário. Você pode escolher entre vários tipos de recursos de computação. Para obter mais informações, consulte Computação.

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

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.

Você pode controlar novas tentativas de tarefas nos Jobs do Lakeflow para ajudar na recuperação de erros transitórios.

Para aplicativos executados no Azure Databricks, implemente a lógica de repetição com retirada exponencial ao se conectar a serviços externos ou serviços do Azure, como Serviços de Armazenamento, Banco de Dados SQL do Azure ou Hubs de Eventos do Azure. O Databricks Runtime inclui resiliência interna para muitos serviços do Azure, mas o código do aplicativo deve lidar com falhas transitórias específicas do serviço.

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 Databricks dá suporte à redundância de zona para cada componente:

• Plano de controle: Em regiões que dão suporte a zonas de disponibilidade, o plano de controle é executado em várias zonas de disponibilidade. O plano de controle lida com falhas de zona automaticamente, com impacto mínimo e nenhuma intervenção do usuário necessária.

  Os dados do espaço de trabalho do plano de controle são armazenados em bancos de dados. Em regiões que dão suporte a zonas de disponibilidade, os bancos de dados são replicados em várias zonas da região. Contas de armazenamento que atendem 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 de armazenamento primária está inativa.

• Raiz do DBFS: Em regiões que dão suporte a zonas de disponibilidade, você pode configurar a conta de armazenamento da raiz DBFS para usar o ZRS (armazenamento com redundância de zona). Em regiões emparelhadas compatíveis com zonas de disponibilidade, você pode usar opcionalmente o armazenamento com redundância de zona geográfica (GZRS).

• Plano de computação: O Databricks dá suporte à distribuição automática de zona para recursos de computação, o que significa que seus recursos são distribuídos entre várias zonas de disponibilidade. Essa distribuição ajuda suas cargas de trabalho de produção a alcançar resiliência a falhas de zona.

  Ao usar a computação sem servidor, você não seleciona explicitamente zonas para sua computação. O Databricks gerencia a seleção de zonas das VMs e a substituição de VMs que podem ser perdidas devido a falhas de zona.

Requirements

Para usar o suporte à zona de disponibilidade no Azure Databricks, você precisa dos seguintes requisitos:

• Suporte à região: O suporte à zona de disponibilidade do Azure Databricks está disponível em todas as regiões do Azure que dão suporte ao Azure Databricks e fornecem zonas de disponibilidade. Para obter uma lista de regiões que dão suporte ao Azure Databricks, consulte Produtos disponíveis por região. Para obter uma lista completa de regiões que dão suporte a zonas de disponibilidade, consulte as regiões do Azure que dão suporte a zonas de disponibilidade.

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

• Capacidade de computação: Verifique se há capacidade de computação suficiente em várias zonas em sua região de destino. O Azure Databricks distribui automaticamente nós de cluster entre zonas, mas você 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 nós de cluster entre zonas de disponibilidade. A distribuição depende da capacidade disponível em cada zona. Durante períodos de alta demanda, os nós de um cluster podem estar concentrados em menos zonas. Quando você usa computação sem servidor, o Azure Databricks gerencia a seleção de zona de VMs e a substituição de VMs que podem ser perdidas devido a interrupções de zona.

Custo

A distribuição de zona não afeta os custos de computação porque você paga pelo mesmo número de VMs, independentemente do posicionamento da zona de disponibilidade. Para obter mais informações, consulte os preços de computação do Azure Databricks.

A redundância padrão para a conta de armazenamento gerenciada, ou raiz DBFS, é o GRS (armazenamento com redundância geográfica). Alterar para ZRS ou GZRS pode afetar seus custos de armazenamento. Para obter mais informações, veja Preços do Armazenamento de Blobs do Azure.

Configurar o suporte à zona de disponibilidade

• Plano de controle: O plano de controle dá suporte automaticamente à redundância de zona em regiões que têm zonas de disponibilidade. Você não precisa configurar nada.

• Raiz do DBFS: Você pode configurar a redundância de zona para o armazenamento raiz do DBFS ao criar um novo workspace ou modificar um workspace existente:

  • Crie um novo workspace com armazenamento DBFS Root com redundância de zona: Ao criar um novo workspace do Azure Databricks, você pode, opcionalmente, configurar a conta de armazenamento associada para usar ZRS ou GZRS em vez do padrão GRS. Para obter mais informações, consulte Alterar as opções de redundância de armazenamento do workspace.

  • Habilitar redundância de zona no armazenamento raiz do DBFS: Para workspaces existentes, você pode alterar a configuração de redundância da conta de armazenamento do workspace para ZRS ou GZRS. Para obter mais informações sobre como habilitar a redundância de zona, consulte Alterar as configurações de replicação de uma conta de armazenamento.

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

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que esperar quando um workspace é configurado com suporte à zona de disponibilidade e todas as zonas de disponibilidade estão operacionais.

• Replicação de dados entre zonas: A replicação de dados para armazenamento de workspace ocorre de forma síncrona entre zonas quando a raiz do DBFS usa uma conta ZRS ou GZRS. Essa abordagem garante uma consistência forte com impacto mínimo no desempenho.

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

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando um espaço de trabalho é configurado com suporte à zona de disponibilidade e ocorre uma interrupção na zona de disponibilidade.

• Detecção e resposta: A Microsoft detecta automaticamente falhas de zona e inicia procedimentos de resposta. Você não precisa executar nenhuma ação para failover de nível de zona.

• Notificação: A Microsoft não notifica você automaticamente quando uma zona está inoperante. Mas você pode usar a página de status do Azure Databricks para ver uma visão geral de todos os principais serviços do Azure Databricks. Você também pode assinar atualizações de status em componentes de serviço individuais e receber um alerta quando o status do serviço ao qual você assina é alterado.

• Solicitações ativas: Clusters em execução podem perder nós na zona afetada. O gerenciador de cluster solicita automaticamente os nós substitutos das zonas remanescentes. Caso o nó de controle seja perdido, o cluster e o trabalho são reiniciados completamente.

• Perda de dados esperada:

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

  • Raiz do DBFS: os dados do workspace permanecerão disponíveis se usarem configurações de armazenamento ZRS ou GZRS.

  • Plano de computação: Os dados armazenados em cache em VMs são efêmeros. Todos os dados perdidos de VMs durante uma falha de zona são recuperados do armazenamento. Se o nó do driver for perdido, o trabalho será reiniciado e recalculará os resultados.

• Tempo de inatividade esperado:

  • Plano de controle: o plano de controle do Databricks executa o failover automático em zonas íntegras em cerca de 15 minutos.

  • Raiz do DBFS: Não espere tempo de inatividade para contas de armazenamento que usam ZRS ou GZRS.

  • Plano de computação: Se os nós forem perdidos porque suas VMs residem na zona de disponibilidade afetada, o gerenciador de cluster do Azure solicitará nós de substituição do provedor de computação do Azure. Se as zonas íntegras restantes tiverem capacidade suficiente para atender à solicitação, o provedor de computação extrairá nós das zonas íntegras para substituir os nós perdidos. Esse processo pode levar vários minutos.

    Se o nó principal for perdido por causa de uma falha na zona, todo o cluster será reiniciado, o que pode causar tempos de recuperação mais longos em comparação com a perda de nós de trabalho. Planeje esse comportamento nas estratégias de agendamento e monitoramento do trabalho.

    Você pode usar pools de instância ou sem servidor para reduzir esse tempo.

• Redirecionamento de tráfego:

  • Plano de controle: o plano de controle do Databricks executa o failover automático em zonas íntegras em cerca de 15 minutos.

  • Raiz do DBFS: O Armazenamento do Azure redireciona automaticamente as solicitações para clusters de armazenamento em zonas saudáveis.

  • Plano de computação: O gerenciador de cluster alterna automaticamente para nodos em zonas saudáveis.

Recuperação de zona

Quando a zona de disponibilidade com falha é recuperada, o Azure Databricks retoma automaticamente as operações normais em todas as zonas. O gerenciador de cluster pode reequilibrar a distribuição dos nós durante as criações de nós subsequentes, mas os nós existentes continuam a operar em suas zonas atuais até que sejam encerrados.

Você não precisa executar nenhuma ação para operações de failback. A distribuição de zona normal é retomada para novas implantações de cluster.

Testar falhas em zonas

O Azure Databricks é um serviço gerenciado em que a Microsoft lida com o failover de zona automaticamente e realiza testes regulares de interrupção de zona. Não é necessário testar cenários de falha de zona para o próprio serviço.

Para suas aplicações executadas no Azure Databricks, teste a resiliência das tarefas simulando falhas de nó do driver e monitorando o comportamento de reinicialização do cluster. Verifique se suas tarefas de processamento de dados conseguem lidar com reinicializações do cluster e retomar a partir de pontos de verificação 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, seu workspace também estará indisponível. Se você precisar de implantações de várias regiões, consulte a recuperação de desastre do Azure Databricks.

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

O Azure Databricks não oferece capacidade integrada de operar em múltiplas regiões. Para uma proteção abrangente e multirregional das suas cargas de trabalho analíticas, você precisa implementar sua própria abordagem.

Soluções típicas de várias regiões envolvem dois ou mais workspaces. Você pode escolher entre diversas estratégias, incluindo arquiteturas ativa-passiva e ativa-ativa.

Para escolher uma arquitetura, considere os seguintes fatores:

• A criticidade da carga de trabalho para sua empresa
• A duração potencial de uma interrupção (horas ou possivelmente um dia inteiro)
• O esforço necessário para tornar o workspace totalmente operacional
• O esforço necessário para restaurar ou recuperar para a região primária

Para cargas de trabalho que exigem proteção de várias regiões, consulte a recuperação de desastre do Azure Databricks.

Backup e recuperação

O Azure Databricks faz backup automático de bancos de dados como parte das operações gerenciadas do serviço. Esse processo inclui conteúdo do notebook, definições de trabalho, configurações de cluster e configurações de controle de acesso.

Recomendamos que você armazene seus dados no armazenamento do Catálogo do Unity. Você pode replicar dados por meio de replicação de armazenamento ou clonagem delta.

Os recursos de backup e restauração no nível do workspace não estão diretamente disponíveis. Planeje procedimentos de recriação do workspace que incluem a restauração de configurações, usuários e controles de acesso de seus processos de sincronização.

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

O Azure Databricks executa a manutenção automática da plataforma para aplicar atualizações de segurança, implantar novos recursos e melhorar a confiabilidade do serviço. Você pode configurar as janelas de manutenção do seu cluster para diminuir a chance de que essas atividades impactem suas cargas de trabalho de produção. Para obter mais informações, confira Atualização automática do cluster.

Contrato de nível de serviço

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

Conteúdo relacionado

• Recuperação de desastre do Azure Databricks
• Práticas recomendadas de confiabilidade para o Azure Databricks
• Visão geral da confiabilidade do Azure