Livre blanc
EMC Solutions Group
Présentation
Ce livre blanc décrit la transformation d’un déploiement SAP traditionnel en une solution de continuité d’activité critique avec datacenters en mode actif-actif. La solution repose sur EMC® VPLEXTM Metro, EMC Symmetrix® VMAXTM, EMC VNXTM, VMware vSphere® HA, Oracle RAC, un réseau Brocade et SUSE Linux Enterprise Server for SAP Applications.
Juin 2012
EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP
EMC VPLEX, Symmetrix VMAX, VNX, VMware vSphere HA, réseau Brocade, Oracle RAC, SUSE Linux Enterprise
• Gestion simplifiée pour la haute disponibilité et la continuité d’activité
• Déploiements SAP critiques durables
• Datacenters en mode actif/actif
EMC Mission-Critical Business Continuity for SAP 2 Copyright © 2012 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.
VMware, VMware vSphere, ESXi, vCenter et vMotion sont des marques
déposées ou des marques commerciales de VMware, Inc. aux États-Unis et/ou dans d’autres juridictions.
Brocade, DCX, MLX, VCS et VDX sont des marques déposées de Brocade Communications Systems, Inc. aux États-Unis et/ou dans d’autres pays.
Toutes les autres marques citées dans le présent document sont la propriété de leurs détenteurs respectifs.
Référence H9542.1
Table des matières
Résumé analytique ... 5
Business case ... 5
Présentation de solution ... 5
Principaux avantages ... 6
Introduction ... 7
Objectif ... 7
Périmètre ... 7
Audience... 7
Terminologie ... 7
Présentation de solution ... 9
Introduction ... 9
Architecture de la solution ... 10
Couches de protection ... 14
Profil de base de données et de charge de travail ... 15
Ressources matérielles ... 15
Ressources logicielles ... 16
Infrastructure EMC VPLEX Metro ... 17
Introduction ... 17
Configuration de la solution VPLEX Metro ... 20
Configuration de VPLEX Witness ... 22
Contrôle des performances VPLEX ... 23
Infrastructure virtualisée VMware ... 24
Introduction ... 24
Déploiements VMware sur VPLEX Metro ... 25
Configuration d’un cluster étendu VMware ... 27
Configuration de VMware vSphere HA ... 29
Configuration de VMware vSphere DRS ... 31
EMC Virtual Storage Integrator et VPLEX ... 31
Architecture du système SAP ... 33
Introduction ... 33
Configuration du système SAP ... 34
Configuration de SUSE Linux Enterprise High Availability Extension ... 36
Architecture d’Oracle Database ... 44
Introduction ... 44
Oracle RAC et VPLEX ... 45
Configuration Oracle ACFS ... 46
Oracle Extended RAC sur VPLEX Metro ... 46
EMC Mission-Critical Business Continuity for SAP 4
Configuration des groupes de disques Oracle ASM ... 47
Processus de migration de base de données Oracle ... 48
Infrastructure réseau Brocade ... 55
Introduction ... 55
Configuration du réseau IP ... 57
Configuration du réseau SAN ... 58
Infrastructure de stockage EMC ... 59
Introduction ... 59
Configuration de Symmetrix VMAX ... 60
Configuration de VNX5700 ... 61
Haute disponibilité et continuité d’activité : test et validation ... 62
Introduction ... 62
Défaillance du processus du service de mise en file d’attente SAP ... 62
Défaillance de la machine virtuelle de l’instance SAP ASCS ... 64
Défaillance d’un nœud Oracle RAC ... 66
Panne de site ... 67
Isolement de cluster VPLEX ... 70
Conclusion ... 73
Résumé ... 73
Conclusions ... 73
Références ... 75
EMC ... 75
Oracle ... 75
VMware ... 75
SUSE ... 76
SAP ... 76
Annexe : exemples de configuration ... 77
Exemple de configuration CRM ... 77
Exemple de profil d’instance ASCS ... 77
Exemple de profil d’instance ERS ... 78
Exemple de profil START ERS ... 78
Exemple de profil d’instance DI ... 79
Résumé analytique
Pour rester compétitives, les entreprises internationales exigent une disponibilité constante des informations et des applications. La solution EMC décrite dans ce livre blanc propose une stratégie de continuité d’activité et de haute disponibilité pour les applications critiques, telles que SAP ERP.
Les objectifs de point de restauration (RPO) et les objectifs de temps de
restauration (RTO) sont des metrics fondamentaux à prendre en compte lors de la planification d’une stratégie de continuité d’activité critique. Ils répondent à deux questions essentielles que les entreprises se posent lorsqu’elles évaluent l’impact potentiel d’un sinistre ou d’une panne :
• Quelle quantité de données pouvons-nous nous permettre de perdre (RPO) ?
• Quelle doit être la vitesse de restauration du système ou de l’application (RTO) ?
La stratégie de continuité d’activité critique de SAP requiert des RPO et des RTO très stricts afin de réduire au minimum le risque de perte de données et les délais de restauration. Lors de l’élaboration d’une telle stratégie, les principaux défis auxquels les entreprises sont confrontées sont les suivants :
• réduction des RPO et des RTO ;
• élimination des points uniques de défaillance (technologies, personnel, processus) ;
• optimisation de l’utilisation des ressources ;
• réduction des coûts d’infrastructure ;
• gestion de la complexité associée à l’intégration, à la maintenance et au test de plusieurs solutions ponctuelles.
Ce livre blanc présente une solution EMC destinée à relever tous ces défis liés aux applications SAP ERP présentant une couche de base de données Oracle Real
Applications Clusters (RAC) 11g.
Cette solution adopte un modèle de déploiement actif-actif innovant pour des datacenters distants de 100 km maximum. Elle passe ainsi du modèle
traditionnel de reprise après sinistre actif-passif à une solution de continuité d’activité haute disponibilité, offrant une disponibilité des applications 24x7, sans aucun point unique de défaillance et présentant des RTO et des RPO proches de zéro.
EMC® VPLEXTM Metro est la principale technologie à l’origine de cette solution.
VPLEX Metro est une solution de réseau de stockage (SAN) assurant à la fois la fédération locale et distribuée du stockage. Sa technologie hors pair,
AccessAnywhereTM, permet la présence de données identiques sur deux sites géographiques distincts. L’accès à ces données et leur mise à jour sont possibles sur les deux sites simultanément. Lorsque VPLEX Witness est ajouté à la solution, les applications sont toujours disponibles, sans aucune interruption de service, même en cas d’interruption de l’un des datacenters.
Business case
Présentation de solution
EMC Mission-Critical Business Continuity for SAP 6 Ce livre blanc démontre comment cette solution de continuité d’activité innovante peut être mise en œuvre grâce aux technologies suivantes :
• EMC VPLEX Metro fournit la couche de stockage virtuel indispensable à un datacenter Metro en mode actif-actif.
• EMC VPLEX Witness assure la disponibilité continue des applications, même en cas d’interruption de l’un des datacenters.
• Les baies EMC Symmetrix® VMAXTM et EMC VNXTM, qui présentent une disponibilité éprouvée de 99,999 %, prennent en charge la hiérarchisation FAST (Fully Automated Storage Tiering), ainsi qu’un vaste choix de
technologies de réplication. Elles constituent les plates-formes de stockage d’entreprise de la solution.
• La migration d’une base de données d’instance unique vers Oracle RAC sur clusters éloignés (Extended Distance Clusters) permet de supprimer les points uniques de défaillance au niveau de la couche de base de données, à distance.
• VMware vSphere® virtualise les composants d’applications SAP et les supprime en tant que points uniques de défaillance. VMware® High Availability (HA) protège les machines virtuelles en cas de pannes du serveur physique et du système d’exploitation.
• SUSE Linux Enterprise Server for SAP Applications, avec SUSE Linux Enterprise High Availability Extension et SAP Enqueue Replication Server (ERS), protège les services centraux SAP (serveurs de messages et de mise en file d’attente) sur deux nœuds de cluster pour supprimer ces services en tant que points uniques de défaillance.
• Les fabrics Brocade Ethernet et les routeurs principaux MLXe assurent la mise en réseau transparente et fournissent une extension Layer 2 entre les sites.
• Les backbones Brocade DCX 8510 offrent une infrastructure SAN redondante incluant une extension de fabric.
Cette solution permet d’améliorer la disponibilité des applications SAP de la manière suivante :
• élimination des points uniques de défaillance au niveau de toutes les couches de l’environnement, pour créer unsystème SAP distribué et à haute disponibilité ;
• mise en œuvre de datacenters en mode actif-actif prenant en charge des RPO et RTO proches de zéro et la continuité d’activité critique.
Avantages supplémentaires :
• gestion entièrement automatique des pannes ;
• utilisation accrue des ressources matérielles et logicielles :
utilisation en mode actif-actif des deux datacenters,
équilibrage automatique de la charge entre les datacenters,
maintenance sans interruption de service,
• gestion simplifiée de la haute disponibilité SAP ;
• déploiement simplifié d’Oracle RAC sur clusters éloignés (Extended Distance Clusters) ;
• coûts réduits grâce à une automatisation accrue et à une meilleure utilisation de l’infrastructure.
Principaux avantages
Introduction
Ce livre blanc décrit une solution qui améliore la disponibilité des applications SAP par la création de datacenters fonctionnant en mode actif-actif sur des sites géographiquement distincts et par la suppression des points uniques de
défaillance au niveau de toutes les couches de l’environnement.
Dans les environnements SAP, les interruptions d’activité peuvent résulter de défaillances techniques, logiques ou logistiques. La présente solution aborde la continuité d’activité du point de vue technique.
Ce livre blanc vise à :
• présenter les principales technologies qui rendent la continuité d’activité possible ;
• décrire l’architecture et la conception de la solution ;
• décrire la configuration des principaux composants ;
• décrire la procédure de conversion d’une base de données d’instance unique Oracle en cluster Oracle RAC à quatre nœuds sur Oracle Automatic Storage Management (ASM) ;
• présenter les résultats des tests effectués qui démontrent l’élimination des points uniques de défaillance au niveau de toutes les couches de
l’environnement ;
• identifier les principaux avantages métiers offerts par la solution.
Ce livre blanc est destiné aux administrateurs de base SAP, aux administrateurs de base de données Oracle, aux administrateurs de stockage, aux architectes informatiques et aux directeurs techniques responsables de la conception, de la création et de la gestion des applications SAP critiques dans des
environnements 24x7.
Dans ce livre blanc, les termes répertoriés dans le Tableau 1 sont utilisés.
Tableau 1. Terminologie
Terme Description
ABAP SAP Advanced Business Application Programming
ACFS Oracle ASM Cluster File System
ASCS ABAP SAP Central Services
ASM Oracle Automatic Storage Management
CIFS Common Internet File System
CNA Adaptateur de réseau convergé
CRM Gestionnaire des ressources du cluster
DI Instance de dialogue
DPS Dynamic Path Selection
DRS VMware vSphere Distributed Resource Scheduler dvSwitch Switch distribué vSphere
DWDM Multiplexage par répartition en longueur d’onde ERP Planification des ressources d’entreprise
ERS Enqueue Replication Server
FAST VP Fully Automated Storage Tiering for Virtual Pools Objectif
Périmètre
Audience
Terminologie
EMC Mission-Critical Business Continuity for SAP 8
Terme Description
FCoE Fibre Channel over Ethernet
FEC Forward Error Correction
FRA Flash Recovery Area
HA Haute disponibilité
HAIP IP virtuelle à haute disponibilité
HBA Adaptateur HBA
IDES SAP Internet Demonstration and Evaluation System
ISL Inter-Switch Link
LACP Link Aggregation Control Protocol
LAG Link Aggregation Group
LLDP Link Layer Discovery Protocol
LUW Unité logique de travail
MCT Multi-Chassis Trunking
MPLS Multi-Protocol Label Switching
MPP Plug-in de multipathing
NAS Stockage rattaché au réseau
NFS Network File System
NL-SAS SAS (Serial Attached SCSI) nearline
OCR Oracle Cluster Registry
Oracle Extended RAC Oracle RAC sur clusters éloignés
RAC Real Application Clusters
RFC Appel de fonction distant
RMAN Oracle Recovery Manager
RPO Objectif de point de restauration RTO Objectif de temps de restauration
SAN Réseau de stockage
SBD Périphérique de bloc STONITH
SFP Small Form-Factor Pluggable
SLES SUSE Linux Enterprise Server
SLE HAE SUSE Linux Enterprise High Availability Extension
SMT Subscription Management Tool
SPOF Point unique de défaillance
STONITH Shoot The Other Node In The Head TAF Transparent Application Failover
ToR Top-of-Rack
VCS Switch de cluster virtuel
vLAG Virtual Link Aggregation Group
vLAN LAN virtuel
VMDK Disque virtuel
VMFS Virtual Machine File System
VMHA VMware High Availability
VNX OE VNX Operating Environment
VPLS Virtual Private LAN Service
VPN Réseau privé virtuel
VRF Virtual Routing and Forwarding
VSI Virtual Storage Integrator
Solution
Haute disponibilité et continuité d’activité
Présentation de solution
Mises en œuvre SAP : problématique et solution
Les mises en œuvre SAP traditionnelles présentent plusieurs points uniques de défaillance, y compris :
• Services centraux
• Serveur de mise en file d’attente*
• Serveur de messages*
• Serveur de base de données
• Déploiement sur site unique
• Stockage sur disque local
* Dans cette solution, les serveurs de mise en file d’attente et de messages sont mis en œuvre en tant que services dans l’instance ABAP SAP Central Services (ASCS).
Ce livre blanc présente une solution visant à améliorer la disponibilité des applications SAP. L’architecture et les composants de la solution créent une solution en cluster actif-actif pour l’intégralité de la pile SAP afin d’améliorer la fiabilité et la disponibilité tout en simplifiant le déploiement et la gestion de l’environnement. Cette solution présente les avantages suivants :
• suppression des points uniques de défaillance au niveau de toutes les couches de l’environnement, afin de générer un système SAP haute disponibilité ;
• création de datacenters fonctionnant en mode actif-actif pour permettre la continuité d’activité critique.
La Figure 1 illustre les points uniques de défaillance d’un environnement SAP et les composants de la solution utilisés pour les traiter.
Figure 1. Mises en œuvre SAP : problématique et solution Introduction
Problématique Points uniques de défaillance
EMC Mission-Critical Business Continuity for SAP 10 Les sections suivantes décrivent les solutions mises en œuvre au niveau de
chaque couche de l’environnement afin d’offrir la haute disponibilité et la continuité d’activité, comme illustré sur la Figure 2.
Figure 2. Transition vers la haute disponibilité : vue logique Haute disponibilité de la couche de stockage
L’ensemble du stockage nécessaire pour chaque serveur de l’environnement a été déplacé vers des baies de stockage d’entreprise (Symmetrix VMAX et VNX). Des backbones
Brocade 8510 ont été déployés pour mettre en œuvre un fabric SAN redondant permettant l’accès au stockage.
Cette configuration tire parti de la disponibilité éprouvée de 99,999 % qu’offrent les baies et les backbones SAN, ainsi que de leurs fonctions avancées de gérabilité et de continuité d’activité.
Figure 3. Haute disponibilité du stockage Haute disponibilité de la base de données
Le serveur de base de données correspond au référentiel d’entreprise de l’application SAP. Pour les besoins de cette solution, le serveur de base de données back-end a été converti d’une base de données d’instance unique Oracle en base de données Oracle RAC à 4 nœuds sur Oracle ASM. Cette conversion supprime le serveur de base de données en tant que point unique de défaillance.
Figure 4. Haute disponibilité de la base de données Architecture de la
solution
Haute disponibilité de l’application SAP
Les serveurs d’application SAP ont été entièrement virtualisés à l’aide de VMware ESXiTM 5.0. Chaque machine virtuelle SAP a été déployée à l’aide de SUSE Linux Enterprise Server for SAP Applications 11 SP1 en tant que système d’exploitation invité.
SUSE Linux Enterprise High Availability Extension et SAP Enqueue Replication Server (ERS) ont également été déployés pour protéger les serveurs de messages et de mise en file d’attente de SAP. Ce déploiement supprime les services centraux ABAP SAP Central Services (ASCS) en tant que point unique de défaillance.
Figure 5. Haute disponibilité de l’application SAP Haute disponibilité du datacenter
La solution de cluster à haute disponibilité décrite ci-dessus permet de protéger SAP au sein du datacenter. En vue d’obtenir une haute disponibilité entre les datacenters, la solution utilise la technologie de virtualisation du stockage EMC VPLEX Metro, tel que représenté sur la Figure 6. La technologie de cluster actif-actif VPLEX Metro Access Anywhere unique permet un accès en
lecture/écriture aux volumes distribués sur des distances synchrones. En mettant les données en miroir entre les différents sites, VPLEX permet aux utilisateurs des deux sites d’accéder simultanément aux mêmes informations.
Figure 6. Haute disponibilité du datacenter
Cette solution combine VPLEX Metro avec SUSE Linux Enterprise High Availability Extension (au niveau de la couche du système d’exploitation) et Oracle RAC (au niveau de la couche de base de données) afin de supprimer le datacenter en tant que point unique de défaillance et d’offrir une stratégie de continuité d’activité fiable pour les applications critiques.
EMC Mission-Critical Business Continuity for SAP 12 L’exécution d’Oracle RAC sur clusters éloignés (Extended Distance Clusters) sur VPLEX présente les avantages suivants :
• VPLEX simplifie la gestion d’Oracle RAC sur clusters éloignés (Extended Distance Clusters), étant donné que la haute disponibilité intersites est intégrée au niveau de l’infrastructure.
Pour un administrateur de base de données Oracle, l’installation, la configuration et la maintenance sont exactement les mêmes que pour une mise en œuvre d’Oracle RAC sur un site unique.
• VPLEX élimine le recours à la mise en miroir des disques ASM sur l’hôte et les cycles CPU hôtes que ce processus consomme.
Avec VPLEX, les groupes de disques ASM sont configurés avec une redondance externe et sont protégés par la mise en miroir distribuée de VPLEX.
• Les hôtes doivent uniquement se connecter à leur cluster VPLEX local, et les E/S sont envoyées une seule fois à partir de ce nœud. Cependant, les hôtes disposent d’un accès en lecture/écriture complet à la même base de données sur les deux sites.
Avec la mise en miroir des groupes de disques ASM sur l’hôte, chaque E/S d’écriture doit être envoyée deux fois : une fois à chaque miroir.
• Il est inutile de déployer un disque de vote Oracle sur un troisième site qui servirait de périphérique de quorum au niveau de l’application.
• VPLEX vous permet de créer des groupes de cohérence capables de protéger plusieurs bases de données et/ou applications en tant qu’une unité.
La solution utilise VPLEX Witness pour surveiller la connectivité entre les
deux clusters VPLEX et assurer une disponibilité continue en cas de défaillance de la partition réseau entre les clusters ou de défaillance d’un cluster. VPLEX Witness est déployé sur une machine virtuelle située dans un troisième domaine de panne distinct (site C).
Haute disponibilité du réseau
Dans chaque datacenter, un fabric Ethernet a été généré à l’aide d’une technologie de switch de cluster virtuel (VCS) Brocade, qui offre une couche d’accès durable et autoréparatrice avec transfert de l’ensemble des liens. Les vLAG (groupes d’agrégation de liens virtuels) connectent les fabrics VCS aux routeurs principaux Brocade MLXe, qui étendent le réseau Layer 2 sur les deux datacenters.
La Figure 7 représente l’architecture physique de toutes les couches de la solution, y compris les composants réseau.
Figure 7. Architecture de la solution
EMC Mission-Critical Business Continuity for SAP 14 Le Tableau 2 résume les couches à haute disponibilité (HA) utilisées par la
solution afin de supprimer les points uniques de défaillance.
Tableau 2. Haute disponibilité en local
Haute disponibilité en local
Protection Site Composants protégés
VMware HA et VMware DRS Sites A et B Machines virtuelles SAP SUSE Linux Enterprise HAE et SAP
Enqueue Replication Server Sites A et B Serveurs de mise en file d’attente et de messages de SAP
Plusieurs instances de dialogue SAP Sites A et B Processus de travail SAP (DIA, UPD, UP2, SPO)
VMware Sites A, B et C Virtualisation des serveurs
Oracle RAC Sites A et B Base de données Oracle
Oracle Clusterware Sites A et B Système de fichiers partagé SAP Oracle ACFS Sites A et B SAP Oracle Home, répertoire SAP global,
répertoire de transport SAP, répertoire SAP ASCS EMC Symmetrix VMAX Site A Stockage local, RAID, multipathing
EMC VNX Site B Stockage local, RAID, multipathing
VPLEX Metro étend ensuite la haute disponibilité avec une architecture en cluster, qui repousse les limites du datacenter et permet aux serveurs de plusieurs
datacenters de disposer d’un accès en lecture/écriture aux périphériques de stockage en mode bloc partagés. La transformation du datacenter amène la haute disponibilité traditionnelle à un niveau inédit de continuité d’activité critique.
La Figure 8 illustre cette conception de la haute disponibilité, avec VPLEX Witness et la connexion entre clusters déployés pour offrir le niveau le plus élevé de résilience.
Figure 8. Haute disponibilité en local avec VPLEX permettant la continuité d’activité multisite
Toutes les technologies illustrées sur la Figure 8 sont détaillées dans les sections correspondantes du livre blanc.
Couches de protection
Le Tableau 3 décrit le profil de base de données et de charge de travail de la solution.
Tableau 3. Profil de base de données et de charge de travail Caractéristique du profil Détails
Nombre de bases de données 1
Type de base de données SAP OLTP Taille de la base de données 500 Go Nom de la base de données VSE
Oracle RAC 4 nœuds physiques
Profil de charge de travail Processus SAP personnalisés de la commande au paiement
Le Tableau 4 détaille les ressources matérielles de la solution.
Tableau 4. Environnement matériel de la solution
Objectif Quantité Configuration
Stockage (site A) 1 EMC Symmetrix VMAX doté de :
• 2 moteurs
• 171 disques FC de 450 Go
• 52 disques SATA de 2 To
Stockage (site B) 1 EMC VNX5700 doté de :
• 30 disques NL-SAS de 2 To
• 79 disques SAS de 600 Go Fédération distribuée du
stockage
2 Cluster VPLEX Metro doté de :
• 2 moteurs VS2 Serveurs de base de données
Oracle RAC
4 4 CPU à huit cœurs, 128 Go de RAM
Serveurs VMware ESXi pour SAP 4 2 CPU à quatre cœurs, 128 Go de RAM Serveur VMware ESXi pour
VPLEX Witness
2 2 CPU à deux cœurs, 48 Go de RAM
Plate-forme de routage et de commutation du réseau
2 Backbone Brocade DCX 8510 doté de :
• 1 carte d’extension FC Fx8-24
• 2 lames FC à 48 ports avec prise en charge de vitesse filaire FC de 16 Gbit Routeur Brocade MLXe
4 Brocade VDX 6720 en mode VCS Profil de base de
données et de charge de travail
Ressources matérielles
EMC Mission-Critical Business Continuity for SAP 16 Le Tableau 5 détaille les ressources logicielles de la solution.
Tableau 5. Environnement logiciel de la solution
Logiciels Version Objectif
EMC Enginuity™ 5875.198.148 Environnement d’exploitation Symmetrix VMAX
EMC VPLEX GeoSynchrony 5.1 Environnement d’exploitation VPLEX
EMC VPLEX Witness 5.1 Composant de surveillance et
d’arbitrage pour la gestion d’une panne de cluster VPLEX et de la perte de communication entre les clusters EMC VNX Operating
Environment for Block 05.31.000.5.715 Environnement d’exploitation VNX EMC VNX Operating
Environment for File 7.0.52.1 Environnement d’exploitation VNX
EMC UnisphereTM 1.1 Logiciel de gestion VNX
SUSE Linux Enterprise Server for SAP Applications, y compris SUSE Linux Enterprise High Availability Extension
11 SP1 Système d’exploitation de tous les serveurs de l’environnement
VMware vSphere 5.0 Hypervisor hébergeant toutes les
machines virtuelles Oracle Database 11g (avec
infrastructure Oracle Grid et Oracle RAC)
Enterprise
Edition 11.2.0.3 Logiciel de cluster et de base de données Oracle
SAP ERP 6.04 Système IDES SAP ERP
Ressources logicielles
Infrastructure EMC VPLEX Metro
Présentation
Cette section présente l’infrastructure VPLEX Metro pour la solution, comprenant les composants suivants :
• cluster EMC VPLEX Metro à chaque datacenter (site A et site B) ;
• EMC VPLEX Witness dans un domaine de panne distinct (site C).
EMC VPLEX
EMC VPLEX constitue une solution de virtualisation du stockage pour les baies de stockage EMC et tierces. EMC décline VPLEX en trois configurations qui répondent aux besoins des clients en matière de haute disponibilité et de mobilité des données, comme illustré sur la Figure 9 :
• VPLEX Local
• VPLEX Metro
• VPLEX Geo
Figure 9. Topologies VPLEX
Pour une description détaillée de ces configurations VPLEX, consultez les documents répertoriés à la section Références , page 75.
EMC VPLEX Metro
Cette solution utilise VPLEX Metro, qui repose sur une architecture en cluster unique aidant les clients à repousser les limites du datacenter et permettant aux serveurs de différents datacenters de disposer d’un accès en lecture/écriture aux périphériques de stockage en mode bloc partagé. VPLEX Metro offre un accès actif-actif en mode bloc aux données de deux sites sur des distances synchrones avec un temps d’aller-retour pouvant atteindre 5 ms.
EMC VPLEX Witness
VPLEX Witness est un serveur externe facultatif installé en tant que machine virtuelle dans un domaine de panne séparé des clusters VPLEX. VPLEX Witness se connecte aux deux clusters VPLEX à l’aide d’un réseau privé virtuel (VPN) via le réseau IP de gestion. Il nécessite un temps d’aller-retour n’excédant pas 1 seconde.
Introduction
EMC Mission-Critical Business Continuity for SAP 18 En rassemblant ses propres observations avec les informations rapportées
régulièrement par les clusters, VPLEX Witness permet au cluster ou aux clusters de différencier les pannes de partition de réseau intercluster et les pannes de cluster, et de reprendre automatiquement les E/S sur le site approprié.
La sémantique de la gestion des pannes VPLEX Witness s’applique uniquement aux volumes distribués au sein d’un groupe de cohérence, et uniquement lorsque les règles de déconnexion identifient un cluster statique privilégié pour le groupe de cohérence (pour plus d’informations, reportez-vous à la section Groupes de cohérence VPLEX, page 19).
Interface de gestion EMC VPLEX
Vous pouvez gérer et administrer un environnement VPLEX grâce à la console de gestion VPLEX Web ou vous connecter directement à un serveur de gestion et démarrer une session VPlexcli (interface de ligne de commande VPLEX).
Haute disponibilité d’EMC VPLEX
VPLEX Metro rend l’application et les données plus mobiles et, lorsqu’il est configuré avec VPLEX Witness, offre une infrastructure de haute disponibilité pour les applications en cluster, comme Oracle RAC. VPLEX Metro permet de générer un cluster éloigné comme s’il s’agissait d’un cluster local et de supprimer le
datacenter en tant que point unique de défaillance. En outre, étant donné que les données et les applications sont actives sur les deux sites, la solution offre une stratégie de continuité d’activité simple.
Il est même possible d’atteindre un niveau de disponibilité encore plus élevé en faisant appel à la configuration de connexion entre clusters VPLEX. Dans ce cas, chaque hôte est connecté aux clusters VPLEX des deux sites. Dans l’éventualité improbable d’une panne complète du cluster VPLEX, l’hôte est ainsi assuré de disposer d’un chemin d’accès de substitution vers le cluster VPLEX restant.
Structures de stockage logique VPLEX
VPLEX encapsule les périphériques de baie de stockage physique traditionnels et applique des couches d’abstraction logique à ces LUN exportées, comme illustré sur la Figure 10.
Figure 10. Structures de stockage logique VPLEX
Un volume de stockage est une LUN exportée à partir d’une baie et encapsulée par VPLEX. Une extension désigne le mécanisme que VPLEX emploie pour diviser les volumes de stockage, et peut utiliser une partie ou l’intégralité de la capacité du volume de stockage sous-jacent. Un périphérique encapsule une extension ou combine plusieurs extensions ou d’autres périphériques en un seul grand
périphérique présentant un type RAID spécifique. Un périphérique distribué est un périphérique qui encapsule d’autres périphériques provenant de deux clusters VPLEX distincts.
Sur la couche supérieure des structures de stockage VPLEX se trouvent les volumes virtuels. Ces volumes sont créés à partir d’un périphérique de premier niveau (périphérique distribué ou non) et utilisent toujours la capacité totale de ce périphérique. Les volumes virtuels sont les éléments exposés par VPLEX aux hôtes à l’aide de ses ports front-end. VPLEX présente un volume virtuel à un hôte au travers d’une vue de stockage.
VPLEX peut encapsuler les périphériques sur des baies de stockage hétérogène, y compris les périphériques thin provisionnés virtuellement et les LUN traditionnelles.
Groupes de cohérence VPLEX
Les groupes de cohérence regroupent des volumes virtuels, de sorte que les mêmes règles de déconnexion et autres propriétés puissent être appliquées à tous les volumes du groupe. Il existe deux types de groupe de cohérence :
• Groupes de cohérence synchrones : ils sont utilisés dans VPLEX Local et VPLEX Metro afin d’appliquer les mêmes règles de déconnexion et autres propriétés au groupe de volumes d’une configuration. Cette action simplifie la configuration et l’administration sur les systèmes d’envergure.
Les groupes de cohérence synchrones utilisent une mise en cache à écriture immédiate (connue sous le nom de mode de cache synchrone) et, avec VPLEX Metro, sont pris en charge sur des clusters séparés par un temps de latence pouvant atteindre 5 ms. VPLEX Metro envoie les écritures aux volumes de stockage back-end et accuse réception d’une écriture à l’application uniquement lorsque les volumes de stockage back-end des deux clusters accusent réception de l’écriture.
• Groupes de cohérence asynchrones : ils sont utilisés pour les volumes distribués dans VPLEX Geo, où il arrive que les clusters soient séparés par un temps de latence pouvant atteindre 50 ms.
Règles de déconnexion
Les règles de déconnexion sont des règles prédéfinies qui déterminent la sémantique du traitement des E/S pour un groupe de cohérence, lorsque la connectivité avec un cluster distant est interrompue (par exemple, en cas de panne du cluster distant ou du partitionnement de réseau).
Les groupes de cohérence synchrones prennent en charge les règles de déconnexion suivantes, afin de déterminer le comportement du cluster lors d’une panne :
• la règle de préférence statique détermine un cluster privilégié ;
• la règle qui ne désigne pas automatiquement de gagnant (no-automatic- winner) suspend les E/S sur les deux clusters.
Lorsqu’une règle de déconnexion est définie, elle est systématiquement appelée en cas de perte de connectivité entre les clusters. Cependant, VPLEX Witness peut être déployé pour remplacer la règle de préférence statique et s’assurer que le cluster qui n’a pas été privilégié reste actif en cas de panne du cluster privilégié.
EMC Mission-Critical Business Continuity for SAP 20 Structures de stockage
La Figure 10 présente la structure de stockage physique et logique utilisée par VPLEX Metro dans le cadre de cette solution.
Figure 11. Structure de stockage physique et logique VPLEX pour la solution Un mappage un vers un a lieu entre les extensions, les périphériques et les volumes de stockage sur chaque site. Les périphériques encapsulés sur le site A (cluster-1) sont des périphériques thin provisionnés virtuellement tandis que les périphériques encapsulés sur le site B (cluster-2) sont des LUN traditionnelles.
Tous les périphériques du cluster-1 sont mis en miroir à distance sur le cluster-2, dans une configuration RAID 1 distribuée, afin de créer des périphériques
distribués. Ces derniers sont encapsulés dans des volumes virtuels, qui sont ensuite présentés aux hôtes par des vues de stockage.
Groupe de cohérence
Les groupes de cohérence sont essentiels aux bases de données et à leurs applications. Par exemple :
• Fidélité de l’ordre des écritures : afin de maintenir l’intégrité des données, toutes les LUN de base de données Oracle (par exemple, fichiers log, de données et de contrôle) doivent être placées ensemble dans un groupe de cohérence unique.
• Dépendances transactionnelles : il arrive souvent que plusieurs bases de données présentent des dépendances transactionnelles, comme
lorsqu’une application émet des transactions vers plusieurs bases de données et s’attend à ce que ces dernières soient cohérentes entre elles.
Toutes les LUN nécessitant une préservation de la dépendance d’E/S doivent résider dans un groupe de cohérence unique.
Configuration de la solution VPLEX Metro
• Dépendance entre applications : Oracle RAC conserve Oracle Cluster Registry (OCR) et les fichiers de vote dans un ensemble de disques devant être accessible en vue de conserver la disponibilité de la base de données.
Les disques OCR et de base de données doivent résider dans un groupe de cohérence unique.
Dans le cadre de cette solution, un groupe de cohérence synchrone unique (Extended_Oracle_RAC_CG) contient tous les volumes virtuels conservant les binaires de la base de données Oracle 11g, les groupes de disques Oracle ASM, ainsi que les fichiers OCR et les fichiers de vote. Le cluster-1 est le cluster privilégié de la règle de déconnexion pour le groupe de cohérence.
Processus de configuration
Pour la solution, les structures de stockage logiques VPLEX Metro sont
configurées comme suit (les figures comprises entre la Figure 12 et la Figure 16 montrent des extraits des assistants de configuration fournis par la console de gestion VPLEX) :
• Volume de stockage : un volume de stockage désigne une LUN exportée à partir d’une baie et encapsulée par VPLEX. La Figure 12 présente plusieurs volumes de stockage créés sur le site A, comme affiché dans la console de gestion VPLEX.
Figure 12. Volumes de stockage EMC VPLEX (site A)
• Extension : dans la solution, un mappage un vers un a lieu entre les extensions et les volumes de stockage, tel qu’illustré sur la Figure 12 et la Figure 13.
Figure 13. Assistant EMC VPLEX Extent Creation
• Périphérique : dans la solution, un mappage un vers un a lieu entre les périphériques et les extensions. La Figure 14 indique l’option utilisée pour configurer ce mappage un vers un.
Figure 14. Assistant EMC VPLEX Device Creation
EMC Mission-Critical Business Continuity for SAP 22
• Périphérique distribué : dans la solution, les périphériques distribués ont été créés par la mise en miroir à distance d’un périphérique dans une configuration RAID 1 distribuée, comme l’illustre la Figure 15.
Figure 15. Assistant EMC VPLEX Device Creation
• Volume virtuel : dans la solution, tous les périphériques de premier niveau sont des périphériques distribués. Ils sont encapsulés dans des volumes virtuels, que VPLEX présente aux hôtes par des vues de stockage. Les vues de stockage déterminent les hôtes qui disposent d’un accès aux volumes virtuels, et les ports VPLEX sur lesquels se trouvent ces volumes virtuels.
• Groupe de cohérence : La Figure 16 indique le groupe de cohérence créé pour la solution, soit Extended_Oracle_RAC_CG.
Figure 16. Assistant EMC VPLEX Create Consistency Group La solution utilise VPLEX Witness pour surveiller la connectivité entre les
deux clusters VPLEX et assurer une disponibilité continue en cas de défaillance de la partition réseau entre les clusters ou de défaillance d’un cluster. Cette
configuration est considérée comme VPLEX Metro HA, étant donné que la disponibilité du stockage est assurée sur le site resté actif.
VPLEX Witness est déployé sur un troisième domaine de panne distinct (site C) et connecté aux clusters VPLEX sur le site A et le site B. Le site C est situé à moins d’une seconde des sites A et B en termes de temps de latence.
Lorsqu’une solution VPLEX Witness a été installée et configurée, la console de gestion VPLEX affiche l’état des composants Witness de cluster, tel qu’illustré sur la Figure 17.
Configuration de VPLEX Witness
Figure 17. Composants et état d’EMC VPLEX Witness
VPLEX 5.1 offre une surveillance améliorée des performances par le biais du tableau de bord de contrôle des performances. Ce tableau de bord fournit une vue
personnalisable des performances du système VPLEX et vous permet d’afficher et de comparer différents aspects des performances système, jusqu’au niveau directeur.
De nombreux metrics différents sont actuellement disponibles :
• graphique de la latence front-end ;
• graphique de la bande passante front-end ;
• graphique du débit front-end ;
• graphique d’utilisation du CPU ;
• graphique de l’état de la reconstruction ;
• graphique des performances de la liaison WAN ;
• graphique de la latence back-end.
La Figure 18 indique les performances CPU et front-end sur le cluster-1 (VPLEX du site A) lors du regroupement des statistiques Oracle sur la base de données SAP VSE.
Figure 18. Tableau de bord de contrôle des performances VPLEX Contrôle des
performances VPLEX
EMC Mission-Critical Business Continuity for SAP 24
Infrastructure virtualisée VMware
Présentation
Dans la solution, les serveurs d’applications SAP sont entièrement virtualisés par VMware vSphere 5. Cette section présente l’infrastructure de virtualisation qui utilise les options et composants suivants :
• VMware vSphere 5.0
• VMware vCenterTM Server
• VMware vSphere vMotion®
• VMware vSphere High Availability (HA)
• VMware vSphere Distributed Resource SchedulerTM (DRS)
• EMC PowerPath®/VE for VMware vSphere Version 5.7
• EMC Virtual Storage Integrator for VMware vSphere Version 5.1 VMware vSphere 5
VMware vSphere 5 est une plate-forme de virtualisation particulièrement puissante, évolutive et complète. Ses services d’infrastructure transforment le matériel informatique en plate-forme informatique partagée hautes performances, et ses services d’applications aident les départements informatiques à offrir des niveaux supérieurs de disponibilité, de sécurité et d’évolutivité.
VMware vCenter Server
VMware vCenter est une plate-forme de gestion centralisée pour les
environnements vSphere. Elle offre contrôle et visibilité sur chaque niveau de l’infrastructure virtuelle.
VMware vSphere vMotion
VMware vSphere vMotion est une technologie VMware qui prend en charge la migration dynamique des machines virtuelles entre les serveurs, sans
interruption ou perte de service pour les utilisateurs.
Storage vMotion est une technologie VMware qui permet la migration dynamique du stockage d’une machine virtuelle sans interruption de disponibilité de la machine virtuelle. Cette technologie permet la réaffectation de machines virtuelles dynamiques vers d’autres datastores.
VMware vSphere High Availability
VMware vSphere High Availability (HA) est un composant vSphere qui assure une haute disponibilité à toutes les applications qu’exécute une machine virtuelle, indépendamment de son système d’exploitation ou de sa configuration matérielle sous-jacente.
VMware vSphere Distributed Resource Scheduler
VMware vSphere Distributed Resource Scheduler (DRS) assure de manière dynamique et automatique l’équilibrage de la charge et le déplacement des machines virtuelles entre les différents serveurs VMware ESXi.
Introduction
EMC PowerPath/VE
EMC PowerPath/VE for VMware vSphere offre des fonctions de multipathing PowerPath qui permettent d’optimiser les environnements virtuels VMware vSphere. PowerPath/VE est installé sur l’hôte VMware ESXi comme un module de noyau et fonctionne comme un plug-in de multipathing (MPP) qui fournit aux hôtes VMware ESXi des fonctions avancées de gestion des chemins.
EMC Virtual Storage Integrator for VMware vSphere
EMC Virtual Storage Integrator (VSI) for VMware vSphere est un plug-in pour le client VMware vSphere. Il fournit une interface de gestion unique pour gérer le stockage EMC au sein de l’environnement vSphere. VSI procure un environnement utilisateur unifié et flexible, qui permet de mettre à jour chacune des fonctions indépendamment, mais aussi d’introduire rapidement de nouvelles fonctions pour répondre à l’évolution des exigences clients.
Lorsque PowerPath/VE est installé sur un hôte VMware ESXi, VSI indique des détails importants de multipathing pour les périphériques, notamment la règle d’équilibrage de la charge, le nombre de chemins actifs et le nombre de chemins inactifs.
EMC VPLEX Metro fournit un accès simultané au même ensemble de
périphériques situés dans deux emplacements physiques distincts. Il offre ainsi l’infrastructure actif/actif requise pour des clusters étendus géographiquement basés sur VMware vSphere. L’utilisation de la technologie Brocade vLAG (Virtual Link Aggregation Group) permet d’étendre les VLAN et, par conséquent, les sous- réseaux entre différents datacenters physiques.
En déployant les fonctions et les composants VMware vSphere avec VPLEX Metro, les fonctionnalités suivantes deviennent disponibles :
• vMotion : capacité à migrer de manière dynamique des machines virtuelles entre des sites pour anticiper des événements planifiés comme une
maintenance matérielle.
• Storage vMotion : capacité à migrer le stockage d’une machine virtuelle sans interrompre la disponibilité de cette dernière. Cette technologie permet la réaffectation de machines virtuelles dynamiques vers d’autres datastores.
• VMware DRS : automatisation de la répartition de la charge et du
déplacement de machines virtuelles entre des sites à l’aide des groupes DRS et des règles d’affinité.
• VMware HA : un environnement VPLEX Metro configuré avec VPLEX Witness est considéré comme une configuration VPLEX Metro HA puisqu’il assure la disponibilité du stockage sur le site resté actif en cas de panne au niveau d’un site. La combinaison de VPLEX Metro HA et d’une technologie de mise en cluster avec basculement sur incident de l’hôte (comme VMware HA) assure le redémarrage automatique d’une application en cas de sinistre au niveau d’un site. La Figure 19 illustre cette architecture haute disponibilité.
Déploiements VMware sur VPLEX Metro
EMC Mission-Critical Business Continuity for SAP 26 Figure 19. VMware HA avec VPLEX Witness : vue logique
• Connexion entre clusters VPLEX Metro HA : il est possible d’améliorer encore davantage la protection du cluster VMware HA par l’ajout d’une connexion entre clusters entre les serveurs VMware ESXi locaux et le cluster VPLEX sur le site distant.
Les événements locaux d’indisponibilité des données (que VMware vSphere 5.0 ne reconnaît pas) peuvent survenir en l’absence de panne intégrale du site. La connexion d’environnements vSphere avec les clusters VPLEX offre une protection contre cette éventualité et garantit que les machines virtuelles en échec sont automatiquement déplacées vers le site resté actif.
La connexion entre clusters VPLEX est disponible pour une latence entraînée par la distance allant jusqu’à 1 ms.
Cette solution utilise VPLEX Metro HA avec une connexion entre clusters pour optimiser la disponibilité des machines virtuelles VMware, comme illustré sur la Figure 20.1
1 Pour plus d’informations, consultez le TechBook EMC : EMC VPLEX Metro Witness Technology and High Availability.
Figure 20. VMware HA avec VPLEX Witness et connexion entre clusters : vue logique VMware et EMC prennent en charge une configuration de cluster étendu
comprenant des hôtes VMware ESXi de plusieurs sites2. Dans la solution, un cluster vSphere unique est étendu entre le site A et le site B à l’aide d’un volume virtuel distribué VPLEX avec VMware HA et VMware DRS. Le cluster contient quatre hôtes, deux sur chaque site. La connexion entre clusters de VPLEX Metro HA améliore la résilience de la configuration.
Dans vCenter, il est facile d’afficher la configuration de ce cluster (SiteAandSiteB) et les fonctions activées, comme l’illustre la Figure 21. Cette vue présente également les ressources mémoire, CPU et de stockage disponibles pour le cluster.
Figure 21. Cluster vSphere avec HA et DRS activés
2 Pour plus de détails sur les exigences et les scénarios, consultez l’article 1026692 de la base de connaissances VMware : Using VPLEX Metro with VMware HA
Configuration d’un cluster étendu VMware
EMC Mission-Critical Business Continuity for SAP 28 Chaque serveur VMware ESXi est configuré avec deux adaptateurs physiques
10 GbE qui assurent un basculement sur incident et de hautes performances. Un switch distribué vSphere (dvSwitch)3 fait office de switch unique, commun à tous les hôtes. Les adaptateurs physiques 10 GbE (également appelés adaptateurs uplink) sont alloués au dvSwitch.
Deux groupes de ports distribués sont alloués au dvSwitch :
• dvPortGroupSiteAB : pour le trafic réseau des machines virtuelles ;
• Management Network : pour le trafic VMkernel et, plus particulièrement, pour le trafic vMotion.
La Figure 22 présente la configuration du dvSwitch. Puisque les switches
vSphere 5.0 distribués et les switches Brocade VCS prennent en charge le protocole LLDP (Link Layer Discovery Protocol), il est également possible d’identifier aisément les propriétés des switches physiques associés depuis vCenter.
Figure 22. Configuration du dvSwitch et détail du LLDP
Le datastore EXT_SAP_VPLEX_DS01 a été créé sur un volume distribué VPLEX de 1 To, puis présenté aux hôtes VMware ESXi dans le cluster étendu. Toutes les machines virtuelles ont été migrées vers ce datastore (avec Storage vMotion), car elles doivent être en mesure de partager des disques virtuels ou d’utiliser
vMotion entre plusieurs sites. La Figure 23 présente le détail de la configuration du datastore.
3 Un dvSwitch offre une configuration réseau qui s’étend à tous les hôtes membres et permet aux machines virtuelles de préserver la cohérence de leur configuration réseau lorsqu’elles migrent entre des hôtes. Pour plus d’informations, consultez le document VMware vSphere Mise en réseau ESXi 5.0.
Figure 23. Datastore EXT_SAP_VPLEX_DS01, et hôtes et machines virtuelles associés
Activation de VMware vSphere HA et de VMware vSphere DRS
vSphere HA tire parti de plusieurs hôtes VMware ESXi. Configuré comme un cluster, il permet une restauration rapide après les pannes et une haute disponibilité à faible coût pour les applications exécutées sur les machines virtuelles.4 vSphere HA protège la disponibilité des applications comme suit :
• Il offre une protection contre les pannes de serveurs en redémarrant les machines virtuelles sur d’autres serveurs VMware ESXi du cluster.
• Il offre une protection contre les pannes liées aux applications en
surveillant en permanence une machine virtuelle et en la réinitialisant en cas de défaillance de l’OS invité.
Pour la solution, à la fois vSphere HA et DRS ont été activés, comme l’illustre la Figure 24.
Figure 24. Assistant vSphere HA
4 Pour plus d’informations sur vSphere HA, consultez le document VMware vSphere Disponibilité ESXi 5.0.
Configuration de VMware
vSphere HA
EMC Mission-Critical Business Continuity for SAP 30 VM Monitoring
VM Monitoring a été configuré pour redémarrer les machines virtuelles individuellement si leur heartbeat n’est pas reçu après 60 secondes.
Options de redémarrage des machines virtuelles
L’option VM Restart Priority des quatre machines virtuelles SAP a été définie sur High. Cette configuration garantit que ces machines virtuelles sont démarrées en priorité en cas de panne. La Figure 25 présente ce paramètre et le paramètre Host Isolation Response (par défaut).
Figure 25. Paramètres VM Restart Priority et Host Isolation Response Heartbeats du datastore
Lorsque vous créez un cluster vSphere HA, un hôte unique est automatiquement élu hôte maître. L’hôte maître surveille l’état de toutes les machines virtuelles protégées et de tous les hôtes esclaves. Lorsque l’hôte maître ne peut pas communiquer avec un hôte esclave, il utilise les heartbeats du datastore pour déterminer si l’hôte esclave est défaillant, se trouve dans une partition réseau ou est isolé du réseau.
Pour répondre aux exigences de vSphere HA en termes de heartbeats du datastore, un second datastore (EXT_SAP_VPLEX_HA_HB) a été créé sur un volume distribué VPLEX de 20 Go, puis présenté à tous les hôtes VMware ESXi, comme l’illustre la Figure 26. Dans un environnement de production, vCenter sélectionne automatiquement deux datastores ou plus à cette fin, en fonction de la visibilité de l’hôte.
Figure 26. vSphere HA Cluster Status : datastores pour les heartbeats
Groupes d’hôtes VMware DRS et groupes de machines virtuelles
Les groupes d’hôtes DRS et les groupes de machines virtuelles simplifient la gestion des ressources des hôtes VMware ESXi. Les fonctionnalités suivantes n’étaient pas requises pour cette solution.
Règles d’affinité VMware DRS
DRS utilise des règles d’affinité pour contrôler le positionnement des machines virtuelles sur les hôtes d’un cluster. DRS offre deux types de règle d’affinité :
• une règle d’affinité VM-Host, qui spécifie une relation d’affinité entre un groupe de machines virtuelles et un groupe d’hôtes ;
• une règle d’affinité VM-VM, qui détermine si des machines virtuelles
spécifiques doivent être exécutées sur le même hôte ou rester sur des hôtes distincts.
Le Tableau 6 et la Figure 27 représentent la règle d’affinité VM-VM utilisée par la solution.
Tableau 6. Règle d’affinité VMware DRS Règle d’affinité VM-VM
SAPASCS - Separate Maintient les machines virtuelles SAPASCS1 et SAPASCS2 sur des hôtes distincts.
Figure 27. Règle d’affinité DRS VM-VM pour le cluster vplex_esxi_metro_HA
EMC Virtual Storage Integrator (VSI) améliore la visibilité sur VPLEX directement depuis l’interface utilisateur de vCenter. Les fonctions Storage Viewer et Path Management sont accessibles via l’onglet EMC VSI, comme l’illustre la Figure 28.
Dans la solution, les volumes distribués VPLEX hébergent le datastore EXT_SAP_VPLEX_DS01 Virtual Machine File System (VMFS), et Storage Viewer fournit les détails des volumes virtuels, des volumes de stockage et des chemins vers le datastore.
Comme l’illustre la Figure 28, les LUN qui composent le datastore correspondent à quatre volumes VPLEX Metro RAID 1 distribués de 256 Go, accessibles via PowerPath.
Configuration de VMware
vSphere DRS
EMC Virtual Storage Integrator et VPLEX
EMC Mission-Critical Business Continuity for SAP 32 Figure 28. VSI Storage Viewer : datastores
Architecture du système SAP
Présentation
Cette section présente l’architecture du système SAP déployé sur les
deux datacenters dans le cadre de la solution. La couche d’application SAP utilise les composants SAP et SUSE suivants :
Le système SAP s’exécute dans un environnement hybride : ses services SAP se trouvent sur des machines virtuelles et sa base de données sur des serveurs physiques. Toutes les instances SAP sont installées sur des machines virtuelles VMware vSphere dont le système d’exploitation est SUSE Linux Enterprise Server for SAP Applications. La base de données sous-jacente est une base de données Oracle RAC physique sur ASM. Les environnements VMware et Oracle sont présentés dans différentes sections du livre blanc (voir Infrastructure virtualisée VMware et Architecture ).
SAP ERP 6.0
SAP ERP 6.0, optimisé par la plate-forme technologique SAP NetWeaver, est une application ERP intégrée qui répond aux besoins métiers essentiels des
moyennes et des grandes entreprises de tous les secteurs. SAP ERP 6.0 offre un ensemble complet de processus métiers intégrés et interfonctionnels. Il agit également comme une plate-forme de processus métiers solide, qui prend en charge la croissance continue, l’innovation et l’excellence opérationnelle.
SAP IDES (Internet Demonstration and Evaluation System) prend en charge les démos, les tests et l’évaluation fonctionnelle sur la base de données et de clients préconfigurés. IDES contient des données d’application pour divers scénarios métiers, ainsi que des processus métiers conçus pour refléter des exigences métiers réelles et pour produire de nombreuses caractéristiques réalistes. Cette solution utilise IDES pour représenter une entreprise modèle à des fins de test.
SUSE Linux Enterprise Server for SAP Applications
SUSE Linux Enterprise Server est un système d’exploitation pour serveur extrêmement fiable, évolutif et sûr développé pour optimiser les applications physiques, virtuelles et Cloud. Il s’agit d’une des plates-formes Linux
recommandées pour SAP.
SUSE Linux Enterprise Server for SAP Applications (basé sur la nouvelle
technologie SUSE Linux Enterprise Server) est optimisé pour toutes les solutions logicielles et appliances SAP NetWeaver critiques. SAP et SUSE valident et certifient conjointement SUSE Linux Enterprise Server for SAP Applications pour éliminer toute incompatibilité logicielle potentielle. Grâce à cette relation étroite, la charge de travail applicative est intégrée avec le système d’exploitation, et tout risque d’incompatibilité lors de l’application de correctifs aux applications ou au système d’exploitation est éliminé.
Introduction
Application SAP
• SAP Enhancement Package 4 for SAP ERP 6.0 IDES
• SAP NetWeaver Application Server for ABAP 7.01
• SAP Enqueue Replication Server
Système d’exploitation
• SUSE Linux Enterprise Server for SAP Applications 11 SP1
• SUSE Linux Enterprise High Availability Extension
EMC Mission-Critical Business Continuity for SAP 34 SUSE Linux Enterprise High Availability Extension
SUSE Linux Enterprise Server for SAP Applications intègre SUSE Linux Enterprise High Availability Extension, qui offre une mise en cluster des services et des applications haute disponibilité, des systèmes de fichiers et des systèmes de fichiers en cluster, un stockage rattaché au réseau (NAS), des systèmes de fichiers réseau, des gestionnaires de volumes, un réseau de stockage (SAN) et des pilotes, ainsi que les moyens de gérer tous ces composants lorsqu’ils fonctionnent ensemble. SUSE Linux Enterprise High Availability Extension fournit une solution en cluster intégrée pour les déploiements Linux physiques et virtuels, ce qui permet l’implémentation de clusters Linux haute disponibilité et
l’élimination des points de défaillance uniques.
Architecture du système SAP
La solution met en œuvre une architecture de système SAP haute disponibilité, comme l’illustre la Figure 29.
Figure 29. Architecture du système SAP Configuration du
système SAP
Le serveur de file d’attente et le serveur de messages sont dissociés de l’instance centrale et mis en œuvre en tant que services dans l’instance ASCS5. SAP ERS est installé en tant qu’élément de l’architecture haute disponibilité pour réduire à zéro les pertes en cas de verrouillage des applications et pour renforcer la protection du serveur de file d’attente6. Deux instances de dialogue sont installées pour fournir des processus de travail redondants, par exemple de dialogue (DIA), d’arrière-plan (BGD), de mise à jour (UPD), de spool (SPO) et de passerelle.
Principales caractéristiques de la conception
La conception du système SAP déployé pour la solution présente les principales caractéristiques suivantes :
• L’instance ASCS est installée avec un nom d’hôte virtuel (SAPVIPE) pour la dissocier du nom d’hôte de la machine virtuelle.
• L’instance ERS est installée avec un autre numéro d’instance (01) pour éviter toute confusion lorsque ASCS et ERS sont contrôlés par le cluster.
• Les correctifs, paramètres, paramètres de base et paramètres d’équilibrage de la charge SAP sont tous installés et configurés conformément au guide d’installation SAP et aux notes SAP répertoriées à la page 75.
• Cette solution utilise les bonnes pratiques VMware pour SAP7.
• Les processus de mise à jour SAP (UPD/UP2) sont configurés sur les instances de serveur d’applications supplémentaires.
• Les profils d’instance SAP ASCS, ERS, Start et de dialogue sont mis à jour en fonction des configurations ERS. Reportez-vous à l’Annexe : exemples de configuration pour découvrir des exemples de configurations.
• Les systèmes de fichiers partagés SAP, y compris /sapmnt/<SID>
(disponible pour toutes les instances SAP) et /usr/sap/<SID>/ASCS00 (disponible pour les nœuds de cluster SAP, l’instance ASCS et l’instance ERS) sont stockés sur Oracle ASM Cluster File System (ACFS) et montés comme des partages NFS sur les machines virtuelles SAP. Ces systèmes de fichiers partagés sont présentés comme une ressource NFS à haute
disponibilité, gérée par Oracle Clusterware.
• Certaines fonctionnalités IDES (par exemple, la synchronisation avec le système GTS) sont désactivées afin d’éliminer des interfaces externes superflues qui sortent du cadre de la solution.
5 Le serveur de file d’attente gère les verrouillages logiques. Son objectif est de minimiser la durée d’un verrouillage de base de données. Contrairement aux verrouillages de base de données, un verrouillage SAP peut se produire sur plusieurs LUW de base de données.
Le serveur de message informe tous les serveurs (instances) d’un système SAP de
l’existence des autres serveurs. D’autres clients (par exemple, des clients SAPlogon et RFC avec équilibrage de la charge) peuvent également le contacter pour obtenir plus
d’informations sur l’équilibrage de la charge.
6 SAP ERS offre un mécanisme de réplication pour le serveur de file d’attente en
conservant une copie de la table de verrouillage dans son segment de mémoire partagé.
L’installation ERS pour Linux ne fait pas partie du processus SAPInst standard. Pour obtenir des instructions relatives à l’installation, consultez le portail d’aide SAP dédié à Enqueue Replication Server sur help.sap.com.
7 Pour plus d’informations, consultez : SAP Solutions on VMware: Best Practices Guide.
EMC Mission-Critical Business Continuity for SAP 36
• Dans cette solution, le stockage de l’environnement SAP tout entier est encapsulé et virtualisé. Le stockage est distribué entre les deux sites et rendu disponible aux serveurs SAP par VPLEX Metro.
Architecture de machine virtuelle SAP avec SUSE Linux Enterprise High Availability Extension
La solution utilise SUSE Linux Enterprise High Availability Extension pour protéger les services centraux (serveur de messages et serveur de file d’attente) sur les deux nœuds de cluster générés sur les machines virtuelles VMware. VMware High Availability (VMHA) protège les machines virtuelles. La Figure 30 présente cette architecture.
Figure 30. Architecture du cluster SAP ASCS avec SUSE Linux Enterprise HAE
Les principaux composants de SUSE Linux Enterprise High Availability Extension mis en œuvre dans cette solution incluent :
• OpenAIS8/Corosync9, un gestionnaire de cluster haute disponibilité qui prend en charge le basculement sur incident de plusieurs nœuds ;
• des agents de ressources (adresse IP virtuelle, maître/esclave et
SAPInstance) pour surveiller et contrôler la disponibilité des ressources ;
• une interface utilisateur haute disponibilité et divers outils de ligne de commande.
8 OpenAIS est une implémentation ouverte d’Application Interface Specification (AIS) fournie par Service Availability Forum (SA Forum).
9 Corosync Cluster Engine est un système de communication de groupes contenant des fonctions supplémentaires pour la mise en œuvre de la haute disponibilité dans les applications.
Configuration de SUSE Linux Enterprise High Availability Extension
Le Tableau 7 présente la configuration des machines virtuelles SAP.
Tableau 7. Machines virtuelles SAP
Rôle de la VM Quantité CPU
virtuels Mémoire (Go) Disque de démarrage de
l’OS (Go) Nom de la VM
SAP ASCS 1 2 4 32 SAPASCS1
SAP ERS 1 2 4 32 SAPASCS2
SAP AAS 2 2 4 32 SAPDI1
2 4 32 SAPDI2
Processus d’installation et de configuration
Le livre blanc SUSE Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability – Simple Stack présente l’installation et la configuration du logiciel SUSE et de SAP NetWeaver.
Annexe : exemples de configuration présente un exemple de fichier de
configuration qui prend en charge les fonctions et fonctionnalités validées par cette solution. Considérez les valeurs temporelles (expiration du délai, intervalles, etc.) données ici comme des valeurs « initiales » à ajuster et à optimiser en
fonction de votre environnement.
Dans la solution, SUSE Linux Enterprise High Availability Extension a été installé et configuré avec YaST et Pacemaker GUI. Voici un résumé du processus
d’installation et de configuration :
1. Définissez un serveur SMT interne (pour des raisons de sécurité) afin de mettre à jour tous les packages logiciels vers les versions les plus récentes.
2. Dans le module YaST Software Management, sélectionnez Patterns > High Availability pour installer High Availability Extension, comme l’illustre la Figure 31.
EMC Mission-Critical Business Continuity for SAP 38 Figure 31. Installation de SUSE Linux Enterprise High Availability Extension
3. Dans le module YaST Cluster, configurez les paramètres de base du cluster, comme l’illustre la Figure 32.
Figure 32. Configuration des paramètres de base du cluster
4. Dans Pacemaker GUI, configurez les paramètres de cluster globaux, comme indiqué sur la Figure 33
Figure 33. Configuration des paramètres de cluster globaux
EMC Mission-Critical Business Continuity for SAP 40 5. Dans Pacemaker GUI, ouvrez la catégorie Resources, puis configurez
IPaddr2, le maître/l’esclave et les ressources SAPInstance, comme indiqué sur la Figure 34.
Figure 34. Configuration des ressources
6. Dans Pacemaker GUI, configurez les dépendances des ressources, comme indiqué sur la Figure 35.
Figure 35. Configuration des dépendances des ressources
7. Dans Pacemaker GUI, démarrez le cluster, puis vérifiez que le cluster et tous les agents de ressource fonctionnent normalement, comme indiqué sur la Figure 36.