EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP

Transcription

1 Livre blanc EMC MISSION-CRITICAL BUSINESS CONTINUITY FOR SAP EMC VPLEX, EMC Symmetrix VMAX 10K avec Enginuity Gestion simplifiée pour une disponibilité et une continuité d activité élevées Déploiements SAP critiques durables Datacenters en mode actif-actif EMC Solutions Group Résumé 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 actifactif. La solution repose sur EMC VPLEX Metro, EMC Symmetrix VMAX, VMware vsphere High Availability, Oracle RAC, Brocade Networking et SUSE Linux Enterprise Server for SAP Applications. Novembre 2012

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 ni garantie d aucune sorte concernant les informations contenues dans la présente publication et rejette plus spécialement toute garantie tacite de qualité commerciale ou d adéquation à un usage particulier. L utilisation, la copie et la distribution de tout logiciel EMC décrit dans la présente publication nécessitent une licence logicielle en cours de validité. Pour obtenir la liste actualisée des noms de produits EMC, consultez la rubrique des marques EMC via le lien Législation, sur 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 H

3 Table des matières Résumé analytique... 5 Business case... 5 Présentation de la solution... 5 Principaux avantages... 6 Introduction... 8 Objectif... 8 Portée... 8 Audience... 8 Terminologie... 8 Présentation de la solution Introduction Architecture de la solution Couches de protection Profil de base de données et de charge de travail Ressources matérielles Ressources logicielles Infrastructure de stockage EMC Introduction EMC Symmetrix VMAX 10K Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX Configuration du VMAX Infrastructure EMC VPLEX Metro Introduction Mobilité des données VPLEX Configuration de la solution VPLEX Metro Configuration de VPLEX Witness Contrôle des performances VPLEX Infrastructure virtualisée VMware Introduction Déploiements VMware sur VPLEX Metro Configuration d un cluster étendu VMware Configuration de VMware vsphere HA Configuration de VMware vsphere DRS EMC Virtual Storage Integrator et VPLEX

4 Architecture du système SAP Introduction Configuration du système SAP Configuration de SUSE Linux Enterprise High Availability Extension Architecture d Oracle Database Introduction Oracle RAC et VPLEX Configuration Oracle ACFS Oracle Extended RAC sur VPLEX Metro Configuration des groupes de disques Oracle ASM Infrastructure réseau Brocade Introduction Configuration du réseau IP Configuration du réseau SAN Haute disponibilité et continuité d activité : tests et validation Introduction Défaillance du processus du service de mise en file d attente SAP Défaillance de la machine virtuelle de l instance SAP ASCS Défaillance du nœud Oracle RAC Panne du site Isolement de cluster VPLEX Conclusion Résumé Conclusions Références EMC Oracle VMware SUSE SAP Annexe : exemples de configuration Exemple de configuration CRM Exemple de profil d instance ASCS Exemple de profil d instance ERS Exemple de profil START ERS Exemple de profil d instance DI

5 Résumé analytique Business case 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 ; suppression des points uniques de défaillance (SPOF) : technologie, 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 le 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. Présentation de la solution La solution repose principalement sur EMC VPLEX Metro. VPLEX Metro est une solution SAN permettant la fédération locale et distribuée du stockage. Sa technologie hors pair, AccessAnywhere TM, 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. Le 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 actif-actif. 5

6 VPLEX Data Mobility permet de déplacer les données de la couche de stockage sans interruption. EMC VPLEX Witness assure la disponibilité continue des applications, même en cas d interruption de l un des datacenters. Les baies de stockage EMC Symmetrix VMAX 10K avec Enginuity (présentant une disponibilité éprouvée de 99,999 %), prennant en charge Fully Automated Storage Tiering (FAST), ainsi qu un vaste choix de technologies de réplication, 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 (serveur 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. Principaux avantages 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 un système SAP distribué et à haute disponibilité ; mise en œuvre de datacenters actif-actif qui prennent en charge les RPO et RTO proches de zéro et la continuité d activité critique. Avantages supplémentaires : environnements de stockage validés et fiables pour SAP reposant sur une baie Symmetrix VMAX 10K ; gestion entièrement automatique des pannes ; 6

7 amélioration de l utilisation 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) ; réduction des coûts grâce à une automatisation accrue et l utilisation de l infrastructure ; déplacement simple et rapide des données entre les baies de stockage. 7

8 Introduction Objectif 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. Portée La portée du livre blanc consiste à : 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 ; 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. Audience Terminologie Ce livre blanc est destiné aux administrateurs de base SAP, aux administrateurs de base de données Oracle, aux administrateurs de stockage, aux architectes IT 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. Terme AAS ABAP ACFS ASCS ASM CIFS CNA CRM DI DPS DRS dvswitch DWDM ERP ERS FAST VP FCoE FEC Terminologie Description SAP Additional Application Server SAP Advanced Business Application Programming Oracle ASM Cluster File System ABAP SAP Central Services Oracle Automatic Storage Management Common Internet File System Adaptateur de réseau convergé Gestionnaire des ressources du cluster Instance de dialogue Dynamic Path Selection VMware vsphere Distributed Resource Scheduler Switch distribué vsphere Multiplexage par répartition en longueur d onde Planification des ressources d entreprise Enqueue Replication Server Fully Automated Storage Tiering for Virtual Pools Fibre Channel over Ethernet Forward Error Correction 8

9 Terme FRA HA HAIP HBA IDES ISL LACP LAG LLDP LUW MCT MPLS MPP NAS NFS NL-SAS OCR Oracle Extended RAC RAC RFC RPO RTO SAN SBD SFP SLES SLE HAE SMT SPOF STONITH TAF ToR VCS vlag vlan VMDK VMFS VMware HA VPLS VPN VRF VSI Description Flash Recovery Area Haute disponibilité IP virtuelle à haute disponibilité Adaptateur HBA SAP Internet Demonstration and Evaluation System Inter-Switch Link Link Aggregation Control Protocol Link Aggregation Group Link Layer Discovery Protocol Unité logique de travail Multi-Chassis Trunking Multi-Protocol Label Switching Plug-in de multipathing Stockage rattaché au réseau Network File System SAS (Serial Attached SCSI) nearline Oracle Cluster Registry Oracle RAC sur clusters éloignés (Extended Distance Clusters) Real Application Clusters Appel de fonction distant Objectif de point de restauration Objectif de temps de restauration Réseau de stockage Périphérique de bloc STONITH Small Form-Factor Pluggable SUSE Linux Enterprise Server SUSE Linux Enterprise High Availability Extension Subscription Management Tool Point unique de défaillance Shoot The Other Node In The Head Transparent Application Failover Top-of-Rack Switch de cluster virtuel Virtual Link Aggregation Group LAN virtuel Disque virtuel Virtual Machine File System VMware High Availability Virtual Private LAN Service Réseau privé virtuel Virtual Routing and Forwarding Virtual Storage Integrator 9

10 Présentation de la solution Introduction Mises en œuvre SAP : le défi et la 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 ensemble du stack 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 : supprime les 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ée des datacenters fonctionnant en mode actif-actif pour permettre la continuité d activité critique. 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 : le défi et la solution 10

11 Architecture de la solution 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 représenté à 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 VMAX 10K et VMAX 20K. 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 constitue le référentiel d entreprise de l application SAP. Pour cette solution, la base de données backend a été convertie d une base de données Oracle en instance unique en un cluster Oracle RAC à quatre nœuds. 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 11

