Partilhar via


Noções básicas sobre a configuração de backup periódico no Azure Service Fabric

A configuração do backup periódico de seus serviços de estado confiáveis ou atores confiáveis consiste nas seguintes etapas:

  1. Criação de políticas de backup: nesta etapa, uma ou mais políticas de backup são criadas dependendo dos requisitos.

  2. Habilitando o backup: nesta etapa, você associa as políticas de backup criadas na Etapa 1 às entidades, Aplicativo, Serviço ou uma Partição necessários.

Criar política de backup

Uma política de backup consiste nas seguintes configurações:

  • Restauração automática em caso de perda de dados: Especifica se a restauração deve ser acionada automaticamente usando o backup mais recente disponível caso a partição sofra um evento de perda de dados.

Nota

Recomenda-se NÃO definir a Restauração Automática em clusters de produção

  • Backups incrementais máximos: define o número máximo de backups incrementais a serem feitos entre dois backups completos. Os backups incrementais máximos especificam o limite superior. Um backup completo pode ser feito antes que o número especificado de backups incrementais seja concluído em uma das seguintes condições:

    1. A réplica nunca fez um backup completo desde que se tornou principal.

    2. Alguns dos registros de log desde o último backup foram truncados.

    3. A réplica ultrapassou o limite MaxAccumulatedBackupLogSizeInMB.

  • Agendamento de backup: o tempo ou a frequência com que devem ser feitos backups periódicos. Pode-se agendar backups para serem recorrentes em intervalos especificados ou em um horário fixo diariamente/semanalmente.

    1. Agendamento de backup baseado em frequência: esse tipo de agendamento deve ser usado se for necessário fazer backup de dados em intervalos fixos. O intervalo de tempo desejado entre dois backups consecutivos é definido usando ISO8601 formato. O agendamento de backup baseado em frequência oferece suporte à resolução de intervalos por minuto.

      {
          "ScheduleKind": "FrequencyBased",
          "Interval": "PT10M"
      }
      
    2. Agendamento de backup baseado em tempo: esse tipo de agendamento deve ser usado se for necessário fazer backup de dados em horários específicos do dia ou da semana. O tipo de frequência de programação pode ser diário ou semanal.

      1. Agendamento diário de backup baseado em tempo: esse tipo de agendamento deve ser usado se a necessidade for fazer backup de dados em horários específicos do dia. Para especificar isso, defina ScheduleFrequencyType como Diário e defina RunTimes como lista de horas desejadas durante o dia em ISO8601 formato, a data especificada juntamente com a hora será ignorada. Por exemplo, 0001-01-01T18:00:00 representa 18:00 todos os dias, ignorando a parte de data 0001-01-01. O exemplo abaixo ilustra a configuração para acionar o backup diário às 9h00 e às 18h00 todos os dias.

        {
            "ScheduleKind": "TimeBased",
            "ScheduleFrequencyType": "Daily",
            "RunTimes": [
              "0001-01-01T09:00:00Z",
              "0001-01-01T18:00:00Z"
            ]
        }
        
      2. Agendamento semanal de backup baseado em tempo: esse tipo de agendamento deve ser usado se for necessário fazer backup de dados em horários específicos do dia. Para especificar isso, defina ScheduleFrequencyType como Semanal, defina RunDays como lista de dias em uma semana em que o backup precisa ser acionado e defina RunTimes como lista de horas desejadas durante o dia em ISO8601 formato, a data especificada juntamente com a hora será ignorada. Lista de dias de uma semana em que acionar o backup periódico. O exemplo abaixo ilustra a configuração para acionar o backup diário às 9h00 e às 18h00 de segunda a sexta-feira.

        {
            "ScheduleKind": "TimeBased",
            "ScheduleFrequencyType": "Weekly",
            "RunDays": [
               "Monday",
               "Tuesday",
               "Wednesday",
               "Thursday",
               "Friday"
            ],
            "RunTimes": [
              "0001-01-01T09:00:00Z",
              "0001-01-01T18:00:00Z"
            ]
        }
        
  • Armazenamento de backup: especifica o local para carregar backups. O armazenamento pode ser armazenamento de blob do Azure ou compartilhamento de arquivos.

    1. Azure blob store with managed identity: este tipo de armazenamento deve ser selecionado quando for necessário armazenar backups gerados no Azure. Clusters autônomos e baseados em nuvem podem usar esse tipo de armazenamento. A descrição desse tipo de armazenamento requer BlobServiceUri e o nome do contêiner onde os backups precisam ser carregados. Se o contêiner com o nome especificado não estiver disponível, ele será criado durante o carregamento de um backup. Substitua account-name pelo nome da sua conta de armazenamento.

      {
          "StorageKind": "ManagedIdentityAzureBlobStore",
          "FriendlyName": "AzureMI_storagesample",
          "BlobServiceUri": "https://<account-name>.blob.core.windows.net",
          "ContainerName": "backup-container",
          "ManagedIdentityType": "VMSS",
          "ManagedIdentityClientId": "<Client-Id of User-Assigned MI>" 
      }
      

      [OBSERVAÇÃO] Use o parâmetro ManagedIdentityClientId Optional com Client-Id of User-Assigned Managed Identity no caso de várias Identidades Gerenciadas Atribuídas pelo Usuário atribuídas ao seu recurso ou ambas as SAMI ou UAMI atribuídas, e precisamos usar UAMI como padrão, caso contrário, não há necessidade deste paramter.

      siga as etapas para atribuição de identidade gerenciada no recurso do Azure:

      1. Habilitar a identidade gerenciada atribuída ao sistema ou ao usuário no VMSS Configurar identidades gerenciadas no conjunto de dimensionamento de máquina virtual

      2. Atribuir função à identidade gerenciada do VMSS à conta de armazenamento Atribuir funções do Azure usando o portal do Azure - Azure RBAC

        1. Função de Colaborador de Dados de Blob de Armazenamento no mínimo

      Para obter mais informações sobre Identidade Gerenciada

    2. Repositório de blobs do Azure com ConnectionString: esse tipo de armazenamento deve ser selecionado quando for necessário armazenar backups gerados no Azure. Clusters autônomos e baseados em nuvem podem usar esse tipo de armazenamento. A descrição para esse tipo de armazenamento requer cadeia de conexão e nome do contêiner onde os backups precisam ser carregados. Se o contêiner com o nome especificado não estiver disponível, ele será criado durante o carregamento de um backup.

      {
          "StorageKind": "AzureBlobStore",
          "FriendlyName": "Azure_storagesample",
          "ConnectionString": "<Put your Azure blob store connection string here>",
          "ContainerName": "backup-container"
      }
      

      Nota

      Serviço de restauração de backup não funciona com o armazenamento do Azure v1 ConnectionString não é recomendado em produção como acesso direto ao recurso sem autenticação do usuário

    3. Compartilhamento de arquivos: esse tipo de armazenamento deve ser selecionado para clusters autônomos quando for necessário armazenar o backup de dados localmente. A descrição para esse tipo de armazenamento requer um caminho de compartilhamento de arquivos onde os backups precisam ser carregados. O acesso ao compartilhamento de arquivos pode ser configurado usando uma das seguintes opções:

      1. Autenticação Integrada do Windows, em que o acesso ao compartilhamento de arquivos é fornecido a todos os computadores pertencentes ao cluster do Service Fabric. Nesse caso, defina os campos a seguir para configurar o armazenamento de backup baseado em compartilhamento de arquivos.

        {
            "StorageKind": "FileShare",
            "FriendlyName": "Sample_FileShare",
            "Path": "\\\\StorageServer\\BackupStore"
        }
        
      2. Proteger a partilha de ficheiros utilizando o nome de utilizador e a palavra-passe, em que o acesso à partilha de ficheiros é fornecido a utilizadores específicos. A especificação de armazenamento de compartilhamento de arquivos também fornece capacidade de especificar nome de usuário secundário e senha secundária para fornecer credenciais de fall-back caso a autenticação falhe com nome de usuário primário e senha primária. Nesse caso, defina os campos a seguir para configurar o armazenamento de backup baseado em compartilhamento de arquivos.

        {
            "StorageKind": "FileShare",
            "FriendlyName": "Sample_FileShare",
            "Path": "\\\\StorageServer\\BackupStore",
            "PrimaryUserName": "backupaccount",
            "PrimaryPassword": "<Password for backupaccount>",
            "SecondaryUserName": "backupaccount2",
            "SecondaryPassword": "<Password for backupaccount2>"
        }
        

