La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

La solution NetApp

Contributeurs

Vous pouvez utiliser la technologie NetApp Snapshot de Azure NetApp Files pour créer des sauvegardes de bases de données en quelques secondes. Le temps nécessaire à la création d’une copie Snapshot ne dépend pas de la taille de la base de données, car cette copie ne déplace aucun bloc de données sur la plateforme de stockage. De plus, cette technologie n’a aucune incidence sur les performances du système SAP en direct. Par conséquent, vous pouvez planifier la création de copies Snapshot sans tenir compte des périodes de pointe de dialogue ou d’activité de lots. Les clients SAP sur Azure NetApp Files programmons généralement plusieurs sauvegardes Snapshot en ligne pendant la journée, par exemple, toutes les quatre heures sont courantes. Ces sauvegardes Snapshot sont généralement conservées pendant trois à cinq jours sur le système de stockage principal, avant d’être supprimées.

Les copies Snapshot offrent également des avantages clés pour les opérations de restauration et de reprise. Grâce à une opération de restauration de volume, la restauration de l’intégralité d’une base de données est effectuée à n’importe quel point dans le temps, en fonction des copies Snapshot disponibles. Ce processus ne dure que quelques secondes, quelle que soit la taille de la base de données. Comme plusieurs sauvegardes Snapshot en ligne sont créées pendant la journée, le temps nécessaire au processus de restauration est considérablement réduit par rapport à une approche de sauvegarde traditionnelle. Étant donné qu’une opération de restauration peut être effectuée avec une copie Snapshot antérieure (au lieu de 24 heures), il faut appliquer moins de journaux de transaction. Par conséquent, le RTO est réduit à plusieurs minutes, au lieu de plusieurs heures requises pour les sauvegardes conventionnelles à un cycle unique.

Les sauvegardes de copie Snapshot sont stockées sur le même système de disque que les données en ligne actives. Par conséquent, NetApp recommande d’utiliser les sauvegardes de copies Snapshot comme supplément plutôt que comme remplacement des sauvegardes sur un emplacement secondaire. La plupart des actions de restauration et de restauration sont gérées par une opération de restauration de volume sur le système de stockage primaire. Les restaurations depuis un emplacement secondaire sont uniquement nécessaires si le système de stockage primaire contenant les copies Snapshot est endommagé. Vous pouvez utiliser l’emplacement secondaire si vous devez restaurer une sauvegarde qui n’est plus disponible à partir d’une copie Snapshot.

Vous pouvez sauvegarder vos données dans un emplacement secondaire à l’aide de sauvegardes supplémentaires basées sur des fichiers HANA. Ces sauvegardes basées sur des fichiers peuvent être planifiées à une fréquence beaucoup plus basse, avec donc un impact moindre sur les performances du système de production.

Lorsque la réplication entre régions Azure NetApp Files est utilisée pour la reprise après incident, toutes les sauvegardes Snapshot sont également répliquées sur le site de reprise après incident, puis disponibles sous forme de sauvegarde secondaire déchargée. Voir aussi "Tr-4891 : reprise après incident de SAP HANA avec Azure NetApp Files".

Vous pouvez également décharger des copies Snapshot pour la conservation à long terme vers le stockage Azure Blob via l’outil Azure AzCopy. Cela nécessite des scripts supplémentaires en dehors du service SnapCenter.

La figure suivante présente un exemple de configuration de protection des données utilisant les sauvegardes Snapshot et les sauvegardes basées sur des fichiers.

Erreur : image graphique manquante

Exécution des sauvegardes Snapshot

La figure suivante présente une capture d’écran de l’environnement HANA d’un client exécutant SAP HANA sur un système de stockage NetApp. Le client utilise des copies NetApp Snapshot pour sauvegarder la base de données HANA. Comme le montre la figure, la base de données HANA (environ 2,3 To) est sauvegardée en 2 minutes et 11 secondes à l’aide de la technologie de sauvegarde Snapshot.

La majeure partie du temps d’exécution global du workflow de sauvegarde est le temps nécessaire pour exécuter le point de sauvegarde HANA, cette étape dépend de la charge exercée sur la base de données HANA. La sauvegarde Snapshot de stockage elle-même s’effectue toujours en quelques secondes.

Erreur : image graphique manquante

Comparaison des objectifs de délai de restauration

Cette section présente une comparaison RTO des sauvegardes Snapshot basées sur les fichiers et le stockage. Le RTO est défini par la somme du temps nécessaire à la restauration de la base de données, ainsi que du temps nécessaire au démarrage et à la restauration de cette base de données.

Temps nécessaire pour restaurer la base de données

Avec une sauvegarde basée sur des fichiers, le temps de restauration dépend de la taille de l’infrastructure de base de données et de sauvegarde, ce qui définit la vitesse de restauration en mégaoctets par seconde (Mbit/s). Par exemple, si l’infrastructure prend en charge une opération de restauration à une vitesse de 250 Mo, il faut environ 1 heure et 10 minutes pour restaurer une base de données de 1 To.