12 Haute disponibilité de l application SAP Les serveurs d application SAP ont été entièrement virtualisés à l aide de VMware ESXi TM 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é à 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

13 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 les administrateurs 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 résidant sur un 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 résidant sur un hôte des groupes de disques ASM, 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 groupes d agrégation de liens virtuels (vlag) connectent les fabrics VCS aux routeurs principaux Brocade MLXe, qui étendent le réseau Layer 2 sur les deux datacenters. 13

14 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 14

15 Couches de protection 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 A et B Machines virtuelles SAP SUSE Linux Enterprise HAE et SAP Enqueue Replication Server Plusieurs instances de dialogue SAP A et B A et B Serveurs de mise en file d attente et de messages de SAP Processus de travail SAP (DIA, UPD, UP2, SPO) VMware A, B et C Virtualisation des serveurs Oracle RAC A et B Base de données Oracle Oracle Clusterware A et B Système de fichiers partagé SAP Oracle ACFS A et B SAP Oracle Home, répertoire SAP global, répertoire de transport SAP, répertoire SAP ASCS EMC Symmetrix VMAX 20K A Stockage local, RAID, multipathing EMC Symmetrix VMAX 10K 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 nouveau niveau de continuité d activité critique. Figure 8 illustre cette conception de la haute disponibilité, avec VPLEX Witness et Cross-Cluster Connect 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é à distance 15

16 Toutes les technologies présentées à la Figure 8 sont détaillées dans les sections correspondantes du livre blanc. Profil de base de données et de charge de travail 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 la base de données Taille de la base de données Nom de la base de données Oracle RAC Profil de charge de travail SAP OLTP 500 Go VSE 4 nœuds physiques Processus SAP personnalisés de la commande au paiement Ressources matérielles 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 Baie Symmetrix VMAX 20k avec Enginuity : 2 moteurs 171 disques FC de 450 Go 52 disques SATA de 2 To Stockage (site B) 1 Baie Symmetrix VMAX 10k avec Enginuity : 1 moteur 30 disques NL-SAS de 2 To 79 disques SAS de 600 Go Fédération distribuée du stockage Serveurs de bases de données Oracle RAC Serveurs VMware ESXi pour SAP Serveur VMware ESXi pour VPLEX Witness Plate-forme de routage et de commutation du réseau 2 Cluster VPLEX Metro doté de : 2 moteurs VS2 4 4 CPU à huit cœurs, 128 Go de RAM 4 2 CPU à quatre cœurs, 128 Go de RAM 2 2 CPU à deux cœurs, 48 Go de RAM 2 Backbone Brocade DCX 8510 doté de : 1 carte d extension FC Fx lames FC à 48 ports avec prise en charge de vitesse filaire FC de 16 Go Routeur Brocade MLXe 4 Brocade VDX 6720 en mode VCS 16

17 Ressources logicielles Tableau 5 détaille les ressources logicielles de la solution. Tableau 5. Environnement logiciel de la solution Logiciel Version Objectif EMC Enginuity Enginuity 5876 Q SR Environnement d exploitation du Symmetrix VMAX EMC VPLEX GeoSynchrony 5.1 Patch 2 Environnement d exploitation VPLEX EMC VPLEX Witness 5.1 Patch 2 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 Unisphere TM 5.1 Logiciel de gestion de VPLEX EMC Unisphere T Logiciel de gestion du VMAX EMC Virtual Storage Integrator (VSI) Intégration du stockage VMware EMC PowerPath/VE 5.7 P01 (build 2) Logiciel de multipathing 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 Update 1 Hypervisor hébergeant toutes les machines virtuelles Oracle Database 11g (avec infrastructure Oracle Grid et Oracle RAC) Enterprise Edition Logiciel de cluster et de base de données Oracle SAP ERP 6.04 Système IDES SAP ERP 17

18 Infrastructure de stockage EMC Introduction Présentation Cette section décrit l infrastructure de stockage de la solution : une baie Symmetrix VMAX 20K constitue la plate-forme de stockage du site A ; une baie Symmetrix VMAX 10K constitue la plate-forme de stockage du site B. Les deux baies de stockage sont déployées avec une configuration des unités logiques (LUN) correspondante. EMC Symmetrix VMAX 10K Le Symmetrix VMAX 10K est une nouvelle plate-forme de stockage d entreprise conçue pour fournir des fonctions de stockage virtuel haut de gamme à un nombre croissant de départements informatiques et de fournisseurs de services. Il répond ainsi à leurs exigences en matière de stockage tout en composant avec leurs ressources restreintes. Le VMAX 10K est conçu pour une installation, une configuration et une utilisation simples. Il convient parfaitement aux clients ayant besoin de performances accrues en mode défaillance et constitue un point d entrée idéal dans une infrastructure de stockage basée sur le Symmetrix. S appuyant sur Virtual Matrix Architecture, le VMAX 10K garantit une fiabilité, une disponibilité et une facilité de service de niveau entreprise. Le VMAX 10K inclut une préconfiguration, qui facilite la configuration le jour même de la réception de la baie. L installation nécessite moins de 4 heures. Le VMAX 10K est un système provisionné virtuellement à 100 %. Virtual Provisioning offre à un hôte, une application ou un système de fichiers la possibilité de bénéficier de davantage d espace que ce qui lui est physiquement alloué. Le stockage physique est alloué uniquement lors de l écriture des données, et non lors de la configuration initiale de l application. Cette configuration supprime les calculs manuels et peut également réduire les coûts d alimentation et de refroidissement, du fait de la diminution de la capacité de stockage inactive dans la baie. L ajout de FAST VP pour le stockage hiérarchisé entièrement automatisé facilite l installation et les opérations quotidiennes pour les départements informatiques disposant d une équipe et de ressources informatiques restreintes. Tirant parti de l intégration du stockage EMC avec VMware la plus étroite du marché, le VMAX 10K offre désormais un stockage d entreprise encore plus efficace grâce à une nouvelle intégration avec la plate-forme d infrastructure de type Cloud VMware vsphere 5. EMC Virtual Storage Integrator (VSI) for VMware simplifie le processus d intégration du stockage EMC dans un environnement virtualisé. EMC Enginuity Operating Environment est le centre névralgique qui contrôle l ensemble des composants d une baie du VMAX 10K. 18

19 Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX L environnement d exploitation EMC Enginuity 5876 Q SR est le centre névralgique qui contrôle l ensemble des composants d une baie de stockage EMC Symmetrix. Enginuity est un environnement d exploitation du stockage (SOE) intelligent, multitâche et préventif qui contrôle le flux de données de stockage. Il est entièrement dédié aux opérations de stockage et optimisé pour les niveaux de service exigés dans les environnements haut de gamme. Cette version d Enginuity est centrée sur les points suivants : facilité d utilisation/de gestion ; multitenancy ; optimisation ; VMAX 10K. Le VMAX 20K offre un équilibre parfait entre la facilité d utilisation, les performances, la haute disponibilité et le prix pour les entreprises plus petites ou les clients milieu de gamme supérieur exigeant une conception de stockage multicontrôleur. Le VMAX 20K fournit des niveaux d évolutivité, de capacité et de performances plus élevés pour les clients plus exigeants. Tous les systèmes VMAX s appuient sur Virtual Matrix Architecture, leader sur le marché, exécutent le même code Enginuity et partagent une interface unique offrant une gestion centralisée : EMC Unisphere for VMAX. EMC Unisphere for VMAX est une interface utilisateur avancée offrant à un utilisateur EMC ordinaire une expérience sur les plates-formes de stockage. EMC Unisphere for VMAX permet aux clients de provisionner, gérer et surveiller facilement les environnements VMAX, tel que représenté à la Figure 9. Figure 9. Unisphere for VMAX 19

