BONNES PRATIQUES EN MATIÈRE DE CONTINUITÉ … · Bonnes pratiques en matière de continuité d’activité pour l’intégration sur mesure du datacenter SAP HANA sur les systèmes

Livre blanc

BONNES PRATIQUES EN MATIÈRE DE CONTINUITÉ D’ACTIVITÉ POUR L’INTÉGRATION SUR MESURE DU DATACENTER SAP HANA

Sur les systèmes de stockage EMC VNX, avec EMC MirrorView et EMC SnapView

Solutions EMC Résumé Ce livre blanc présente les fonctionnalités logicielles et matérielles de la gamme de produits EMC VNX, et propose un ensemble complet de bonnes pratiques et de procédures pour assurer la haute disponibilité et la continuité d’activité lors de l’utilisation de SAP HANA avec EMC® VNX®

dans le cadre d’un déploiement TDI (intégration sur mesure du datacenter). Cette solution inclut EMC MirrorViewTM et EMC SnapViewTM. Février 2015

Bonnes pratiques en matière de continuité d’activité pour l’intégration sur mesure du datacenter SAP HANA sur les systèmes de stockage EMC VNX, avec

MirrorView et SnapView

2

Copyright © 2015 EMC Corporation. Tous droits réservés.

EMC estime que les informations figurant dans ce document sont exactes à la date de publication. Ces informations sont modifiables sans préavis.

Les informations contenues dans ce document sont fournies « en l’état ». EMC Corporation ne fournit aucune déclaration ou garantie d’aucune sorte concernant les informations contenues dans cette publication et rejette plus spécialement toute garantie implicite de qualité commerciale ou d’adéquation à une utilisation particulière.

L’utilisation, la copie et la diffusion de tout logiciel EMC décrit dans cette publication nécessitent une licence logicielle en cours de validité.

Pour obtenir la liste actualisée des noms de produits, consultez la rubrique des marques commerciales EMC Corporation via le lien Législation, sur france.emc.com.

Toutes les autres marques citées dans le présent document sont la propriété de leurs détenteurs respectifs.

Référence H13955

http://france.emc.com/�



3

Sommaire

Sommaire ........................................................................................................................................... 3 Business Case ................................................................................................................................. 5

Présentation de la solution .............................................................................................................. 5

Résultats principaux ........................................................................................................................ 5

Introduction ....................................................................................................................................... 6 Objectif de ce document .................................................................................................................. 6

Périmètre ......................................................................................................................................... 6

Audience.......................................................................................................................................... 6

Présentation technique ...................................................................................................................... 7 Introduction ..................................................................................................................................... 7

Prise en charge de la reprise après sinistre dans SAP HANA ............................................................. 7

Sauvegardes ............................................................................................................................... 7

Réplication système HANA .......................................................................................................... 8

Réplication du stockage .............................................................................................................. 8

Réplication du stockage SAP HANA avec la gamme VNX ...................................................................... 9 Protection de l’entreprise et conformité avec MirrorView .................................................................. 9

Snapshots de la base de données SAP HANA avec SnapView .......................................................... 9

Vue d’ensemble des technologies de réplication VNX ...................................................................... 9

Modes de fonctionnement de MirrorView ....................................................................................... 10

Mode MirrorView/Synchronous ................................................................................................. 10

Journal des tentatives d’écriture MirrorView/S ........................................................................... 10

Mode MirrorView/Asynchronous ............................................................................................... 11

Besoins en matière de bande passante pour la réplication ........................................................ 12

Groupes de cohérence ............................................................................................................... 13

Quand utiliser MirrorView/S et MirrorView/A .................................................................................. 13

Copies de données cohérentes avec SnapView .............................................................................. 13

Système d’exploitation et système de fichiers partagé HANA ......................................................... 13

Exemples d’utilisation illustrant les bonnes pratiques en matière de continuité d’activité pour la réplication du stockage SAP HANA ........................................................................................ 14

Exemples d’utilisation pour SAP HANA ........................................................................................... 14

Configuration générale requise ...................................................................................................... 14

Configuration logicielle requise ...................................................................................................... 15

Environnement de test pour les exemples d’utilisation .................................................................. 15

Maintien du fichier SAP HANA global.ini sur le site distant ............................................................. 15

Exemple d’utilisation 1 : Configuration d’une mise en miroir à distance pour assurer la protection des données en cas de sinistre (déploiement synchrone ou asynchrone) .......................... 17

Exemple d’utilisation 2 : Basculement sur incident planifié vers le site secondaire (maintenance) ..... 19



4

Exemple d’utilisation 3 : Basculement sur incident non planifié vers le site secondaire (sinistre) ...... 21 Partie 1 ...................................................................................................................................... 21

Partie 2 ...................................................................................................................................... 22

Exemple d’utilisation 4 : Retour arrière vers le site principal ............................................................. 24

Exemple d’utilisation 5 : Mise en miroir asynchrone à distance entre plusieurs baies VNX ................. 26

Exemple d’utilisation 6 : Création de snapshots de base de données redémarrables et accessibles en écriture à des fins de réaffectation vers le site secondaire ..................................... 30

Conclusion ....................................................................................................................................... 32 Résumé .......................................................................................................................................... 32

Résultats ........................................................................................................................................ 32

Références ....................................................................................................................................... 33 Documentation EMC ...................................................................................................................... 33

Documentation SAP ....................................................................................................................... 33



5

Résumé analytique

Les clients déploient des bases de données et des applications intégrées SAP HANA dans la plupart des domaines les plus critiques, comme la fabrication, la comptabilité, la gestion de l’inventaire, la vente et le marketing. Ces domaines d’activité, entre autres, sont au cœur du fonctionnement d’une entreprise. C’est pourquoi les interruptions et les pertes de données peuvent être catastrophiques. Afin d’assurer la disponibilité de ces systèmes, les entreprises qui en dépendent doivent approcher la continuité d’activité de façon exhaustive, tant au niveau de la planification que de l’exécution.

Les systèmes fédérés tels que SAP nécessitent seulement de procéder à la restauration de ces bases de données en cas de sinistre, ou de tester de temps à autre l’efficacité de cette restauration pour des besoins métiers ou d’audit.

La gamme EMC® VNX® est largement utilisée dans les environnements SAP, pour les applications critiques et avec les bases de données traditionnelles. Elle offre désormais une même plate-forme fiable pour les couches logicielle et matérielle, aussi bien pour les bases de données SAP HANA que pour les bases de données traditionnelles. Dans cette solution, la technologie de cohérence EMC MirrorViewTM associée aux snapshots EMC SnapViewTM permet aux clients SAP de répliquer de manière cohérente et de tester ou de restaurer avec fiabilité les nombreuses fonctions métiers de l’environnement SAP. MirrorView et SnapView assurent systématiquement la haute disponibilité et la continuité d’activité des environnements critiques, pour une protection des données synchrone et asynchrone.

Les exemples d’utilisation détaillés dans ce livre blanc illustrent les bonnes pratiques en matière de mise en œuvre de la réplication du stockage SAP HANA sur les baies de la gamme EMC VNX, à l’aide d’outils à l’efficacité éprouvée, déjà largement utilisés par les clients. Ces exemples montrent comment procéder à une restauration avec MirrorView et SnapView, et comment créer des répliques restaurables et redémarrables de bases de données, à distance.

Business Case

Présentation de la solution

Résultats principaux



6

Introduction

Ce livre blanc offre une introduction à la réplication SAP HANA pour la gamme EMC VNX, et propose un ensemble complet de bonnes pratiques et de procédures pour assurer la continuité d’activité dans le cadre de l’utilisation de SAP HANA sur un support VNX avec un déploiement TDI (intégration sur mesure du datacenter).

Dans ce livre blanc, vous trouverez :

• une introduction aux principales technologies incluses dans cette solution ;

• une description des bonnes pratiques et des considérations relatives à la conception pour la mise en œuvre de cette solution ;

• une description de la configuration et du déploiement des principaux composants ;

• des exemples d’utilisation illustrant une mise en œuvre réussie de cette solution.

Ce livre blanc s’adresse aux administrateurs de bases de données et de systèmes SAP HANA, aux administrateurs de stockage, ainsi qu’aux architectes système chargés de la mise en œuvre, de la maintenance et de la protection de bases de données SAP HANA in-memory et de systèmes de stockage robustes. Nous partons du principe que le lecteur a déjà une certaine connaissance des bases de données SAP HANA in-memory, des systèmes de stockage EMC VNX et des logiciels VNX, en particulier MirrorView et SnapView.

