Compréhension de la configuration de la sauvegarde périodique dans Azure Service Fabric

  • Article

La configuration de la sauvegarde périodique de vos Services fiables avec état ou Reliable Actors comprend les étapes suivantes :

  1. Création des stratégies de sauvegarde : dans cette étape, une ou plusieurs stratégies de sauvegarde sont créées en fonction des besoins.

  2. Activation de la sauvegarde : dans cette étape, vous associez les stratégies de sauvegarde créées à l’étape 1 aux entités requises : une application, un service ou une partition.

Créer la stratégie de sauvegarde

Une stratégie de sauvegarde se compose des configurations suivantes :

  • Restauration automatique en cas de perte de données : spécifie s’il faut déclencher la restauration automatiquement à l’aide de la dernière sauvegarde disponible si la partition subit une perte de données.

Notes

Il est recommandé de ne PAS définir la restauration automatique dans les clusters de production

  • Nombre maximal de sauvegardes incrémentielles : définit le nombre maximal de sauvegardes incrémentielles à effectuer entre deux sauvegardes complètes. Le nombre maximal de sauvegardes incrémentielles spécifie la limite supérieure. Une sauvegarde complète peut-être effectuée avant que le nombre spécifié de sauvegardes incrémentielles soit atteint dans l’une des situations suivantes

    1. Le réplica n’a jamais fait l’objet d’une sauvegarde complète depuis qu’il est devenu principal.

    2. Certains enregistrements du journal écrits depuis la dernière sauvegarde ont été tronqués.

    3. Le réplica a dépassé la limite MaxAccumulatedBackupLogSizeInMB.

  • Planification de la sauvegarde : heure ou fréquence auxquelles effectuer les sauvegardes périodiques. Il est possible de planifier des sauvegardes périodiques à intervalles définis ou à heure fixe chaque jour ou semaine.

    1. Planification de sauvegarde basée sur la fréquence : ce type de planification doit être utilisé si les sauvegardes doivent être effectuées à intervalles fixes. L’intervalle de temps souhaité entre deux sauvegardes consécutives est défini à l’aide du format ISO8601. La planification de sauvegarde basée sur la fréquence prend en charge une résolution d’intervalle à la minute.

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

    2. Planification de sauvegarde basée sur l’heure : ce type de planification doit être utilisé si les sauvegardes doivent être effectuées à des heures spécifiques dans la journée ou la semaine. La fréquence de planification peut être quotidienne ou hebdomadaire.

      1. Quotidienne Planification de sauvegarde basée sur l’heure : ce type de planification doit être utilisé si les sauvegardes doivent être effectuées à des heures spécifiques de la journée. Pour spécifier cela, définissez ScheduleFrequencyType sur Quotidienne, et RunTimes sur la liste des heures souhaitées pendant la journée au format ISO8601. La date spécifiée avec les heures sera ignorée. Par exemple, 0001-01-01T18:00:00 indique 06:00 chaque jour, en ignorant la partie date 01-01-0001. L’exemple ci-dessous illustre la configuration pour déclencher une sauvegarde quotidienne à 09:00 et à 18:00.

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

      2. Hebdomadaire Planification de sauvegarde basée sur l’heure : ce type de planification doit être utilisé si les sauvegardes doivent être effectuées à des heures spécifiques de la journée. Pour spécifier cela, définissez ScheduleFrequencyType sur Hebdomadaire, et RunDays sur la liste des jours de la semaine durant lesquels une sauvegarde doit être déclenchée, et RunTimes sur la liste des heures souhaitées pendant la journée au format ISO8601. La date spécifiée avec les heures sera ignorée. Liste des jours de la semaine durant lesquels déclencher la sauvegarde périodique. L’exemple ci-dessous illustre la configuration pour déclencher une sauvegarde quotidienne à 09:00 et à 18:00, du lundi au vendredi.

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

  • Stockage de sauvegarde : spécifie l’emplacement où charger les sauvegardes. Le stockage peut être un stockage d’objets blob Azure ou un partage de fichiers.

    1. Stockage Blob Azure : ce type de stockage doit être sélectionné si les sauvegardes générées dans Azure doivent être stockées. Des clusters autonomes et basés sur Azure peuvent utiliser ce type de stockage. La description de ce type de stockage nécessite une chaîne de connexion et le nom du conteneur dans lequel les sauvegardes doivent être chargées. Si le conteneur du nom spécifié n’est pas disponible, il est créé lors du chargement de la sauvegarde.

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

      Notes

      Le service de sauvegarde et de restauration ne fonctionne pas avec Stockage Azure v1.

    2. Partage de fichiers : ce type de stockage doit être sélectionné pour les clusters autonomes si la sauvegarde de données doit être stockée localement. La description de ce type de stockage requiert la spécification du chemin du partage de fichiers dans lequel les sauvegardes doivent être chargées. L’accès au partage de fichiers peut être configuré à l’aide d’une des options suivantes

      1. Authentification Windows intégrée : le partage de fichiers est accessible à tous les ordinateurs appartenant au cluster Service Fabric. Dans ce cas, définissez les champs suivants pour configurer un stockage de sauvegarde basé sur un partage de fichiers.

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

      2. Protection du partage de fichiers à l’aide d’un nom d’utilisateur et d’un mot de passe : le partage de fichiers est accessible à des utilisateurs spécifiques. La spécification du stockage du partage de fichiers offre également la possibilité de spécifier un nom d’utilisateur et un mot de passe secondaires pour fournir des informations d’identification de secours en cas d’échec de l’authentification avec le nom d’utilisateur et le mot de passe principaux. Dans ce cas, définissez les champs suivants pour configurer un stockage de sauvegarde basé sur un partage de fichiers.

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

