Confiabilidade no Armazenamento do Azure Mover

O Armazenamento do Azure Mover é um serviço totalmente gerido que migra ficheiros e pastas para o Armazenamento do Azure, mantendo os ficheiros sincronizados entre contas de armazenamento. Use o Storage Mover quando estiver a mover dados para o Azure, ou quando precisar de manter os dados sincronizados entre diferentes locais dentro do Azure.

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 Armazenamento do Azure Mover responde a uma variedade de potenciais interrupções e problemas, incluindo falhas transitórias, falhas em zonas de disponibilidade e falhas regionais. Também descreve como proteger a configuração do seu Storage Mover.

Important

Este artigo aborda apenas a fiabilidade do serviço Armazenamento do Azure Mover e os seus recursos. A fiabilidade de uma migração de ponta a ponta depende de todos os componentes: o serviço Storage Mover, quaisquer agentes Storage Mover que implemente, o ambiente de origem e a conectividade da rede, e a conta de armazenamento alvo. És responsável pela fiabilidade dos agentes, sistemas de origem e armazenamento alvo. Para mais informações sobre a fiabilidade do Armazenamento do Azure, veja Fiabilidade no Armazenamento de Blobs do Azure e Fiabilidade no Ficheiros do Azure.

Visão geral da arquitetura de confiabilidade

Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.

Arquitetura lógica

O Armazenamento do Azure Mover foi concebido para migrar e sincronizar dados entre locais de armazenamento, não para servir pedidos no caminho de execução de uma carga de trabalho de produção. Tem uma hierarquia de recursos que define os componentes que implementas e geres. O recurso de topo chama-se storage mover. Num mecanismo de transferência de armazenamento, define projetos que contêm definições de tarefa que descrevem o que deve ser migrado e para onde. Os endpoints definem as localizações de origem e destino para um trabalho de migração ou sincronização.

Para alguns cenários, como migrações a partir de ambientes on-premises, também se implementa um ou mais agentes Storage Mover. Um agente é um software que executa numa máquina que controla, como uma máquina virtual ou física. Alguns cenários não requerem um agente.

O serviço armazena metadados de configuração, incluindo projetos, endpoints, registos de agentes, definições de trabalhos e histórico de execução de trabalhos. Estes metadados não incluem os dados que migra.

Arquitetura física

O serviço Armazenamento do Azure Mover corre numa infraestrutura gerida pela Microsoft. Os agentes correm em hardware que tu geres. És responsável pela fiabilidade dos agentes, o que está fora do âmbito deste artigo.

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.

Se uma falha transitória afetar a comunicação entre um agente e o serviço Storage Mover, ou ao ligar-se a uma fonte ou destino, o agente tenta automaticamente novamente. Para tarefas de Azure para Azure, o serviço também é resistente a muitas falhas transitórias. Quando a conectividade for restabelecida, as tarefas de migração em curso são retomadas.

Em alguns casos, falhas transitórias aparecem como erros no histórico de execução do trabalho. Para uma descrição dos códigos de erro, incluindo erros transitórios, consulte os códigos de estado e os tipos de erro do Armazenamento do Azure Mover. Para orientações sobre como resolver problemas persistentes de conectividade de rede, consulte Troubleshoot Armazenamento do Azure Mover network connectivity.

Resiliência a falhas na zona de disponibilidade

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.

Nas regiões que suportam zonas de disponibilidade, a plataforma distribui os metadados de configuração do storage mover entre zonas com base no melhor esforço, mas este comportamento não é garantido. Se as suas migrações de armazenamento precisarem de suportar a perda de uma zona, desenhe o seu processo de migração para tolerar a perda de um storage mover e reveja a Resiliência face a falhas regionais.

Considere o efeito de uma falha de zona no contexto de como utiliza o Storage Mover. O serviço orquestra a migração e a sincronização dos dados e, normalmente, não está no trajeto de execução da sua carga de trabalho de produção. Se um transportador de armazenamento não estiver disponível durante uma falha de zona, um trabalho de migração ou sincronização normalmente é atrasado em vez de causar uma interrupção de produção, podendo retomar ou tentar novamente o trabalho depois de o serviço recuperar. O Storage Mover também não oferece um acordo de nível de serviço (SLA) de disponibilidade, por isso o seu design não deve assumir que o serviço está continuamente disponível. Se a sua carga de trabalho depende da sincronização contínua, avalie se este tipo de atraso é aceitável para o seu cenário.