20 Configuration du VMAX Organisation du stockage Dans le cadre de cette solution, VPLEX Metro, Oracle Extended RAC et les volumes SAP sont organisés à l aide de Virtual Provisioning. Cette configuration place les fichiers log et les fichiers de données Oracle dans des thin pools séparés et leur permet d utiliser une protection RAID distincte. Les fichiers de données résident dans un pool protégé par RAID 5 et les fichiers redo log dans un pool protégé par RAID 1. Le stockage n a été préalloué à aucun périphérique, exception faite des périphériques Oracle REDO log. EMC recommande la préallocation de ces périphériques lors de leur création, à l aide d une allocation persistante. Cette action assure une disponibilité anticipée de leur stockage. En outre, si une récupération de l espace inutilisé est exécutée sur le pool à un moment donné, leur capacité préallouée n est pas renvoyée vers l espace libre du pool. Figure 10 est une représentation logique de la manière dont l organisation du stockage correspond aux groupes de disques Oracle ASM. Figure 10. Groupes de stockage et groupes de disques ASM Tableaux de périphériques Tableau 6 indique la taille et le nombre des périphériques configurés pour chaque groupe de disques ASM. Tableau 6. Tailles des périphériques Groupe de stockage Nombre de périphériques OCR 5 8 FRA 4 16 REDO 8 16 DATA ACFS 4 16 Taille des périphériques (Go) 20

21 Tableau 7 indique la taille et le nombre des périphériques configurés pour VPLEX Metro. Tableau 7. Taille et nombre des périphériques configurés pour VPLEX Metro Périphérique VPLEX Nombre de périphériques Métadonnées VPLEX 2 80 Volume log VPLEX 2 20 Taille des périphériques (Go) Sauvegarde des métadonnées VPLEX

22 Infrastructure EMC VPLEX Metro Introduction 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 représenté à la Figure 11 : VPLEX Local ; VPLEX Metro ; VPLEX Geo. Figure 11. Topologies VPLEX Pour une description détaillée de ces configurations VPLEX, consultez les documents répertoriés à la section Références à la page 73. 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 de 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. 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é. 22

23 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 à la page 24). EMC Unisphere for VPLEX Vous pouvez gérer et administrer un environnement VPLEX grâce à l interface utilisateur Web Unisphere for VPLEX (tel que représenté à la Figure 12) ou vous pouvez vous connecter directement à un serveur de gestion et démarrer une session VPlexcli (interface de ligne de commande VPLEX). Figure 12. EMC Unisphere for 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 vous permet de générer un cluster éloigné comme s il s agissait d un cluster local, et permet de supprimer le datacenter en tant que point de défaillance unique. 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. Si vous utilisez une configuration VPLEX entre clusters, vous pouvez atteindre un degré de disponibilité plus élevé encore. 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. 23

24 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 représenté à la Figure 13. Volumes virtuels Périphérique Périphérique Extension Volume de stockage Figure 13. 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 (un périphérique ou périphérique distribué) et utilisent toujours la capacité totale du périphérique de premier niveau. 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 par 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 les 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. 24

25 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ù les clusters peuvent être 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-automaticwinner) suspend les E/S sur les deux clusters. Lors d une perte de connectivité entre plusieurs clusters, la règle de déconnexion configurée est automatiquement utilisée. 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é. Mobilité des données VPLEX Présentation La fonction de mobilité des données VPLEX permet une migration sans interruption des éléments de stockage (extension et périphériques) dans ou entre les clusters. La mobilité des données présente les avantages suivants : consolidation des datacenters ; migration rapide des données entre les différents datacenters ; déplacement et réaffectation d applications et de données à distance ; migration de données entre baies différentes pour : réaffectation d'un périphérique «à chaud» d un stockage plus lent à un stockage plus rapide ; réaffectation d'un périphérique «à froid» d un stockage plus rapide à un stockage plus lent ; retrait d'un volume ou d'une baie de stockage. 25

26 Migrations d extension Vous pouvez utiliser les migrations d extension pour déplacer des données entre les extensions d un même cluster. Les volumes de stockage peuvent être situés sur la même baie ou sur des baies différentes. Figure 14 illustre la migration d extension Figure 14. Migration d extension sur un cluster VPLEX Migrations de périphérique Les périphériques non distribués de type RAID 0, RAID 1 ou RAID C peuvent utiliser la migration de périphérique pour déplacer des données entre les périphériques d un même cluster ou de clusters différents. Les périphériques peuvent être intégrés avec des extensions ou des périphériques uniques ou multiples. Figure 15 illustre la migration de périphérique. Figure 15. Migration d un périphérique dans ou entre des clusters VPLEX Cette solution utilise des périphériques distribués. Avec ce type de périphérique, les migrations d extension sont utilisées pour migrer l extension sous-jacente vers chaque tronçon du périphérique. Les migrations de périphérique entre différents périphériques distribués ne sont pas prises en charge. 26

27 Configuration de la mobilité des données Les conditions préalables pour le périphérique ou l extension cible sont les suivantes : la taille de la cible doit être égale ou supérieure à celle du périphérique ou de l extension source ; la cible doit être plus grande que la source, l espace supplémentaire ne peut pas être utilisé ; la cible ne doit comporter aucun volume existant. Les tâches de mobilité des extensions et des périphériques peuvent être créées, exécutées et surveillées à partir de : VPLEX CLI : les migrations peuvent être exécutées comme tâches ponctuelles ou comme traitements par lot, avec des fichiers de planification de migration réutilisables. Pour plus d informations, consultez le Guide EMC VPLEX CLI. Interface utilisateur Unisphere for VPLEX : l interface utilisateur ne prend pas en charge les traitements de mobilité par lot. Cependant, plusieurs extensions/périphériques peuvent être migrés à l aide d un assistant. Sur un cluster VPLEX, jusqu à 25 migrations locales et 25 migrations distribuées peuvent s exécuter simultanément. Toute migration dépassant ces limites est mise en file d attente jusqu à ce qu une migration existante soit terminée. Figure 16 représente la création de plusieurs tâches de mobilité des extensions à l aide de l assistant Extent Mobility de l interface Unisphere for VPLEX. Elle présente également les tâches en cours d exécution et l état des différentes tâches. Figure 16. Création et surveillance des tâches de mobilité des extensions 27

