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

  • Artigo

A configuração do backup periódico dos seus serviços com estado confiáveis ou Reliable Actors é composto pelas 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. Habilitação do backup: nesta etapa, você associará políticas de backup criadas na Etapa 1 às entidades necessárias, Aplicativo, Serviço ou uma Partição.

Criar Política de Backup

Uma política de backup é composta pelas seguintes configurações:

  • Restauração automática na perda de dados: especifica se você deve disparar a restauração automaticamente usando o último backup disponível caso a partição passe por um evento de perda de dados.

Observação

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

  • Máx. de backups incrementais: define o número máximo de backups incrementais a serem executados entre dois backups completos. O máximo de backups incrementais especifica o limite superior. Um backup completo pode ser executado antes que um número especificado de backups incrementais seja concluído em uma das seguintes condições

    1. A réplica nunca executou um backup completo desde que se tornou primária.

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

    3. A réplica passou do limite MaxAccumulatedBackupLogSizeInMB.

  • Agendamento de backup: o tempo ou a frequência em que se executa backups periódicos. É possível agendar backups para serem recorrentes e um intervalo especificado ou a uma hora fixa diária/semanalmente.

    1. Agendamento de backup baseado em frequência: esse tipo de agendamento deverá ser usado se for necessário executar backup de dados em intervalos fixos. O intervalo de tempo desejado entre dois backups consecutivos é definido usando o formato ISO8601. O agendamento de backup baseado em frequência é compatível com a resolução de intervalo ao minuto.

      {
    "ScheduleKind": "FrequencyBased",
    "Interval": "PT10M"
}

    2. Agendamento de backup baseado em tempo: esse tipo de agendamento deverá ser usado se for necessário executar backup de dados em horários específicos do dia ou semana. O tipo de frequência do agendamento pode ser diário ou semanal.

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

        {
    "ScheduleKind": "TimeBased",
    "ScheduleFrequencyType": "Daily",
    "RunTimes": [
      "0001-01-01T09:00:00Z",
      "0001-01-01T18:00:00Z"
    ]
}

      2. Agendamento de backup baseado em tempo semanal: esse tipo de agendamento deverá ser usado se for necessário executar backup de dados em horários específicos do dia. Para especificar isso, defina ScheduleFrequencyType como Semanal; e defina RunDays como a lista de dias em uma semana quando o backup precisa ser disparado e RunTimes como a lista de horários desejados durante o dia no formato ISO8601, a data especificada junto com a hora será ignorada. Lista de dias de uma semana quando disparar o backup periódico. O exemplo abaixo ilustra a configuração para disparar um backup diário às 9h e às 18h 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 o armazenamento de blobs do Azure ou o compartilhamento de arquivos.

    1. Armazenamento de blobs do Azure: esse tipo de armazenamento deve ser selecionado quando a necessidade é armazenar backups gerados no Azure. Os clusters autônomos e baseados no Azure podem usar esse tipo de armazenamento. Uma descrição para esse tipo de armazenamento requer uma cadeia de conexão e um nome do contêiner, em que 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": "BackupContainer"
}

      Observação

      O serviço de restauração de backup não funciona com armazenamento do Azure v1

    2. Compartilhamento de arquivos: esse tipo de armazenamento deverá ser selecionado para os clusters autônomos quando houver a necessidade de armazenar backup de dados localmente. Uma descrição desse tipo de armazenamento requer um caminho de compartilhamento de arquivos para o qual 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 que pertencem ao cluster do Service Fabric. Nesse caso, defina os campos a seguir para configurar o armazenamento de backup baseado no compartilhamento de arquivos.

        {
    "StorageKind": "FileShare",
    "FriendlyName": "Sample_FileShare",
    "Path": "\\\\StorageServer\\BackupStore"
}

      2. Proteção do compartilhamento de arquivos usando o nome do usuário e senha, em que o acesso ao compartilhamento de arquivos é fornecido a usuários específicos. A especificação do armazenamento do compartilhamento de arquivos também oferece a capacidade de especificar um nome do usuário e senha secundários para fornecer credenciais de fallback caso a autenticação falhe com o nome do usuário e senha primários. Nesse caso, defina os campos a seguir para configurar o armazenamento de backup baseado no compartilhamento de arquivos.

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

Observação

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

  • Política de retenção: especifica a política para reter os backups no armazenamento configurado. Há suporte para a Política de Retenção Básica.

    1. Política de retenção básica: essa política de retenção permite garantir a utilização de armazenamento ideal, removendo arquivos de backup que não são mais necessários. RetentionDuration pode ser especificado para definir o período de tempo para os quais backups são necessários para ser mantidos no armazenamento. MinimumNumberOfBackups é um parâmetro opcional que pode ser especificado para certificar-se de que o número especificado de backups é sempre retido independentemente de RetentionDuration. O exemplo abaixo ilustra a configuração para manter os backups para 10 dias e não permite que o número de backups caia para baixo de 20.

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

