Et des meilleures pratiques
Cas d'utilisation pour la mise à jour, la copie et le clonage du système
Suggérer des modifications
PDF
Il existe plusieurs scénarios dans lesquels les données d'un système source doivent être mises à la disposition d'un système cible à des fins de test ou de formation. Ces systèmes de test et de formation doivent être mis à jour régulièrement avec les données du système source pour s'assurer que les tests et les formations sont effectués avec le dataset actuel.
Ces opérations d'actualisation de système se composent de plusieurs tâches au niveau des couches infrastructure, base de données et application. Plusieurs jours peuvent être nécessaires, selon le niveau d'automatisation.
SAP Lama et NetApp peuvent être utilisés pour accélérer et automatiser les tâches nécessaires au niveau des couches de l'infrastructure et de la base de données. Au lieu de restaurer une sauvegarde à partir du système source vers le système cible, SAP Lama utilise la copie NetApp Snapshot et la technologie NetApp FlexClone pour permettre l'exécution des tâches nécessaires vers une base de données HANA démarrée en quelques minutes au lieu de plusieurs heures, comme illustré dans la figure ci-dessous. Le temps nécessaire au processus de clonage est indépendant de la taille de la base de données. Par conséquent, même des systèmes très volumineux peuvent être créés en quelques minutes. La réduction de l'exécution est encore possible en automatisant les tâches du système d'exploitation et de la couche base de données ainsi que du post-traitement SAP.
Lutter contre la corruption logique
Une corruption logique peut être provoquée par des erreurs logicielles, des erreurs humaines ou du sabotage. Malheureusement, la corruption logique ne peut souvent pas être abordée avec les solutions standard de haute disponibilité et de reprise après incident. Par conséquent, selon la couche, l'application, le système de fichiers ou le stockage où la corruption logique s'est produite, un temps d'indisponibilité minimal et les exigences de perte de données acceptables ne peuvent parfois pas être respectés.
Le pire cas étant la corruption logique d'une application SAP. Les applications SAP fonctionnent souvent dans un environnement dans lequel les différentes applications communiquent entre elles et échangent des données. Par conséquent, la restauration et la récupération d'un système SAP dans lequel une corruption logique s'est produite n'est pas l'approche recommandée. La restauration du système à un point dans le temps avant la corruption entraîne une perte de données. Par ailleurs, le paysage SAP ne serait plus synchronisé et devrait nécessiter un post-traitement supplémentaire.
Au lieu de restaurer le système SAP, la meilleure approche consiste à tenter de corriger l'erreur logique dans le système en analysant le problème dans un système de réparation distinct. L'analyse de la cause première nécessite la participation du processus métier et du propriétaire des applications. Dans ce cas, vous créez un système de réparation (clone du système de production) basé sur les données stockées avant l'altération logique. Dans le système de réparation, les données requises peuvent être exportées et importées dans le système de production. Avec cette approche, le système de production n'a pas besoin d'être arrêté et, dans le meilleur des cas, aucune donnée ni seule une petite fraction des données n'est perdue.
Lors de la configuration du système de réparation, la flexibilité et la vitesse sont essentielles. Avec les sauvegardes Snapshot basées sur le stockage NetApp, la technologie NetApp FlexClone permet de créer un clone du système de production à partir de plusieurs images cohérentes de bases de données. Les volumes FlexClone peuvent être créés en quelques secondes au lieu de plusieurs heures si une restauration redirigée depuis une sauvegarde basée sur des fichiers est utilisée pour configurer le système de réparation.
Test de reprise après incident
Une stratégie efficace de reprise d'activité doit tester le workflow requis. Les tests démontrent si la stratégie fonctionne et si la documentation interne est suffisante. Il permet également aux administrateurs de former les procédures requises.
La réplication du stockage avec SnapMirror permet d'exécuter les tests de reprise d'activité sans mettre en péril le RTO et le RPO. Des tests de reprise après incident peuvent être effectués sans interrompre la réplication des données. Pour les tests de reprise d'activité de SnapMirror asynchrone et synchrone, les sauvegardes Snapshot et les volumes FlexClone sont utilisés à la cible de reprise d'activité.
SAP Lama peut être utilisé pour orchestrer l'ensemble de la procédure de test, et prend également en charge l'escrime réseau, la maintenance de l'hôte cible, etc.
