Condividi tramite

Informazioni sulla configurazione del backup periodico in Azure Service Fabric

  • Articolo

La configurazione del backup periodico dei servizi Reliable con stato o dei Reliable Actors è costituita dai passaggi seguenti:

  1. Creazione di criteri di backup: in questo passaggio vengono creati uno o più criteri di backup a seconda dei requisiti.

  2. Abilitazione del backup: in questo passaggio si associano i criteri di backup creati nel passaggio 1 alle entità richieste, applicazione, servizio o partizione.

Crea criterio di backup

Un criterio di backup è costituito dalle configurazioni seguenti:

  • Ripristino automatico in caso di perdita di dati: specifica se attivare il ripristino automaticamente usando il backup disponibile più recente nel caso in cui la partizione subisca un evento di perdita di dati.

Nota

È consigliabile NON impostare il ripristino automatico nei cluster di produzione

  • Numero massimo di backup incrementali: definisce il numero massimo di backup incrementali da eseguire tra due backup completi. Max incremental backups (N. massimo di backup incrementali) specifica il limite massimo. Un backup completo può essere eseguito prima del raggiungimento del numero di backup incrementali specificato se si verifica una delle situazioni seguenti:

    1. La replica non ha mai eseguito un backup completo dopo essere diventata primaria.

    2. Alcuni record di log successivi all'ultimo backup sono stati troncati.

    3. La replica ha superato il limite specificato in MaxAccumulatedBackupLogSizeInMB.

  • Pianificazione del backup: l'ora o la frequenza con cui eseguire backup periodici. È possibile pianificare l'esecuzione di backup a intervalli specificati o con un orario fisso ogni giorno o ogni settimana.

    1. Pianificazione dei backup basata sulla frequenza: questo tipo di pianificazione deve essere usato se è necessario eseguire il backup dei dati a intervalli fissi. L'intervallo di tempo desiderato tra due backup successivi può essere definito usando il formato ISO 8601. La pianificazione backup basata sulla frequenza supporta la risoluzione di intervalli fino a un minuto.

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

    2. Pianificazione del backup basata sul tempo: questo tipo di pianificazione deve essere usato se è necessario eseguire il backup dei dati in orari specifici del giorno o della settimana. Il tipo di frequenza di pianificazione può essere giornaliero o settimanale.

      1. Pianificazione dei backup basata sull'ora giornaliera: questo tipo di pianificazione deve essere usato se è necessario eseguire il backup dei dati in orari specifici del giorno. Per specificare questo, impostare ScheduleFrequencyType su Giornaliero; e impostare RunTimes su un elenco degli orari desiderati durante il giorno nel formato ISO8601, la data specificata insieme all'ora verrà ignorata. Ad esempio, 0001-01-01T18:00:00 rappresenta 6:00 PM ogni giorno, ignorando la parte della data 0001-01-01. L'esempio seguente illustra la configurazione per attivare il backup giornaliero alle 9:00 e alle 16:00 ogni giorno.

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

      2. Pianificazione del backup settimanale basata sull'ora: questo tipo di pianificazione deve essere usato se è necessario eseguire il backup dei dati in orari specifici del giorno. Per specificare questo valore, impostare su ScheduleFrequencyTypeSettimanale. Impostare su RunDays Elenco di giorni in una settimana in cui è necessario attivare il backup e impostare RunTimes l'elenco dell'ora desiderata durante il giorno nel formato ISO8601, la data specificata insieme all'ora verrà ignorata. Elenco dei giorni della settimana in cui attivare il backup periodico. Nell'esempio seguente viene illustrata la configurazione per attivare il backup giornaliero alle 9:00 e alle 18:00 durante lunedì e venerdì.

        {
    "ScheduleKind": "TimeBased",
    "ScheduleFrequencyType": "Weekly",
    "RunDays": [
       "Monday",
       "Tuesday",
       "Wednesday",
       "Thursday",
       "Friday"
    ],
    "RunTimes": [
      "0001-01-01T09:00:00Z",
      "0001-01-01T18:00:00Z"
    ]
}

  • Archiviazione di backup: specifica il percorso in cui caricare i backup. La destinazione di archiviazione può essere l'archivio BLOB di Azure o una condivisione di file.

    1. Archivio BLOB di Azure con identità gestita: questo tipo di archiviazione deve essere selezionato quando è necessario archiviare i backup generati in Azure. Sia i cluster autonomi che i cluster basati sul cloud possono usare questo tipo di archiviazione. La descrizione di questo tipo di archiviazione richiede il parametro BlobServiceUri e il nome del contenitore in cui devono essere caricati i backup. Se il contenitore con il nome specificato non è disponibile, viene creato durante il caricamento di un backup. Sostituire account-name con il nome dell'account di archiviazione.

      {
    "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>" 
}

      [NOTA] Usare il parametro facoltativo ManagedIdentityClientId con l'ID client dell'identità gestita assegnata dall'utente in caso in cui alla risorsa siano state assegnate più identità gestite assegnate dall'utente o siano presenti identità gestite assegnate sia dal sistema che dall’utente e per impostazione predefinita sia necessario usare l’identità gestita assegnata dall'utente. In caso contrario, è possibile ignorare questo parametro.

      Seguire la procedura per l'assegnazione di identità gestite in una risorsa di Azure:

      1. Abilitare l'identità gestita assegnata dal sistema o dall'utente nel set di scalabilità di macchine virtuali Configurare identità gestite nel set di scalabilità di macchine virtuali

      2. Assegnare il ruolo all'identità gestita del set di scalabilità di macchine virtuali all'account di archiviazione seguendo le istruzioni che iniziano nel passaggio due di Assegnare ruoli di Azure usando il portale di Azure - Controllo degli accessi in base al ruolo di Azure

        • Ruoli minimi: collaboratore per l'account di archiviazione, collaboratore ai dati BLOB di archiviazione e collaboratore ai dati della tabella di archiviazione

      Per altre informazioni sull'identità gestita

    2. Archivio BLOB di Azure con ConnectionString: questo tipo di archiviazione deve essere selezionato quando è necessario archiviare i backup generati in Azure. Sia i cluster autonomi che i cluster basati sul cloud possono usare questo tipo di archiviazione. La descrizione di questo tipo di archiviazione richiede la stringa di connessione e il nome del contenitore in cui devono essere caricati i backup. Se il contenitore con il nome specificato non è disponibile, viene creato durante il caricamento di un backup.

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

      Nota

      Il servizio di backup/ripristino non funziona con ConnectionString di Archiviazione di Azure v1 e non è consigliato nell'ambiente di produzione perché si accede direttamente alla risorsa senza autenticazione utente

    3. Condivisione file: questo tipo di archiviazione deve essere selezionato per i cluster autonomi quando è necessario archiviare il backup dei dati in locale. La descrizione di questo tipo di archiviazione richiede il percorso di condivisione file in cui devono essere caricati i backup. L'accesso alla condivisione file può essere configurato usando una delle seguenti opzioni

      1. Autenticazione integrata di Windows, in cui l'accesso alla condivisione file viene fornito a tutti i computer appartenenti al cluster di Service Fabric. In questo caso, impostare i campi seguenti per configurare l'archiviazione di backup basata su condivisione file .

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

      2. Protezione della condivisione file tramite nome utente e password, in cui l'accesso alla condivisione file viene fornito a utenti specifici. La specifica di archiviazione basata sulla condivisione file consente anche di specificare un nome utente secondario e una password secondaria come credenziali di fallback, nel caso in cui l'autenticazione con il nome utente primario e la password primaria abbia esito negativo. In questo caso, impostare i campi seguenti per configurare l'archiviazione di backup basata su condivisione file .

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