Habilitar backup periódico

Após definir a política de backup para atender aos requisitos de backup de dados, a política de backup deverá ser devidamente associada a um aplicativo ou a um serviço ou a uma partição.

Observação

Verificar se não há atualizações de aplicativo 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 no Modelo de aplicativo. A política de backup pode ser associada a um aplicativo, serviço ou uma partição na hierarquia. A política de backup propaga-se hierarquicamente até o próximo nível. Supondo que haja apenas uma política de backup criada e associada a um aplicativo, o backup de todas as partições com estado que pertencem a todos os serviços com estado confiáveis e Reliable Actors do aplicativo será realizado usando a política de backup. Ou, se a política de backup estiver associada a um Serviço com estado confiável, o backup de todas as suas partições será realizado 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 é necessário para todos os serviços do aplicativo, exceto para os serviços específicos em que há a necessidade de ter um backup de dados usando o agendamento de frequência maior ou colocando o backup em uma conta de armazenamento ou compartilhamento de arquivos diferente. Para resolver esses cenários, o serviço de restauração de backup facilita a substituição da política propagada no escopo do serviço e da partição. Quando a política de backup está associada no serviço ou na partição, ela substitui a política de backup propagada, se houver.

Exemplo

Este exemplo usa uma configuração com dois aplicativos, MyApp_A e MyApp_B. O aplicativo MyApp_A contém dois Serviços com estado confiáveis, SvcA1 e SvcA3 e um único serviço de Ator Confiável, ActorA2. SvcA1 contém três partições, enquanto ActorA2 e SvcA3 contêm, cada um, duas partições. O aplicativo MyApp_B contém três serviços com estado confiáveis, SvcB1, SvcB2 e SvcB3. SvcB1 e SvcB2 contêm duas partições cada um, 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 um backup diário dos dados para todas as partições de todos os Serviços com estado confiáveis e Reliable Actors pertencentes ao aplicativo. Carregue os dados de backup para o local BackupStore1.

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

    3. O tamanho dos dados na partição SvcA1_P2 é maior do que o esperado, e seus dados de backup devem ser armazenados em um local de armazenamento diferente BackupStore2.

  2. MyApp_B

    1. Crie um backup dos dados todo domingo às 8h para todas as partições do serviço SvcB1. Carregue os dados de backup para o local BackupStore1.

    2. Crie um backup dos dados todos os dias às 8h para a partição SvcB2_P1. Carregue os dados de backup para o local BackupStore1.

Para abordar esses requisitos de backup de dados, as políticas de backup BP_1 até 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 o agendamento de backup baseado em frequência, em que a frequência é definida como 24 horas e o armazenamento de backup é configurado para usar o local de armazenamento BackupStore1. Habilite essa política para o aplicativo MyApp_A usando a API Habilitar o backup do aplicativo. Essa ação permite o backup de dados usando a política de backup BP_1 para todas as partições de serviços com estado confiáveis e Reliable Actors pertencentes ao aplicativo MyApp_A.

    2. Crie uma política de backup, BP_2, com o agendamento de backup baseado em frequência, em que a frequência é definida como 1 hora e o armazenamento de backup é configurado para usar o local de armazenamento BackupStore1. Habilite essa política para o serviço SvcA3 usando a API Habilitar o backup do serviço. Essa ação substitui a política BP_1 propagada ao habilitar explicitamente a política de backup BP_2 para todas as partições do serviço SvcA3, levando a um backup de dados usando a política de backup BP_2 para essas partições.

    3. Crie uma política de backup, BP_3, com o agendamento de backup baseado em frequência, em que a frequência é definida como 24 horas e o armazenamento de backup é configurado para usar o local de armazenamento BackupStore2. Habilite essa política para a partição SvcA1_P2 usando a API Habilitar backup de partição. Essa ação substitui a política BP_1 propagada ao habilitar explicitamente a política de backup BP_3 para a partição SvcA1_P2.

  2. MyApp_B

    1. Crie uma política de backup, BP_4, com um agendamento de backup baseado em horário, em que o tipo de frequência do agendamento é definido como semanal, os dias de execução são definidos como domingo e os horários de execução são definidos como 8h. O armazenamento de backup é configurado para usar o local de armazenamento BackupStore1. Habilite essa política para o serviço SvcB1 usando a API Habilitar o backup do serviço. Essa ação habilita o backup de dados usando a política de backup BP_4 para todas as partições do serviço SvcB1.

    2. Crie uma política de backup, BP_5, com um agendamento de backup baseado em horário, em que o tipo de frequência do agendamento é definido como diário e os horários de execução são definidos como 8h. O armazenamento de backup é configurado para usar o local de armazenamento BackupStore1. Habilite essa política para a partição SvcB2_P1 usando a API Habilitar backup de partição. Essa ação habilita o backup de dados usando a política de backup BP_5 para a partição SvcB2_P1.