Avec les sauvegardes de copie Snapshot du stockage, le temps de restauration ne dépend pas de la taille de la base de données et se situe dans une plage de quelques secondes lorsque vous pouvez effectuer la restauration à partir du stockage primaire. Une restauration à partir d’une sauvegarde basée sur des fichiers n’est nécessaire qu’en cas d’incident lorsque le stockage primaire n’est plus disponible.

Temps nécessaire au démarrage de la base de données

L’heure de début de la base de données dépend de la taille du magasin de lignes et de colonnes. Pour le magasin de colonnes, l’heure de début dépend également de la quantité de données préchargées lors du démarrage de la base de données. Dans les exemples suivants, nous supposons que l’heure de début est de 30 minutes. L’heure de début est identique pour une restauration et une restauration basées sur des fichiers, ainsi qu’une restauration et une restauration basées sur des copies Snapshot.

Temps nécessaire pour restaurer la base de données

La durée de restauration dépend du nombre de journaux qui doivent être appliqués après la restauration. Ce nombre est déterminé par la fréquence à laquelle les sauvegardes de données sont effectuées.

Avec les sauvegardes de données basées sur des fichiers, la planification des sauvegardes est généralement une fois par jour. Une fréquence de sauvegarde plus élevée n’est généralement pas possible car la sauvegarde dégrade les performances de production. Par conséquent, dans le pire des cas, tous les journaux qui ont été écrits pendant la journée doivent être appliqués lors de la récupération avant.

Les sauvegardes de données de copie Snapshot du stockage sont généralement planifiées à une fréquence plus élevée, car elles n’influencent pas les performances de la base de données SAP HANA. Par exemple, si des sauvegardes de copies Snapshot sont planifiées toutes les six heures, la durée de restauration est, dans le pire des cas, un quart de la durée de restauration d’une sauvegarde basée sur des fichiers (6 heures / 24 heures = 1/4).

La figure suivante représente un exemple de RTO pour une base de données de 1 To lorsque des sauvegardes de données basées sur des fichiers sont utilisées. Dans cet exemple, une sauvegarde est effectuée une fois par jour. L’objectif RTO diffère selon le moment où la restauration et la restauration ont été effectuées. Si la restauration et la restauration ont été effectuées immédiatement après la sauvegarde, le RTO se base principalement sur la durée de restauration, qui est de 1 heure et 10 minutes dans l’exemple. La durée de restauration a été augmentée à 2 heures et 50 minutes lorsque la restauration et la restauration ont été effectuées immédiatement avant la prochaine sauvegarde, et le RTO maximal était de 4 heures et 30 minutes.

Erreur : image graphique manquante

La figure suivante montre un exemple de RTO pour une base de données de 1 To lorsque des sauvegardes Snapshot sont utilisées. Avec les sauvegardes Snapshot basées sur le stockage, le RTO ne dépend que des temps de démarrage de la base de données et du délai de restauration suivant, car la restauration s’effectue en quelques secondes, quelle que soit la taille de la base de données. Le temps de restauration par progression augmente également en fonction de la durée de la restauration et de la restauration, mais étant donné la fréquence plus élevée des sauvegardes (toutes les 6 heures dans cet exemple), le temps de restauration par progression est de 43 minutes au maximum. Dans cet exemple, le RTO maximal est de 1 heure et 13 minutes.

Erreur : image graphique manquante

La figure ci-dessous présente une comparaison RTO des sauvegardes Snapshot basées sur les fichiers et le stockage pour différentes tailles de bases de données et fréquences de sauvegardes Snapshot. La barre verte indique la sauvegarde basée sur des fichiers. Les autres barres affichent les sauvegardes de copies Snapshot avec différentes fréquences de sauvegarde.

Avec une seule sauvegarde de données à copie Snapshot par jour, le RTO est déjà réduit de 40 % par rapport à une sauvegarde de données basée sur des fichiers. La réduction augmente à 70 % lorsque quatre sauvegardes Snapshot sont effectuées par jour. La figure montre également qu’elle n’a pas de courbe, si la fréquence des sauvegardes Snapshot augmente, elle passe à plus de quatre à six sauvegardes Snapshot par jour. Nos clients configurent donc généralement entre quatre et six sauvegardes Snapshot par jour.

Erreur : image graphique manquante

Ce graphique indique la taille de la RAM du serveur HANA. La taille de la base de données en mémoire est calculée comme étant égale à la moitié de la taille de la mémoire vive du serveur.

Le délai de restauration et de récupération est calculé sur la base des hypothèses suivantes : la base de données peut être restaurée à 250 Mbit/s ; le nombre de fichiers journaux par jour est de 50 % de la taille de la base de données (par exemple, une base de données de 1 To crée 500 Mo de fichiers journaux par jour) ; Par contre, une restauration peut être effectuée à 100 Mbit/s.