Objectif de ce document

Périmètre

Audience



7

Présentation technique

La plupart des clients qui utilisent une base de données SAP HANA in-memory avec un déploiement TDI (intégration sur mesure du datacenter) sur des baies de stockage EMC VNX doivent protéger leurs applications critiques ainsi que la base de données SAP HANA in-memory contre les sinistres, les pannes matérielles ou logicielles, ou encore les erreurs humaines, en maintenant une copie des données en local ou sur un site distant.

SAP HANA prend en charge la reprise après sinistre grâce à des sauvegardes ou à la réplication système HANA, ce qui permet d’intégrer en toute transparence SAP HANA dans des solutions de continuité d’activité existantes basées sur des technologies de réplication VNX, et ainsi de fédérer l’ensemble des stratégies de restauration.

Remarque : le livre blanc EMC intitulé Storage Configuration Best Practices for SAP HANA Tailored Datacenter Integrations on EMC VNX Series Unified Storage Systems explique comment utiliser les baies de stockage EMC VNX en mode TDI.

SAP HANA offre trois niveaux de reprise après sinistre : les sauvegardes, la réplication système HANA et la réplication du stockage. Chaque solution permet de répondre à des objectifs de point de restauration (RPO) différents, tout en respectant l’objectif de temps de restauration (RTO) requis, sachant que :

• l’objectif de point de restauration (RPO) représente le point de cohérence devant être atteint par HANA lors de la restauration ;

• l’objectif de temps de restauration (RTO) représente le temps alloué pour que le système HANA soit restauré à un point de cohérence spécifique.

Sauvegardes

Les sauvegardes protègent la persistance HANA principale contre les défaillances du stockage. Par conséquent, la cible de sauvegarde HANA ne doit jamais se trouver sur la même baie de stockage que la persistance HANA principale. Typiquement, les systèmes de sauvegarde peuvent répliquer le stockage de sauvegarde sur un système distant afin de le protéger en cas de défaillance du site.

Avec les sauvegardes HANA, l’objectif de point de restauration dépend de la fréquence des sauvegardes HANA effectuées par le client. Cela peut aller de quelques minutes à plusieurs heures. Avec les sauvegardes, l’objectif de temps de restauration peut être de plusieurs heures, car les sauvegardes HANA doivent être restaurées sur la persistance, et à partir de là être lues en mémoire avant que la base de données ne soit disponible.

EMC propose des solutions de sauvegarde HANA basées sur les lignes de produits EMC NetWorker® et EMC Data Domain®.

Introduction

Prise en charge de la reprise après sinistre dans SAP HANA



8

Réplication système HANA

La réplication système HANA est une solution de reprise après sinistre basée sur une application, qui fait appel à un système auxiliaire HANA, copie exacte du système principal actif. Chaque système secondaire doit comprendre le même nombre de nœuds HANA actifs. Comme avec la réplication du stockage, la réplication système HANA exige une connexion fiable entre le site principal et le site secondaire. La technologie de réplication prend en charge plusieurs modes, y compris les modes synchrone, synchrone in-memory et asynchrone.

Avec le système de réplication HANA, seul le contenu de la base de données a besoin d’être répliqué vers le site secondaire.

Réplication du stockage

La réplication de stockage HANA dans le cadre d’un déploiement TDI est une méthode pratique pour protéger HANA contre les défaillances du site. La persistance HANA principale est répliquée sur un site secondaire à l’aide de technologies basées sur les baies de stockage. En fonction des besoins en matière de RTO et de RPO, et de la distance entre le site principal et le site secondaire, vous pouvez mettre en œuvre une réplication de stockage synchrone (RPO = 0) ou asynchrone (RPO ≥ 0). En cas de sinistre, le RTO correspond au temps nécessaire pour démarrer la base de données HANA sur le site secondaire.

La réplication de stockage HANA offre plusieurs avantages aux clients par rapport à la réplication système HANA. La réplication du stockage inclut la persistance de la base de données afin d’assurer la disponibilité des données sur un site distant. La réplication de stockage peut également inclure des données en dehors du système HANA au niveau de la technologie de cohérence de la baie de stockage, créant ainsi une image à un point dans le temps cohérente de l’ensemble des applications métiers sur le site secondaire.

En plus de la réplication de la persistance de la base de données HANA, vous pouvez inclure des composants comme les volumes de démarrage de système d’exploitation, le système de fichiers partagé HANA (qui inclut les fichiers binaires et les fichiers de configuration HANA), ou encore des applications non HANA, afin de fédérer les stratégies de reprise après sinistre.

Ce livre blanc couvre plusieurs exemples d’utilisation de la réplication de stockage SAP HANA en local et à distance, sur des baies de stockage VNX. Seule la persistance de la base de données HANA est prise en compte ici (volumes de données et de logs).

Remarque : le document SAP HANA Administration Guide offre plus de détails sur les différentes solutions de reprise après sinistre, ainsi que sur leurs avantages et leurs inconvénients.



9

Réplication du stockage SAP HANA avec la gamme VNX

On appelle « cohérence des données » l’exactitude et l’intégrité des données, notamment au niveau des différentes copies effectuées. VNX propose plusieurs solutions de réplication en local ou à distance pour les bases de données SAP HANA in-memory. Avec le logiciel MirrorView, il est possible de créer des miroirs de la persistance de la base de données SAP HANA. Ces miroirs comportent leurs propres données externes et fichiers d’applications, partageant le même groupe de cohérence. En répliquant la persistance SAP HANA de cette manière, vous créez un point de cohérence pour les différentes entités et applications métiers en prévision d’un éventuel sinistre. En cas de basculement sur incident vers le site de reprise après sinistre, une série d’opérations de redémarrage des applications permettent de réduire la complexité et l’interruption de service de manière générale.

Tous les systèmes critiques ont besoin de plusieurs copies de leurs données, pour le développement, les tests, l’assurance qualité, les sauvegardes, etc. Étant donné que la gamme VNX fait appel au logiciel SnapView en plus des snapshots de stockage SAP HANA, de multiples copies de la persistance de la base de données SAP HANA (données et logs) peuvent être créées ou restaurées en quelques secondes. Les exemples fournis dans ce document mettent en avant une utilisation de SnapView sur un site distant pour créer une image à un point dans le temps cohérente de la persistance de la base de données, qui pourra ensuite être utilisée par les serveurs HANA sur le site distant à des fins de test ou de développement, en parallèle de la réplication des données du site local vers le site distant.

La gamme de baies de stockage EMC VNX prend en charge diverses technologies de réplication à distance développées par EMC, afin de protéger vos données en cas de sinistre. Ces technologies sont :

• MirrorView

• VNX Replicator

• EMC RecoverPoint

• EMC SRDF®

• EMC VPLEX®

• EMC Replication Manager

Ce livre blanc traite de la réplication de stockage SAP HANA à l’aide des technologies MirrorView/Synchronous (MirrorView/S) et MirrorView/Asynchronous (MirrorView/A) pour la persistance HANA sur les périphériques en mode bloc. Il existe d’autres technologies de réplication VNX qui ne sont pas couvertes par ce document.

En plus de la réplication à distance, la gamme EMC VNX prend en charge les deux technologies de réplication locale suivantes :

• SnapView

• Snapshots VNX

Protection de l’entreprise et conformité avec MirrorView

Snapshots de la base de données SAP HANA avec SnapView

Vue d’ensemble des technologies de réplication VNX



10

Ces deux technologies permettent de créer des snapshots de LUN en mode bloc. Cependant, elles font appel à des technologies sous-jacentes différentes et prennent en charge les différents types de LUN au niveau de la baie VNX. Vous ne pouvez utiliser les snapshots VNX qu’avec des LUN en pool, et vous ne pouvez utiliser SnapView que sur des LUN traditionnelles et des MetaLUN. Étant donné que les MetaLUN sont recommandées dans les environnements HANA, ce document explique comment utiliser SnapView avec HANA.

MirrorView/S et MirrorView/A sont les modes de fonctionnement de base de MirrorView. Ils permettent tous les deux de protéger votre base de données SAP HANA et de préserver la cohérence de l’ordre des écritures.

Mode MirrorView/Synchronous

Le mode MirrorView/S est utilisé pour créer une solution sans perte de données pour les transactions validées. Il offre la possibilité de répliquer un grand nombre de bases de données et d’applications à distance tout en garantissant la reproduction à l’identique des données entre les périphériques source et cible.