O diagrama seguinte mostra um storage mover com metadados de infraestrutura e configuração distribuídos por três zonas:

Diagrama de um mecanismo de movimentação do armazenamento com redundância entre zonas, distribuído por três zonas de disponibilidade.

Note

A fiabilidade de qualquer migração de dados também depende das contas de armazenamento e dos agentes que utiliza. Por exemplo, se a sua conta de armazenamento alvo usa armazenamento localmente redundante (LRS), não é resiliente a uma falha de zona. Para tornar uma migração resistente a falhas de zona, utilize uma conta de armazenamento de destino com redundância entre zonas.

Requisitos

Suporte regional: A distribuição numa base de melhor esforço dos metadados de configuração entre zonas só pode ocorrer numa região que suporte tanto o Storage Mover como as zonas de disponibilidade. Verifique a disponibilidade da região do Storage Mover e compare com a lista de regiões que suportam zonas de disponibilidade. Mesmo nestas regiões, a resiliência das zonas não é garantida.

Custo

O Storage Mover não oferece suporte configurável para zonas de disponibilidade, por isso não incorre em custos adicionais relacionados com as zonas de disponibilidade. Para mais informações sobre como o Storage Mover é faturado, consulte Compreender a faturação do Armazenamento do Azure Mover.

Configurar o suporte à zona de disponibilidade

O Storage Mover não oferece suporte para zonas de disponibilidade configuráveis, por isso não há nada para ativar ou aderir. Para mais informações sobre como criar um recurso Storage Mover, consulte Planeamento de implementação para Armazenamento do Azure Mover.

Comportamento quando todas as zonas estão íntegras

Esta secção descreve o que esperar quando um transportador de armazenamento está numa região que suporta zonas de disponibilidade e todas as zonas estão operacionais.

  • Operação entre zonas: A infraestrutura em qualquer uma das zonas de disponibilidade da região pode servir operações de gestão e acesso a metadados. As ligações do agente podem aceder ao serviço através de qualquer zona.

  • Distribuição de dados entre zonas: O serviço visa replicar de forma síncrona os metadados de configuração entre as zonas de disponibilidade da região.

Comportamento durante uma falha de zona

Esta secção descreve o que esperar quando um transportador de armazenamento está numa região que suporta zonas de disponibilidade e há uma falha numa das zonas.

  • Deteção e resposta: A plataforma foi concebida para detetar a perda de uma zona de disponibilidade e redirecionar o tráfego para zonas saudáveis, mas esta resposta é o melhor esforço e não é garantida.
  • Notificação: A Microsoft não te informa automaticamente quando uma zona está inativa. No entanto, pode utilizar o Azure Resource Health para monitorizar a integridade de um recurso individual, e pode configurar alertas de integridade de recursos para notificá-lo de problemas. Também pode usar Azure Service Health para compreender o estado geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas Saúde do Serviço para o notificar de problemas.

  • Pedidos ativos: As operações de gestão em curso, que dependem da infraestrutura na zona afetada, podem falhar, e é necessário tentá-las novamente. Os trabalhos de migração ativa de dados que correm em agentes podem continuar a funcionar, mas operações de gestão que dependem do serviço de metadados podem não estar disponíveis.

  • Perda de dados esperada: Os dados que um transportador de armazenamento está a migrar não se perdem durante uma falha de zona.

    Como o Storage Mover não garante que os metadados de configuração sejam distribuídos entre as zonas, uma falha de zona pode tornar alguns dos metadados de configuração do storage mover temporariamente indisponíveis até a zona recuperar.

  • Tempo de inatividade previsto: A plataforma tenta restabelecer operações utilizando outra zona, mas em algumas situações as operações podem estar indisponíveis até que a zona afetada recupere. Prepare a sua carga de trabalho seguindo as orientações de tratamento de falhas transitórias.

  • Redistribuição: Se a plataforma redirecionar o tráfego para zonas de disponibilidade saudáveis, faz-no com base no melhor esforço.

Recuperação de zona

Quando uma zona de disponibilidade recupera, a plataforma pretende restaurar a capacidade na zona recuperada e reequilibrar o tráfego entre zonas. Este comportamento é o melhor esforço e não é garantido. Não precisas de tomar qualquer ação para iniciar a recuperação da zona.

