La figure suivante illustre la vue logique de la communication entre le serveur SnapCenter , la base de données SAP HANA et le système de stockage. Le serveur SnapCenter utilise les plug-ins HANA et Linux pour communiquer avec la base de données HANA et les systèmes d'exploitation Linux.

L'option de déploiement recommandée et par défaut pour les plug-ins SnapCenter est l'installation sur l'hôte de la base de données HANA. Avec cette option de déploiement, toutes les configurations et fonctionnalités décrites dans le chapitre « Configuration prise en charge par SnapCenter » sont valides. Il existe quelques exceptions où les plug-ins SnapCenter ne peuvent pas être installés sur l'hôte de la base de données HANA mais doivent être configurés sur un hôte de plug-ins central, qui peut être le serveur SnapCenter lui-même. Un hôte de plug-in central est requis pour les systèmes HANA à hôtes multiples ou les systèmes HANA exécutés sur la plateforme IBM Power. Les deux options de déploiement peuvent également être combinées, par exemple en utilisant le serveur SnapCenter comme hôte de plug-ins central pour un système multi-hôtes et en déployant les plug-ins sur les hôtes de base de données HANA pour tous les autres systèmes HANA mono-hôte.

Dans SnapCenter , une ressource HANA peut être détectée automatiquement ou configurée manuellement. Un système HANA est automatiquement détecté par défaut dès que les plugins HANA et Linux sont déployés sur l'hôte de la base de données. La détection automatique de SnapCenter ne prend pas en charge plusieurs installations HANA sur le même hôte. Les systèmes HANA gérés à l'aide d'un hôte de plug-in central doivent être configurés manuellement dans SnapCenter. De plus, les volumes non liés aux données sont par défaut des ressources configurées manuellement.

Bien que SnapCenter prenne en charge le déploiement centralisé de plug-ins pour les systèmes HANA, il existe des limitations en matière de prise en charge des plateformes et des fonctionnalités. Les configurations et opérations d'infrastructure suivantes ne sont pas prises en charge pour les systèmes HANA configurés avec un hôte de plug-in central :

SAP recommande d'inclure des contrôles réguliers de cohérence des blocs HANA dans la stratégie de sauvegarde globale. Avec les sauvegardes traditionnelles basées sur des fichiers, cette vérification est effectuée à chaque opération de sauvegarde. Avec les sauvegardes par instantané, le contrôle de cohérence doit être exécuté en plus des opérations de sauvegarde par instantané, par exemple une fois par semaine.

Techniquement, il existe deux options pour exécuter le contrôle de cohérence des blocs.

L'outil hdbpersdiag de HANA fait partie de l'installation de HANA et permet d'exécuter des opérations de vérification de cohérence des blocs sur une base de données HANA hors ligne. Il est donc parfaitement adapté à une utilisation conjointe avec les sauvegardes Snapshot, où les sauvegardes Snapshot existantes peuvent être présentées à hdbpersdiag.

En comparant les deux approches, hdbpersdiag présente des avantages significatifs par rapport à la sauvegarde basée sur des fichiers pour les contrôles de cohérence des blocs HANA. L'une des dimensions est la capacité de stockage requise. Dans le cas des sauvegardes basées sur des fichiers, il est nécessaire de disposer d'au moins la taille d'une sauvegarde pour chaque système HANA. Si vous avez, par exemple, 15 systèmes HANA avec une taille de persistance de 3 To, vous aurez besoin de 45 To supplémentaires rien que pour les contrôles de cohérence. Avec hdbpersdiag, aucune capacité de stockage supplémentaire n'est requise puisque l'opération est exécutée sur une sauvegarde Snapshot existante ou sur un FlexClone d'une sauvegarde Snapshot existante. La deuxième dimension est la charge du processeur sur l'hôte HANA pendant l'opération de vérification de cohérence. Une sauvegarde basée sur des fichiers nécessitera des cycles CPU sur l'hôte de la base de données HANA, tandis que le traitement hdbpersdiag peut être entièrement déchargé de l'hôte HANA lorsqu'il est utilisé en combinaison avec un hôte de vérification central. Le tableau ci-dessous résume les principales caractéristiques.

NetApp recommande d'utiliser hdbpersdiag pour exécuter des contrôles de cohérence des blocs HANA. Des détails supplémentaires sur la mise en œuvre sont disponibles dans le chapitre "Contrôles de cohérence des blocs avec SnapCenter".

Avant de configurer SnapCenter et le plug-in SAP HANA, la stratégie de protection des données doit être définie en fonction des exigences RTO et RPO des divers systèmes SAP.

Une approche commune consiste à définir des types de systèmes tels que la production, le développement, les tests ou les systèmes sandbox. Tous les systèmes SAP d'un même type de système ont généralement les mêmes paramètres de protection des données.