Notes

Assurez-vous que la fiabilité du stockage correspond au minimum aux exigences de fiabilité des données de sauvegarde.

  • Stratégie de conservation : spécifie la stratégie permettant de conserver les sauvegardes dans le stockage configuré. Seule la stratégie de conservation de base est prise en charge.

    1. Stratégie de conservation de base : cette stratégie de conservation permet de garantir une utilisation optimale du stockage en supprimant les fichiers de sauvegarde qui ne sont plus obligatoires. RetentionDuration peut être spécifié pour définir l’intervalle de temps pendant lequel les sauvegardes doivent être conservées dans le stockage. MinimumNumberOfBackups est un paramètre facultatif qui peut être spécifié pour vous assurer que le nombre spécifié de sauvegardes sont toujours conservées, indépendamment de RetentionDuration. L’exemple ci-dessous illustre la configuration de la conservation des sauvegardes pendant 10 jours et n’autorise pas le nombre de sauvegardes à descendre en dessous de 20.

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

Activer la sauvegarde périodique

Après définition d’une stratégie de sauvegarde répondant aux exigences de sauvegarde de données, cette stratégie doit être correctement associée à une application, à un service ou à une partition.

Notes

Assurez-vous qu’aucune mise à niveau d’application n’est en cours avant d’activer la sauvegarde.

Propagation hiérarchique de la stratégie de sauvegarde

Dans Service Fabric, la relation entre l’application, le service et les partitions est hiérarchique, comme expliqué dans Modèle d’application. Une stratégie de sauvegarde peut être associée à une application, à un service, ou à une partition dans la hiérarchie. La stratégie de sauvegarde se propage de façon hiérarchique au niveau suivant. En supposant qu’il n’y ait qu’une seule stratégie de sauvegarde créée et associée à une application, toutes les partitions avec état appartenant à tous les Services fiables avec état et Reliable Actors de l’application seront sauvegardées à l’aide de la stratégie de sauvegarde. Ou bien, si la stratégie de sauvegarde est associée à un Service fiable avec état, toutes ses partitions seront sauvegardées à l’aide de la stratégie de sauvegarde.

Remplacement de stratégie de sauvegarde

Il peut y avoir un scénario où une sauvegarde de données avec la même planification de sauvegarde est requise pour tous les services de l’application, à l’exception de services spécifiques où il est nécessaire de disposer d’une sauvegarde de données utilisant une planification de fréquence supérieure, ou d’effectuer la sauvegarde vers un compte de stockage ou un partage de fichiers différents. Pour ces scénarios, le service de sauvegarde/restauration offre la possibilité de remplacer la stratégie propagée au niveau d’un service et d’une partition. Quand la stratégie de sauvegarde est associée à un service ou à une partition, elle remplace une éventuelle stratégie de sauvegarde propagée.