Nota

Verificare che l'affidabilità di archiviazione soddisfi o superi i requisiti di affidabilità dei dati di backup.

  • Criteri di conservazione: specifica i criteri per conservare i backup nella risorsa di archiviazione configurata. Sono supportati solo i criteri di conservazione di base.

    1. Criteri di conservazione di base: questo criterio di conservazione consente di garantire un utilizzo ottimale dell'archiviazione rimuovendo i file di backup, che non sono più necessari. Specificare RetentionDuration per impostare l'intervallo di tempo in cui i backup devono essere conservati nella risorsa di archiviazione. MinimumNumberOfBackups è un parametro facoltativo che può essere specificato per assicurarsi che venga sempre mantenuto il numero specificato di backup indipendentemente da RetentionDuration. L'esempio seguente illustra la configurazione per conservare i backup per 10 giorni e non consente il numero di backup al di sotto di 20.

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

Abilitare il backup periodico

Dopo aver definito i criteri di backup per soddisfare i requisiti di backup dei dati, i criteri di backup devono essere associati in modo appropriato a un'applicazione o a un servizio o a una partizione.

Nota

Prima di abilitare il backup, assicurarsi che non siano in corso aggiornamenti dell'applicazione

Propagazione gerarchica dei criteri di backup

In Service Fabric la relazione tra applicazioni, servizi e partizioni è gerarchica come illustrato in Modello di applicazione. I criteri di backup possono essere associati a un'applicazione, a un servizio o a una partizione nella gerarchia. I criteri di backup si propagano gerarchicamente al livello successivo. Supponendo che esista solo una politica di backup creata e associata a un'applicazione, tutte le partizioni stateful appartenenti a tutti i servizi stateful Reliable e Reliable Actorsdell'applicazione vengono sottoposte a backup usando la politica di backup. In alternativa, se i criteri di backup sono associati a un Reliable Stateful Service, viene eseguito il backup di tutte le partizioni usando i criteri di backup.