Les paramètres à définir sont les suivants :

Le tableau suivant présente un exemple de paramètres de protection des données pour les types de systèmes production, développement et test. Pour le système de production, une fréquence de sauvegarde élevée a été définie, et les sauvegardes sont répliquées sur un site de sauvegarde secondaire une fois par jour. Les systèmes de test ont des exigences moindres et aucune réplication des sauvegardes.

Le tableau suivant présente les politiques et les calendriers qui devraient être configurés pour les paramètres de protection des données ci-dessus.

Le schéma ci-dessous récapitule les calendriers et les durées de conservation des sauvegardes. Si SnapCenter est utilisé pour gérer la conservation des sauvegardes de journaux, toutes les sauvegardes de journaux plus anciennes que la sauvegarde Snapshot la plus ancienne seront supprimées. Autrement dit, les sauvegardes des journaux sont conservées aussi longtemps que nécessaire pour permettre une restauration à jour pour chaque sauvegarde disponible.

Lorsque le chiffrement persistant HANA est utilisé, il est essentiel de créer des sauvegardes des clés racine en plus des sauvegardes de données standard. Des sauvegardes de la clé racine sont nécessaires pour récupérer la base de données HANA en cas de perte du volume de données et du système de fichiers d'installation HANA. Pour plus d'informations, consultez "Guide d'administration de SAP HANA".

SnapCenter prend en charge les opérations de sauvegarde par instantané des systèmes HANA MDC avec un ou plusieurs locataires. SnapCenter prend également en charge deux opérations de restauration différentes d'un système HANA MDC. Vous pouvez soit restaurer l'intégralité du système, la base de données système et tous les locataires, soit restaurer un seul locataire. Certaines conditions préalables sont nécessaires pour permettre à SnapCenter d'exécuter ces opérations.

Dans un système MDC, la configuration du locataire n'est pas nécessairement statique. Des locataires peuvent être ajoutés ou supprimés. SnapCenter ne peut pas se fier à la configuration découverte lors de l'ajout de la base de données HANA à SnapCenter. Pour permettre une opération de restauration d'un seul locataire, SnapCenter doit savoir quels locataires sont inclus dans chaque sauvegarde Snapshot. De plus, il doit savoir quels fichiers et répertoires appartiennent à chaque locataire inclus dans la sauvegarde Snapshot.

Par conséquent, à chaque opération de sauvegarde, SnapCenter identifie les informations du locataire. Cela inclut les noms des locataires et les informations correspondantes sur les fichiers et les répertoires. Ces données doivent être stockées dans les métadonnées de sauvegarde Snapshot pour pouvoir prendre en charge une opération de restauration mono-locataire.

Une autre étape de la découverte automatique de l'application consiste à détecter le nœud principal ou secondaire de la réplication du système HANA (HSR). Si un système HANA est configuré avec HSR, SnapCenter doit identifier le nœud principal lors de chaque opération de sauvegarde afin que les commandes SQL de sauvegarde soient exécutées sur le nœud principal HSR. Voir aussi "Réplication système SAP HANA : sauvegarde et restauration avec SnapCenter".

SnapCenter détecte également la configuration du volume de données HANA et la mappe aux ressources du système de fichiers et de stockage. Grâce à cette approche, SnapCenter peut gérer les modifications de configuration des volumes HANA, par exemple les partitions multiples ou les modifications de configuration de stockage telles que les migrations de volumes.

L'étape suivante consiste en l'opération de sauvegarde par instantané elle-même. Cette étape comprend la commande SQL permettant de déclencher l'instantané de la base de données HANA, la sauvegarde de l'instantané de stockage et la commande SQL permettant de fermer l'opération d'instantané HANA. En utilisant la commande close, la base de données HANA met à jour le catalogue de sauvegarde de la base de données système et de chaque locataire.

Pour la gestion de la conservation des sauvegardes de données et de la gestion des catalogues de sauvegardes HANA, SnapCenter doit exécuter les opérations de suppression du catalogue pour la base de données système et toutes les bases de données de locataires identifiées lors de la première étape. De la même façon pour les sauvegardes de journaux, le flux de travail SnapCenter doit fonctionner sur chaque locataire qui faisait partie de l'opération de sauvegarde.

La figure suivante présente une vue d'ensemble du workflow de sauvegarde.

La gestion de la conservation des sauvegardes de données et le nettoyage des sauvegardes de journaux peuvent être divisés en cinq domaines, notamment la gestion de la conservation de :

La figure suivante présente les différents flux de travail et les dépendances de chaque opération. Les sections suivantes décrivent en détail les différentes opérations.