• Aucun résultat trouvé

EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP

N/A
N/A
Protected

Academic year: 2022

Partager "EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP"

Copied!
79
0
0

Texte intégral

(1)

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

(2)

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

(3)

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

(4)

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

(5)

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

(6)

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

(7)

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

(8)

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

(9)

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

(10)

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

(11)

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.

(12)

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.

(13)

Figure 7. Architecture de la solution

(14)

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

(15)

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

(16)

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

(17)

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

(18)

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

(19)

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é.

(20)

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

(21)

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

(22)

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

(23)

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

(24)

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

(25)

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

(26)

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.

(27)

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

(28)

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.

(29)

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

(30)

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

(31)

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

(32)

EMC Mission-Critical Business Continuity for SAP 32 Figure 28. VSI Storage Viewer : datastores

(33)

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

(34)

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

(35)

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.

(36)

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

(37)

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.

(38)

EMC Mission-Critical Business Continuity for SAP 38 Figure 31. Installation de SUSE Linux Enterprise High Availability Extension

(39)

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

(40)

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.

Références

Documents relatifs

Configure an ext4 file system mounted on the LVM logical volume my_l v on the shared storage for the nodes in the cluster, as described in Section 3.2, “ Configuring an LVM Volume

In Red Hat Enterprise Linux 7 High Availability Add-On, adding of clusters, nodes, and resources are done via pcs at the command-line, or pcsd for graphical configuration. For

The following command creates a location constraint for a resource to prefer the specified node or nodes.. pcs constraint location rsc prefers

Oracle Clusterware includes the High Availability (HA) service stack which provides the infrastructure to manage the Oracle Database as a resource in the cluster environment..

Avec Beagle (également appelé Moteur de recherche de bureau), vous pouvez facilement effectuer des recherches dans votre espace d'informations personnelles (généralement votre

4 Si vous avez besoin d'un type de fichier qui ne se trouve pas dans la liste Types connus, cliquez sur Ajouter pour ouvrir une boîte de dialogue dans laquelle vous pouvez

Vous trouverez toutes les informations sur la configuration ma- térielle et logicielle requise pour l’installation de SUSE LINUX Enterprise Server sur des plates-formes IBM POWER

Ex3: pour chercher tous les fichiers qui ont été modifier il y a deux jours dans votre répertoire courant.