Avec la réplication MirrorView/S, illustrée à la Figure 1, chaque écriture sur l’hôte local est reproduite en simultané sur le site distant. Une fois que la baie VNX distante a accusé réception des E/S, l’écriture est validée sur l’hôte local. Ainsi, en cas de sinistre au niveau du site local, les données du site secondaire seront exactement les mêmes (RPO = 0).

Figure 1. Réplication MirrorView/Synchronous

La réplication synchrone affecte la latence des opérations d’E/S. Étant donné que le système SAP HANA requiert des latences faibles pour les E/S d’écriture sur la persistance, la distance entre les deux sites s’en trouve forcément limitée. Quand utiliser MirrorView/S et MirrorView/A Pour plus d’informations, reportez-vous à la rubrique .

Journal des tentatives d’écriture MirrorView/S

MirrorView/S utilise un journal des tentatives d’écriture (en option) pour effectuer le suivi des écritures en cours, à la fois sur la baie locale et sur la baie distante. Deux LUN dédiées sont utilisées à cet effet. Chaque processeur de stockage se voit attribuer une écriture. Dans les situations de restauration, le journal des tentatives d’écriture peut être utilisé pour identifier les extensions à synchroniser entre le site local et le système de stockage distant. Si vous avez installé un système de base de données HANA sur plusieurs baies, vous devez désactiver le journal des tentatives d’écriture.

Modes de fonctionnement de MirrorView



11

Vous pouvez saisir les exemples de commandes suivants pour créer votre journal de tentatives d’écriture sur une baie VNX. Vous devez impérativement prévoir un journal pour la baie principale et la baie secondaire. Les LUN dédiées au journal de tentatives d’écriture doivent être créées sur un groupe RAID, et elles peuvent résider sur l’un des groupes RAID utilisés pour la persistance HANA :

naviseccli -h <VNX ip> bind r5 0 -rg 31 -cap 2048 -sq mb -sp a

naviseccli -h <VNX ip> bind r5 1 -rg 31 -cap 2048 -sq mb -sp b

naviseccli -h <VNX ip> mirror -sync -allocatelog -spA 0 -spB 1 –o

Remarque : dans cet exemple, les LUN dédiées au journal de tentatives d’écriture sont associées au groupe RAID 31. Leurs identifiants sont 0 et 1. Le journal de tentatives d’écriture est requis sur la baie principale et la baie secondaire.

Saisissez la commande suivante pour afficher la configuration du journal de tentatives d’écriture :

naviseccli -h <VNX IP> mirror -sync –listlog Mode MirrorView/Asynchronous

Le mode MirrorView/A, illustré Figure 2, fait appel à un modèle de mise à jour périodique permettant de fournir une image à un point dans le temps cohérente des données sur les périphériques cibles, avec un RPO supérieur à zéro. Les modifications apportées aux données sur le site principal sont suivies et appliquées au site distant selon une fréquence définie par l’utilisateur :

1. Manuellement

2. Quelques minutes après le début du dernier transfert

3. Quelques minutes après la fin du dernier transfert

La troisième option est utilisée dans ce document pour la plupart des tests HANA avec MirrorView/A. Cependant, dans certains exemples d’utilisation (Exemple d’utilisation 6 : Création de snapshots de base de données redémarrables et accessibles en écriture à des fins de réaffectation vers le site secondaire, notamment), le transfert doit être déclenché manuellement.

En effectuant le suivi des zones de données qui sont modifiées sur les périphériques, il est possible d’envoyer moins de données (par exemple, si les écritures ont lieu au niveau des mêmes zones d’une mise à jour à l’autre). Les mises à jour sont lissées sur l’ensemble de la période de mise à jour, même en cas de pics d’écriture sur les LUN sources. De cette manière, la bande passante et le coût des liaisons entre les sites sont optimisés.

Le mode MirrorView/A suit et stocke les changements de données dans le pool de LUN réservées global, qui est requis sur les baies locale et distante.



12

Figure 2. Réplication MirrorView/Asynchronous

Le principal avantage du mode MirrorView/A est qu’il permet de répliquer des données sur une plus grande distance. En effet, le temps de réponse SAP HANA n’est pas dépendant de la latence de la liaison.

Pool de LUN réservées pour le mode MirrorView/A Le pool de LUN réservées est constitué de LUN privées représentant 20 % (au moins) de la capacité totale des LUN source. Le nombre de LUN doit correspondre au moins au nombre de LUN source.

Cette capacité supplémentaire est requise sur la baie locale et la baie distante, et vous devez la prévoir lorsque vous utilisez le mode MirrorView/A pour une reprise après sinistre.

Vous pouvez utiliser les commandes d’exemple suivantes pour créer un pool de LUN réservées sur une baie VNX :

naviseccli -h <VNX ip> bind r5 <lun id> -rg <raid group> -cap <capacity> -sq gb -sp a Répétez la commande et créez le nombre de LUN requises :

naviseccli -h <VNX ip> reserved –lunpool –addlun <lun_numbers> Vous devez également disposer d’un pool de LUN réservées si vous utilisez SnapView (voir la rubrique Exemple d’utilisation 6 : Création de snapshots de base de données redémarrables et accessibles en écriture à des fins de réaffectation vers le site secondaire).

Remarque : le document VNX Command Line Interface Reference for Block 5.33, disponible sur le site de support en ligne EMC, offre davantage d’informations sur la planification et le dimensionnement d’un pool de LUN réservées.

Besoins en matière de bande passante pour la réplication

Lorsque vous utilisez la réplication de stockage synchrone avec MirrorView/S, vous pouvez calculer les besoins en bande passante entre le site principal et le site secondaire pour les pics de charges applicatives grâce à la formule suivante :

Nombre de nœuds de calcul HANA x 200 Mo/s

Par exemple, pour une installation HANA scale-out 3+1, vous aurez besoin d’une bande passante de 600 Mo/s entre le site principal et le site secondaire.

Avec la réplication asynchrone, les besoins en bande passante dépendent du taux de modification de la base de données et de l’intervalle selon lequel les modifications apportées sont répliquées sur le site distant. Vous pouvez spécifier cet intervalle lorsque vous configurez le mode MirrorView/A. Il définit le RPO de la réplication.



13

Groupes de cohérence

La technologie MirrorView (/S aussi bien que /A) inclut une fonctionnalité de groupe de cohérence basé sur un système de stockage. Un groupe de cohérence basé sur un système de stockage est une collection de miroirs qui fonctionnent ensemble et forment une unité au sein du système de stockage. Toutes les opérations, comme la synchronisation, la promotion ou la rupture, ont lieu sur l’ensemble des membres de ce groupe de cohérence. Les groupes de cohérence permettent également de gérer la dépendance de l’ordre des écritures de l’ensemble des membres, et de s’assurer qu’une copie redémarrable de la base de données est toujours disponible sur le système secondaire.

Il existe trois types de solutions de base pour la reprise après sinistre :

• Solution Campus : les données sont typiquement transmises par fibre optique avec des équipements VNX et SAN sur une distance inférieure à 66 km, à l’aide d’extensions de canal ou de fibres optiques longue distance.

• Solution Metro : pour les distances inférieures à 100 km.

• Solution Geo : pour les distances supérieures à 100 km.

Dans le cas des clusters Campus et Metro, on utilise généralement le mode MirrorView/S. Cependant, pour SAP HANA, il est important que la latence se situe dans la partie inférieure de l’intervalle [0-9] ms quand le nombre d’E/S sur le périphérique de log reste inférieur à 4 000. Si cela n’est pas réalisable avec l’infrastructure existante et la réplication synchrone, vous pouvez passer à la réplication asynchrone.

Le réseau étendu WAN (Wide Area Network) offre une connectivité MirrorView sur de longues distances avec des réseaux de télécommunications comme IP, SONET ou ATM. Le mode MirrorView/A convient mieux à toutes les mises en œuvre WAN.

Vous pouvez utiliser SnapView afin de créer des copies cohérentes de vos données. Ces copies pourront ensuite être utilisées pour configurer des systèmes de test ou de développement sur le site secondaire sans interrompre la réplication. Les opérations effectuées sur le snapshot peuvent être réinitialisées à leur état d’origine.

Les exemples d’utilisation de ce livre blanc décrivent la réplication de la persistance de la base de données SAP HANA (périphériques de données et de logs). SAP HANA utilise également un système de fichiers partagé NFS /hana/shared hébergé sur la baie VNX. La réplication de ce système de fichiers, qui contient les fichiers binaires, les fichiers de configuration et les traces HANA, peut être effectuée à l’aide de VNX Replicator.