Seguir o diagrama descreve as políticas de backup explicitamente habilitadas e as políticas de backup propagadas.

Service Fabric Application Hierarchy

Desabilitar o backup

As políticas de backup poderão ser desabilitadas quando não houver necessidade de realizar backup de dados. A política de backup habilitada em um aplicativo só poderá ser desabilitada no mesmo aplicativo usando a API Desabilitar backup de aplicativos, a política de backup habilitada em um serviço poderá ser desabilitada no mesmo serviço usando a API Desabilitar backup de serviços e a política de backup habilitada em uma partição poderá ser desabilitada na mesma partição usando a API Desabilitar backup de partições.

  • Desabilitar a política de backup para um aplicativo interrompe todos os backups periódicos de dados que ocorrem em decorrência da propagação da política de backup para as partições do serviço com estado confiável ou as partições do Reliable Actor.

  • Desabilitar a política de backup para um serviço interrompe todos os backups periódicos de dados que ocorrem em decorrência da propagação dessa política de backup para as partições do serviço.

  • Desabilitar a política de backup para uma partição interrompe todos os backups periódicos de dados que acontecem devido à política de backup na partição.

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

    {
    "CleanBackup": true 
}

Observação

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

Suspender e retomar o backup

Uma determinada situação pode demandar a suspensão temporária do backup periódico de dados. Nessa situação, dependendo do requisito, a suspensão da API de backup pode ser usada em um aplicativo, em um serviço ou em uma partição. A suspensão do backup periódico é transitiva na subárvore da hierarquia do aplicativo do ponto em que é aplicada.

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

  • Quando a suspensão é aplicada em um serviço usando a API Suspender o backup do serviço, então todas as partições nesse serviço são suspensas para o backup periódico dos dados.

  • Quando a suspensão é aplicada em uma partição usando a API Suspender o backup da partição, então as partições nesse serviço são suspensas para o backup periódico dos dados.

Depois que a necessidade de suspensão tiver acabado, então o backup periódico dos dados poderá ser restaurado usando a respectiva API retomar backup. O backup periódico deve ser retomado no mesmo aplicativo, serviços ou partição em que ele foi suspenso.

Diferença entre Suspender e Desabilitar backups

Desabilitar backup deve ser usado quando os backups não forem mais necessários para um aplicativo, serviço ou partição específico. É possível invocar a solicitação de desabilitação de backup junto com o parâmetro de limpeza de backups como verdadeiro, o que significa que todos os backups existentes também são excluídos. No entanto, a solicitação suspender deve ser usada em cenários em que pretende-se desativar os backups temporariamente, por exemplo, quando o disco local fica cheio ou o upload de backup está falhando devido a um problema de rede conhecido, etc.

Embora a desabilitação possa ser invocada apenas em um nível no qual tenha sido anteriormente habilitada de forma explícita para backup, a suspensão poderá ser aplicada em qualquer nível no qual esteja atualmente habilitada para backup diretamente ou por meio de herança/hierarquia. Por exemplo, se o backup estiver habilitado em um nível de aplicativo, será possível invocar apenas desabilitar no nível do aplicativo, no entanto, a solicitação suspender poderá ser invocada no aplicativo em qualquer serviço ou partição sob esse aplicativo.

Restauração automática em perda de dados

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

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

Observação

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

Obter configuração de backup

As APIs separadas são disponibilizadas para obter informações de configuração de backup em um escopo do aplicativo, do serviço e da partição. Obter informações de configuração de backup de aplicativo, 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, escopo no qual a política de backup é aplicada e a suspensão de backup é detalhada. A seguir, há uma breve descrição sobre os resultados retornados dessas APIs.

  • Informações de configuração de backup de aplicativo: fornece os detalhes da política de backup aplicada em aplicativo e todas as políticas substituídas em serviços e partições pertencentes ao aplicativo. Elas também incluem as informações de suspensão do 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 em vigor em serviço e o escopo no qual essa política foi aplicada e todas as política substituídas em suas partições. Elas também incluem as informações de suspensão para o serviço e suas partições.

  • Informações de configuração de backup de partição: fornece os detalhes da política de backup em vigor em partição e o escopo no qual essa política foi aplicada. Elas também incluem as informações de suspensão das partições.

Listar backups disponíveis

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

Essas APIs também são compatíveis com a paginação dos resultados, quando o parâmetro MaxResults é definido como inteiro positivo diferente de zero; então, a API retorna o máximo de itens de informações de backup de MaxResults. No caso, há mais itens de informações de backup disponíveis do que o valor MaxResults; em seguida, um token de continuação é retornado. O parâmetro do 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 for passado para a próxima chamada da API, ela retornará o próximo conjunto de resultados. Nenhum token de continuação é incluído na resposta quando todos os resultados disponíveis são retornados.

A seguir, há informações breves sobre as variantes com suporte.

Próximas etapas