28 Mobilité des données dans cette solution Cette solution utilise une infrastructure VPLEX Metro existante. Dans le cadre de l actualisation des technologies, les baies de stockage back-end on été remplacées par des baies VMAX. Les tâches de mobilité des données VPLEX ont été utilisées pour la migration des données sans interruption à partir des baies d origine vers les nouvelles baies. Les systèmes (dans le cas présent, les serveurs VMware ESXi et les machines virtuelles) ont été mis sous tension et étaient disponibles tout au long de la migration, comme l illustre la Figure 17. Figure 17. Serveurs VMware ESXi, machines virtuelles et datastores disponibles au cours de la migration Configuration de la solution VPLEX Metro Structures de stockage Figure 18 présente la structure de stockage physique et logique utilisée par VPLEX Metro dans le cadre de cette solution. Un mappage un vers un a lieu entre les extensions, les périphériques et les volumes de stockage sur chaque site. 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. Ils sont encapsulés à des volumes virtuels, qui sont ensuite présentés aux hôtes par des vues de stockage. 28

29 Figure 18. Structures de stockage physique et logique VPLEX pour la solution Groupes de cohérence Les groupes de cohérence sont essentiels aux bases de données et à leurs applications. Par exemple : Respect 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. Condition préalable transactionnelle : il arrive souvent que plusieurs bases de données présentent des conditions préalables transactionnelles, comme lorsqu une application émet des transactions vers plusieurs bases de données et s attend à ce que les bases de données soient cohérentes entre elles. Toutes les LUN nécessitant une préservation de la condition préalable d E/S doivent résider dans un groupe de cohérence unique. Condition préalable d application : 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. 29

30 Processus de configuration Pour la solution, les structures de stockage logiques VPLEX Metro sont configurées comme suit (les figures comprises entre la Figure 19 et la Figure 23 montrent des extraits des assistants de configuration fournis par la console de gestion VPLEX) : Volume de stockage : Un volume de stockage est une LUN exportée à partir d une baie et encapsulée par VPLEX. Figure 19 présente plusieurs volumes de stockage créés sur le site A, comme affiché dans la console de gestion VPLEX. Figure 19. EMC VPLEX storage volumes (site A) Extension : dans la solution, un mappage un vers un a lieu entre les extensions et les volumes de stockage, tel que représenté à la Figure 19 et à la Figure 20. Figure 20. 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. Figure 21 indique l option utilisée pour configurer ce mappage un vers un. Figure 21. Assistant EMC VPLEX Device Creation 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 22. Figure 22. Assistant EMC VPLEX Device Creation 30

31 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 : Figure 23 indique le groupe de cohérence créé pour la solution (Extended_Oracle_RAC_CG). Figure 23. Assistant EMC VPLEX Create Consistency Group Configuration de VPLEX Witness 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é à une distance des sites A et B présentant un temps de latence inférieur à 1 seconde. 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 que représenté à la Figure 24. Figure 24. Composants et état d EMC VPLEX Witness 31

32 Contrôle des performances VPLEX VPLEX 5.1 offre une surveillance améliorée des performances avec le 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ébut 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. Figure 25 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 25. Tableau de bord de contrôle des performances VPLEX 32

33 Infrastructure virtualisée VMware Introduction 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 composants et les options suivants : VMware vsphere 5.0 Update 1 ; VMware vcenter TM 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 la plate-forme de virtualisation la plus puissante, évolutive et complète du marché. 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 de disponibilité, de sécurité et d évolutivité plus élevés. 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 à travers 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) répartit dynamiquement et automatiquement la distribution de la charge et le placement des machines virtuelles sur les différents serveurs VMware ESXi. 33

34 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 de gestion des chemins avancées. 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 de ces fonctions indépendamment des autres, 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, par exemple, la règle d équilibrage de la charge, le nombre de chemins actifs et le nombre de chemins inactifs. Déploiements VMware sur VPLEX Metro 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 une infrastructure active/active, qui offre des clusters étendus géographiquement basés sur VMware vsphere. L utilisation de la technologie Brocade Virtual Link Aggregation Group (vlag) permet d étendre les VLAN et, par conséquent, les sousré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 : la capacité de migrer dynamiquement des machines virtuelles entre des sites pour anticiper des événements planifiés comme une maintenance matérielle. Storage vmotion : la capacité de migrer le stockage d une machine virtuelle sans interrompre la disponibilité de cette machine virtuelle. Cette technologie permet la réaffectation de machines virtuelles dynamiques vers d autres datastores. VMware DRS : la distribution de la charge et le déplacement de machines virtuelles automatiques 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 du site. La combinaison de VPLEX Metro HA et d une technologie de mise en cluster en cas de basculement sur incident de l hôte (comme VMware HA) redémarre automatiquement une application en cas de sinistre au niveau du site. Figure 26 illustre cette architecture haute disponibilité. 34

35 Figure 26. VMware HA avec VPLEX Witness : vue logique Connexion entre clusters VPLEX Metro HA : la protection du cluster VMware HA peut encore être améliorée 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 s élevant jusqu à 1 ms. Cette solution utilise VPLEX Metro HA avec une connexion entre clusters pour optimiser la disponibilité des machines virtuelles VMware, comme représenté à la Figure Pour plus d informations, consultez le TechBook EMC : EMC VPLEX Metro Witness Technology and High Availability. 35

36 Figure 27. VMware HA avec VPLEX Witness et connexion entre clusters : vue logique Configuration d un cluster étendu VMware VMware et EMC prennent en charge une configuration de cluster étendu comprenant des hôtes VMware ESXi de plusieurs sites 2. Dans la solution, un cluster vsphere unique est étendu entre le site A et le site B à l aide d un volume distribué virtuel 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 28. Cette vue présente également la mémoire, le CPU et les ressources de stockage disponibles pour le cluster. Figure 28. Cluster vsphere haute disponibilité avec DRS activé 2 Pour plus de détails sur les exigences et les scénarios, consultez l article de la base de connaissances VMware : Using VPLEX Metro with VMware HA 36

37 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 offre un switch unique, commun à tous les hôtes. Les adaptateurs physiques 10 GbE (également appelés adaptateurs uplink) sont affectés au dvswitch. Deux groupes de ports distribués sont affectés à dvswitch : dvportgroupsiteab : pour le trafic réseau des machines virtuelles ; Management Network : pour le trafic VMkernel et, plus particulièrement, pour le trafic vmotion. Figure 29 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), les propriétés des switches physiques associés peuvent facilement être déterminées par vcenter. Figure 29. 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 devaient être en mesure de partager des disques virtuels ou d utiliser vmotion entre plusieurs sites. Figure 30 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 conserver la cohérence de leur configuration réseau lorsqu elles migrent entre des hôtes. Pour plus d informations, consultez le document VMware vsphere Networking ESXi

38 Figure 30. Le datastore EXT_SAP_VPLEX_DS01 et les hôtes et machines virtuelles associés Configuration de VMware vsphere HA 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 dues 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 31. Figure 31. Assistant vsphere HA 4 Pour plus d informations sur vsphere HA, consultez le document VMware vsphere Availability ESXi

39 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 était définie sur High. Cette configuration garantit que ces machines virtuelles sont démarrées en priorité en cas de panne. Figure 32 présente ce paramètre et le paramètre Host Isolation Response (par défaut). Figure 32. 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 33. 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 33. vsphere HA Cluster Status : datastores pour les heartbeats 39