Nota

Certifique-se de que a confiabilidade do armazenamento atenda ou exceda os requisitos de confiabilidade dos dados de backup.

  • Política de retenção: especifica a política para reter backups no armazenamento configurado. Apenas a Política de Retenção Básica é suportada.
    1. Política de retenção básica: essa política de retenção permite garantir a utilização ideal do armazenamento removendo arquivos de backup, que não são mais necessários. RetentionDuration pode ser especificado para definir o período de tempo durante o qual os backups devem ser mantidos no armazenamento. MinimumNumberOfBackups é um parâmetro opcional que pode ser especificado para garantir que o número especificado de backups seja sempre mantido, independentemente do RetentionDuration. O exemplo abaixo ilustra a configuração para reter backups por 10 dias e não permite que o número de backups fique abaixo de 20.

      {
          "RetentionPolicyType": "Basic",
          "RetentionDuration": "P10D",
          "MinimumNumberOfBackups": 20
      }
      

Habilitar backup periódico

Depois de definir a política de backup para atender aos requisitos de backup de dados, a política de backup deve ser associada adequadamente a um aplicativo, serviço ou partição.

Nota

Verifique se não há atualizações de aplicativos em andamento antes de habilitar o backup

Propagação hierárquica da política de backup

No Service Fabric, a relação entre aplicativo, serviço e partições é hierárquica, conforme explicado em Modelo de aplicativo. A política de backup pode ser associada a um aplicativo, serviço ou partição na hierarquia. A política de backup propaga-se hierarquicamente para o próximo nível. Supondo que haja apenas uma política de backup criada e associada a um aplicativo, todas as partições com estado pertencentes a todos os serviços com estado confiáveis e atores confiáveis do aplicativo são copiadas usando a política de backup. Ou, se a política de backup estiver associada a um serviço stateful confiável, todas as suas partições serão copiadas usando a política de backup.