Remarque : la réplication du système de fichiers NFS n’est pas abordée dans ce document, mais vous pouvez consulter à ce sujet le document Using VNX Replicator 8.1, qui est disponible sur le site de support en ligne EMC.

Si les serveurs HANA démarrent à partir d’un SAN et si le système d’exploitation est installé sur des LUN VNX, vous pouvez inclure ces LUN dans les scénarios de réplication MirrorView en les ajoutant aux groupes de cohérence. Cependant, des étapes supplémentaires peuvent être requises si vous redémarrez le site distant après un basculement sur incident. Vous devez alors ajuster les noms d’hôtes et les adresses réseau.

Quand utiliser MirrorView/S et MirrorView/A

Copies de données cohérentes avec SnapView

Système d’exploitation et système de fichiers partagé HANA



14

Exemples d’utilisation illustrant les bonnes pratiques en matière de continuité d’activité pour la réplication du stockage SAP HANA

Les rubriques ci-après décrivent les exemples d’utilisation illustrant les bonnes pratiques pour la mise en œuvre d’une réplication du stockage et d’une restauration SAP HANA à l’aide des technologies MirrorView et SnapView.

IMPORTANT : les commandes présentées dans ces exemples d’utilisation sont des suggestions qu’il vous faut personnaliser en fonction de votre environnement. Créez des scripts avec ces commandes personnalisées, puis testez-les et validez-les avec précaution avant de mettre en œuvre ces exemples d’utilisation dans un environnement de production.

Les six exemples d’utilisation suivants pour SAP HANA et VNX montrent comment implémenter des répliques restaurables et redémarrables de bases de données, en local et à distance. Les exemples d’utilisation 1 à 4 et 6 peuvent être mis en œuvre à l’aide de MirrorView/S ou MirrorView/A. L’exemple d’utilisation 5 ne peut être mis en œuvre qu’avec MirrorView/A.

• Exemple d’utilisation 1 : Configuration d’une mise en miroir à distance pour assurer la protection des données en cas de sinistre (déploiement synchrone ou asynchrone)

• Exemple d’utilisation 2 : Basculement sur incident planifié vers le site secondaire (maintenance)

• Exemple d’utilisation 3 : Basculement sur incident non planifié vers le site secondaire (sinistre)

• Exemple d’utilisation 4 : Retour arrière vers le site principal

• Exemple d’utilisation 5 : Mise en miroir asynchrone à distance entre plusieurs baies VNX

• Exemple d’utilisation 6 : Création de snapshots de base de données redémarrables et accessibles en écriture à des fins de réaffectation vers le site secondaire

Avant de pouvoir mettre en place une solution de reprise après sinistre pour SAP HANA dans un scénario d’intégration sur mesure du datacenter (TDI), vous devez remplir les conditions suivantes :

• Vous devez appliquer une licence MirrorView/S ou MirrorView/A aux baies VNX principale et secondaire.

• Vous devez vous assurer qu’une connexion MirrorView existe entre la source et la destination. Les liaisons MirrorView sont des connexions logiques entre deux baies VNX, physiquement connectées par des câbles, des routeurs, des extensions, des switches et d’autres périphériques réseau.

• Les deux baies doivent être configurées avec des volumes HANA identiques, tel que décrit dans le livre blanc EMC Storage Configuration Best Practices for SAP HANA TDI on EMC VNX Series Storage Systems.

• Vous devez appliquer une licence SnapView sur la baie locale et/ou la baie distante si vous utilisez cette technologie, comme décrit dans l’exemple d’utilisation 6.

• Une capacité de disque supplémentaire est requise sur les baies principale et secondaire pour le pool de LUN réservées si vous utilisez MirrorView/A ou SnapView.

Exemples d’utilisation pour SAP HANA

Configuration générale requise



15

Ces exemples d’utilisation ont été testés avec les versions logicielles suivantes :

• SAP HANA 1.0 SPS08, rév 82

• SUSE Linux SLES 11 SP3 pour les applications SAP, noyau 3.0.101-0.15

• VNX OE Block 05.33.000.5.074 sur les baies principale et secondaire Les exemples d’utilisation décrits dans ce document, tels qu’illustrés Figure 3, ont été testés sur un déploiement SAP HANA scale-out avec trois nœuds de calcul et un nœud auxiliaire sur une baie principale VNX 5400 connectée avec Fibre Channel (FC) à une baie secondaire VNX 7600, comme illustré Figure 3.

Figure 3. Environnement de test pour les exemples d’utilisation

Chaque baie VNX est connectée à un serveur de gestion sur lequel est installée l’interface de ligne de commande VNX Navisphere (NaviSecCLI). Les exemples d’utilisation décrits dans les rubriques suivantes font appel à ces commandes NaviSecCLI :

• La commande -h <primary VNX> target IP address doit être exécutée sur le serveur de gestion local.

• La commande -h <secondary VNX> target IP address doit être exécutée sur le serveur de gestion distant.

Les serveurs SAP HANA doivent se trouver sur les deux sites. Les serveurs du site 2 font appel aux unités secondaires pour leur persistance HANA en cas de basculement sur incident. Des snapshots distants sont utilisés lorsque la persistance est utilisée sur le site secondaire à des fins de test ou de développement, en parallèle de la réplication.

La section relative au stockage du fichier HANA global.ini contient les références des partitions de stockage HANA sur les LUN de stockage. EMC utilise les UUID des LUN pour identifier les périphériques de stockage appropriés.

Configuration logicielle requise

Environnement de test pour les exemples d’utilisation

Maintien du fichier SAP HANA global.ini sur le site distant



16

Ces UUID peuvent être identifiés à l’aide de deux méthodes :

• Méthode 1 : à partir du serveur SAP HANA

Si vous avez besoin d’identifier l’UUID d’une LUN de données d’1,5 To, saisissez la commande suivante sur le nœud HANA :

multipath -ll | grep -B1 1.5T

36006016025403a00c8e8afa7495fe411 dm-10 DGC, RAID 5 size=1.5T features=’1 queue_if_no_path’ hwhandler=’1 emc’wp=rw La chaîne 36006016025403a00c8e8afa7495fe411 est l’UUID de la LUN de stockage correspondante.

Remarque : Linux ajoute le préfixe 3 à l’UUID de stockage.

• Méthode 2 : à partir d’un serveur de gestion avec NaviSecCLI

• Les UUID des LUN peuvent être affichés avec cette commande :

naviseccli -h <primary VNX> getlun -uid –name LOGICAL UNIT NUMBER 310 UID: 60:06:01:60:32:E0:35:00:CA:C1:DF:69:72:6E:E4:11 Name LUN_Data1 [..]

Remarque : les commandes NaviSecCLI affichent l’UUID sans le préfixe 3.

Le fichier HANA global.ini ressemblera alors à ceci :

[storage] ha_provider = hdb_ha.fcClient partition_*_* prtype = 5 partition_1_data wwid = 36006016032e035000b287d720277e411 partition_1_log wwid = 3600601604a303500b09e9a780277e411 partition_2_data wwid = 36006016032e0350070470eaa0277e411 partition_2_log wwid = 36006016032e03500da327b790277e411 partition_3_data wwid = 36006016032e035000c287d720277e411 partition_3_log wwid = 3600601604a303500b19e9a780277e411

IMPORTANT : préparez un fichier global.ini contenant les entrées de partition des LUN secondaires. Renommez le fichier, par exemple en global.ini_DR, puis enregistrez-le dans le même dossier que le fichier global.ini habituel. Échangez les fichiers global.ini au moment de démarrer HANA sur le site secondaire. Vous pouvez utiliser la même méthode pour démarrer HANA sur le site secondaire avec des LUN SnapView à des fins de test ou de développement.



17

Exemple d’utilisation 1 : Configuration d’une mise en miroir à distance pour assurer la protection des données en cas de sinistre (déploiement synchrone ou asynchrone)

Cet exemple d’utilisation montre comment créer des miroirs distants de la persistance de la base de données SAP HANA (données et logs) afin d’assurer leur protection en cas de sinistre, à l’aide de MirrorView (/S ou /A).

Les périphériques principaux de l’installation VNX sur le site 1 sont répliqués sur des périphériques secondaires situés dans l’installation VNX du site 2. Tant que la réplication est active, il n’est pas possible d’accéder aux périphériques secondaires à partir des nœuds HANA du site 2.

Les grandes étapes de la configuration d’une réplication entre un site principal et un site secondaire sont les mêmes, que vous utilisiez MirrorView/S ou MirrorView/A. Les commandes CLI font appel à des options différentes (mirror-sync et mirror-async).

La Figure 4 offre une vue d’ensemble de cet exemple d’utilisation.