Exemple

Cet exemple utilise une configuration avec deux applications, MyApp_A et MyApp_B. L’application MyApp_A contient deux services fiables avec état, SvcA1 et SvcA3, et un service Reliable Actor, ActorA2. Le service SvcA1 contient trois partitions, tandis que les services ActorA2 et SvcA3 contiennent chacun deux partitions. L’application MyApp_B contient trois services fiables avec état, SvcB1, SvcB2, et SvcB3. Les services SvcB1 et SvcB2 contiennent chacun deux partitions, tandis que le service SvcB3 en contient trois.

Supposons que les exigences de sauvegarde de données de ces applications sont les suivantes

  1. MyApp_A

    1. Créer une sauvegarde quotidienne des données de toutes les partitions de tous les Services fiables avec état et Reliable Actors appartenant à l’application. Charger les données de sauvegarde dans l’emplacement BackupStore1.

    2. L’un des services, SvcA3, nécessite une sauvegarde de données toutes les heures.

    3. La taille des données de la partition SvcA1_P2 est plus importante que prévu, et ses données de sauvegarde doivent être stockées dans un autre emplacement de stockage, BackupStore2.

  2. MyApp_B

    1. Créer une sauvegarde des données de toutes les partitions du service SvcB1 chaque dimanche à 8 h 00. Charger les données de sauvegarde dans l’emplacement BackupStore1.

    2. Créer une sauvegarde des données de la partition SvcB2_P1 chaque jour à 8 h 00. Charger les données de sauvegarde dans l’emplacement BackupStore1.

Pour répondre à ces exigences de sauvegarde de données, des stratégies de sauvegarde BP_1 à BP_5 sont créées, et la sauvegarde est activée comme suit.

  1. MyApp_A

    1. Créer une stratégie de sauvegarde, BP_1, avec une planification de sauvegarde basée sur la fréquence, où la fréquence est définie sur 24 h. Le stockage de sauvegarde est configuré pour utiliser l’emplacement de stockage BackupStore1. Activer cette stratégie pour l’application MyApp_A à l’aide de l’API Activer la sauvegarde de l’application. Cette action active la sauvegarde de données à l’aide de la stratégie de sauvegarde BP_1 pour toutes les partitions de Services fiables avec état et de Reliable Actors appartenant à l’application MyApp_A.

    2. Créer une stratégie de sauvegarde, BP_2, avec une planification de sauvegarde basée sur la fréquence, où la fréquence est définie sur 1 h. Le stockage de sauvegarde est configuré pour utiliser l’emplacement de stockage BackupStore1. Activer cette stratégie pour le service SvcA3 à l’aide de l’API Activer la sauvegarde du service. Cette action remplace la stratégie propagée BP_1 par la stratégie de sauvegarde explicitement activée BP_2 pour toutes les partitions du service SvcA3, ce qui amène la sauvegarde de données à utiliser la stratégie de sauvegarde BP_2 pour ces partitions.

    3. Créer une stratégie de sauvegarde, BP_3, avec une planification de sauvegarde basée sur la fréquence, où la fréquence est définie sur 24 h. Le stockage de sauvegarde est configuré pour utiliser l’emplacement de stockage BackupStore2. Activer cette stratégie pour la partition SvcA1_P2 à l’aide de L’API Activer la sauvegarde de la partition. Cette action remplace la stratégie propagée BP_1 par la stratégie de sauvegarde explicitement activée BP_3 pour la partition SvcA1_P2.

  2. MyApp_B

    1. Créer une stratégie de sauvegarde, BP_4, avec une planification de sauvegarde basée sur l’heure, où le type de fréquence de planification est défini sur hebdomadaire, le jour d’exécution défini sur dimanche, et l’heure d’exécution définie sur 8 h 00. Le stockage de sauvegarde est configuré pour utiliser l’emplacement de stockage BackupStore1. Activer cette stratégie pour le service SvcB1 à l’aide de l’API Activer la sauvegarde du service. Cette action active la sauvegarde de données à l’aide de la stratégie de sauvegarde BP_4 pour toutes les partitions du service SvcB1.

    2. Créer une stratégie de sauvegarde, BP_5, avec une planification de sauvegarde basée sur l’heure, où le type de fréquence de planification est défini sur quotidien, et l’heure d’exécution définie sur 8 h 00. Le stockage de sauvegarde est configuré pour utiliser l’emplacement de stockage BackupStore1. Activer cette stratégie pour la partition SvcB2_P1 à l’aide de L’API Activer la sauvegarde de la partition. Cette action active la sauvegarde de données à l’aide de la stratégie de sauvegarde BP_5 pour la partition SvcB2_P1.