Teste de falhas de zona

Não é possível iniciar ou testar uma falha numa zona de disponibilidade para um mover de armazenamento. Uma vez que o Storage Mover não garante resiliência entre zonas, não assuma que o Storage Mover sobrevive a uma falha de zona. Se o seu processo de migração precisa de suportar a perda de uma zona, valide a resiliência de ponta a ponta desse processo e reveja a Resiliência face a falhas regionais para encontrar abordagens que permitam controlar o failover.

Resiliência a falhas em toda a região

Armazenamento do Azure Mover é um serviço de região única. Quando implementa um recurso Armazenamento do Azure Mover, seleciona uma região para armazenar os metadados de configuração do recurso. Se a região do storage mover sofrer uma falha, as operações de gestão que o agente realiza e que dependem do Azure podem não ser concluídas. Além disso, quaisquer migrações ativas de dados para contas de armazenamento localizadas na região afetada podem falhar.

Se o seu storage mover estiver numa região Azure com um par, os seus metadados de configuração são replicados para a região Azure emparelhada para fins de recuperação de desastres, e a Microsoft pode ativar o failover para a região emparelhada durante um desastre que afete a sua região principal.

Se o seu storage mover estiver numa região não emparelhada, a Microsoft não replica metadados de configuração e não existe um failover incorporado para outra região. No entanto, você pode implantar recursos separados em várias regiões. Nesse cenário, é sua responsabilidade gerenciar a replicação, a distribuição de tráfego e o failover. Se usar uma região não emparelhada, ou se a replicação de metadados incorporada não satisfizer as suas necessidades, pode criar uma estratégia personalizada de failover multi-região.

Note

És responsável pela recuperação de desastres para as tuas fontes de dados (incluindo Azure e fontes de dados locais), alvos e agentes.

Transição gerida pela Microsoft para uma região associada

Se o seu recurso do Storage Mover estiver numa região que se emparelha com outra região, a Microsoft replica os metadados de configuração do seu storage mover para a região emparelhada.

Diagrama de um mover de armazenamento a replicar os seus metadados para uma região emparelhada.

Em caso de indisponibilidade de uma região, a Microsoft pode efetuar um failover para a região emparelhada, recorrendo aos metadados de configuração replicados. Este processo é uma opção padrão e não requer nenhuma intervenção sua.

Diagrama de um mover de armazenamento a falhar para uma região emparelhada.

O failover dos recursos do Storage Mover pode ocorrer num momento diferente do failover de outros serviços do Azure.

Important

É improvável que a Microsoft inicie o failover exceto após um atraso significativo e é feito com base no melhor esforço. Se precisares de cumprir prazos específicos para a recuperação do Storage Mover, ou se o comportamento padrão de replicação e failover não corresponder às tuas necessidades, usa soluções multi-região personalizadas para resiliência , planeando e iniciando o teu próprio failover.

A replicação entre regiões aplica-se apenas a metadados de configuração. Não se aplica aos dados de origem nem à conta de armazenamento de destino, que tem as suas próprias opções de fiabilidade e replicação. Para mais informações, consulte Fiabilidade no Armazenamento de Blobs do Azure e Fiabilidade no Ficheiros do Azure.

Requisitos

Suporte de região: A replicação multi-região gerida pela Microsoft está disponível apenas para recursos do Storage Mover que implementa numa região com uma região emparelhada. Para recursos em regiões não emparelhadas, não é fornecida replicação entre regiões nem ativação pós-falha. Para alcançar resiliência entre regiões em regiões não emparelhadas, utilize uma solução personalizada multi-região.

Custo

O Storage Mover não cobra pela replicação multi-região gerida pela Microsoft da configuração do seu storage mover. No entanto, poderá haver um pequeno custo para a replicação entre regiões. Para obter mais informações, consulte Preços de largura de banda.

Configurar suporte a várias regiões

A replicação multi-região gerida pela Microsoft é automaticamente ativada para recursos do Storage Mover em regiões emparelhadas. Não configura nem adere a este comportamento.

Comportamento quando todas as regiões estão saudáveis