Figure 4. Mise en miroir à distance

Afin de mettre en place une mise en miroir à distance pour la protection des données en cas de sinistre, en mode synchrone ou asynchrone, procédez comme suit :

1. Activez une connexion MirrorView entre les baies VNX.

Avant de pouvoir établir une connexion, les ports MirrorView des deux baies doivent être reliés à l’aide d’une topologie réseau et d’une bande passante capable de prendre en charge la méthode de réplication prévue (synchrone ou asynchrone).

Remarque : le livre blanc EMC intitulé MirrorView Knowledgebook contient des informations supplémentaires sur les ports MirrorView.

Saisissez la commande suivante afin d’établir une connexion MirrorView entre la baie principale et la baie secondaire :

naviseccli -h <primary VNX> mirror -enablepath <secondary VNX> -connectiontype fibre



18

2. Configurez les paramètres de réplication comme suit :

a. MirrorView/S : configurez le journal de tentatives d’écriture comme décrit dans la rubrique Journal des tentatives d’écriture MirrorView/S.

b. MirrorView/A : configurez le pool de LUN réservées comme décrit dans la rubrique Pool de LUN réservées pour le mode MirrorView/A.

3. Activez l’image principale de chaque LUN sur le système principal :

naviseccli -h <primary VNX> mirror -async -create -name Lun_Data1_Mirror -lun <alu> –o Répétez la commande précédente pour l’ensemble des LUN. Utilisez un nom différent pour chaque miroir. La chaîne <alu> doit être remplacée par l’identifiant de la LUN de la baie.

Remarque : si vous avez configuré la réplication synchrone, utilisez mirror -sync dans toutes les commandes restantes de cet exemple d’utilisation. Assurez-vous d’utiliser la même méthode de réplication sur tous les périphériques persistants.

4. Ajoutez les images secondaires aux miroirs comme suit :

naviseccli -h <primary VNX> mirror -async -addimage -name Lun_Data1_Mirror -arrayhost <secondary VNX> -lun <alu> Répétez la commande précédente pour toutes les LUN secondaires. La chaîne <alu> doit être remplacée par l’identifiant de la LUN de la baie secondaire.

5. Créez un groupe de cohérence portant le nom HANA_Volumes comme suit :

Le groupe de cohérence gère la cohérence de l’ordre des écritures sur l’ensemble des LUN et permet d’exécuter les commandes MirrorView sur ce groupe plutôt que sur des périphériques individuels. Une fois vos groupes de cohérence créés, ajoutez toutes les LUN HANA persistantes (données et logs) à ces groupes. Si vous redémarrez le système à partir d’un SAN, vous pouvez ajouter les LUN du système d’exploitation au groupe de cohérence.

naviseccli -h <primary VNX> mirror -async -creategroup - name HANA_Volumes –enddelay 0 –o naviseccli -h <primary VNX> mirror -async -addtogroup – name HANA_Volumes -mirrorname Lun_Data1_Mirror Répétez la commande précédente pour l’ensemble des miroirs. Pour le mode MirrorView/A seulement, le paramètre -enddelay 0 permet d’amorcer rapidement le cycle de mise à jour suivant. Si vous devez contrôler manuellement le processus de mise à jour vers les LUN cibles, utilisez à la place le paramètre -manualupdate.

La synchronisation initiale démarre automatiquement. Notez que la synchronisation de l’ensemble des périphériques peut prendre un peu de temps. Saisissez la commande suivante pour vérifier l’état de la synchronisation :

naviseccli -h <primary VNX> mirror -async -listgroups - name HANA_Volumes -state Group Name: HANA_Volumes State: Consistent Quand l’état est Consistent ou Synchronized, les LUN du site secondaire sont prêtes à prendre le relais de la base de données en cas de sinistre.



19

Exemple d’utilisation 2 : Basculement sur incident planifié vers le site secondaire (maintenance)

Cet exemple d’utilisation illustre comment effectuer un basculement sur incident de la persistance HANA vers le site 2 à l’aide de MirrorView (/S ou /A) à des fins de maintenance du site 1. Par exemple, vous pouvez effectuer un basculement sur incident le temps de remplacer du matériel. Cet exemple d’utilisation montre comment assurer la disponibilité de la persistance de la base de données (unités secondaires) sur l’installation HANA auxiliaire du site 2, en réalisant une permutation de personnalité automatique entre les périphériques. (Le site 2 devient le site principal, et la réplication s’effectue en direction de l’ancien site principal, désormais devenu secondaire).

La Figure 5 illustre l’état du système après un basculement sur incident planifié et une permutation de personnalité entre les périphériques, quand le site 1 est en mode de maintenance.

Figure 5. Activer la protection à distance tandis que la production est effectuée sur le

site 2

Pour effectuer un basculement sur incident vers le site de maintenance secondaire, procédez comme suit :

1. Retirez les LUN principales des serveurs HANA locaux.

Dans un scénario de basculement sur incident planifié, commencez par stopper le système HANA au niveau du site principal, puis éteignez les serveurs HANA. Retirez les LUN principales des storage groups pour tous les serveurs HANA (de calcul et auxiliaires), car les serveurs perdront tout accès en lecture et en écriture.

Saisissez la commande suivante pour afficher la liste des LUN d’un storage group :

naviseccli -h <primary VNX> storagegroup -list -gname Server01



20

Retirez ensuite toutes les LUN à l’aide du numéro de LUN hôte (HLU) que vous trouverez dans la sortie de la commande précédente :

naviseccli -h <primary VNX> storagegroup -removehlu - gname Server01 -hlu <hlu> –o Répétez la commande précédente pour l’ensemble des LUN principales et storage groups. Préparez un script à cet effet.

2. Effectuez un basculement sur incident du groupe de cohérence HANA_Volumes afin d’activer l’accès en écriture sur les périphériques de destination.

Saisissez la commande suivante afin de promouvoir les LUN secondaires d’origine du site 2 au rôle d’images principales, et de changer automatiquement le rôle des LUN du site 1 en images secondaires :

naviseccli -h <secondary VNX> mirror -async –promotegroup -name HANA_Volumes –o

Remarque : utilisez mirror -sync si vous avez configuré la réplication synchrone.

3. Assurez la disponibilité des LUN sur les serveurs HANA du site secondaire.

Cette étape implique que vous ayez déjà créé des storage groups pour les serveurs HANA sur le site secondaire, et qu’ils incluent déjà les initiateurs HBA des serveurs HANA auxiliaires. Les storage groups ne doivent pas contenir de LUN. Vous les ajouterez dans le cadre d’un scénario de basculement sur incident.

Entrez la commande suivante :

naviseccli -h <secondary VNX> storagegroup -addhlu -gname server05 -alu <alu> -hlu <hlu> –o Répétez la commande précédente pour tous les storage groups et LUN, et remplacez la chaîne <alu> par l’identifiant de LUN de la baie et la chaîne <hlu> par l’identifiant de LUN de l’hôte. Préparez un script à cet effet. Les unités secondaires du groupe de cohérence HANA_Volumes sont désormais accessibles en lecture/écriture et peuvent être découvertes par le système d’exploitation pour démarrer SAP HANA sur le site distant. Assurez-vous que le fichier global.ini du système HANA du site 2 contient les bonnes entrées de partition avec des pointeurs vers les nouveaux UUID des périphériques du site 2, avant de démarrer HANA. Par exemple, utilisez le fichier global.ini_DR préparé précédemment.



21

Exemple d’utilisation 3 : Basculement sur incident non planifié vers le site secondaire (sinistre)

Cet exemple d’utilisation montre comment effectuer un basculement sur incident de la persistance HANA vers le site 2 à l’aide de MirrorView (/S ou /A). En cas de sinistre, cet exemple d’utilisation assure la disponibilité de la persistance de la base de données sur l’installation HANA du site 2, qui devient alors le nouveau site de production. Le site 1 reste indisponible tant que la production est effectuée sur le site 2.

Cet exemple d’utilisation est constitué de deux parties. La première partie explique comment effectuer un basculement sur incident et exécuter la production HANA sur le site 2. Une fois le site 1 réparé et de nouveau en ligne, vous pouvez passer à la deuxième partie, qui explique comment configurer une réplication du site 2 vers le site 1 afin d’assurer la protection des données désormais en cours d’exécution sur le site 2.

La Figure 6 illustre l’état du système après un sinistre, quand le site 2 devient le nouveau site de production.

Figure 6. Nouveau site de production (site 2) après un sinistre

Partie 1