40 Configuration de VMware vsphere DRS 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. Tableau 8 et Figure 34 illustre la règle d affinité utilisée par la solution. Tableau 8. Règle d affinité VMware DRS Règle d affinité VM-VM SAPASCS Separate Maintient les machines virtuelles SAPASCS2 et SAPASCS3 sur des hôtes distincts. Figure 34. Règle d affinité DRS VM-VM pour le cluster vplex_esxi_metro_ha EMC Virtual Storage Integrator et VPLEX EMC Virtual Storage Integrator (VSI) améliore la visibilité sur VPLEX directement depuis l interface utilisateur de vcenter. Les fonctions Storage Viewer et Gestion des chemins sont accessibles par l onglet EMC VSI, comme l illustre la Figure 35. 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 35, les LUN qui composent le datastore sont quatre volumes VPLEX Metro RAID 1 distribués de 256 Go, accessibles via PowerPath. 40

41 Figure 35. VSI Storage Viewer : datastores 41

42 Architecture du système SAP Introduction 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 de l application SAP utilise les composants SAP et SUSE suivants : 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 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é. 42

43 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 zone de stockage et des pilotes, ainsi que les moyens de gérer tous ces composants lorsqu ils fonctionnent ensemble. SUSE Linux Enterprise High Availability Extension offre 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. Configuration du système SAP Architecture du système SAP La solution met en œuvre une architecture de système SAP haute disponibilité, comme l illustre la Figure 36. Figure 36. Architecture du système SAP 43

44 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 ASCS 5. SAP ERS est installé en tant que partie 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 attente 6. Deux instances Dialog sont installées pour fournir des méthodes de travail redondantes, 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 73. Cette solution utilise les bonnes pratiques VMware pour SAP 7. 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 Dialog 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 tous les nœuds de cluster SAP, toutes les instances ASCS et toutes les instances 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 non nécessaires qui sortent du cadre de la solution. 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. 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. 44

45 Configuration de SUSE Linux Enterprise High Availability Extension 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 (VMware HA) protège toutes les machines virtuelles, y compris ASCS et le serveur d applications supplémentaire (AAS). Figure 37 présente cette architecture. Figure 37. 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 : OpenAIS 8 /Corosync 9, 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 l implémentation de haute disponibilité dans les applications. 45

46 Tableau 9 présente la configuration des machines virtuelles SAP. Tableau 9. 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 SAPASCS2 SAP ERS SAPASCS3 SAP AAS SAPDI 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

47 Figure 38. 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 39. Figure 39. Configuration des paramètres de base du cluster 47

48 4. Dans Pacemaker GUI, configurez les paramètres de cluster globaux, comme indiqué à la Figure 40. Figure 40. Configuration des paramètres de cluster globaux 5. Dans Pacemaker GUI, ouvrez la catégorie Resources, et configurez IPaddr2, le maître/l esclave, et les ressources SAPInstance, comme l illustre la Figure 41. Figure 41. Configuration des ressources 48

49 6. Dans Pacemaker GUI, configurez les dépendances des ressources, comme l illustre la Figure 42. Figure 42. Configuration des dépendances des ressources 7. Dans Pacemaker GUI, démarrez le cluster, et vérifiez que le cluster et tous les agents de ressource fonctionnent normalement, comme l illustre la Figure 43. Figure 43. Vérification de l état du cluster 49

50 Principales caractéristiques de la conception Configuration du périphérique STONITH SBD (périphérique de bloc STONITH) et STONITH (Shoot The Other Node In The Head) permettent l isolement (de nœuds) dans un cluster grâce au stockage partagé. Cette solution utilise une partition de disque virtuel (VMDK) comme un périphérique SBD STONITH. 10 Par conséquent, les deux nœuds de cluster doivent disposer d un accès simultané à ce disque virtuel. Le disque virtuel est stocké dans le même datastore que les machines virtuelles SAP. Il est approvisionné et protégé par VPLEX, et il est disponible sur les deux sites. Par défaut, VMFS empêche les machines virtuelles d accéder en lecture et en écriture simultanément à un même VMDK. Toutefois, vous pouvez activer le partage en configurant l option multi-writer 11, comme l illustre la Figure 44. Figure 44. Option multi-writer Le périphérique SBD est protégé par VPLEX, et est accessible par le biais du logiciel de multipathing EMC PowerPath/VE. Les paramètres d expiration du délai pour le périphérique SBD doivent être correctement configurés pour prendre en compte l expiration du délai du cluster Oracle RAC sous-jacent ainsi que le processus d isolement VLEX. Figure 45 présente la configuration utilisée dans cette solution. Figure 45. Configuration du périphérique SBD 10 SBD est essentiel pour gérer les scénarios de déconnexion dans le cluster. Un périphérique SBD unique est configuré pour cette solution. Cette configuration de périphérique SBD est uniquement destinée à des fins de test ; pour la configuration de production, consultez le document Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack. 11 Pour plus d informations, consultez l article de la base de connaissances VMware : Disabling simultaneous write protection provided by VMFS using the multi-writer flag. 50

51 Configuration maître/esclave L agent de ressources SAPInstance contrôle l instance ASCS ainsi que l instance ERS appropriée. Il est configuré comme une ressource maître/esclave, qui étend les rôles de la ressource de «started» et «stopped» en «master» et «slave». Une instance promue au rang de maître démarre l instance SAP ASCS. L instance rétrogradée au rang d esclave démarre l instance ERS. Le mode maître/esclave garantit qu une instance ASCS n est jamais démarrée sur le même nœud que l ERS. Figure 46 présente la configuration de l agent de ressources SAPInstance. Figure 46. Configuration de l agent de ressources SAPInstance Figure 47 présente la configuration de l agent de ressources maître/esclave. Figure 47. Configuration de l agent de ressources maître/esclave 51

52 Contraintes au niveau des ressources L instance ASCS et son IP virtuelle sont liées à l aide des contraintes d ordre et de colocation appropriées. Figure 48 présente la configuration des contraintes en matière de colocation et d ordre des ressources. Figure 48. Configuration des contraintes en matière de colocation et d ordre des ressources Concept d interrogation SUSE Linux Enterprise High Availability Extension peut surveiller en continu l état des processus SAP sur chaque nœud de cluster, et prendre les décisions appropriées en matière de promotion/destitution des instances respectives ASCS et ERS. Il est inutile de mettre en œuvre le concept d interrogation SAP. Vérifiez que cette fonction n est PAS activée dans le profil d instance ERS. Pour un exemple de profil d instance ERS, reportez-vous à la section Exemple de profil d instance ERS à la page