Substituindo a política de backup

Pode haver um cenário em que o backup de dados com o mesmo agendamento de backup seja necessário para todos os serviços do aplicativo, exceto para serviços específicos, onde a necessidade é ter backup de dados usando agendamento de frequência mais alta ou fazendo backup para uma conta de armazenamento ou compartilhamento de arquivos diferente. Para lidar com esses cenários, o serviço de restauração de backup oferece a facilidade de substituir a política propagada no escopo do serviço e da partição. Quando a política de backup é associada ao serviço ou à partição, ela substitui a política de backup propagada, se houver.

Exemplo

Este exemplo usa a instalação com dois aplicativos, MyApp_A e MyApp_B. O aplicativo MyApp_A contém dois serviços Reliable Stateful, SvcA1 & SvcA3, e um serviço Reliable Ator, ActorA2. SvcA1 contém três partições, enquanto ActorA2 e SvcA3 contêm duas partições cada. O Application MyApp_B contém três serviços Reliable Stateful, SvcB1, SvcB2 e SvcB3. _SvcB1 e SvcB2 contêm duas partições cada, enquanto SvcB3 contém três partições.

Suponha que os requisitos de backup de dados desses aplicativos são os seguintes

  1. MyApp_A

    1. Crie backup diário de dados para todas as partições de todos os serviços Reliable Stateful e Reliable Actors pertencentes ao aplicativo. Carregue dados de backup para o local BackupStore1.

    2. Um dos serviços, SvcA3, requer backup de dados a cada hora.

    3. O tamanho dos dados na partição SvcA1_P2 é mais do que esperado e seus dados de backup devem ser armazenados em diferentes locais de armazenamento BackupStore2.

  2. MyApp_B

    1. Crie backup de dados todos os domingos às 8:00 para todas as partições do serviço SvcB1 . Carregue dados de backup para o local BackupStore1.

    2. Crie backup de dados todos os dias às 8:00 da manhã para SvcB2_P1 de partição. Carregue dados de backup para o local BackupStore1.