Effectuez un basculement sur incident et exécutez la production HANA sur le site 2 :

1. Saisissez la commande suivante afin de forcer un basculement sur incident du groupe de cohérence HANA_Volumes et ainsi activer l’accès en écriture sur les périphériques secondaires. Le site 2 devient ainsi le site principal :

naviseccli -h <secondary VNX> mirror -async –promotegroup -name HANA_Volumes –o

Si vous essayez de promouvoir les LUN du site secondaire alors que la connexion entre les deux sites est rompue, comme dans cet exemple d’utilisation, vous obtenez le message d’erreur suivant :

Unable to contact MirrorView/A on remote array during group promote (0x715280fd)



22

Si cette erreur se produit, forcez la promotion comme suit :

naviseccli -h <secondary VNX> mirror -async –promotegroup -name HANA_Volumes -type force –o

Local Status: Local Promote succeeded. Remote Status: Unable to send a message to the secondary or peer SP. Check to see if the MirrorView connections between secondary and primary arrays have been established. (0x71528003) Une fois la promotion forcée effectuée, les LUN sont disponibles en lecture/écriture sur le site secondaire, qui héberge désormais la production SAP HANA.

Remarque : si vous avez configuré la réplication synchrone, utilisez mirror -sync dans toutes les commandes restantes de cet exemple d’utilisation. Assurez-vous d’utiliser la même méthode de réplication sur tous les périphériques persistants.

2. Saisissez la commande suivante pour assurer la disponibilité des nouvelles LUN principales pour les hôtes du site 2 :

naviseccli -h <secondary VNX> storagegroup -addhlu -gname server05 -alu <alu> -hlu <hlu> –o Répétez la commande précédente pour l’ensemble des LUN et des storage groups, et remplacez la chaîne <alu> par l’identifiant de LUN de la baie et la chaîne <hlu> par l’identifiant de LUN de l’hôte. Préparez un script à cet effet. Les unités secondaires du groupe de cohérence HANA_Volumes sont désormais accessibles en lecture/écriture et peuvent être découvertes par le système d’exploitation pour démarrer SAP HANA sur le site secondaire. Assurez-vous que le fichier global.ini du système HANA du site 2 contient les bonnes entrées de partition avec des pointeurs vers les nouveaux UUID des périphériques du site 2, avant de démarrer HANA. Par exemple, utilisez le fichier global.ini_DR préparé précédemment.

Partie 2

Une fois le site principal restauré et réparé, et la baie VNX principale à nouveau disponible et en ligne, activez les LUN du site 1 en tant qu’images secondaires :

1. Retirez les LUN du site 1 des storage groups, comme suit :

naviseccli -h <primary VNX> storagegroup -removehlu - gname Server01 -hlu <hlu> –o Répétez la commande précédente pour l’ensemble des LUN et storage groups. Remplacez la chaîne <hlu> par l’identifiant de LUN de l’hôte. Préparez un script à cet effet.

2. Détruisez le groupe de cohérence obsolète du site 1, comme suit :

naviseccli -h <primary VNX> mirror -async -destroygroup - name HANA_Volumes -force –o Détruisez les miroirs obsolètes du site 1, comme suit :

naviseccli -h <primary VNX> mirror -async -destroy -name Lun_Data1_Mirror -force –o Répétez la commande précédente pour l’ensemble des miroirs.



23

3. Saisissez la commande suivante pour détruire le groupe de cohérence du site 2 avant de définir de nouveaux miroirs :

naviseccli -h <secondary VNX> mirror -async –destroygroup -name HANA_Volumes -force –o

4. Saisissez la commande suivante pour créer de nouveaux miroirs avec les LUN principales du site 2 et les LUN secondaires du site 1 :

naviseccli -h <secondary VNX> mirror -async -addimage - name Lun_Data1_Mirror -arrayhost <primary VNX> -lun <alu> Répétez la commande précédente pour l’ensemble des miroirs. Remplacez la chaîne <alu> par l’identifiant de LUN de la baie. Créez un script à cet effet.

5. Créez à nouveau le groupe de cohérence HANA _Volumes sur le site 2 :

naviseccli -h <secondary VNX> mirror -async –creategroup -name HANA_Volumes –enddelay 0 –o Ajoutez des LUN et attendez la fin de la synchronisation initiale :

naviseccli -h <secondary VNX> mirror -async -addtogroup - name HANA_Volumes -mirrorname Lun_Data1_Mirror Répétez la commande précédente pour l’ensemble des miroirs. Créez un script à cet effet.



24

Exemple d’utilisation 4 : Retour arrière vers le site principal Après un sinistre et un basculement sur incident de la base de données HANA sur le site 2 en suivant les étapes de l’exemple d’utilisation 3, réparez le site 1 et rendez-le accessible et disponible pour la réplication MirrorView. Avant de ramener la base de données SAP HANA en ligne sur le site principal, suivez les étapes de la Partie 2 de l’exemple d’utilisation 3. Ces étapes permettent de rétablir la réplication à partir du site 2 (qui héberge la production pendant que le site 1 est en panne), vers le site 1. Quand tous les périphériques sont associés à l’état Consistent ou Synchronized, vous pouvez promouvoir les périphériques du site 1 au rôle d’images principales.

Remarque : ce processus est un événement planifié et nécessite un court arrêt de la production, le temps de procéder au retour arrière du site 2 vers le site 1.

Pour effectuer le retour arrière vers le site principal, procédez comme suit :

1. Vérifiez l’état de la réplication afin de vous assurer que les périphériques sont notés comme synchronisés ou cohérents :

naviseccli -h <secondary VNX> mirror -async -listgroups - name HANA_Volumes –state Group Name: HANA_Volumes State: Consistent

Remarque : si vous avez configuré MirrorView/S, utilisez mirror -sync dans toutes les commandes de cet exemple d’utilisation.

Une fois que les périphériques sont associés à l’état Consistent ou Synchronized, les LUN du site 1 sont prêtes à prendre le relais de la base de données.

2. Stoppez le système SAP HANA du site 2.

3. Effectuez un retour arrière du groupe de cohérence HANA_Volumes afin d’activer l’accès en écriture pour les périphériques du site 1.

Promouvez les LUN du site 1 au rôle d’images principales et changez automatiquement le rôle des LUN du site 2 pour en faire des images secondaires :

naviseccli -h <primary VNX> mirror -async -promotegroup - name HANA_Volumes –o

4. Faites en sorte que les LUN principales soient disponibles pour les serveurs HANA du site 1.

Dans la Partie 2 de l’exemple d’utilisation 3, les LUN du site 1 ont été retirées de leurs storage groups, car elles n’étaient pas accessibles en écriture pendant la réplication. Saisissez la commande suivante pour les ajouter de nouveau aux storage groups, afin qu’elles soient disponibles pour les serveurs HANA du site 1 :

naviseccli -h <primary VNX> storagegroup -addhlu -gname Server01 -alu <alu> -hlu <hlu> –o



25

Répétez la commande précédente pour l’ensemble des LUN et storage groups. Remplacez la chaîne <alu> par l’identifiant de LUN de la baie et la chaîne <hlu> par l’identifiant de LUN de l’hôte. Préparez un script à cet effet. Les périphériques principaux du groupe de cohérence HANA_Volumes sont maintenant accessibles en lecture/écriture, et ils peuvent être découverts par le système d’exploitation pour démarrer le système SAP HANA sur le site 1. Assurez-vous que le fichier global.ini du système HANA contient les bonnes entrées de partition avec des pointeurs vers les UUID des périphériques principaux, avant de démarrer HANA.



26

Exemple d’utilisation 5 : Mise en miroir asynchrone à distance entre plusieurs baies VNX

Cet exemple d’utilisation montre comment créer des miroirs distants redémarrables d’une persistance de base de données SAP HANA (données et logs). La protection des données en cas de sinistre est assurée à l’aide de MirrorView/A. Dans ce cas particulier, la persistance de stockage de la base de données HANA est distribuée sur plusieurs baies VNX. Les besoins en matière de performance de SAP HANA permettent de connecter un nombre limité de nœuds de calcul HANA à une même baie VNX.

Remarque : référez-vous au livre blanc Storage Configuration Best Practices for SAP HANA TDI on EMC VNX Series Storage Systems, disponible sur le site de support en ligne EMC, pour plus de détails concernant l’évolutivité.

Quand une même base de données HANA est distribuée sur plusieurs baies VNX, vous ne pouvez plus gérer la dépendance de l’ordre des écritures à l’aide de groupes de cohérence, car ces groupes ne peuvent pas être mis en miroir sur l’ensemble des baies.