53 Architecture d Oracle Database Introduction Présentation Cette section présente la grille et la base de données sous-jacentes aux applications SAP dans la solution. La base de données était à l origine une instance unique Oracle Database 11g physique. Pour éliminer le serveur de base de données en tant que point de défaillance unique, la base de données de l instance unique a été migrée vers un cluster physique Oracle RAC 11g à 4 nœuds, où la base de données Oracle réside sur ASM. La solution utilise les composants et options Oracle suivants : Oracle Database 11g Release 2 Enterprise Edition ; Oracle Automatic Storage Management (ASM) et Oracle ASM Cluster File System (ACFS) ; Oracle Clusterware ; Oracle Real Applications Clusters (RAC) 11g on Extended Distance Clusters. Oracle Database 11g R2 Oracle Database 11g Release 2 Enterprise Edition offre des performances, une évolutivité, une sécurité et une fiabilité leaders sur le marché pour une variété de serveurs uniques ou en cluster exécutant Windows, Linux ou UNIX ainsi que des fonctions complètes pour les applications de traitement des transactions, décisionnelles et de gestion de contenu. Oracle ASM et Oracle ACFS Oracle ASM est un système de fichiers de base de données et un gestionnaire de disques intégré compatible avec le système de cluster. Les fonctions de gestion de volumes et le système de fichiers ASM sont intégrés dans le noyau de la base de données Oracle. Dans Oracle Database 11g R2, Oracle ASM a également été étendu pour inclure la prise en charge d OCR et des fichiers de vote à placer dans les groupes de disques ASM. Oracle ACFS (une fonction d ASM dans Oracle Database 11g) étend la fonction d ASM pour lui permettre de se comporter comme un système de fichiers de cluster général. Les binaires Oracle Database peuvent résider sur ACFS, tout comme les fichiers de prise en charge (par exemple, les logs de traces et d alerte) et les fichiers d autres applications qu Oracle, comme SAP ERP. Les autres serveurs qu Oracle peuvent accéder aux volumes ACFS à l aide des protocoles NAS standard, comme NFS et le système CIFS. Oracle Clusterware Oracle Clusterware est une solution de gestion de cluster portable intégrée dans la base de données Oracle. Cette solution offre l infrastructure nécessaire pour exécuter Oracle RAC, y compris les services de gestion de cluster et les services haute disponibilité. Une autre application qu Oracle peut également gagner en disponibilité à travers le cluster grâce à Oracle Clusterware. Infrastructure Oracle Grid Dans Oracle Database 11g R2, Oracle Grid Infrastructure combine Oracle ASM et Oracle Clusterware en un ensemble de binaires distinctes du logiciel de la base de données. Cette infrastructure offre à présent le cluster et les services de stockage requis pour exécuter une base de données Oracle RAC. 53

54 Oracle Real Application Clusters 11g Oracle RAC est principalement une solution haute disponibilité pour les applications de base de données Oracle dans le datacenter. Il permet à plusieurs instances Oracle d accéder à une base de données unique. Le cluster se compose d un groupe de serveurs indépendants, fonctionnant ensemble comme un système unique, et partageant le même ensemble de disques de stockage. Chaque instance s exécute sur un serveur distinct du cluster. RAC garantit la haute disponibilité, l évolutivité, la tolérance aux pannes, l équilibrage de la charge et les gains de performances. Il peut également supprimer tout point de défaillance unique de la solution de base de données. Oracle Extended RAC Oracle RAC sur clusters éloignés (Extended Distance Clusters) est une architecture qui permet aux serveurs du cluster de résider dans des emplacements physiques distincts. Ceci supprime le datacenter en tant que point unique de défaillance. Oracle Extended RAC permet à tous les nœuds du cluster (indépendamment de leur emplacement) d être actifs. Il assure une haute disponibilité et la continuité d activité lors d une panne réseau ou du site, comme suit : Le stockage et les données restent disponibles et actifs sur le site resté actif. Les services Oracle équilibrent la charge et basculent sur les nœuds Oracle RAC sur le site resté actif. Oracle Transparent Application Failover (TAF) permet aux sessions de basculer automatiquement vers les nœuds Oracle RAC sur le site resté actif. Les applications tierces gérées par Oracle Clusterware peuvent équilibrer la charge et basculer vers les nœuds Oracle RAC sur le site resté actif (par exemple : le processus httpd d Apache ou de NFS). Les nœuds Oracle RAC du site resté actif continuent à traiter les transactions. Oracle recommande d utiliser l architecture Oracle Extended RAC lorsque les deux datacenters sont relativement proches (pas éloignés de plus de 100 km) 12. Oracle RAC et VPLEX Configuration Oracle ACFS Oracle RAC s exécute normalement dans un datacenter local en raison de l impact potentiel de la latence entraînée par la distance et de la complexité qui en découle, ainsi que des frais supplémentaires requis pour étendre Oracle RAC à tous les datacenters utilisant la mise en miroir basée sur l hôte avec Oracle ASM. Toutefois, avec EMC VPLEX Metro, un déploiement Oracle Extended RAC (du point de vue de l administrateur de base de données Oracle) est une installation et une configuration Oracle RAC standard 13. Cette solution utilise quatre volumes ACFS montés sur le cluster Oracle RAC, comme l illustre la Tableau 10. Trois de ces volumes (SAPMNT, USRSAPTRANS et ASCS00) ont ensuite été exportés en tant que partages NFS vers les serveurs SAP, à l aide d une adresse IP virtuelle et d une ressource NFS haute disponibilité gérées par Oracle Clusterware. 12 Consultez le livre blanc Oracle : Oracle Real Application Clusters (RAC) on Extended Distance Clusters. 13 Consultez le livre blanc EMC : Oracle Extended RAC with EMC VPLEX Metro Best Practices Planning. 54

55 Tableau 10. Volumes Oracle ACFS et points de montage Volume ACFS Taille (Go) Point de montage Description SAP_O_HOME 16 /oracle/vse/112 ORACLE_HOME pour base de données VSE partagé sur tous les nœuds Oracle RAC SAPMNT 16 /sapmnt/vse Répertoire SAP global (où sont stockés les noyaux et les profils) partagé sur toutes les machines virtuelles SAP USRSAPTRANS 16 /usr/sap/trans Répertoire de transport SAP (où sont stockés les fichiers de transport) partagé sur toutes les machines virtuelles SAP Dialog Instance ASCS00 16 /usr/sap/vse/ascs00 Répertoire d instance SAP ASCS (où sont stockés les fichiers liés aux instances) partagé sur les nœuds du cluster SUSE Linux Enterprise High Availability Extension Oracle Extended RAC sur VPLEX Metro Figure 49 fournit une représentation logique du déploiement d Oracle Extended RAC sur VPLEX Metro pour la solution. Figure 49. Oracle Extended RAC sur EMC VPLEX Metro 55

56 Configuration des groupes de disques Oracle ASM Tableau 11 présente la configuration et la mise en page des groupes de disques ASM. Tableau 11. Groupe de disques ASM* Taille et configuration de groupe de disques Oracle ASM Nombre de disques Taille du groupe de disques (Go) Redondance OCR 5 40 Normal EA_SAP_ACFS 4 64 Externe EA_SAP_DATA Externe EA_SAP_REDO 4 64 Externe EA_SAP_REDOM 4 64 Externe EA_SAP_FRA Externe * Le préfixe EA_SAP_ est uniquement utilisé pour identifier les groupes de disques ASM associés à l application SAP dans Extended Oracle RAC. Connexion à Oracle RAC à partir de SAP Pour permettre à SAP de se connecter à la base de données Oracle RAC, tnsnames.ora se trouvait sur chaque machine virtuelle SAP (SAPDI1 et SAPDI2), comme l illustre la Figure 50. VSE.WORLD= (DESCRIPTION = (LOAD_BALANCE = OFF) (FAILOVER = ON) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = sse-ea-erac-scan-c01.sse.ea.emc.com) (PORT = 1521) ) ) (CONNECT_DATA = ) ) (SERVICE_NAME = VSE.sse.ea.emc.com) (FAILOVER_MODE = (TYPE = SELECT) (METHOD = BASIC)) Figure 50. Exemple d entrée de fichier tnsnames.ora pour la base de données Oracle RAC TAF (Transparent Application Failover) est une fonction côté client qui permet aux clients de se reconnecter aux instances restées actives si une instance de base de données rencontre une panne. TAF peut être définie à l aide d une chaîne de connexion spécifiée côté client ou d attributs de service côté serveur. Dans la solution, le service de base de données VSE.sse.ea.emc.com était configuré pour TAF sur Oracle RAC. Il était également configuré côté client pour permettre à SAP d utiliser TAF. TAF était définie pour établir des connexions lors du basculement sur incident et pour fournir aux utilisateurs des curseurs ouverts afin de continuer à les extraire après l échec des opérations sélectionnées. 56