Para atender a esses requisitos de backup de dados, as políticas de backup BP_1 para BP_5 são criadas e o backup é habilitado da seguinte maneira.

  1. MyApp_A

    1. Crie uma política de backup, BP_1, com agendamento de backup baseado em frequência, onde a frequência é definida como 24 horas. e armazenamento de backup configurado para usar o local de armazenamento BackupStore1. Habilite esta política para o Application MyApp_A usando a API Enable Application Backup . Essa ação permite o backup de dados usando BP_1 de política de backup para todas as partições de serviços Reliable Stateful e Reliable Actors pertencentes a MyApp_A de aplicativos.

    2. Crie uma política de backup, BP_2, com agendamento de backup baseado em frequência, onde a frequência é definida como 1 hora. e armazenamento de backup configurado para usar o local de armazenamento BackupStore1. Habilite esta política para o serviço SvcA3 usando a API Enable Service Backup . Essa ação substitui o BP_1 de política propagado pelo BP_2 de política de backup explicitamente habilitado para todas as partições do serviço SvcA3, levando ao backup de dados usando BP_2 de política de backup para essas partições.

    3. Crie uma política de backup, BP_3, com agendamento de backup baseado em frequência, onde a frequência é definida como 24 horas. e armazenamento de backup configurado para usar o local de armazenamento BackupStore2. Habilite esta política para SvcA1_P2 de partições usando a API Habilitar Backup de Partição. Essa ação substitui o BP_1 de política propagado por BP_3 de política de backup explicitamente habilitado para SvcA1_P2 de partição.

  2. MyApp_B

    1. Crie uma política de backup, BP_4, com agendamento de backup baseado em tempo, onde o tipo de frequência de agendamento é definido como semanal, dias de execução é definido como domingo e horários de execução são definidos como 8h00. Armazenamento de backup configurado para usar o local de armazenamento BackupStore1. Habilite esta política para o serviço SvcB1 usando a API Enable Service Backup . Essa ação permite o backup de dados usando BP_4 de política de backup para todas as partições do serviço SvcB1.

    2. Crie uma política de backup, BP_5, com agendamento de backup baseado em tempo, onde o tipo de frequência de agendamento é definido como diário e o tempo de execução é definido como 8:00 AM. Armazenamento de backup configurado para usar o local de armazenamento BackupStore1. Habilite esta política para SvcB2_P1 de partições usando a API Habilitar Backup de Partição. Essa ação permite o backup de dados usando BP_5 de política de backup para SvcB2_P1 de partição.

O diagrama a seguir mostra políticas de backup explicitamente habilitadas e políticas de backup propagadas.

Hierarquia de aplicativos do Service Fabric

Desativar a cópia de segurança

As políticas de backup podem ser desativadas quando não há necessidade de fazer backup de dados. A política de backup habilitada em um aplicativo só pode ser desabilitada no mesmo aplicativo usando Desabilitar API de Backup de Aplicativo, a política de backup habilitada em um serviço pode ser desabilitada no mesmo serviço usando Desabilitar API de Backup de Serviço e a política de Backup habilitada em uma partição pode ser desabilitada na mesma partição usando Desabilitar API de Backup de Partição.

  • A desativação da política de backup de um aplicativo interrompe todos os backups periódicos de dados como resultado da propagação da política de backup para partições de serviço Reliable Stateful ou partições Reliable Ator.

  • A desativação da política de backup para um serviço interrompe todos os backups periódicos de dados como resultado da propagação dessa política de backup para as partições do serviço.

  • A desativação da política de backup para uma partição interrompe todo o backup periódico de dados devido à política de backup na partição.

  • Ao desativar o backup para uma entidade (aplicativo/serviço/partição), CleanBackup pode ser definido como true para excluir todos os backups no armazenamento configurado.

    {
        "CleanBackup": true 
    }
    

Nota

Verifique se não há atualizações de aplicativos em andamento antes de desabilitar o backup

Suspender ou retomar backup

Certas situações podem exigir a suspensão temporária do backup periódico de dados. Nessas situações, dependendo do requisito, a API de backup de suspensão pode ser usada em um Aplicativo, Serviço ou Partição. A suspensão periódica de backup é transitiva sobre a subárvore da hierarquia do aplicativo a partir do ponto em que é aplicada.

  • Quando a suspensão é aplicada em um aplicativo usando a API de backup de aplicativo de suspensão, todos os serviços e partições sob esse aplicativo são suspensos para backup periódico de dados.

  • Quando a suspensão é aplicada em um serviço usando a API de backup de serviço de suspensão, todas as partições sob esse serviço são suspensas para backup periódico de dados.

  • Quando a suspensão é aplicada em uma partição usando a API de backup de partição de suspensão, as partições sob este serviço são suspensas para backup periódico de dados.

Uma vez terminada a necessidade de suspensão, o backup periódico de dados pode ser restaurado usando a respetiva API de backup de retomada. O backup periódico deve ser retomado no mesmo aplicativo, serviço ou partição em que foi suspenso.

  • Se a suspensão foi aplicada em um aplicativo, ela deve ser retomada usando a API de backup de aplicativo de retomada .

  • Se a suspensão foi aplicada em um Serviço, ela deve ser retomada usando a API de Backup do Serviço de Retomada.

  • Se a suspensão foi aplicada em uma partição, ela deve ser retomada usando a API de backup de partição retomada.

Diferença entre suspender e desativar backups