Dans cet exemple d’utilisation, la base de données SAP HANA crée une image à un point dans le temps cohérente de la persistance sur disque à l’aide des snapshots de stockage SAP HANA. Cette fonctionnalité, combinée à MirrorView/A, permet de créer une image ponctuelle cohérente redémarrable de la base de données sur le site 2.

Les snapshots de stockage SAP HANA sont déclenchés à l’aide d’une ligne de commande HANA et doivent être synchronisés avec les mises à jour de miroir de la persistance de base de données sur le site secondaire. Combinez les commandes correspondantes dans un script shell et faites en sorte qu’il soit exécuté à intervalles réguliers (toutes les 30 minutes, par exemple). Cet intervalle correspond à l’objectif de point de restauration (RPO) de la réplication.

La Figure 7 illustre une installation SAP HANA déployée sur deux baies VNX.

Figure 7. Réplication asynchrone avec plusieurs baies VNX principales



27

Pour configurer une mise en miroir asynchrone à distance avec plusieurs baies VNX, procédez comme suit :

1. Activez la connexion MirrorView entre les baies VNX (comme dans l’exemple d’utilisation 1) :

Remarque : dans cet exemple d’utilisation, la connexion MirrorView est requise entre la baie VNX1 et la baie VNX3, et entre la baie VNX2 et la baie VNX4, comme illustré Figure 7.

naviseccli -h <primary VNX1> mirror -enablepath <secondary VNX3> -connectiontype fibre naviseccli -h <primary VNX2> mirror -enablepath <secondary VNX4> -connectiontype fibre

2. Configurez un pool de LUN réservées dans chaque baie pour MirrorView/A, comme décrit dans la rubrique Pool de LUN réservées pour le mode MirrorView/A.

3. Activez l’image principale de chaque LUN sur les baies du site 1 :

naviseccli -h <primary VNX1> mirror -async -create -name Lun_Data1_Mirror -lun <alu> –o Répétez la commande précédente pour l’ensemble des LUN de la baie VNX1. Remplacez la chaîne <alu> par l’identifiant de LUN de la baie. naviseccli -h <primary VNX2> mirror -async -create -name Lun_Data3_Mirror -lun <alu> –o Répétez la commande précédente pour l’ensemble des LUN de la baie VNX2. Remplacez la chaîne <alu> par l’identifiant de LUN de la baie.

4. Ajoutez les images secondaires aux miroirs :

naviseccli -h <primary VNX1> mirror -async -addimage - name Lun_Data1_Mirror -arrayhost <secondary VNX3> -lun <alu> Répétez la commande précédente pour l’ensemble des miroirs de la baie VNX1. Remplacez la chaîne <alu> par l’identifiant de LUN de la baie. naviseccli -h <primary VNX2> mirror -async -addimage - name Lun_Data3_Mirror -arrayhost <secondary VNX4> -lun <alu> Répétez la commande précédente pour l’ensemble des miroirs de la baie VNX2. Remplacez la chaîne <alu> par l’identifiant de LUN de la baie.

5. Créez deux groupes de cohérence, HANA_Volumes1 et HANA_Volumes2 :

naviseccli -h <primary VNX1> mirror -async -creategroup - name HANA_Volumes1 –manualupdate –o naviseccli -h <primary VNX1> mirror -async -addtogroup – name HANA_Volumes1 -mirrorname Lun_Data1_Mirror Répétez la commande précédente pour l’ensemble des miroirs de la baie VNX1. naviseccli -h <primary VNX2> mirror -async -creategroup - name HANA_Volumes2 –manualupdate –o



28

naviseccli -h <primary VNX2> mirror -async -addtogroup – name HANA_Volumes2 -mirrorname Lun_Data3_Mirror Répétez la commande précédente pour l’ensemble des miroirs de la baie VNX2. La synchronisation initiale démarre automatiquement. Notez que la synchronisation de l’ensemble des périphériques peut prendre un peu de temps. Saisissez la commande suivante pour vérifier l’état de la synchronisation :

naviseccli -h <primary VNX1> mirror -async -listgroups - name HANA_Volumes1 –state naviseccli -h <primary VNX2> mirror -async -listgroups - name HANA_Volumes2 –state Quand l’état est Consistent ou Synchronized, les LUN du site 2 sont prêtes à prendre le relais de la base de données en cas de sinistre.

6. Créez un miroir distant redémarrable de la persistance de la base de données et créez un script shell incluant les étapes 6a à 6d. Planifiez l’exécution de ce script à intervalles réguliers, par exemple toutes les 30 minutes. Cet intervalle correspond à l’objectif de point de restauration (RPO) de la réplication. Le logiciel client SAP HANA doit être installé sur le serveur de gestion pour pouvoir exécuter les commandes HANA hdbsql.

Un miroir redémarrable contient un état cohérent de la base de données distribuée sur l’ensemble des LUN des baies principales. Utilisez les snapshots de stockage HANA pour obtenir cet état. Ces snapshots sont déclenchés avec hdbsql ou SAP HANA Studio. Ils permettent de créer une image redémarrable cohérente de la persistance HANA sur l’ensemble des baies principales. Cet état cohérent peut ensuite être transféré en toute sécurité sur les baies secondaires. Dès que les LUN du site secondaire sont promues au rôle de LUN principales, le système HANA peut redémarrer à partir de cet état cohérent.

a. Vérifiez que tous les nœuds HANA du site principal sont fonctionnels en saisissant la commande suivante sur l’un des nœuds en tant qu’utilisateur <sid>adm :

python $DIR_INSTANCE/exe/python_support/landscapeHostConfiguration.py. Utilisez echo $? pour afficher le code de retour lorsque vous exécutez la commande. Si le code de retour est 3 ou plus, cela signifie que le système HANA est dans un état valide et que vous pouvez poursuivre la procédure. Si le code de retour est 2 ou moins, cela signifie que le système HANA a un problème qui doit être résolu. Dans ce cas, vous ne pouvez pas créer une image cohérente redémarrable sur le site 2.

b. Préparez la base de données SAP HANA pour un snapshot de stockage. Vous devez exécuter cette commande HANA en tant qu’utilisateur <sid>adm :

hdbsql -i <instance number> -u <system user> -p <system password> BACKUP DATA CREATE SNAPSHOT



29

Remarque : référez-vous au document SAP HANA Administration Guide pour en savoir plus sur les snapshots de stockage HANA.

c. Quand vous avez terminé, mettez à jour manuellement chaque groupe de cohérence :

naviseccli -h <primary VNX1> mirror -async -syncgroup -name HANA_Volumes1 –o naviseccli -h <primary VNX2> mirror -async -syncgroup -name HANA_Volumes2 –o Saisissez la commande ci-après pour vérifier l’état des miroirs :

naviseccli -h <primary VNX1> mirror -async -listgroups -name HANA_Volumes1 –state naviseccli -h <primary VNX2> mirror -async -listgroups -name HANA_Volumes2 –state

d. Fermez le snapshot dès que le transfert démarre, sinon le système principal utilisera ce snapshot en cas de redémarrage. Déterminez dans un premier temps l’identifiant du snapshot de sauvegarde en saisissant la commande HANA suivante :

hdbsql -i <instance number> -j -u <system user> -p <system password> "SELECT BACKUP_ID, SYS_START_TIME FROM "PUBLIC"."M_BACKUP_CATALOG" WHERE ENTRY_TYPE_NAME = ’data snapshot’ AND STATE_NAME = ’prepared’" BACKUP_ID,SYS_START_TIME 1418133891303,"2014-12-09 09:04:51.303000000" L’identifiant de sauvegarde est requis pour fermer le snapshot. Assurez-vous que l’horodatage affiché correspond au snapshot que vous avez pris. Fermez ensuite le snapshot :

hdbsql -i <instance number> -u <system user> -p <system password> "BACKUP DATA CLOSE SNAPSHOT BACKUP_ID 1418133891303 SUCCESSFUL ’Remote Storage Clone’" Si le transfert de données échoue pour une raison ou une autre, vous devez abandonner le snapshot de stockage SAP HANA à l’aide de la commande suivante :

hdbsql -i <instance number> -u <system user> -p <system password> "BACKUP DATA CLOSE SNAPSHOT BACKUP_ID 1418133891303 UNSUCCESSFUL ’Storage Clone Failed’"

7. En cas de sinistre, ou pendant une maintenance planifiée sur le site principal, promouvez le site 2 au rôle de site principal, comme décrit dans les exemples d’utilisation 2 et 3. Pour redémarrer la base de données HANA sur le site 2, vous utiliserez l’image ponctuelle cohérente représentée par le snapshot de stockage de la persistance HANA.