Le diagramme suivant illustre explicitement les stratégies de sauvegarde activées et les stratégies de sauvegarde propagées.

Service Fabric Application Hierarchy

Désactiver la sauvegarde

Les stratégies de sauvegarde peuvent être désactivées quand il n’est pas nécessaire de sauvegarder des données. Une stratégie de sauvegarde activée au niveau d’une application ne peut être désactivée que pour cette application à l’aide de l’API Désactiver la sauvegarde de l’application. Une stratégie de sauvegarde activée au niveau d’un service ne peut être désactivée que pour ce service à l’aide de l’API Désactiver la sauvegarde du service. Et une stratégie de sauvegarde activée au niveau d’une partition ne peut être désactivée que pour cette partition à l’aide de l’API Désactiver la sauvegarde de la partition.

  • La désactivation d’une stratégie de sauvegarde pour une application arrête toutes les sauvegardes périodiques de données qui se produisent en raison de la propagation de la stratégie de sauvegarde aux partitions de service avec état fiable ou aux partitions Reliable Actor.

  • La désactivation d’une stratégie de sauvegarde pour un service arrête toutes les sauvegardes périodiques de données qui se produisent en raison de la propagation de cette stratégie de sauvegarde aux partitions du service.

  • La désactivation d’une stratégie de sauvegarde pour une partition arrête toute sauvegarde périodique des données se produisant en raison de la stratégie de sauvegarde définie au niveau de la partition.

  • Lors de la désactivation de la sauvegarde d’une entité (application/service/partition), CleanBackup peut être défini sur true pour supprimer toutes les sauvegardes dans le stockage configuré.

    {
    "CleanBackup": true 
}

Notes

Assurez-vous qu’aucune mise à niveau d’application n’est en cours avant de désactiver la sauvegarde.

Suspendre et reprendre une sauvegarde

Certaines situations peuvent exiger une suspension temporaire de la sauvegarde périodique des données. Dans ce cas, selon l’exigence, l’API Suspendre la sauvegarde peut être utilisée au niveau d’une application, d’un service ou d’une partition. La suspension d’une sauvegarde périodique est transitive vers la sous-arborescence de la hiérarchie de l’application à partir du point où elle est appliquée.

  • Lorsque la suspension est appliquée à une application à l’aide de l’API Suspendre la sauvegarde de l’application, la sauvegarde périodique des données est suspendue pour l’ensemble des services et partitions sous cette application.

  • Lorsque la suspension est appliquée à un service à l’aide de l’API Suspendre la sauvegarde du service, la sauvegarde périodique des données est suspendue pour toutes les partitions sous ce service.

  • Lorsque la suspension est appliquée à une partition à l’aide de l’API Suspendre la sauvegarde de la partition, la sauvegarde périodique des données est suspendue cette partition.

Une fois la nécessité de suspension passée, la sauvegarde périodique des données peut être restaurée à l’aide de l’API Reprendre la sauvegarde appropriée. La sauvegarde périodique doit être reprise au même niveau d’application, de service ou de partition que celui auquel elle a été suspendue.

Différence entre la suspension et la désactivation des sauvegardes

Vous ne devriez désactiver les sauvegardes que lorsqu’elles ne sont plus nécessaires pour une application, un service ou une partition spécifiques. Il est en fait possible de demander la désactivation de la sauvegarde avec le paramètre de nettoyage des sauvegardes, ce qui a pour effet de supprimer également toutes les sauvegardes existantes. Il convient cependant de recourir à une suspension quand on souhaite désactiver temporairement les sauvegardes, par exemple, quand le disque local est saturé ou lorsque le chargement de la sauvegarde échoue en raison d’un problème réseau connu.