57 Infrastructure réseau Brocade Introduction Présentation Cette section décrit les réseaux IP et SAN déployés pour la solution dans les deux datacenters, et l extension Layer 2 entre les datacenters. L infrastructure du réseau est constituée des composants Brocade suivants : Réseau IP Switches de datacenter Brocade VDX 6720 Routeurs de la gamme Brocade MLX Adaptateurs CNA Brocade 1020 SAN Backbones Brocade DCX 8510 Adaptateurs HBA Brocade 825 Brocade VDX 6720 Le switch pour datacenter Brocade VDX 6720 est un switch de port fixe hautes performances, à latence extrêmement faible et à vitesse câblée de 10 GbE. Il est spécialement conçu pour améliorer l utilisation du réseau, optimiser la disponibilité des applications, accroître l évolutivité et simplifier drastiquement l architecture réseau des datacenters virtualisés. Disposant de nombreuses fonctions Layer 2, Brocade VDX 6720 est une plate-forme idéale pour les déploiements de switches ToR (Top-of-Rack). En fournissant la technologie Brocade VCS Fabric, Brocade VDX 6720 permet aux entreprises de concevoir un fabric Ethernet de datacenter, révolutionnant la conception des réseaux Layer 2, et proposant une base intelligente pour les datacenters optimisés pour le Cloud. Gamme Brocade MLX Les routeurs de la gamme Brocade MLX sont conçus pour créer des réseaux optimisés pour le Cloud. Ils offrent des fonctions de densité de vitesse câblée de 100 GbE, 10 GbE et 1 GbE ; d IPv4 riche, d IPv6, de Multi-VRF, de MPLS (Multiprotocol Label Switching) et de support Ethernet leaders sur le marché, ainsi que des switches Layer 2 avancés. En tirant parti de la gamme Brocade MLX, les datacenters critiques peuvent prendre en charge davantage de trafic, parvenir à une meilleure virtualisation, et fournir des services basés sur le Cloud de grande valeur en utilisant moins d infrastructure, en simplifiant leurs opérations et en réduisant leurs coûts. De plus, les routeurs de la gamme Brocade MLX simplifient les réseaux des grands campus en réduisant les couches d agrégation et centrale, ainsi qu en fournissant une connectivité entre les sites avant MPLS/VPLS. Tous les routeurs de la gamme Brocade MLX permettent de réduire les coûts d alimentation et de refroidissement grâce à la faible consommation électrique et à la dissipation thermique de leur classe. Conçus pour une mise en réseau sans interruption, les routeurs de la gamme Brocade MLX disposent du Multi-Chassis Trunking (MCT), qui fournit plus de 30 To/s de bande passante à double châssis, des liaisons de routage entièrement actives/actives et un flux de trafic sans interruption en cas de basculement du nœud. Les entreprises peuvent atteindre une résilience élevée grâce aux fabrics de switch redondants, aux modules de gestion, aux alimentations et aux systèmes de refroidissement. Pour garantir davantage la disponibilité des applications et du réseau, le système d exploitation Brocade IronWare propose des fonctions de basculement de gestion et de mises à niveau logicielles sans perturbation. 57

58 Backbone Brocade DCX 8510 Les réseaux doivent évoluer pour prendre en charge les exigences croissantes des environnements hautement virtualisés et des architectures de Cloud privé. Aujourd hui, Fibre Channel (FC) est la norme de facto pour la mise en réseau du stockage dans le datacenter. L introduction de Fibre Channel 16 Go/s prolonge la vie de cette technologie robuste, fiable et hautes performances. FC permet aux entreprises de continuer à tirer profit de leurs investissements informatiques existants lorsqu elles relèvent leurs défis métiers les plus difficiles. Les backbones Brocade DCX 8510 constituent l infrastructure de switches Fibre Channel 16 Go/s la plus puissante du secteur. En outre, ils fournissent la base hautes performances la plus fiable et évolutive pour le stockage de Cloud privé et les environnements hautement virtualisés. Ils sont conçus pour améliorer la réactivité tout en fournissant un accès continu aux informations et en réduisant les coûts d infrastructure et d administration. La fonction FC de 16 Go des routeurs Brocade DCX 8510 offre des avantages importants pour la connectivité SAN Metro de datacenter à datacenter : Sa capacité de 16 Go offre le débit maximal et la latence FC la plus basse pour les déploiements utilisant des connexions par fibre entre datacenters. Vitesse filaire FC de 10 Go facultative pour un taux d utilisation filaire optimal si un réseau DWDM est déployé entre plusieurs sites. Cette fonction nécessite une licence. Trunking ISL (Inter-Switch Link) facultatif au niveau de la trame permettant un taux d utilisation élevé par rapport au trunking DPS standard. Cette fonction nécessite une licence. Compression facultative pour les ISL entre les datacenters. Elle augmente la bande passante pour les déploiements où le nombre de connexions de site à site est limité. Chiffrement des données à la volée facultatif pour les ISL entre les datacenters pour les déploiements nécessitant des niveaux de sécurité des données très élevés. Détection et restauration de la perte de crédit de la mémoire tampon. FEC (Forward Error Correction) automatique, qui corrige proactivement jusqu à 11 erreurs de bit par trames FC de bits. Le mode de diagnostic pour les ports ISL entre les datacenters peut être utilisé sur n importe quel port ISL (hors ligne), et offre les fonctions suivantes : tests de boucles optiques et électriques ; tests de la saturation des liaisons ; précision de la mesure de la distance de liaison à 5 m près lors d une utilisation avec SFP+ 8 GbE et à 50 m près avec SFP+ 10 GbE. 58

59 Configuration du réseau IP Dans la solution, le réseau IP de chaque datacenter est constitué de deux switches Brocade VDX 6720 dans une configuration VCS. Tous les serveurs sont connectés au réseau avec des connexions redondantes 10 GbE fournies par des adaptateurs CNA Brocade Les deux switches Brocade VDX de chaque site sont connectés à un routeur Brocade MLX Series à l aide d un vlag (Virtual Link Aggregation Group). Les routeurs de la gamme Brocade MLX étendent le réseau Layer 2 entre les deux datacenters. Remarque Un vlag est un service de fabric qui permet à un LAG (Link Aggregation Group) d être généré à partir de plusieurs switches Brocade VDX. Tout comme un LAG standard, un vlag utilise LACP (Link Aggregation Control Protocol) pour contrôler le groupement de plusieurs ports physiques qui forment un canal logique unique. Oracle RAC dépend d une IP virtuelle haute disponibilité (HAIP ou connexion RAC) pour la communication réseau privé. Avec HAIP, le trafic des connexions est réparti entre les différentes interfaces identifiées comme le réseau privé. Dans la solution, un VLAN distinct (VLAN 10) est utilisé pour les connexions. VLAN 20 a traité tout le trafic public. Tout le trafic entre le site A et le site B est acheminé par des routeurs Brocade MLX à l aide de plusieurs ports configurés comme un LAG. Figure 51 présente l infrastructure réseau IP. Figure 51. Les réseaux de la solution IP 59