Esta secção descreve o que esperar quando um storage mover está configurado para replicação e failover entre regiões, e a região principal está operacional.

  • Operação entre regiões: O seu recurso Storage Mover na região principal serve todos os pedidos. A região emparelhada é usada apenas em caso de um failover iniciado pela Microsoft.

  • Replicação de dados entre regiões: A região primária replica a configuração de forma assíncrona à região emparelhada. Como a replicação é assíncrona, alterações recentes na configuração podem não ser refletidas na região emparelhada no momento da falha.

Comportamento durante uma interrupção regional

Esta secção descreve o que esperar quando um storage mover está configurado para replicação e failover entre regiões, e há uma falha na região principal.

  • Deteção e resposta: A Microsoft deteta falhas de região e decide se inicia um failover. É improvável que a Microsoft inicie o failover, a não ser após um atraso significativo, e o failover é efetuado num regime de melhor esforço.

  • Notificação: A Microsoft não o notifica automaticamente quando uma região está inativa. No entanto:

  • Pedidos ativos: Os pedidos de gestão ativa são cancelados e precisam de ser tentados novamente após a conclusão do failover. Os trabalhos de migração ativa de dados a correr em agentes podem falhar se dependerem da região que está a sofrer a falha.

  • Perda de dados esperada: Como a replicação entre regiões é assíncrona, quaisquer alterações de metadados de configuração que não sejam replicadas para a região emparelhada no momento da interrupção podem ser perdidas.

  • Tempo de inatividade previsto: Um failover regional pode demorar até 24 horas a ser concluído. Durante este período, o seu migrador de armazenamento não está disponível.

  • Redistribuição: Após a conclusão do failover, o Storage Mover começa a executar trabalhos a partir da região emparelhada.

    No entanto, é necessário voltar a registar agentes contra o transportador de armazenamento na região emparelhada.

Recuperação da região

Quando a região primária original recupera, a Microsoft coordena o failback. Tens de re-registar agentes contra o transportador de armazenamento na região principal.

Teste para falhas regionais

A plataforma Armazenamento do Azure Mover gere replicação entre regiões, failover e recuperação regional. Como a Microsoft gere totalmente esta funcionalidade, não pode iniciar nem testar um failover regional.

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

Se precisares de controlar quando ocorre o failover, ou se estiveres numa região não emparelhada mas ainda precisares que o teu storage mover seja resiliente a falhas de região, implementa recursos independentes do Storage Mover em múltiplas regiões Azure. És responsável por todos os aspetos desta abordagem, incluindo:

  • Criar e manter projetos, endpoints, agentes e definições de funções equivalentes em cada região.
  • Detetar falhas de região e decidir quando fazer failover.
  • Redirecionar agentes e empregos de migração para a região secundária.
  • Reconciliação do estado do trabalho e histórico de execução entre regiões.

Uma solução multirregional personalizada funciona tanto para regiões emparelhadas como não emparelhadas, e dá-lhe controlo total sobre o seu processo de failover.

Para mais informações, consulte Recuperação de desastres iniciada pelo cliente para Armazenamento do Azure Mover.

Backup e restauração

Armazenamento do Azure Mover é um serviço de orquestração de migração e movimentação de dados. Não armazena os dados que migras. O serviço armazena apenas metadados de configuração, como projetos, endpoints, definições de jobs e histórico de execução de jobs. Não há dados de migração para fazer backup.

Para proteger a configuração do seu Storage Mover, defina os seus recursos usando infraestrutura como código, como ficheiros Bicep, e armazene essas definições no controlo de versão. Se precisares de recriar um recurso, podes redistribuí-lo a partir da tua configuração armazenada.

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

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

A Microsoft aplica regularmente atualizações de serviço e realiza outras manutenções. A plataforma Azure gere estas atividades automaticamente, garantindo que a manutenção é fluida e transparente para si. Não é esperado qualquer tempo de indisponibilidade durante os eventos de manutenção, a menos que tenha sido informado através da manutenção planeada do Azure Service Health.

Os agentes do Storage Mover são automaticamente atualizados.

Contrato de nível de serviço

O Storage Mover é um serviço de migração e não oferece um acordo de nível de serviço (SLA) de disponibilidade. No entanto, a documentação do Storage Mover descreve as metas de escala e desempenho esperadas. Estes objetivos baseiam-se em migrações simuladas e não constituem garantia ou compromisso.

Conteúdo relacionado

  • Last updated on