Bonnes pratiques de configuration du stockage pour l

Transcription

Livre blanc
BONNES PRATIQUES DE CONFIGURATION
DU STOCKAGE POUR L’INTÉGRATION SUR
MESURE DU DATACENTER SAP HANA SUR
LES SYSTÈMES DE STOCKAGE EMC VMAX ET
VMAX3
• Systèmes de stockage VMAX (10K, 20K et 40K) et VMAX3
(100K, 200 K et 400K) pour SAP HANA
Solutions EMC
Résumé
Ce livre blanc présente une nouvelle manière de surmonter les restrictions du modèle
d’appliance SAP HANA (High Performance Analytical Appliance) actuel. Grâce à
l’intégration sur mesure du datacenter (TDI, Tailored Data Center Integration) dans les
systèmes de stockage EMC® VMAX® et VMAX3TM, les clients peuvent intégrer SAP
HANA dans une infrastructure de datacenter déjà bien établie, ce qui procure de
nombreux avantages.
Février 2015
Copyright © 2014-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 cette publication 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 EMC via le lien Législation, sur http://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 H12342.3
Bonnes pratiques de configuration du stockage pour l’intégration sur mesure du
datacenter SAP HANA dans les systèmes de stockage EMC VMAX et VMAX3
Livre blanc
2
Table des matières
Résumé analytique ............................................................................................................................. 5
Business Case ................................................................................................................................. 5
Présentation de solution .................................................................................................................. 6
Principaux avantages ....................................................................................................................... 6
Introduction ....................................................................................................................................... 7
Objectif ............................................................................................................................................ 7
Périmètre ......................................................................................................................................... 7
Audience.......................................................................................................................................... 7
Terminologie .................................................................................................................................... 8
Utilisation du stockage VMAX ou VMAX3 pour SAP HANA .................................................................... 9
Scale-up ou scale-out ...................................................................................................................... 9
Évolutivité TDI SAP HANA ................................................................................................................. 9
Persistance SAP HANA ................................................................................................................... 10
Considérations relatives à la capacité ............................................................................................ 10
Considérations relatives aux disques ............................................................................................. 11
Modèles d’E/S HANA...................................................................................................................... 12
Système de fichiers de données ................................................................................................ 12
Système de fichiers de log ......................................................................................................... 13
Images OS SAP HANA sur VMAX ..................................................................................................... 13
Système de fichiers partagé SAP HANA sur VMAX ........................................................................... 13
Environnements virtuels................................................................................................................. 14
Persistance SAP HANA dans un environnement virtuel .............................................................. 14
Multipathing vSphere ................................................................................................................ 14
Recommandations de configuration avec VMAX (baies 10K, 20K et 40K) pour SAP HANA................... 15
Connectivité hôte ........................................................................................................................... 15
Exigences en matière de directeur/port FA ..................................................................................... 15
Évolutivité de VMAX ....................................................................................................................... 16
Considérations relatives au provisionnement virtuel ...................................................................... 17
Considérations relatives aux configurations RAID ...................................................................... 18
Thin pools ................................................................................................................................. 18
Métavolumes pour les données et le log.................................................................................... 18
Vue de masquage .......................................................................................................................... 18
Groupe d’initiateurs .................................................................................................................. 18
Groupe de ports ........................................................................................................................ 18
Groupe de stockage .................................................................................................................. 18
Livre blanc
3
Recommandations de configuration avec VMAX3 (baies 100K, 200K et 400K) pour SAP HANA .......... 20
Éléments FAST ............................................................................................................................... 20
Groupe de disques .................................................................................................................... 20
TDAT .......................................................................................................................................... 20
Pool de données ....................................................................................................................... 21
Pool de ressources de stockage ................................................................................................ 21
Objectif de niveau de service (SLO) ................................................................................................ 21
Connectivité hôte ........................................................................................................................... 23
Exigences en matière de directeur/port FA ..................................................................................... 23
Vue de masquage .......................................................................................................................... 24
Groupe d’initiateurs .................................................................................................................. 24
Groupes de ports ....................................................................................................................... 24
Groupe de stockage .................................................................................................................. 25
Évolutivité VMAX3 .......................................................................................................................... 26
Accès au stockage VMAX à partir des nœuds SAP HANA .................................................................... 27
Multipathing Linux natif (DM MPIO)................................................................................................ 27
SLES 11 ..................................................................................................................................... 27
RHEL 6.5 .................................................................................................................................... 27
Liste noire ................................................................................................................................. 28
Système de fichiers XFS ................................................................................................................. 29
Linux LVM ...................................................................................................................................... 29
SAP HANA Storage Connector API ................................................................................................... 29
Fichier global.ini SAP HANA ....................................................................................................... 30
Conclusion ....................................................................................................................................... 31
Résumé .......................................................................................................................................... 31
Conclusions ................................................................................................................................... 31
Références ....................................................................................................................................... 32
Documentation EMC ...................................................................................................................... 32
Documentation VMware ................................................................................................................. 32
Documentation SAP ....................................................................................................................... 32
Ressources Web ........................................................................................................................ 32
Notes d’option de déploiement ................................................................................................. 32
Note de virtualisation ................................................................................................................ 33
Livre blanc
4
Résumé analytique
Business Case
SAP HANA est une plate-forme in-memory qui peut être déployée en local (sur site) ou
dans le Cloud. Cette plate-forme révolutionnaire est particulièrement adaptée à
l’exécution de tâches d’analytique en temps réel ainsi qu’au développement et au
déploiement d’applications en temps réel. La base de données SAP HANA est au
cœur de cette plate-forme de données en temps réel. Elle se distingue de tous les
autres moteurs de base de données actuellement disponibles sur le marché.
Les entreprises possédant d’importants volumes de données ont besoin de données
récentes, disponibles en temps réel et très rapidement, avec un temps de réponse
court et une véritable interactivité. Les données doivent également être disponibles
sans préfabrication, préparation, préagrégation ou réglage.
SAP HANA associe des composants logiciels SAP optimisés sur du matériel éprouvé
fourni par des partenaires SAP.
SAP HANA peut être déployé selon deux modèles différents, comme illustré sur la
Figure 1 :
•
Modèle d’appliance
•
Modèle TDI (intégration sur mesure de datacenter)
Figure 1.
Comparaison entre le modèle d’appliance SAP HANA et le modèle TDI
Par défaut, une appliance SAP HANA intègre des composants de stockage, de calcul
et de réseau. L’appliance est précertifiée par SAP, conçue par des partenaires
fournisseurs de matériel SAP HANA et livrée aux clients avec tous les composants
logiciels préinstallés, y compris les systèmes d’exploitation et le logiciel SAP HANA.
L’approche TDI est plus ouverte et procure un plus haut niveau de flexibilité que le
modèle de déploiement d’appliance. Les serveurs SAP HANA doivent toujours
répondre aux exigences SAP HANA et être des serveurs HANA certifiés. Toutefois, les
composants réseau et de stockage peuvent désormais être partagés dans les
environnements clients. De cette manière, les clients peuvent utiliser les baies de
stockage d’entreprise existantes pour SAP HANA et intégrer SAP HANA de manière
transparente dans les opérations de datacenter existantes, telles que la reprise après
Livre blanc
5
sinistre, la protection, la surveillance et la gestion des données. Cela réduit le timeto-value, les risques et les coûts en vue d’une adoption globale de SAP HANA.
Présentation de
solution
Les baies de stockage d’entreprise utilisées dans les déploiements TDI SAP HANA
doivent être précertifiées par SAP de manière à répondre aux exigences
fonctionnelles et de performances de SAP HANA 1. Nous 2 avons testé les
performances au moyen de l’outil de configuration et de vérification du matériel SAP
HANA (hwcct) et de différents générateurs de charge SAP HANA sur les systèmes de
stockage d’entreprise EMC® VMAX® 10K, 20K et 40K et VMAX3TM 100K, 200K et 400K.
Reposant sur les résultats de ces tests, le présent livre blanc décrit les
recommandations de configuration du stockage pour les baies VMAX et VMAX3, afin
de répondre aux exigences de performances de SAP (indicateurs clés de
performances TDI SAP HANA pour le débit de données et la latence) et d’assurer une
disponibilité optimale pour la persistance de la base de données sur disque.
Remarque : SAP recommande aux clients TDI d’exécuter l’outil hwcct dans leur
environnement pour s’assurer que l’implémentation TDI HANA répond aux critères de
performances SAP.
Principaux
avantages
Cette solution présente les avantages suivants :
•
Intégration de HANA dans l’infrastructure de datacenter existante
•
Utilisation du stockage d’entreprise partagé sur la base des concepts
multisites déjà disponibles pour tirer parti des processus d’exploitation et
d’automatisation établis.
•
Transition aisée vers la nouvelle architecture et mise à profit des services EMC
pour minimiser les risques.
•
Utilisation des processus opérationnels, compétences et outils existants et
élimination des risques et des coûts importants associés au changement
opérationnel.
1
Les systèmes EMC VMAX et VMAX3 sont certifiés par SAP.
Dans ce document, le terme « nous » désigne l’équipe d’ingénieurs GSE (Global Solutions
Engineering) qui a validé la solution.
2
Livre blanc
6
Introduction
Objectif
Depuis le lancement de SAP HANA, les clients ont eu la possibilité d’utiliser le
modèle d’appliance SAP HANA pour le déploiement. Ce modèle présentait toutefois
un certain nombre de limitations :
•
Choix limité au niveau des serveurs, des réseaux et du stockage
•
Impossibilité d’utiliser l’infrastructure de datacenter et les processus
opérationnels existants
•
Tailles fixes pour les capacités de stockage SAP HANA (stockage faisant partie
de l’appliance)
•
Peu de connaissance et de contrôle des composants critiques dans l’appliance
HANA
•
Impossibilité d’utiliser l’infrastructure de datacenter existante et les coûts
opérationnels associés, d’où une augmentation des coûts initiaux
d’infrastructure.
•
Tailles fixes pour les capacités de serveur et de stockage HANA, augmentation
des coûts en raison d’une capacité insuffisante et de l’incapacité à répondre
rapidement aux exigences de développement imprévues
Ce livre blanc décrit une solution qui utilise SAP HANA dans un scénario de
déploiement TDI sur des systèmes de stockage d’entreprise EMC VMAX et VMAX3.
Cette solution réduit les coûts opérationnels et matériels, limite les risques et
améliore la flexibilité quant au choix du fournisseur des serveurs et du réseau.
Toutes les recommandations de configuration présentées dans ce document
reposent sur les exigences de haute disponibilité de SAP, ainsi que sur les résultats
des tests de performances nécessaires pour répondre aux indicateurs clés de
performances de SAP pour le modèle TDI SAP HANA.
Périmètre
Audience
Ce document indique les bonnes pratiques et prodigue des conseils pour le
déploiement de la base de données SAP HANA sur les systèmes de stockage EMC
VMAX et VMAX3. Il fournit ainsi les informations suivantes :
•
Présentation des principales technologies de la solution
•
Description des exigences de configuration pour les systèmes VMAX et VMAX3
avec SAP HANA
•
Instructions pour l’accès au stockage VMAX et VMAX3 à partir des nœuds SAP
HANA
Ce livre blanc s’adresse aux intégrateurs système, aux administrateurs de systèmes
ou de stockage, aux clients, aux partenaires et aux membres de l’équipe EMC
Professional Services qui doivent configurer une baie de stockage VMAX ou VMAX3
dans un environnement TDI pour SAP HANA.
Livre blanc
7
Terminologie
Ce livre blanc utilise la terminologie figurant dans le Tableau 1.
Tableau 1.
Terminologie
Terme
Définition
Hôte de traitement
HANA
Hôte HANA qui traite les données
Hôte de secours
HANA
Hôte HANA qui prend le relais en cas de défaillance de l’hôte de
traitement
Livre blanc
8
Utilisation du stockage VMAX ou VMAX3 pour SAP HANA
SAP HANA est une base de données in-memory. Les données sont conservées dans la RAM
d’un ou de plusieurs hôtes de traitement SAP HANA. Toutes les activités de base de
données, telles que les lectures, insertions, mises à jour ou suppressions, sont par ailleurs
exécutées dans la mémoire principale de l’hôte et non sur le disque. C’est ce qui différentie
SAP HANA des autres bases de données traditionnelles, où seule une partie des données
est mise en cache dans la RAM et les données restantes résident sur le disque.
Scale-up ou scaleout
Vous pouvez installer la base de données SAP HANA sur un système à hôte unique
(scale-up) ou sur des systèmes à plusieurs hôtes (scale-out). Dans les environnements à
hôte unique, la base de données doit tenir dans la RAM d’un seul hôte. Les systèmes à
hôte unique sont les environnements de prédilection pour les charges applicatives de
type OLTP (Online Transaction Processing) telles que SAP Business Suite.
Dans les environnements à plusieurs hôtes, les tables de base de données sont réparties
entre les mémoires vives de plusieurs serveurs. Ces environnements utilisent des hôtes
de travail et de secours. L’hôte de traitement est un composant actif qui accepte et traite
les requêtes de base de données. L’hôte de secours est un composant passif. Tous les
services de base de données y sont exécutés, mais aucune donnée ne réside dans la
RAM. Il attend qu’un hôte de traitement avail tombe en panne pour prendre le relais. Ce
processus est appelé « basculement sur incident automatique de l’hôte ».
Étant donné que, dans ces déploiements, la capacité in-memory peut être très élevée, les
clusters HANA scale-out sont parfaitement adaptés aux charges applicatives de type
OLAP (Online Analytical Processing) avec des datasets très volumineux.
Évolutivité TDI SAP L’évolutivité TDI SAP HANA définit le nombre d’hôtes de traitement HANA de production
(dans les installations scale-out) ou d’hôtes individuels (dans les installations scale-up)
HANA
qui peuvent être connectés à des baies de stockage d’entreprise et qui restent conformes
aux indicateurs clés de performances de SAP pour le stockage d’entreprise. Comme la
capacité utilisée sur le disque pour la persistance HANA est toujours liée à la capacité de
la RAM de la base de données HANA, la capacité requise sur disque pour plusieurs hôtes
HANA n’est pas un facteur restrictif dans la plupart des cas. Les baies de stockage
d’entreprise peuvent fournir une capacité bien plus grande que celle nécessaire pour
HANA. L’évolutivité dépend de plusieurs autres facteurs. Par exemple :
•
Modèle de baie, taille du cache, types de disques
•
Bande passante, débit et latence
•
Utilisation générale et consommation des ressources de la baie
•
Mode de connexion de l’hôte HANA à la baie
•
Configuration du stockage de la persistance HANA
Remarque : les données d’évolutivité figurant dans ce document pour les baies VMAX et
VMAX3 sont des recommandations basées sur les tests de performances réalisés sur
différents modèles. Le nombre réel d’hôtes HANA pouvant être connectés à un système
VMAX ou VMAX3 dans un environnement client peut être supérieur ou inférieur au nombre
d’hôtes HANA indiqué dans ce document. Utilisez l’outil SAP HANA hwcct dans les
environnements clients pour valider les performances SAP HANA et déterminer le nombre
maximal possible d’hôtes HANA sur une baie de stockage spécifique.
Livre blanc
9
Persistance
SAP HANA
SAP HANA utilise le stockage sur disque pour les objectifs suivants :
•
Maintenir la persistance des données in-memory sur disque pour éviter toute
perte de données due à une panne de courant et permettre un basculement sur
incident automatique de l’hôte, auquel cas un hôte de secours HANA prend en
charge les données in-memory de l’hôte de traitement défaillant dans les
installations scale-out
•
Consigner les informations sur les modifications de données (journal redo log)
À cet effet, chaque hôte de traitement SAP HANA (scale-out) ou hôte individuel (scaleup) nécessite deux systèmes de fichiers pour le stockage sur disque : un pour les
données et un pour le log.
Considérations
relatives à la
capacité
En règle générale, la capacité requise pour la persistance SAP HANA sur disque
dépend de la taille de la base de données in-memory et de la taille de la RAM des
serveurs HANA.
Chaque client SAP HANA doit commencer par réaliser un dimensionnement de la
mémoire et du CPU dans le cadre du dimensionnement d’un déploiement SAP HANA.
Pour les nouvelles implémentations SAP HANA, le dimensionnement de la mémoire et
du CPU pour un système SAP HANA se fait au moyen de la version HANA de l’outil SAP
Quick Sizer, disponible sur le site Web SAP Service Marketplace. Dans le cas de
systèmes migrant vers SAP HANA, SAP fournit les outils et les rapports nécessaires à
un dimensionnement correct de la mémoire HANA.
Après avoir déterminé la mémoire requise, vous pouvez estimer les besoins en
volumétrie à l’aide des règles de dimensionnement figurant dans le livre blanc SAP
relatif aux exigences en matière de stockage pour SAP HANA. Les systèmes de
fichiers doivent présenter les caractéristiques suivantes :
•
1x RAM pour le système de fichiers de données
•
½x RAM pour le système de fichiers de log avec 512 Go ou moins, ou au moins
512 Go pour le système de fichiers de log avec 512 Go de RAM ou plus
Pour SAP, la taille de la RAM fait référence à la taille de la base de données, par
opposition à la taille de la mémoire physique des serveurs. Par exemple, la base de
données HANA peut utiliser 1,3 To de RAM sur un hôte unique, mais l’hôte a une
capacité de RAM physique de 2 To. SAP recommande de procéder au
dimensionnement sur la base de la taille réelle de la base de données, soit 1,3 To
dans cet exemple.
Remarque : les critères de dimensionnement SAP ne tiennent pas compte de la croissance
future de la base de données.
Dans certaines situations, vous pouvez toutefois avoir besoin d’augmenter la taille
d’un système de fichiers de données ou de log. EMC recommande de dimensionner la
persistance de la base de données (systèmes de fichiers de données et de log) au
minimum sur la base de la capacité de RAM physique des hôtes HANA.
Pour calculer la capacité de stockage utile requise pour la persistance HANA d’une
appliance scale-up (hôte unique) ou scale-out (plusieurs hôtes), vous avez besoin
des informations suivantes :
Livre blanc
10
•
(A) - Taille de la RAM d’un hôte de traitement HANA
•
(B) - Nombre d’hôtes de traitement HANA
Par exemple, utilisez les formules suivantes afin de calculer la capacité requise pour
une appliance scale-out HANA 6+1, où chaque serveur dispose de 2 To de RAM :
•
Capacité totale pour les données = (A) * (B) = 2 To * 6 = 12 To
•
Capacité totale pour le log = 512 Go * (B) = 512 Go * 6 = 3 To
•
Capacité utile totale pour la persistance HANA = 12 To + 3 To = 15 To
Vous pouvez utiliser la capacité éventuellement disponible ou ajouter de la capacité
pour prendre en charge les systèmes de fichiers sans exigences de performances,
tels que les LUN de système d’exploitation (voir Images OS SAP HANA sur VMAX pour
en savoir plus), et pour le système de fichiers partagé HANA (voir Système de fichiers
partagés SAP HANA sur VMAX pour de plus amples informations).
Considérations
relatives aux
disques
En raison de la charge applicative spécifique de la base de données SAP HANA avec
essentiellement des E/S en écriture, utilisez les types de disques suivants :
•
Disques de 10 000 t/min
•
Disques de 15 000 t/min
•
Disques EFD (Enterprise Flash Drive)
Pour SAP HANA sur des baies VMAX 10K, 20K ou 40K, nous recommandons d’utiliser
une stratégie à un seul niveau (type/technologie de disque et protection RAID). En
effet, toutes les écritures sur le stockage VMAX sont envoyées au cache persistant
VMAX et enregistrées ultérieurement sur les disques. Voilà pourquoi la charge
applicative en écriture HANA tire principalement parti du cache VMAX avant les
éventuels avantages des technologies FAST (Fully Automated Storage Tiering) et
multiniveaux. Une stratégie à un seul niveau constitue une solution adéquate pour
HANA et simplifie le déploiement.
Le stockage VMAX 10K, 20K ou 40K permet de séparer la charge applicative HANA
des charges applicatives non HANA sur une baie de stockage partagée, au moyen
d’un groupe de disques de stockage dédié. Il est possible d’utiliser un groupe de
disques dédié si l’impact des applications non HANA sur les disques partagés est
trop élevé, si bien que les hôtes HANA ne répondent plus aux exigences de
performances. Ce n’est pas une obligation, et les périphériques HANA peuvent
également résider sur des disques partagés.
Avec un stockage VMAX3 100K, 200K ou 400K, les performances de certaines
applications sont contrôlées par le provisionnement d’objectif de niveau de service et
les limites d’hôte. Avec VMAX3, et en raison des améliorations mises en œuvre dans
la technologie FAST, vous pouvez désormais combiner des disques durs de 10 000
ou 15 000 t/min et des disques EFD.
Le nombre de disques requis pour la persistance HANA dépend du type de disque
(10 000 t/min, 15 000 t/min ou EFD), de la capacité requise et de la protection RAID.
Une protection en miroir (RAID 1) sur la baie VMAX garantit des performances
optimales pour les applications caractérisées par des activités d’écriture intensives
comme SAP HANA. Ce principe s’applique essentiellement aux disques de 10 000 et
Livre blanc
11
15 000 t/min. Les disques EFD peuvent faire l’objet d’une configuration RAID 5 de
type 3+1 ou 7+1 (3+1 étant susceptible d’offrir une disponibilité plus élevée,
notamment pour les disques EFD de grande capacité).
Pour répondre aux exigences IOPS des hôtes sur les disques de 10 000 ou
15 000 t/min, vous devez distribuer la persistance HANA sur un certain nombre de
disques. Un hôte de traitement HANA génère approximativement 1 200 opérations
d’E/S par seconde (IOPS). Un disque dur de 10 000 t/min peut prendre en charge
environ 120 IOPS et un disque de 15 000 t/min environ 150 IOPS.
Par exemple, dans l’installation scale-out HANA 6+1 (6 hôtes de traitement et un hôte
de secours, 7 200 IOPS pour les hôtes au total) et une configuration du stockage à un
niveau, distribuez la persistance sur au moins 60 disques de 10 000 t/min ou
48 disques de 15 000 t/min. Choisissez une taille de disque correspondant à la
capacité requise et offrant le meilleur coût total de possession (TCO).
Par exemple, avec l’installation scale-out de type 6+1, la persistance de HANA
requiert 15 To de capacité utile. Le Tableau 2 compare la capacité utile des
différentes tailles de disque et de la protection RAID (en miroir).
Tableau 2.
Modèles d’E/S
HANA
Taille de disque (10 000 ou 15 000 t/min) pour la persistance HANA 15 To
Taille du
disque
Capacite
utile par
disque
Capacité
utile avec
60 disques
Capacité
utile mise en Commentaires
miroir
300 Go
268 Go
16 080 Go
8,40 Go
Ne répond pas aux
exigences de capacité
400 Go
366 Go
21 960 Go
10 980 Go
Ne répond pas aux
exigences de capacité
600 Go
536 Go
32 160 Go
16 080 Go
Répond aux exigences de
capacité avec le meilleur
TCO. Croissance future
limitée.
900 Go
820 Go
49 200 Go
24 600 Go
Répond aux exigences
de capacité et permet
une croissance future.
Les systèmes de fichiers persistants SAP HANA présentent des modèles d’E/S
différents, décrits en détail dans le livre blanc relatif aux exigences en matière de
stockage pour SAP HANA.
Système de fichiers de données
L’accès au système de fichiers de données est principalement aléatoire avec
différentes tailles de blocs allant de 4 Ko à 64 Mo. Les données font l’objet d’une
écriture asynchrone avec des E/S parallèles sur le système de fichiers de données.
Dans des conditions normales de fonctionnement, la plupart des E/S sur le système
de fichiers de données sont des écritures. Les données sont lues à partir du système
de fichiers uniquement durant le redémarrage de la base de données, le basculement
sur incident pour la haute disponibilité (HA) ou le chargement d’une table de
stockage en colonnes.
Livre blanc
12
Système de fichiers de log
L’accès au système de fichiers de log est essentiellement séquentiel avec différentes
tailles de blocs allant de 4 Ko à 1 Mo. SAP HANA conserve un tampon de 1 Mo pour le
journal redo log in-memory. Dès que le tampon est plein, il fait l’objet d’une écriture
synchrone sur le système de fichiers de log. Si une transaction de base de données est
validée avant que le tampon de log soit plein, un bloc plus petit est écrit sur le système
de fichiers. En raison de l’écriture synchrone des données sur le système de fichiers de
log, il est important d’avoir une faible latence pour les E/S sur le périphérique de
stockage, notamment pour les petites tailles de blocs de 4 Ko et 16 Ko.
À l’instar du système de fichiers de données, dans des conditions normales de
fonctionnement de la base de données, la plupart des E/S sur le système de fichiers
de log sont des écritures. Les données sont lues à partir du système de fichiers
uniquement durant le redémarrage de la base de données, le basculement sur
incident pour la haute disponibilité (HA), la sauvegarde du log ou la restauration de
la base de données.
Images OS
SAP HANA sur
VMAX
Vous pouvez démarrer des nœuds SAP HANA à partir de disques locaux ou bien à
partir de périphériques VMAX3 et d’un SAN. Si vous démarrez à partir d’un SAN,
suivez les bonnes pratiques indiquées dans la section « Démarrage à partir d’un
SAN » du Guide de connectivité hôte d’EMC pour Linux.
La capacité requise pour le système d’exploitation est d’environ 100 Go par hôte
HANA (de travail et de veille) ; cela inclut la capacité pour le répertoire / usr/sap.
Système de
fichiers partagé
SAP HANA sur
VMAX
Dans une implémentation scale-out SAP HANA, installez les binaires de base de
données SAP HANA sur un système de fichiers partagé présenté à tous les hôtes d’un
système sous un point de montage /hana/shared. Si un hôte a besoin d’écrire un
vidage de mémoire (pouvant lire jusqu’à 90 % de la taille de la RAM), celui-ci sera
stocké sur ce système de fichiers. En fonction de l’infrastructure et des besoins
spécifiques du client, les options pour les systèmes de fichiers sont les suivantes :
•
Le stockage en mode bloc VMAX peut créer un système de fichiers partagé au
moyen d’un système de fichiers en cluster, tel qu’un système OCFS2 (Oracle
Cluster File System 2), en plus des LUN en mode bloc. SUSE Linux fournit des
fonctionnalités OCFS2 avec le package haute disponibilité ; une licence SUSE
est par ailleurs requise. Le package haute disponibilité fait également partie du
système SUSE Linux Enterprise Server (SLES) pour la distribution d’applications
SAP à partir de SAP, utilisé par la plupart des fournisseurs d’appliances HANA.
•
Des systèmes NAS, tels qu’EMC VNX®, peuvent être utilisés en lieu et place
d’OCFS2 afin de fournir un partage NFS pour le système de fichiers partagé
HANA.
•
Une offre eNAS (NAS intégré) des baies VMAX3 peut fournir le partage NFS.
La taille du système de fichiers partagé HANA doit correspondre à la taille de RAM
totale de la base de données, soit le nombre d’hôtes de traitement multiplié par la
taille de la RAM d’un seul nœud. Le livre blanc relatif aux exigences en matière de
stockage pour SAP HANA donne des informations plus détaillées à ce sujet.
Livre blanc
13
Environnements
virtuels
Les clients ont la possibilité d’exécuter SAP HANA sur l’infrastructure virtualisée
VMware (vSphere). Certaines restrictions et limitations s’appliquent aux
environnements virtualisés, par exemple la taille de RAM maximale d’un nœud HANA.
Consultez les notes SAP OSS correspondantes et suivez les bonnes pratiques
VMware pour le déploiement de SAP HANA sur VMware vSphere.
Pour la persistance SAP HANA sur des baies VMAX dans les environnements virtuels,
toutes les recommandations en matière de configuration physique figurant dans ce
document s’appliquent également aux environnements virtuels. Vous devez
cependant également tenir compte des points suivants dans le cas des
environnements virtuels :
Persistance SAP HANA dans un environnement virtuel
Ajoutez à l’hôte VMware ESX les LUN de données et de log pour un hôte HANA virtuel
et créez un datastore VMFS (Virtual Machine File System) pour chaque LUN. Vous
pouvez ensuite créer un disque virtuel par datastore VMFS et l’ajouter comme LUN de
données ou de log à la machine virtuelle HANA. Reportez-vous aux bonnes pratiques
VMware pour disposer d’un adaptateur SCSI virtuel optimisé.
Multipathing vSphere
Une machine virtuelle HANA n’utilise pas la fonctionnalité multipathing du mappeur
de périphériques Linux (Linux Device Mapper Multipath). Les LUN de données et de
log sont visibles en tant que périphérique unique. Par exemple, / dev/sdb et le
système de fichiers XFS doivent être créés sur ce périphérique unique.
Sur l’hôte VMware ESX, nous recommandons toutefois d’utiliser EMC PowerPath/VE
pour gérer intelligemment les chemins d’E/S et optimiser les performances d’E/S.
Livre blanc
14
Recommandations de configuration avec VMAX (baies 10K, 20K et 40K)
pour SAP HANA
Les recommandations de configuration ci-dessous s’appliquent aux systèmes HANA
de production déployés sur les baies de stockage d’entreprise VMAX 10K, 20K et
40K. Les systèmes HANA de production dans les environnements TDI doivent
répondre aux exigences de performances de SAP (indicateurs clés de performances)
et aux critères de configuration spécifiques suivants.
Connectivité hôte
Les nœuds HANA se connectent aux baies VMAX par le biais d’un réseau de stockage
(SAN) Fibre Channel. Tous les composants SAN nécessitent une liaison 8 Gbit/s, et la
topologie SAN doit suivre les bonnes pratiques avec l’ensemble des liaisons et des
composants redondants.
Exigences en
matière de
directeur/port FA
Une attention toute particulière est requise lors de la connexion de nœuds HANA aux
ports de directeur front-end (ports FA) d’une baie VMAX.
Sur un directeur VMAX, deux ports FA partagent un même cœur de CPU dédié. Par
exemple, FA-1E:0 et FA-1E:1 partagent le même cœur. Pour bénéficier de
performances d’E/S optimales pour les déploiements HANA de production, vous
devez tenir compte des impératifs suivants pour les ports FA d’une baie VMAX :
•
Allouez des ports FA à HANA et ne les partagez pas avec des applications non
HANA.
•
Utilisez un seul port FA par cœur de CPU sur le module d’E/S et n’utilisez pas
le port adjacent. Par exemple, utilisez FA-1E:0 et ne vous servez pas de FA1E:1. N’utilisez pas le port adjacent pour des applications non HANA.
•
Ne connectez jamais un adaptateur HBA unique aux deux ports du même
directeur.
•
Le nombre minimal de ports FA requis pour HANA dépend du nombre de
nœuds HANA connectés à un seul moteur VMAX. Reportez-vous au Tableau 3
pour déterminer le nombre de ports FA requis :
Tableau 3.
Ports FA VMAX 10K, 20K et 40K pour les nœuds de traitement HANA
Nœuds de travail HANA
Ports FA requis
1-2
2
3-4
3
5-6
4
7-8
5
9-10
6
11-12
8
Par exemple, si 16 nœuds HANA sont connectés à une baie VMAX à deux
moteurs, utilisez 5 ports sur chaque moteur pour HANA uniquement.
Livre blanc
15
•
Connectez tous les hôtes HANA à tous les ports FA dédiés à HANA. Plus le
nombre de chemins d’E/S disponibles pour un hôte est élevé, meilleures
sont les performances de SAP HANA.
Remarque : cette règle s’applique aux baies VMAX 10K, 20K et 40K, mais pas à la
gamme VMAX3.
•
Équilibrez les ports FA utilisés pour HANA sur tous les moteurs VMAX
disponibles.
•
Utilisez des ports FC 8 Gbit/s. Bien qu’il soit possible d’utiliser des ports
iSCSI ou FCoE (Fibre Channel over Ethernet) 10 Gbit/s, nous ne les avons pas
validés pour SAP HANA. Les ports FC 2 Gbit/s ou 4 Gbit/s HANA ne sont pas
pris en charge.
La Figure 2 et la Figure 3 illustrent une vue arrière des moteurs VMAX avec des
modules d’E/S FC à 4 ports (8 Gbits/s) pour la connectivité hôte. Pour la connectivité
HANA, nous recommandons d’utiliser les ports d’E/S identifiés par un cadre jaune.
Les ports adjacents ne doivent pas être utilisés.
Évolutivité de
VMAX
Figure 2.
Vue arrière d’un moteur VMAX 10K
Figure 3.
Vue arrière d’un moteur VMAX 20K et 40K
Dans une baie VMAX 10K, 20K ou 40K, l’évolutivité de SAP HANA dépend
principalement du nombre de moteurs disponibles dans la baie. Le Tableau 4
présente les modèles VMAX et une estimation du nombre maximal d’hôtes de
traitement HANA pouvant être connectés en fonction du nombre de moteurs
disponibles.
Livre blanc
16
Tableau 4.
Évolutivité de VMAX3 10K, 20K et 40K
Modèle VMAX
10K
20K
40K
Nombre de moteurs
disponibles
Nombre maximal d’hôtes de
traitement HANA
1
12
2
18
3
24
4
30
1
12
2
20
3
28
4
36
5
44
6
52
7
60
8
68
1
12
2
22
3
32
4
42
5
52
6
62
7
72
8
82
Si vous utilisez le logiciel EMC Symmetrix Remote Data Facility (SRDF) pour la
réplication de stockage SAP HANA, le nombre de ports FA front-end disponibles est
réduit, et le nombre d’hôtes de traitement HANA pouvant être connectés à la baie doit
être adapté en conséquence.
Considérations
relatives au
provisionnement
virtuel
Les baies VMAX utilisent EMC Virtual ProvisioningTM pour fournir de la capacité à une
application. La capacité est allouée au moyen de périphériques de données de
provisionnement virtuel (TDAT) et fournie sous la forme de thin pools en fonction de
la technologie de disque et du type RAID. Les périphériques thin (TDEV) sont des
périphériques accessibles à l’hôte, liés à des thin pools et agrégés par bandes en
natif sur l’ensemble du pool de manière à offrir des performances optimales.
Livre blanc
17
Considérations relatives aux configurations RAID
Pour fournir des performances d’écriture optimales pour la persistance HANA, des
configurations en miroir RAID 1 sont requises pour les périphériques TDAT sur les
disques de 10 000 ou 15 000 t/min. Vous pouvez configurer des périphériques TDAT
sur des disques EFD au moyen du type RAID 5, 3+1 ou 7+1. Nous recommandons la
configuration 3+1.
Thin pools
Nous recommandons de créer un premier thin pool pour tous les volumes de
données HANA et un second thin pool pour les volumes de log HANA dans une baie
VMAX. Toutefois, si les disques sont disponibles en nombre limité dans des
environnements HANA de petite taille, il est possible d’améliorer les performances en
utilisant un seul thin pool pour les deux périphériques. Les thin pools comprennent
des périphériques TDAT. Le nombre et la taille des périphériques TDAT dans un thin
pool dépendent des exigences de capacité SAP HANA et doivent être définis au
moyen des bonnes pratiques de configuration VMAX.
Métavolumes pour les données et le log
Chaque hôte de traitement HANA nécessite un seul volume de données et un seul
volume de log pour les systèmes de fichiers persistants. La taille de ces volumes
dépend des critères décrits plus haut dans la section Considérations relatives à la
capacité.
Vue de masquage
VMAX utilise des vues de masquage pour allouer des ressources de stockage à un
hôte. Nous recommandons de créer une seule vue de masquage pour chaque hôte
HANA. Une vue de masquage comprend les composants suivants :
•
Groupe d’initiateurs
•
Groupe de ports
•
Groupe de stockage
Le groupe d’initiateurs contient les initiateurs (noms universels ou WWN) issus des
adaptateurs de bus hôte (HBA) de l’hôte HANA. Connectez chaque hôte HANA à la
baie VMAX avec au moins deux adaptateurs HBA pour la redondance.
Groupe de ports
Le groupe de ports contient les ports de directeur front-end auxquels l’hôte HANA est
connecté. Le Tableau 3 répertorie le nombre minimal de ports requis pour une
installation HANA avec plusieurs hôtes (une installation scale-out ou des hôtes scaleup multiples). Pour les baies VMAX 10K, 20K et 40K, plus le nombre de ports
attribués aux hôtes HANA est élevé, meilleures sont les performances. Vous devez
cependant veiller à ce qu’un seul adaptateur HBA se connecte à un seul port par
directeur.
Groupe de stockage
Un cluster scale-out SAP HANA utilise le concept de « sans partage » pour la
persistance de la base de données ; chaque hôte de traitement HANA utilise alors sa
Livre blanc
18
propre paire de volumes de données et de log et a un accès exclusif aux volumes
dans des conditions normales de fonctionnement. En cas de défaillance d’un hôte de
traitement HANA, la persistance HANA de l’hôte en échec est transférée à un hôte de
secours. Dans ce cas, tous les périphériques persistants doivent être visibles par
tous les hôtes HANA, car chacun des hôtes peut devenir un hôte de travail ou de
secours.
Les groupes de stockage VMAX d’une base de données HANA doivent contenir tous
les périphériques persistants du cluster de base de données. Le serveur de noms
HANA, en association avec SAP HANA Storage Connector API, assure le montage
correct et l’isolement des E/S de la persistance.
Livre blanc
19
Recommandations de configuration avec VMAX3 (baies 100K, 200K et
400K) pour SAP HANA
Les recommandations de configuration ci-dessous s’appliquent aux systèmes HANA
de production déployés sur les baies de stockage d’entreprise EMC VMAX3 100K,
200K et 400K. Les systèmes HANA de production dans les environnements TDI
doivent répondre aux exigences de performances de SAP (indicateurs clés de
performances) et aux critères de configuration spécifiques suivants.
Éléments FAST
La technologie EMC Fully Automated Storage Tiering (FASTTM) automatise
l’identification des données d’application actives ou inactives pour la réallocation de
ces données sur différents pools dans une baie de stockage VMAX3. FAST surveille
de manière proactive les charges applicatives afin d’identifier les données les plus
sollicitées qui gagneraient à être déplacées vers des disques plus performants. Il
identifie également les données peu sollicitées qui pourraient être transférées vers
des disques de capacité supérieure sans dégrader les performances actuelles. Cette
activité de promotion/relégation vise à respecter les objectifs de niveau de service
définis pour les performances des applications associées. À cet effet, FAST détermine
le pool le plus approprié auquel allouer les données.
Avec VMAX3, les éléments de stockage suivants sont préconfigurés à des fins de
facilité de gestion et ne peuvent pas être modifiés :
•
Groupes de disques de stockage
•
Périphériques TDAT
•
Pools de données
•
Pool de ressources de stockage
Groupe de disques
Un groupe de disques est une collection de disques physiques disponibles dans la
baie VMAX3. Chaque disque d’un groupe de disques partage les mêmes
caractéristiques, déterminées par les critères suivants :
•
Vitesse de rotation des disques durs (15 000, 10 000, 7 200 t/min)
•
EFD
•
Capacité
SAP HANA nécessite des disques EFD ou des disques durs de 15 000 ou
10 000 t/min. Les disques durs de 7 200 t/min ne répondent pas aux exigences de
performances SAP HANA.
TDAT
Chaque groupe de disques est préconfiguré avec des périphériques de données
(TDAT) selon les bonnes pratiques d’EMC en matière de taille et de protection RAID.
SAP HANA nécessite une protection RAID 1 (mise en miroir) sur les disques durs et
RAID 5 3+1 ou 7+1 sur les disques EFD. Dans le cas de disques EFD, la meilleure
configuration est RAID 5 3+1.
Livre blanc
20
Pool de données
Tous les périphériques TDAT dans un groupe de disques de stockage sont ajoutés à
un pool de données. Le pool de données est une collection de périphériques TDAT,
avec une relation « un à un » entre les pools de données et les groupes de disques.
Les performances de chaque pool de données dépendent du type, de la vitesse et de
la capacité des disques, du nombre de disques et de la protection RAID.
Pool de ressources de stockage
Un pool de ressources de stockage (SRP) est une collection de pools de données
formant un domaine FAST. Un pool de données ne peut être ajouté qu’à un seul pool
de ressources de stockage. La baie VMAX3 est livrée avec un seul pool de ressources
de stockage préconfiguré. L’assistance d’EMC est requise pour les configurations
personnalisées.
La Figure 4 illustre un exemple de configuration VMAX3 et un seul pool de ressources
de stockage avec plusieurs groupes de disques et pools de données. Dans les
environnements HANA de grande taille où les charges applicatives HANA doivent être
séparées, nous recommandons l’utilisation d’un pool de ressources de stockage
dédié pour les périphériques HANA. Si HANA est installé sur un SRP à plusieurs
niveaux, le provisionnement de l’objectif de niveau de service (SLO) doit être utilisé
pour s’assurer que les données HANA sont affectées à un niveau plus élevé.
Figure 4.
Objectif de niveau
de service (SLO)
Éléments FAST VMAX3
Dans les baies VMAX3, la technologie FAST a été optimisée et offre désormais des
niveaux de performance qui répondent aux SLO. Des périphériques thin peuvent être
ajoutés aux groupes de stockage ; et les groupes de stockage peuvent être attribués
à un objectif de niveau de service spécifique de manière à définir des attentes en
matière de performances. L’objectif de niveau de service définit le temps de réponse
pour le groupe de stockage. FAST surveille en continu la charge applicative et
l’adapte pour maintenir (ou satisfaire) l’objectif de temps de réponse.
Cinq objectifs de niveau de service sont disponibles, avec différents temps de
réponse moyens cibles attendus. Il existe un SLO supplémentaire, Optimisé, qui n’est
associé à aucun objectif de temps de réponse explicite. Le Tableau 5 répertorie les
SLO disponibles.
Livre blanc
21
Tableau 5.
SLO VMAX3
SLO
Comportement
Temps de réponse
moyen attendu
Diamond
Émule les performances EFD
0,8 ms
Platinum
Émule des performances comprises entre celles
des disques EFD et des disques de 15 000 t/min
3 ms
Gold
Émule les performances des disques de 15 000 t/min 5 ms
Silver
Émule les performances des disques de 10 000 t/min 8 ms
Bronze
Émule les performances des disques de 7 200 t/min
14 ms
Optimisé (par
défaut)
Atteint des performances optimales en plaçant les
données les plus actives sur un stockage plus
performant et les données les moins actives sur le
stockage le plus économique
s.o.
Le temps de réponse réel d’une application associée à chaque objectif de niveau de
service varie en fonction de la charge applicative réelle constatée sur l’application ; il
dépend aussi de la taille d’E/S moyenne, du rapport lecture/écriture et de l’utilisation
de la réplication locale ou à distance.
Si les périphériques HANA sont créés sur un pool de ressources de stockage dédié
avec seulement des disques EFD et/ou des disques durs de 10 000 ou 15 000 t/min,
sélectionnez l’objectif de niveau de service Optimisé. Si vous n’utilisez pas de pool
de ressources de stockage dédié, sélectionnez au moins un objectif de niveau de
service Platinum pour être certain que les données soient allouées à des disques EFD
et/ou sélectionnez des disques de 10 000 ou 15 000 t/min.
Vous pouvez ajouter un des quatre types de charge applicative figurant dans le
Tableau 6 au SLO que vous avez sélectionné (sauf Optimisé) afin de préciser les
attentes en matière de temps de réponse.
Tableau 6.
Charges applicatives de service VMAX3
Workload
Description
OLTP
Charge applicative E/S de petits blocs
OLTP avec réplication
Charge applicative E/S de petits blocs avec réplication locale
ou distante
Decision Support
System (DSS)
Charge applicative E/S de blocs de grande taille
Système d’aide à la
décision (DSS) avec
réplication
Charge applicative E/S de blocs de grande taille avec
réplication locale ou distante
Pour améliorer la latence pour les petites opérations d’E/S de 4 Ko sur les
périphériques de log HANA, attribuez le type de charge applicative OLTP au groupe de
stockage HANA.
Livre blanc
22
Connectivité hôte
Les nœuds HANA se connectent aux baies VMAX3 par le biais d’un SAN Fibre
Channel. Tous les composants SAN nécessitent une liaison 8 Gbit/s ou 16 Gbit/s, et
la topologie SAN doit suivre les bonnes pratiques avec l’ensemble des liaisons et des
composants redondants.
Exigences en
matière de
directeur/port FA
Les cœurs de CPU étant dynamiquement alloués aux ports de directeur FA dans les
baies VMAX3, vous pouvez connecter des hôtes HANA à n’importe quel port d’un
directeur VMAX3. Vous devez cependant connecter (ou zoner) un seul initiateur HBA
à un seul port FA par directeur. Vous pouvez obtenir des niveaux de disponibilité et
de performance plus élevés en connectant chaque nœud HANA à des directeurs
différents et en utilisant plusieurs initiateurs hôtes.
Remarque : vous ne constaterez aucune amélioration en matière de performances ou de
disponibilité si vous connectez le même initiateur hôte à plusieurs ports sur le même
directeur. Si vous connectez le même initiateur hôte à plusieurs ports sur le même FA,
contactez le service de support EMC pour activer l’indicateur Enable Dual Port de
l’architecture FBA (Fixed Block Architecture) VMAX3, qui permet le traitement des
réservations SCSI-3 de cette manière.
Pour bénéficier de performances d’E/S optimales pour les déploiements HANA de
production, vous devez tenir compte des impératifs suivants pour les ports FA de la
baie VMAX3 :
•
Allouez des ports FA à HANA et ne les partagez pas avec des applications non
HANA.
•
Ne connectez pas un seul port d’adaptateur HBA à plusieurs ports sur le même
directeur.
•
Reportez-vous au Tableau 7 pour déterminer le nombre de ports FA requis
pouvant être distribués sur l’ensemble des moteurs disponibles. Le nombre de
ports FA requis pour HANA dépend du nombre de nœuds HANA connectés à un
seul moteur VMAX3.
Tableau 7.
Ports FA VMAX 100K, 200K et 400K pour les nœuds de traitement HANA
Nœuds de travail HANA
Ports FA requis
1-4
2
5-8
4
9-16
8
17-20
12
•
Distribuez les ports FA utilisés pour HANA sur tous les moteurs VMAX3
disponibles et trouvez le bon équilibre entre les directeurs.
Par exemple, si 16 nœuds HANA sont connectés à une baie VMAX3 avec deux
moteurs, équilibrez la connectivité entre les moteurs. Utilisez 8 ports sur
chaque moteur (4 par directeur) pour HANA uniquement.
•
Utilisez des ports FC 8 Gbit/s ou 16 Gbit/s.
Livre blanc
23
•
Veillez à ce que le zoning entre les initiateurs hôtes et les ports de stockage ne
traverse aucun switch et utilise une liaison interswitch.
La Figure 5 illustre une vue arrière du moteur VMAX3. Chaque moteur dispose de
deux directeurs avec jusqu’à 16 ports avant FC (ports 4-11 et 24-31).
Figure 5.
Vue de masquage
Vue arrière d’un moteur VMAX3 avec attributions de ports FA
VMAX3 utilise des vues de masquage pour allouer des ressources de stockage à des
hôtes. Créez une seule vue de masquage pour chaque hôte HANA. Une vue de
masquage comprend les composants suivants :
•
•
Groupe de ports
•
Groupe de stockage
Le groupe d’initiateurs contient les initiateurs WWN de port (PWWN) des adaptateurs
HBA de l’hôte HANA. Connectez chaque hôte HANA à la baie VMAX avec au moins
deux adaptateurs HBA. Les groupes d’initiateurs peuvent être mis en cascade, et un
groupe d’initiateurs de la vue de masquage peut correspondre à une collection de
groupes d’initiateurs issus de chacun des nœuds HANA.
Groupes de ports
Le groupe de ports contient tous les ports front-end VMAX3 auxquels les hôtes HANA
sont connectés. Si l’indicateur FBA Enable Dual Port VMAX3 est défini selon la
procédure décrite dans la section Exigences en matière de directeur/port FA, puis
tous les ports FA utilisés par HANA peuvent être définis dans un groupe de port
unique. Toutefois, si cet indicateur n’a pas été défini, il est important de veiller à ce
qu’un seul port d’adaptateur HBA se connecte à un seul port FA par directeur. Pour
cela, vous pouvez utiliser plusieurs groupes de ports, comme illustré dans l’exemple
de la Figure 6.
La Figure 6 illustre un environnement avec 12 hôtes HANA. Chaque hôte avec deux
adaptateurs HBA est connecté par double fabric aux ports FA d’une baie VMAX3 à
deux moteurs.
Livre blanc
24
Figure 6.
Connectivité SAN VMAX3 et groupes de ports
Dans cet exemple, nous avons créé deux groupes de ports. Chaque groupe de ports
contient quatre ports FA (8 au total pour 12 hôtes HANA), répartis sur deux moteurs,
et les deux directeurs par moteur. Le groupe de ports PG01 est utilisé par les hôtes
HANA hana01 à hana06. Le groupe de ports PG02 est utilisé par les hôtes hana07 à
hana12. Cette connectivité garantit qu’un seul adaptateur HBA se connecte à un seul
port par directeur.
Dans cet exemple, les 12 hôtes HANA appartiennent au même cluster scale-out de
base de données HANA. Par conséquent, tous les périphériques persistants HANA
(données et log) font partie du même groupe de stockage VMAX. Si les hôtes HANA
appartiennent à plusieurs clusters, un seul groupe de stockage par cluster HANA est
alors requis. L’attribution de groupe de ports ne change pas, même avec plusieurs
clusters HANA.
Groupe de stockage
Un cluster scale-out SAP HANA utilise le concept de « sans partage » pour la
persistance de la base de données ; chaque hôte de traitement HANA utilise alors sa
propre paire de volumes de données et de log et a un accès exclusif aux volumes
dans des conditions normales de fonctionnement. En cas de défaillance d’un hôte de
traitement HANA, la persistance HANA de l’hôte en échec est transférée à un hôte de
secours. Dans ce concept, tous les périphériques persistants doivent être visibles par
tous les hôtes HANA, car chacun des hôtes peut devenir un hôte de travail ou de
secours.
Les groupes de stockage VMAX3 d’une base de données HANA doivent contenir tous
les périphériques persistants du cluster de base de données. Le serveur de noms
HANA, en association avec SAP HANA Storage Connector API, assure le montage
correct et l’isolement des E/S de la persistance.
Livre blanc
25
Évolutivité VMAX3
Dans une baie VMAX3 100K, 200K ou 400K, l’évolutivité de SAP HANA dépend
principalement du nombre de moteurs disponibles dans la baie. Le Tableau 8
présente les modèles VMAX3 et une estimation du nombre maximal de nœuds HANA
pouvant être connectés en fonction du nombre de moteurs disponibles :
Tableau 8.
Évolutivité VMAX 100K, 200K et 400K
Modèle VMAX3
100K
200K
400K
Moteurs
Nombre max. de nœuds HANA
1
12
2
20
1
16
2
28
3
40
4
52
1
20
2
32
3
44
4
56
5
68
6
80
7
92
8
104
Si vous utilisez le logiciel SRDF pour la réplication de stockage SAP HANA, le nombre
de ports FA front-end disponibles est réduit, et le nombre maximal d’hôtes de
traitement HANA pouvant être connectés à la baie doit être adapté en conséquence.
Livre blanc
26
Accès au stockage VMAX à partir des nœuds SAP HANA
La base de données SAP HANA nécessite un système d’exploitation Linux SUSE
SLES11 ou Red Hat RHEL 6.5 sur les nœuds HANA. Pour accéder aux périphériques
VMAX en mode bloc à partir des nœuds HANA, veillez à ce que le zoning repose sur
les bonnes pratiques en matière de SAN. Un seul adaptateur HBA doit se connecter à
un seul port par directeur.
Multipathing Linux Pour accéder aux périphériques en mode bloc à partir des nœuds HANA, commencez
par activer le multipathing Linux natif. Suivez les étapes décrites dans le document
natif (DM MPIO)
Guide de la connectivité hôte d’EMC pour Linux pour activer Linux DM-MPIO sur Red
Hat Linux RHEL 6.5 ou SUSE SLES11.
Les sections suivantes donnent des exemples de fichiers multipath.conf :
SLES 11
## Voici un modèle de fichier de configuration multipath-tools
## Supprimez les marques de commentaire des lignes pertinentes
pour votre environnement
##
defaults {
# udev_dir /dev
# polling_interval 10
# selector "round-robin 0"
# path_grouping_policy multibus
# getuid_callout "/lib/udev/scsi_id -g -u -d /dev/%n"
# prio const
# path_checker directio
# rr_min_io 100
# max_fds 8192
# rr_weight priorities
# failback immediate
# no_path_retry fail user_friendly_names no
}
blacklist {
## Remplacer le wwid par le résultat de la commande MPIO
## ’scsi_id -g -u -s /block/[internal scsi disk name]’
## Énumérer les wwid pour tous les disques scsi internes.
## Le wwid de la base de données VCM peut également être
répertorié ici
##
wwid 35005076718d4224d
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode
"^hd[a-z][[0-9]*]"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"
RHEL 6.5
## Voici un modèle de fichier de configuration multipath-tools
## Supprimez les marques de commentaire des lignes pertinentes
pour votre environnement
##
defaults {
# udev_dir /dev
# polling_interval 10
Livre blanc
27
# selector "round-robin 0"
# path_grouping_policy multibus
# getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
# prio_callout /bin/true
# path_checker readsector0
# rr_min_io 100
# rr_weight priorities
# failback immediate
# no_path_retry fail
user_friendly_names no
}
## La ligne wwid dans la section blacklist (liste noire) cidessous est donnée à titre
d’exemple
## pour montrer comment mettre sur liste noire des périphériques
selon le wwid. Les 3 lignes devnode sont
ensuite
## compilées dans la liste noire par défaut. Si vous voulez mettre
sur liste noire des
types
## de périphériques entiers, par exemple tous les périphériques
scsi, utilisez une ligne devnode.
## Toutefois, si vous voulez mettre sur liste noire des
périphériques spécifiques, utilisez
## une ligne wwid. Étant donné que rien ne garantit qu’un
périphérique spécifique
ne
## changera pas de nom au redémarrage (de /dev/sda à /dev/sdb par
exemple),
## les lignes devnode ne sont pas recommandées pour la mise sur
liste noire de
noire de périphériques spécifiques.
##
Remarque : supprimez # pour activer la liste noire devnode. Vous pouvez ajouter le WWID
pour la base de données VCM Symmetrix, comme le montre cet exemple. La base de
données VCM est un périphérique en lecture seule qui est utilisé par la baie. En la mettant
sur liste noire, vous éliminez tous les messages d’erreur susceptibles d’apparaître en raison
de sa présence.
Liste noire
wwid 360060480000190101965533030303230
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z]"
devnode "^cciss!c[0-9]d[0-9]*"
}
Les périphériques persistants HANA doivent être visibles sur un hôte de traitement
HANA après un redémarrage ou une nouvelle analyse (commande rescan-scsibus.sh). Entrez la commande suivante pour vérifier que tous les périphériques sont
présents et que chaque périphérique dispose du nombre de chemins actifs que vous
avez configurés :
$ multipath –ll
360000970000298700460533030303238 dm-10 EMC,SYMMETRIX
size=512G features=’0’ hwhandler=’0’ wp=rw
Livre blanc
28
`-+- policy=’round-robin 0’ prio=1 status=active
|- 2:0:5:1
sdai 66:32 active ready running
|- 1:0:5:1
sdby 68:192 active ready running
`- 2:0:4:1
sdcg 69:64 active ready running
360000970000298700460533030303338 dm-11 EMC,SYMMETRIX
size=512G features=’0’ hwhandler=’0’ wp=rw
|- 2:0:5:3
sdak 66:64 active ready running
|- 1:0:5:3
sdca 68:224 active ready running
`- 2:0:4:3
sdci 69:96 active ready running
360000970000298700460533030303438 dm-12 EMC,SYMMETRIX
size=1.5T features=’0’ hwhandler=’0’ wp=rw
|- 2:0:5:5
sdam 66:96 active ready running
|- 1:0:5:5
sdcc 69:0
active ready running
`- 2:0:4:5
sdck 69:128 active ready running
360000970000298700460533030303538 dm-14 EMC,SYMMETRIX
size=1.5T features=’0’ hwhandler=’0’ wp=rw
|- 2:0:5:6
sdan 66:112 active ready running
|- 1:0:5:6
sdcd 69:16 active ready running
`- 2:0:4:6
sdcl 69:144 active ready running
Système de
fichiers XFS
Le système de fichiers XFS offre les meilleures performances pour les périphériques
de données et de log en mode bloc HANA.
Pour formater un périphérique en mode bloc avec le système de fichiers XFS, entrez la
commande suivante sur le nœud HANA :
$ mkfs.xfs /dev/mapper/3600009700002987004605330303238
Remarque : exécutez cette commande pour tous les périphériques en mode bloc.
Si vous devez étendre un système de fichiers pour une raison quelconque, utilisez la
commande xfs_growfs sur l’hôte Linux une fois le volume étendu sur la baie VMAX.
Linux LVM
Vous pouvez utiliser la fonction de gestion de volumes logiques LVM (Logical Volume
Management) sur l’hôte HANA pour gérer les périphériques de façon plus flexible. Ce
document suppose que tous les périphériques persistants HANA sont présentés aux
hôtes HANA en tant que périphérique unique et que la fonction LVM n’est pas
requise. Dans les environnements où les clients ont besoin de plus de flexibilité et où
la taille des périphériques persistants HANA doit être adaptée selon des incréments
plus granulaires que ceux disponibles avec une extension de MetaLUN sur la baie
VMAX, LVM peut permettre de surmonter ces difficultés. LVM nécessite l’utilisation
d’une interface Storage Connector API spéciale (fcClientLVM), qui fait partie de la
distribution du logiciel SAP HANA.
SAP HANA Storage
Connector API
Dans un environnement scale-out SAP HANA avec des nœuds de traitement et de
secours, SAP HANA Storage Connector API pour Fibre Channel (fcClient) monte et
démonte les périphériques sur les nœuds HANA. En cas d’utilisation de LVM, une
version spéciale de l’API (fcClientLVM) est nécessaire.
Livre blanc
29
En plus du montage des périphériques, l’interface Storage Connector API écrit
également les réservations persistantes SCSI-3 PR sur les périphériques par le biais
de la commande Linuxsg_persist. Cette opération est appelée isolement des E/S. Elle
s’assure qu’un seul nœud de traitement HANA à la fois peut accéder à un ensemble
de périphériques de données et de log.
Fichier global.ini SAP HANA
L’interface Storage Connector API est contrôlée dans la section Storage (stockage) du
fichier global.ini SAP HANA. Cette section contient les entrées pour les périphériques
en mode bloc avec des options de montage en option. Les WWID des entrées de
partition peuvent être déterminés au moyen de la commande multipath-ll sur les
hôtes HANA.
Voici un exemple de fichier global.ini :
[persistence]
basepath_datavolumes=/hana/data/ANA
basepath_logvolumes=/hana/log/ANA
use_mountpoints = yes
[storage]
ha_provider = hdb_ha.fcClient
partition_*_* prType = 5
partition_1_data wwid = 360000970000298700460533030303438
partition_1_log wwid
= 360000970000298700460533030303238
= 360000970000298700460533030303330
= 360000970000298700460533030303338
Livre blanc
30
Conclusion
Résumé
L’utilisation de SAP HANA dans des déploiements TDI (intégration sur mesure du
datacenter) avec des baies de stockage d’entreprise EMC VMAX et VMAX3 procure de
nombreux avantages, notamment une réduction des coûts opérationnels et
matériels, une limitation des risques et une amélioration de la flexibilité quant au
choix du fournisseur du matériel, pour les applications SAP et non SAP.
Conclusions
Cette solution présente les avantages suivants :
•
Intégration de HANA dans l’infrastructure de datacenter existante
•
Utilisation du stockage d’entreprise partagé sur la base des concepts
multisites déjà disponibles pour tirer parti des processus d’exploitation et
d’automatisation établis.
•
Transition aisée vers la nouvelle architecture et mise à profit des services EMC
pour minimiser les risques.
•
Utilisation des processus opérationnels, compétences et outils existants et
élimination des risques et des coûts importants associés au changement
opérationnel.
Livre blanc
31
Références
Documentation
EMC
Vous trouverez la documentation EMC ci-dessous sur france.emc.comou sur la page
de support en ligne d’EMC :
•
Documentation sur la gamme EMC VMAX3 (100K, 200K, 400K) : contient le
guide produit de la plate-forme matérielle et le guide produit TimeFinder pour
les baies VMAX 10K, VMAX 20K, VMAX 40K, VMAX3 100K, VMAX3 200K et
VMAX3 400K.
•
EMC Symmetrix System Viewer for Desktop and iPad : illustre le matériel des
•
Guide de connectivité hôte d’EMC pour Linux
•
Livre blanc EMC Cloud Enabled Infrastructure for SAP
systèmes VMAX et VMAX3, les configurations système à évolutivité
incrémentielle ainsi que la connectivité hôte disponible pour les systèmes
Symmetrix.
Documentation
VMware
Vous trouverez la documentation VMware ci-dessous sur le site www.vmware.com/fr :
Documentation
SAP
Vous trouverez la documentation SAP HANA ci-dessous sur le site
http://help.sap.com/hana/ :
•
Bonnes pratiques et recommandations pour les déploiements scale-up de
SAP HANA sur VMware vSphere
•
SAP HANA Master Guide
•
SAP HANA Server Installation and Update Guide
•
SAP HANA Studio Installation and Update Guide
•
SAP HANA Technical Operations Manual
•
SAP HANA Administration Guide
•
SAP HANA Storage Requirements
Ressources Web
•
Appliance SAP HANA
•
SAP HANA One
•
SAP HANA Enterprise Cloud
•
Intégration sur mesure dd datacenter SAP HANA
Remarque : la documentation ci-dessous nécessite un nom d’utilisateur et un mot de passe
SAP.
Notes d’option de déploiement
•
Note 1681092 : plusieurs bases de données SAP HANA sur une seule
appliance
•
Note 1661202 : prise en charge de plusieurs applications sur SAP HANA
Livre blanc
32
•
Note 1666670 : BW sur SAP HANA ; planification du déploiement dans
l’environnement
Note de virtualisation
•
Note 1788665 : exécution de SAP HANA sur des machines virtuelles VMware
vSphere
Livre blanc
33

Bonnes pratiques de configuration du stockage pour l

Transcription

Documents pareils

Hana Yori Dango Tome 14 - lire le livre en ligne ou télécharger

La Société du Grand Paris retient le PGI de Qualiac

HANA YAHYA SHALABI Date de naissance : 2 juillet 1982 Lieu de

Sousse et Port El Kantaoui

BAUCHER Johanna

Consultant Senior Indépendant SAP BI

Curriculum vitae - Christophe BEUVRY

Voir le PDF en Français

Céline - ARMANDIE RH

Wipro Business Case