60 Configuration du réseau SAN Le réseau SAN de chaque datacenter est composé de backbones Brocade DCX 8510, comme l illustre la Figure 52. Tous les serveurs sont connectés au réseau SAN à l aide de connexions redondantes 8 Go fournies par des adaptateurs HBA Brocade 825. La connexion de VPLEX à VPLEX entre les datacenters utilise plusieurs connexions FC entre les backbones Brocade DCX Ceux-ci sont utilisés en mode actif-actif avec basculement sur incident. Figure 52. Les réseaux de la solution SAN 60

61 Haute disponibilité et continuité d activité : tests et validation Introduction Défaillance du processus du service de mise en file d attente SAP L équipe de validation EMC a d abord installé et validé l environnement sans aucun schéma de protection de continuité d activité ou de haute disponibilité. Nous avons ensuite transformé l environnement en la solution de continuité d activité critique décrite dans le présent livre blanc. Nous avons effectué les tests suivants pour valider la solution et prouver l élimination de tous les points de défaillance uniques de l environnement : défaillance du processus du service de mise en file d attente SAP ; défaillance de la machine virtuelle de l instance SAP ASCS ; défaillance du nœud Oracle RAC ; panne du site ; isolement du cluster VPLEX. Scénario de test Ce scénario de test confirme que, si le processus du service de mise en file d attente est défaillant, le cluster SUSE Linux Enterprise High Availability Extension promeut l instance SAP ERS en une instance ASCS entièrement fonctionnelle, et prend le relais de la table de verrouillage sans interruption pour l utilisateur. Pour tester ce scénario de panne, nous avons mis fin au processus de mise en file d attente sur le nœud ASCS actif à l aide de la commande kill : kill -9 <process id> Comportement du système Le système répond à la défaillance du processus de service de mise en file d attente comme suit : 1. L agent de ressources SAPInstance détecte et rapporte la défaillance, comme l illustre la Figure 53. Figure 53. L agent de ressources SAPInstance détecte et rapporte la défaillance 61

62 2. L agent de ressources maître/esclave promeut le nœud esclave précédent (SAPASCS2) en nœud maître, qui héberge les services ASCS, et démarre ERS en tant qu esclave sur l autre nœud (SAPASCS3) lorsqu il réintègre le cluster (voir Figure 54). Figure 54. L agent de ressources maître/esclave bascule les nœuds maître et esclave 3. La table de verrouillage répliquée est restaurée, comme l illustre la Figure 55. Figure 55. Table de verrouillage répliquée restaurée Résultat L utilisateur ne remarque pas la défaillance du processus de mise en file d attente, sauf si une opération de mise en file d attente est en cours. Dans ce cas, l utilisateur rencontre des temps de réponse des transactions plus longs pendant le switchover. Les nouveaux utilisateurs peuvent se connecter au système immédiatement après le switchover du serveur de messages. Aucune intervention de l administrateur n est requise. 62

63 Défaillance de la machine virtuelle de l instance SAP ASCS Scénario de test Ce scénario de test confirme que, en cas de panne inattendue d un serveur VMware ESXi (équivalente à une panne de machine virtuelle), le cluster High Availability Extension promeut l instance SAP ERS en une instance ASCS entièrement fonctionnelle, et prend le relais de la table de verrouillage, sans interruption pour l utilisateur. Pour tester ce scénario de panne, nous avons mis hors tension (via la console physique distante) le serveur VMware ESXi qui héberge la machine virtuelle de l instance SAP ASCS. Nous avons ensuite redémarré le serveur sans entrer dans le mode Maintenance. Comportement du système Le système répond à la défaillance de la machine virtuelle comme suit : 1. SAPASCS2 n est plus accessible à partir du client vsphere (voir Figure 56). Figure 56. La machine virtuelle rencontre une panne 63

64 2. L agent de ressources SAPInstance détecte et rapporte la défaillance (voir Figure 57). Figure 57. L agent de ressources SAPInstance détecte et rapporte la défaillance 3. VMware HA redémarre la machine virtuelle SAPASCS2 en échec sur l hôte VMware ESXi resté actif, comme l illustre la Figure 58. Figure 58. VMware HA redémarre la machine virtuelle en échec 64

65 4. L agent de ressources maître/esclave promeut le nœud esclave précédent (SAPASCS3) en nœud maître, qui héberge les services ASCS, et démarre ERS en tant qu esclave sur l autre nœud (SAPASCS2) lorsqu il réintègre le cluster (voir Figure 59). Figure 59. L agent de ressources maître/esclave bascule les nœuds maître et esclave 5. La table de verrouillage répliquée est restaurée (voir Figure 60). Figure 60. Table de verrouillage répliquée restaurée Résultat L utilisateur ne remarque pas la défaillance du processus de mise en file d attente, sauf si une opération de mise en file d attente est en cours. Dans ce cas, l utilisateur rencontre des temps de réponse des transactions plus longs pendant le switchover. Les nouveaux utilisateurs peuvent se connecter au système immédiatement après le switchover du serveur de messages. Aucune intervention de l administrateur n est requise. Défaillance du nœud Oracle RAC Scénario de test Ce scénario de test confirme que, en cas de défaillance du nœud Oracle RAC, les instances SAP se connectent automatiquement aux nœuds RAC. Les utilisateurs peuvent continuer leurs transactions sans interruption, sauf si les transactions qui ne sont pas écrites (au niveau de la base de données) sont exécutées sur le nœud RAC en échec. Pour tester ce scénario de défaillance, nous avons redémarré le serveur afin de provoquer une défaillance du nœud Oracle. 65

66 Comportement du système Le système répond à la défaillance du nœud RAC comme suit : 1. Le nœud RAC se déconnecte, et l instance VSE003 n est plus disponible, comme l illustre la Figure 61. Figure 61. oracle@sse-ea-erac-n01:~> srvctl status database -d VSE Instance VSE001 is running on node sse-ea-erac-n01 Instance VSE002 is running on node sse-ea-erac-n02 Instance VSE004 is running on node sse-ea-erac-n03 Instance VSE003 is not running on node sse-ea-erac-n04 Déconnexion du nœud RAC 2. La méthode de travail de l instance SAP se connecte à une autre instance RAC comme le montre la Figure 62.. Figure 62. L instance SAP se connecte à un autre nœud RAC Résultat L utilisateur rencontre des temps de réponse des transactions plus longs lorsque la méthode de travail de l instance de dialogue se reconnecte à un autre nœud RAC. Les transactions qui n ont pas été écrites sont restaurées au niveau de la base de données pour garantir la cohérence des données. L utilisateur reçoit un message d erreur système (vidage partiel) et doit redémarrer la transaction. Aucune intervention de l administrateur n est requise. Panne du site Scénario de test Ce scénario de test confirme que, en cas de panne du site entier, les nœuds RAC restés actifs préservent les opérations de bases de données. Pour tester ce scénario de panne, nous avons simulé une panne complète du site A, y compris des composants du cluster VPLEX, du serveur VMware ESXi, du réseau et du nœud RAC d Oracle. VPLEX Witness reste disponible sur le site C. Sur le site B, le cluster-2 VPLEX est resté en communication avec VPLEX Witness. 66