30

Exemple d’utilisation 6 : Création de snapshots de base de données redémarrables et accessibles en écriture à des fins de réaffectation vers le site secondaire

Cet exemple d’utilisation, illustré Figure 8, montre comment créer une copie d’un système HANA à l’aide de snapshots VNX SnapView, sans interrompre la réplication. Une telle copie peut servir à créer des systèmes de test ou de développement, ou simplement à maintenir plusieurs images à un point dans le temps.

Les sessions VNX SnapView sont des snapshots à un point dans le temps cohérents de l’ensemble du système HANA. Lorsque vous créez un ensemble de LUN de snapshot, vous pouvez associer ces LUN à une session SnapView. Vous pouvez créer plusieurs sessions afin de conserver plusieurs états du système.

Remarque : vous ne pouvez pas suivre la procédure décrite dans cet exemple d’utilisation si le système HANA est installé sur plusieurs baies VNX principales. Si le système HANA est installé sur plusieurs baies VNX principales, vous devez utiliser un snapshot de stockage SAP HANA afin de créer une image à un point dans le temps cohérente de la base de données en complément des snapshots SnapView.

Figure 8. Utilisation de snapshots sur le site secondaire à des fins de test ou de

développement

1. Pour créer des snapshots de base de données redémarrables et accessibles en écriture à des fins de réaffectation vers le site secondaire, procédez comme suit : Créez des LUN de snapshot sur le site 2 :

Avant de pouvoir utiliser les snapshots cohérents, vous devez créer des LUN de snapshot. Ces LUN de snapshot seront allouées au pool de LUN réservées.

naviseccli -h <secondary VNX> snapview -createsnapshot <alu> -snapshotname Lun_Data1_Snap Répétez la commande précédente pour l’ensemble des LUN. Remplacez la chaîne <alu> par l’identifiant de LUN de la baie.



31

Les UUID des LUN de snapshot doivent figurer dans le fichier HANA global.ini si vous voulez démarrer HANA sur le site secondaire à l’aide des snapshots. Saisissez la commande suivante pour identifier ces UUID :

naviseccli -h <secondary VNX> snapview –listsnapshots SnapView logical unit name: Lun_Log2_Snap SnapView logical unit ID: 60:06:01:60:32:E0:35:00:A8:08:FB:F4:46:80:E4:11 Target Logical Unit: 215 State: Inactive La sortie contiendra l’ensemble des LUN de snapshot.

Remarque : le système d’exploitation ajoute le préfixe 3 aux UUID.

2. Créez une session SnapView :

naviseccli -h <secondary VNX> snapview -startsession HANA_Snap -lun <LUN list> -consistent

Remarque : vous devez activer un snapshot sur cette session avant de pouvoir y accéder.

Les paramètres Consistent garantissent que le système HANA peut redémarrer.

Remplacez l’option <LUN list> par la liste de toutes les LUN du groupe de cohérence. Par exemple, 310 315 320 210 215 220.

3. Activez la session SnapView et faites en sorte que les LUN de snapshot soient disponibles pour les hôtes du site 2, comme suit :

naviseccli -h <secondary VNX> snapview -activatesnapshot HANA_Snap -snapshotname Lun_Data1_Snap Répétez la commande précédente pour l’ensemble des LUN de snapshot. Créez un script à cet effet. Une fois les LUN activées, vous devez les ajouter aux storage groups du site 2 en tant que LUN de snapshot à l’aide de la commande suivante :

naviseccli -h <secondary VNX> storagegroup -addsnapshot - gname server05 -hlu <hlu> -snapshotname Lun_Data1_Snap Répétez la commande précédente pour l’ensemble des LUN de snapshot et des storage groups. Remplacez la chaîne <hlu> par l’identifiant de LUN de l’hôte. Le système HANA peut à présent être redémarré sur le site 2 à l’aide des LUN de snapshot. Assurez-vous que les bons UUID de LUN de snapshot figurent dans le fichier HANA global.ini.

4. Supprimez la session SnapView (facultatif) :

Vous pouvez supprimer la session SnapView si vous n’avez plus besoin des LUN.

Saisissez la commande suivante pour supprimer la session SnapView des storage groups :

naviseccli -h <secondary VNX> snapview -stopsession HANA_Snap -o



32

Conclusion

Si vous déployez des environnements SAP, y compris des bases de données SAP HANA, vous pouvez assurer la protection et la disponibilité de vos données critiques en toutes circonstances.

Grâce à la gamme VNX et à la technologie de cohérence MirrorView, ainsi qu’aux snapshots SnapView, vous pouvez mettre en œuvre une réplication cohérente entre votre site de production et votre site de reprise après sinistre, afin de restaurer de manière fiable vos données ou de tester les nombreuses fonctions métiers de l’environnement SAP. Les baies de stockage EMC VNX offrent une même plate-forme fiable pour les couches logicielle et matérielle, aussi bien pour les bases de données SAP HANA que les bases de données traditionnelles. MirrorView et SnapView assurent systématiquement la haute disponibilité et la continuité d’activité des environnements critiques, pour une protection des données synchrone et asynchrone.

Les exemples d’utilisation de ce livre blanc illustrent les bonnes pratiques en matière de mise en œuvre d’une réplication de stockage SAP HANA sur des baies VNX, à l’aide d’outils à l’efficacité éprouvée, déjà largement utilisés par les clients. Ces exemples d’utilisation illustrent la procédure de restauration à l’aide de MirrorView et de SnapView, et montrent comment mettre en œuvre des répliques de bases de données restaurables et redémarrables, en local ou à distance.

Résumé

Résultats



33

Références

Vous trouverez la documentation EMC ci-dessous sur france.emc.com ou sur le site de support en ligne EMC.

• MirrorView Knowledgebook Releases 30-33 – A Detailed Review

Ce livre blanc est un guide complet des fonctionnalités, des opérations et des bonnes pratiques MirrorView. Il aborde les spécificités du mode synchrone (MirrorView/S) et du mode asynchrone (MirrorView/A), et les compare afin de déterminer celui qu’il vaut mieux employer dans telle ou telle situation.

• Storage Configuration Best Practices for SAP HANA Tailored Data Center Integration on EMC VNX Series Storage Systems

Ce livre blanc montre comment repousser les limites du modèle actuel d’appliance SAP HANA en utilisant l’intégration sur mesure du datacenter (TDI) sur les systèmes de stockage EMC VNX et grâce à l’intégration de SAP HANA dans une infrastructure de datacenter existante.

• VNX Command Line Interface Reference for Block 5.33

Ce document décrit les commandes de l’interface de ligne de commande pour la configuration et la gestion des opérations de stockage en mode bloc sur VNX, y compris les commandes CLI relatives aux applications (Unisphere QoS Manager, Unisphere Analyzer, MirrorView/Asynchronous, MirrorView/Synchronous, SAN Copy, SnapView, Snapshots, ESRS sur le processeur de stockage et DRE).

• Using VNX Replicator 8.1

Ce document explique comment effectuer une réplication sur des baies EMC VNX à l’aide de VNX Replicator.

Vous trouverez la documentation SAP à l’adresse http://help.sap.com/hana_appliance.

• SAP HANA Master Guide

Utilisez ce guide pour planifier l’installation de votre environnement système SAP HANA.

• SAP HANA Server Installation and Update Guide

Utilisez ce guide pour installer et mettre à jour un système SAP HANA à l’aide des outils de gestion du cycle de vie SAP HANA.

• SAP HANA Technical Operations Manual

Utilisez ce guide pour gérer et utiliser votre environnement système SAP HANA.

• SAP HANA Administration Guide

Utilisez ce guide pour l’ensemble des tâches administratives SAP HANA que les administrateurs système doivent effectuer régulièrement ou à la demande à l’aide des outils d’administration SAP HANA (Studio, Cockpit, gestion du cycle de vie, administration XS et HDBSQL).

• SAP HANA Troubleshooting and Performance Analysis Guide

Utilisez ce guide pour résoudre les problèmes de performance propres à votre base de données SAP HANA et déterminer comment améliorer les performances de manière générale.

Documentation EMC

Documentation SAP

http://france.emc.com/�

https://support.emc.com/�

http://help.sap.com/hana_appliance�

Documents

BONNES PRATIQUES EN MATIÈRE DE CONTINUITÉ … · Bonnes pratiques en matière de continuité d’activité pour l’intégration sur mesure du datacenter SAP HANA sur les systèmes