Override dei criteri di backup

In un determinato scenario è possibile che il backup dei dati con la stessa pianificazione sia idoneo per tutti i servizi dell'applicazione ad eccezione di servizi specifici, che richiedono ad esempio una pianificazione più frequente o un backup in un account di archiviazione o una condivisione di file diversa. Per la risoluzione di queste situazioni, il servizio di ripristino del backup dispone di un'opzione per eseguire l'override del criterio propagato a livello del servizio e della partizione. Quando i criteri di backup sono associati al servizio o alla partizione, esegue l'override dei criteri di backup propagati, se presenti.

Esempio

In questo esempio viene usata la configurazione con due applicazioni, MyApp_A e MyApp_B. L'applicazione MyApp_A contiene due servizi Reliable Stateful, SvcA1 & SvcA3 e un servizio Reliable Actor, ActorA2. SvcA1 contiene tre partizioni, mentre ActorA2 e SvcA3 contengono due partizioni ognuna. L'applicazione MyApp_B contiene tre servizi Reliable Stateful, SvcB1, SvcB2 e SvcB3. _SvcB1 e SvcB2 contengono due partizioni ognuna, mentre SvcB3 contiene tre partizioni.

Si supponga che i requisiti di backup dei dati di queste applicazioni siano i seguenti

  1. MyApp_A

    1. Creare il backup giornaliero dei dati per tutte le partizioni di tutti i servizi Reliable con stato stabile e Reliable Actors appartenenti all'applicazione. Caricare i dati di backup nel percorso BackupStore1.

    2. Uno dei servizi SvcA3 richiede il backup dei dati ogni ora.

    3. Le dimensioni dei dati nella SvcA1_P2 di partizione sono maggiori del previsto e i relativi dati di backup devono essere archiviati in un percorso di archiviazione diverso BackupStore2.

  2. MyApp_B

    1. Creare il backup dei dati ogni domenica alle 8:00 per tutte le partizioni del servizio SvcB1 . Caricare i dati di backup nel percorso BackupStore1.

    2. Creare il backup dei dati ogni giorno alle 8:00 per la partizione SvcB2_P1. Caricare i dati di backup nel percorso BackupStore1.