Si une désactivation peut être demandée uniquement à un niveau précédemment activé explicitement pour la sauvegarde, une suspension peut être appliquée à tout niveau actuellement activé pour la sauvegarde, directement ou par voie d'héritage ou de hiérarchie. Par exemple, si la sauvegarde est activée au niveau d’une application, il est possible de demander la désactivation uniquement au niveau de l’application. En revanche, la suspension peut être demandée au niveau d’une application, d’un service ou d’une partition sous cette application.

Restauration automatique en cas de perte de données

Une partition de service peut perdre des données en raison de défaillances inattendues. Par exemple, le disque de deux réplicas sur trois pour une partition (y compris le réplica principal) est endommagé ou effacé.

Quand Service Fabric détecte que la partition perd des données, il appelle la méthode d’interface OnDataLossAsync sur la partition, et attend que la partition effectue l’action requise pour sortir de la perte de données. Dans ce cas, si la stratégie de sauvegarde effective au niveau la partition a l’indicateur AutoRestoreOnDataLoss défini sur true, la restauration est déclenchée automatiquement à l’aide de la dernière sauvegarde disponible pour cette partition.

Notes

Il est recommandé de ne PAS définir la restauration automatique dans les clusters de production

Obtenir la configuration de la sauvegarde

Des API distinctes sont disponibles pour obtenir des informations sur la configuration de la sauvegarde au niveau d’une application, d’un service et d’une partition. Ces API sont respectivement Obtenir les informations sur la configuration de la sauvegarde de l’application, Obtenir les informations sur la configuration de la sauvegarde du service et Obtenir les informations sur la configuration de la sauvegarde de la partition. Essentiellement, ces API retournent la stratégie de sauvegarde applicable, le niveau auquel la stratégie de sauvegarde est appliquée, et des détails sur la suspension de la sauvegarde. Voici une brève description des résultats retournés par ces API.

  • Informations sur la configuration de la sauvegarde de l’application : fournissent les détails de la stratégie de sauvegarde appliquée au niveau de l’application, et toutes les stratégies remplacées au niveau des services et partitions appartenant à l’application. Ces résultats incluent également les informations de suspension de l’application ainsi que de ses services et partitions.

  • Informations sur la configuration de la sauvegarde du service : fournissent les détails de la stratégie de sauvegarde effective du service, l’étendue d’application de cette stratégie et toutes les stratégies remplacées au niveau de ses partitions. Ces résultats incluent également les informations de suspension du service et de ses partitions.

  • Informations sur la configuration de la sauvegarde de la partition : fournissent les détails de la stratégie de sauvegarde effective de la partition, et l’étendue d’application de cette stratégie. Ces résultats incluent également les informations de suspension des partitions.

Répertorier les sauvegardes disponibles

Les sauvegardes disponibles peuvent être répertoriées à l’aide de l’API Obtenir la liste des sauvegardes. Le résultat de l’appel de l’API inclut des éléments d’informations sur la sauvegarde, liés à toutes les sauvegardes disponibles sur le stockage de sauvegarde configuré dans la stratégie de sauvegarde applicable. Différentes variantes de cette API sont fournies pour répertorier les sauvegardes disponibles appartenant à une application, à un service ou à une partition. Ces API prennent en charge l’obtention de la dernière sauvegarde disponible de toutes les partitions applicables, ainsi que le filtrage des sauvegardes en fonction de la date de début et de la date de fin.

Ces API prennent également en charge la pagination des résultats. Quand le paramètre MaxResults est défini sur un entier positif différent de zéro, l’API retourne les éléments d’informations sur la sauvegarde MaxResults. Il peut arriver que des éléments d’informations sur la sauvegarde autres que la valeur MaxResults soient disponibles. Un jeton de continuation est alors renvoyé. Un paramètre de jeton de continuation valide peut être utilisé pour obtenir le jeu de résultats suivant. Quand une valeur de jeton de continuation valide est transmise à l’appel suivant de l’API, celle-ci retourne le jeu de résultats suivant. Quand tous les résultats disponibles ont été retournés, aucun jeton de continuation n’est inclus dans la réponse.

Voici de brèves informations sur les variantes prises en charge.

Étapes suivantes