A desativação do backup deve ser usada quando os backups não forem mais necessários para um determinado aplicativo, serviço ou partição. Pode-se invocar desativar a solicitação de backup juntamente com o parâmetro de backups limpos para ser verdadeiro, o que significaria que todos os backups existentes também são excluídos. No entanto, a suspensão deve ser usada em cenários em que se deseja desativar backups temporariamente, como quando o disco local fica cheio ou o upload do backup está falhando devido a um problema de rede conhecido, etc.

Embora a desativação possa ser invocada apenas em um nível, que anteriormente foi habilitado para backup explicitamente, no entanto, a suspensão pode ser aplicada em qualquer nível, que atualmente está habilitado para backup diretamente ou por meio de herança/hierarquia. Por exemplo, se o backup estiver habilitado em um nível de aplicativo, pode-se invocar desabilitar somente no nível do aplicativo, no entanto, a suspensão pode ser invocada no aplicativo, em qualquer serviço ou partição nesse aplicativo.

Restauração automática em caso de perda de dados

A partição de serviço pode perder dados devido a falhas inesperadas. Por exemplo, o disco de duas das três réplicas de uma partição (incluindo a réplica primária) é corrompido ou apagado.

Quando o Service Fabric deteta que a partição está em perda de dados, ele invoca OnDataLossAsync o método de interface na partição e espera que a partição execute a ação necessária para sair da perda de dados. Nessa situação, se a política de backup eficaz na partição tiver AutoRestoreOnDataLoss o sinalizador definido para true que a restauração seja acionada automaticamente usando o backup mais recente disponível para essa partição.

Nota

Recomenda-se NÃO definir a Restauração Automática em clusters de produção

Obter configuração de backup

APIs separadas são disponibilizadas para obter informações de configuração de backup em um escopo de aplicativo, serviço e partição . Obter Informações de Configuração de Backup de Aplicativos, Obter Informações de Configuração de Backup de Serviço e Obter Informações de Configuração de Backup de Partição são essas APIs, respectivamente. Principalmente, essas APIs retornam a política de backup aplicável, o escopo no qual a política de backup é aplicada e os detalhes da suspensão de backup. A seguir está uma breve descrição sobre os resultados retornados dessas APIs.

  • Informações de configuração de backup de aplicativos: fornece os detalhes da política de backup aplicada no aplicativo e todas as políticas substituídas em serviços e partições pertencentes ao aplicativo. Ele também inclui as informações de suspensão para o aplicativo e seus serviços, e partições.

  • Informações de configuração de backup de serviço: fornece os detalhes da política de backup eficaz em serviço e o escopo no qual essa política foi aplicada e todas as políticas substituídas em suas partições. Ele também inclui as informações de suspensão para o serviço e suas divisórias.

  • Informações de configuração de backup de partição: fornece os detalhes da política de backup eficaz na partição e o escopo no qual essa política foi aplicada. Ele também inclui as informações de suspensão para as partições.

Listar backups disponíveis

Os backups disponíveis podem ser listados usando a API Get Backup List. O resultado da chamada de API inclui itens de informações de backup relacionados a todos os backups disponíveis no armazenamento de backup, que é configurado na política de backup aplicável. Diferentes variantes dessa API são fornecidas para listar backups disponíveis pertencentes a um aplicativo, serviço ou partição. Essas APIs suportam a obtenção do backup mais recente disponível de todas as partições aplicáveis ou a filtragem de backups com base na data de início e na data de término.

Essas APIs também oferecem suporte à paginação dos resultados, quando o parâmetro MaxResults é definido como inteiro positivo diferente de zero, em seguida, a API retorna o máximo de itens de informações de backup MaxResults . No caso, há mais itens de informações de backup disponíveis do que o valor MaxResults , um token de continuação é retornado. O parâmetro de token de continuação válido pode ser usado para obter o próximo conjunto de resultados. Quando o valor do token de continuação válido é passado para a próxima chamada da API, a API retorna o próximo conjunto de resultados. Nenhum token de continuação é incluído na resposta quando todos os resultados disponíveis são retornados.

Seguem-se breves informações sobre as variantes suportadas.

  • Obter lista de backup de aplicativos: retorna uma lista de backups disponíveis para cada partição pertencente a determinado aplicativo do Service Fabric.

  • Obter lista de backup de serviço: retorna uma lista de backups disponíveis para cada partição pertencente a determinado serviço do Service Fabric.

  • Obter lista de backup de partição: retorna uma lista de backups disponíveis para a partição especificada.

Próximos passos