Per soddisfare questi requisiti di backup dei dati, vengono creati i criteri di backup da BP_1 a BP_5 e il backup viene implementato come indicato di seguito.

  1. MyApp_A

    1. Creare una politica di backup, BP_1, con una pianificazione dei backup basata sulla frequenza, in cui la frequenza è impostata su 24 ore. e archiviazione del backup configurata per l'uso della posizione di archiviazione BackupStore1. Abilita questo criterio per l'applicazione MyApp_A usando l'API Abilita il backup dell'applicazione. Questa azione abilita il backup dei dati usando il criterio di backup BP_1 per tutte le partizioni di servizi Reliable Stateful e Reliable Actors appartenenti all'applicazione MyApp_A.

    2. Creare un criterio di backup BP_2 con pianificazione del backup basata sulla frequenza in cui la frequenza è impostata su 1 ora. e archiviazione del backup configurata per l'uso della posizione di archiviazione BackupStore1. Abilitare questo criterio per il servizio SvcA3 usando l'API Abilita backup del servizio . Questa azione esegue l'override dei criteri propagati BP_1 abilitando in modo esplicito i criteri di backup BP_2 per tutte le partizioni del servizio SvcA3 che portano al backup dei dati usando i criteri di backup BP_2 per queste partizioni.

    3. Creare un criterio di backup BP_3 con pianificazione del backup basata sulla frequenza in cui la frequenza è impostata su 24 ore. e archiviazione del backup configurata per l'uso della posizione di archiviazione BackupStore2. Abilitare questo criterio per la partizione SvcA1_P2 usando l'API Abilita backup partizione. Questa azione annulla i criteri propagati BP_1 abilitando esplicitamente i criteri di backup BP_3 per la partizione SvcA1_P2.

  2. MyApp_B

    1. Creare il criterio di backup BP_4 con pianificazione di backup basata sul tempo in cui il tipo di frequenza di pianificazione è impostato su settimanale, il giorno di esecuzione è impostato sulla domenica e l'ora di esecuzione è impostata sulle 8:00. Archivio di backup configurato per l'uso della posizione di archiviazione BackupStore1. Abilitare questo criterio per il servizio SvcB1 usando l'API Abilita backup del servizio . Questa azione abilita il backup dei dati usando i criteri di backup BP_4 per tutte le partizioni del servizio SvcB1.

    2. Creare il criterio di backup BP_5 con pianificazione di backup basata sul tempo in cui il tipo di frequenza di pianificazione è impostato su giornaliera, il giorno di esecuzione è impostato sulla domenica e l'ora di esecuzione è impostata sulle 8:00. Archivio di backup configurato per l'uso della posizione di archiviazione BackupStore1. Abilita questo criterio per la partizione SvcB2_P1 utilizzando l'API Enable Partition Backup. Questa azione abilita il backup dei dati usando i criteri di backup BP_5 per SvcB2_P1 di partizione.

Il diagramma seguente visualizza i criteri di backup abilitati in modo esplicito e i criteri di backup propagati.

Gerarchia di applicazioni di Service Fabric

Disabilitare il backup

È possibile disabilitare i criteri di backup quando non è necessario eseguire il backup dei dati. I criteri di backup abilitati in un'applicazione possono essere disabilitati solo nella stessa applicazione usando l'API Disabilita Backup Applicazione, i criteri di backup abilitati in un servizio possono essere disabilitati nello stesso servizio usando l'API Disable Service Backup, e i criteri di backup abilitati in una partizione possono essere disabilitati nella stessa partizione usando l'API Disabilita Backup Partizione.

  • La disabilitazione dei criteri di backup per un'applicazione arresta tutti i backup periodici dei dati in seguito alla propagazione dei criteri di backup in partizioni del servizio Reliable Stateful o Reliable Actor.

  • La disabilitazione dei criteri di backup per un servizio arresta tutti i backup periodici dei dati in seguito alla propagazione di questo criterio di backup alle partizioni del servizio.

  • La disabilitazione dei criteri di backup per una partizione arresta tutti i backup periodici dei dati a causa dei criteri di backup nella partizione.

  • Durante la disabilitazione del backup per un'entità (application/service/partition), CleanBackup può essere impostata su true per eliminare tutti i backup nella risorsa di archiviazione configurata.

    {
    "CleanBackup": true 
}

Nota

Prima di disabilitare il backup, assicurarsi che non siano in corso aggiornamenti dell'applicazione

Sospendere e riprendere il backup

In determinati casi può risultare necessario sospendere temporaneamente il backup periodico dei dati. In tali situazioni, a seconda del requisito, è possibile usare l'API di backup sospesa in un'applicazione, un servizio o una partizione. La sospensione del backup periodico è transitiva per il sottoalbero della gerarchia dell'applicazione dal punto in cui viene applicata.

  • Quando la sospensione viene applicata a un'applicazione tramite l'API Sospendi backup applicazioni , tutti i servizi e le partizioni in questa applicazione vengono sospesi per il backup periodico dei dati.

  • Quando la sospensione viene applicata a un servizio tramite l'API Sospendi backup del servizio , tutte le partizioni in questo servizio vengono sospese per il backup periodico dei dati.

  • Quando la sospensione viene applicata in una partizione usando l'API Suspend Partition Backup, il backup periodico dei dati in questo servizio viene sospeso per il backup periodico dei dati.

Quando la sospensione non è più necessaria è possibile ripristinare il backup periodico dei dati usando le rispettive API di ripresa del backup. Il backup periodico deve essere ripreso con la stessa applicazione, servizio o partizione in cui è stata sospesa.

Differenza tra sospensione e disabilitazione dei backup

È opportuno usare la funzionalità di disabilitazione dei backup quando i backup non sono più necessari per un'applicazione, un servizio o una partizione specifica. È possibile anche richiamare una richiesta di disabilitazione dei backup insieme al parametro di pulizia dei backup per essere certi che vengano eliminati anche tutti i backup esistenti. È opportuno invece usare la funzionalità di sospensione nei casi in cui si intende disattivare temporaneamente i backup, ad esempio quando il disco locale è pieno o il caricamento di una copia di backup non riesce a causa di un problema di rete e così via.

Mentre la disabilitazione può essere richiamata solo a un livello precedentemente abilitato in modo esplicito per il backup, la sospensione può essere applicata a qualsiasi livello attualmente abilitato per il backup, direttamente o tramite ereditarietà/gerarchia. Se, ad esempio, il backup viene abilitato al livello di un'applicazione, è possibile richiamare la disabilitazione solo al livello dell'applicazione, mentre la sospensione può essere richiamata anche per qualsiasi servizio o partizione presente nell'applicazione.

Ripristino automatico in caso di perdita di dati

La partizione del servizio potrebbe perdere dati a causa di errori imprevisti. Ad esempio, il disco per due su tre repliche per una partizione, inclusa la replica primaria, viene danneggiato o cancellato.

Quando Service Fabric rileva che nella partizione si verifica la perdita di dati, chiama il metodo di interfaccia OnDataLossAsync per la partizione e prevede che la partizione esegua l'azione necessaria per bloccare la perdita di dati. In questa situazione, se il flag AutoRestoreOnDataLoss del criterio di backup in vigore nella partizione è impostato su true il ripristino viene attivato automaticamente usando il backup disponibile più recente per la partizione.

Nota

È consigliabile NON impostare il ripristino automatico nei cluster di produzione

Ottenere la configurazione del backup

Le API separate vengono rese disponibili per ottenere informazioni di configurazione del backup in un'applicazione, un servizio e un ambito di partizione . Ottenere le informazioni di configurazione del backup dell'applicazione, ottenere informazioni di configurazione del backup del servizio e ottenere le informazioni di configurazione del backup della partizione sono rispettivamente queste API. In generale queste API restituiscono il criterio di backup applicabile, l'ambito di applicazione del criterio e i dettagli della sospensione del backup. Segue una breve descrizione dei risultati restituiti da queste API.

  • Informazioni sulla configurazione del backup di un’applicazione: vengono specificati i dettagli dei criteri di backup applicati all'applicazione e di tutti i criteri sottoposti a override nei servizi e nelle partizioni appartenenti all'applicazione. Sono incluse anche informazioni di sospensione per l'applicazione e i servizi e le partizioni corrispondenti.

  • Informazioni sulla configurazione del backup di un servizio: vengono specificati i dettagli dei criteri di backup in vigore nel servizio, l'ambito in cui i criteri sono stati applicati e tutti i criteri sottoposti a override nelle partizioni del servizio. Include anche le informazioni di sospensione per il servizio e le relative partizioni.

  • Get Partition Backup Configuration Info: specifica i dettagli del criterio di backup in vigore nella partizione e l'ambito in cui il criterio è stato applicato. Include anche le informazioni di sospensione per le partizioni.

Elencare i backup disponibili

È possibile elencare i backup disponibili tramite l'API Get Backup List. La chiamata dell'API restituisce informazioni su tutti i backup disponibili nell'archivio di backup, configurato nei criteri di backup applicabili. Sono disponibili diverse varianti dell'API, che consentono di elencare i backup disponibili appartenenti a un'applicazione, un servizio o una partizione. Queste API supportano il recupero dell'ultimo backup disponibile di tutte le partizioni applicabili o il filtro dei backup in base alla data di inizio e alla data di fine.

Queste API supportano anche l'impaginazione dei risultati, quando il parametro MaxResults è impostato su integer diverso da zero, l'API restituisce gli elementi di informazioni di backup maxResults massimi. Nel caso in cui siano disponibili più elementi di informazioni di backup rispetto al valore MaxResults , viene restituito un token di continuazione. Il parametro del token di continuazione valido può essere usato per ottenere il set di risultati successivo. Quando il valore del token di continuazione valido viene passato alla chiamata successiva dell'API, l'API restituisce il set di risultati successivo. Se vengono restituiti tutti i risultati disponibili, la risposta non include un token di continuazione.

Di seguito sono elencate informazioni concise sulle varianti supportate.

Passaggi successivi