BUSINESS CONTINUITY MISSION-CRITICAL EMC PER SAP

Transcript

1 White paper BUSINESS CONTINUITY MISSION-CRITICAL EMC PER SAP Gestione semplificata per High Availability e business continuity Implementazioni SAP mission-critical resilienti Data center active-active EMC Solutions Group Abstract Nel presente white paper viene descritta la trasformazione di un'implementazione SAP tradizionale in una soluzione di business continuity mission-critical con data center active-active. La soluzione utilizza EMC VPLEX Metro, EMC Symmetrix VMAX, VMware vsphere High Availability, Oracle RAC, le soluzioni di rete Brocade e SLES for SAP Applications. Novembre 2012

2 Copyright 2012 EMC Corporation. Tutti i diritti riservati. EMC ritiene che le informazioni contenute nel presente documento siano esatte alla data di pubblicazione. Le informazioni sono soggette a modifica senza preavviso. Le informazioni contenute nella presente documentazione sono fornite "come sono". EMC Corporation non riconosce alcuna garanzia di alcun genere inerente le informazioni riportate nella presente pubblicazione, tra cui garanzie implicite di commerciabilità o idoneità a un determinato scopo. L'utilizzo, la copia e la distribuzione dei prodotti software di EMC descritti in questo documento richiedono una licenza d'uso valida per ciascun software. Per un elenco aggiornato dei nomi dei prodotti EMC, vedere i marchi di EMC Corporation sul sito web di EMC. VMware, VMware vsphere, ESXi, vcenter e vmotion sono marchi o marchi registrati di VMware, Inc. negli Stati Uniti e/o in altre giurisdizioni. Brocade, DCX, MLX, VCS e VDX sono marchi registrati di Brocade Communications Systems, Inc. negli Stati Uniti e/o in altri paesi. Tutti gli altri marchi citati nel presente documento appartengono ai rispettivi proprietari. Part Number H

3 Sommario Executive summary... 5 Business case... 5 Solution overview... 5 Vantaggi principali... 6 Introduzione... 7 Obiettivo... 7 Ambito... 7 Audience... 7 Terminologia... 7 Solution overview... 9 Introduzione... 9 Architettura della soluzione Livelli di protezione Database e profilo del carico di lavoro Risorse hardware Risorse software Infrastruttura di storage EMC Introduzione EMC Symmetrix VMAX 10K Enginuity EMC Symmetrix VMAX 20K EMC Unisphere for VMAX Configurazione VMAX Infrastruttura EMC VPLEX Metro Introduzione Data mobility VPLEX Configurazione della soluzione VPLEX Metro Configurazione di VPLEX Witness Monitoraggio delle prestazioni VPLEX Infrastruttura virtualizzata VMware Introduzione Implementazioni di VMware su VPLEX Metro Configurazione dello stretched cluster di VMware Configurazione di VMware vsphere HA Configurazione di VMware vsphere DRS EMC Virtual Storage Integrator e VPLEX

4 Architettura del sistema SAP Introduzione Configurazione del sistema SAP Configurazione di SUSE Linux Enterprise High Availability Extension Architettura del database Oracle Introduzione Oracle RAC e VPLEX Configurazione di Oracle ACFS Oracle Extended RAC su VPLEX Metro Configurazione del gruppo di dischi ASM Oracle Infrastruttura di rete Brocade Introduzione Configurazione della rete IP Configurazione della rete SAN High Availability e business continuity: test e convalida Introduzione Errore del processo del servizio di accodamento SAP Errore della virtual machine dell'istanza SAP ASCS Errore del nodo Oracle RAC Guasto del sito Isolamento dei cluster VPLEX Conclusioni Riepilogo Risultati Riferimenti EMC Oracle VMware SUSE SAP Appendice: configurazioni di esempio Configurazione di esempio CRM Profilo di un'istanza ASCS di esempio Profilo di un'istanza ERS di esempio Profilo di AVVIO ERS di esempio Profilo di un'istanza DI di esempio

5 Executive summary Business case Per continuare a essere competitive, le imprese globali richiedono la continuous availability delle applicazioni e la disponibilità delle informazioni. La soluzione EMC descritta nel presente white paper offre una strategia di business continuity e High Availability per le applicazioni mission-critical come SAP ERP. Gli obiettivi RPO (Recovery Point Objective) e RTO (Recovery Time Objective) costituiscono metriche essenziali nella pianificazione di una strategia di business continuity mission-critical. Rispondono a due domande fondamentali che le aziende si pongono quando considerano l'impatto potenziale di un disastro o un errore. Quanti dati possiamo permetterci di perdere (RPO)? Quanto è urgente il ripristino del sistema o dell'applicazione (RTO)? La business continuity mission-critical per SAP richiede RPO e RTO aggressivi per ridurre al minimo la perdita di dati e i tempi di ripristino. Tra le problematiche principali che l'azienda deve prendere in considerazione durante la definizione di tale strategia figurano: la riduzione al minimo di RPO e RTO; l'eliminazione dei single point of failure: la tecnologia, il personale, i processi; il massimo utilizzo delle risorse; la riduzione dei costi associati all'infrastruttura; la gestione della complessità di integrazione, manutenzione e test di più soluzioni mirate. Nel presente white paper viene introdotta una soluzione EMC in grado di risolvere tutte queste problematiche per le applicazioni SAP ERP con un livello del database Oracle Real Applications Clusters (RAC) 11g. La soluzione illustra un modello di implementazione active-active innovativo per i data center situati a una distanza massima di 100 km. Il modello DR (disaster recovery) active-passive tradizionale viene trasformato in una soluzione di business continuity con High Availability, availability delle applicazioni 24x7, nessun single point of failure e RTO e RPO vicini allo zero. Solution overview EMC VPLEX Metro è la tecnologia abilitante primaria per questa soluzione. VPLEX Metro è una soluzione di federation basata su SAN, che offre la federation dello storage sia locale sia distribuita. La sua tecnologia innovativa, AccessAnywhere TM, consente la coesistenza dei dati in due siti geograficamente separati e di accedere a e aggiornare contemporaneamente entrambi i siti. Grazie all'aggiunta di VPLEX Witness alla soluzione, le applicazioni continuano a essere disponibili, senza interruzioni o tempi di inattività, anche in caso di interruzione in uno dei data center. Nel white paper viene dimostrato come le tecnologie riportate di seguito contribuiscono a creare questa soluzione di business continuity innovativa. EMC VPLEX Metro fornisce il livello di storage virtuale che abilita un data center Metro active-active. 5

6 La data mobility VPLEX consente il trasferimento senza interruzioni dei dati a livello di storage. EMC VPLEX Witness supporta la continuous availability delle applicazioni, anche in caso di interruzione in uno dei data center. EMC Symmetrix serie VMAX 10K con storage array Enginuity, un'availability comprovata del 99,999%, il supporto di Fully Automated Storage Tiering (FAST) e una gamma di tecnologie di replica fornisce piattaforme di storage di classe enterprise per la soluzione. La migrazione da un database istanza singola a Oracle RAC su cluster a grandi distanze rimuove i single point of failure a livello del database, sull'intera distanza. VMware vsphere virtualizza i componenti delle applicazioni SAP e li elimina come single point of failure. VMware High Availability (HA) protegge le virtual machine in caso di guasto del server o errore del sistema operativo. SLES for SAP Applications, con SUSE Linux Enterprise High Availability Extension e SAP Enqueue Replication Server (ERS), protegge i servizi centrali SAP (server di messaggistica e server di accodamento) in due nodi di cluster per eliminare questi servizi come single point of failure. Le fabric Ethernet e i router core MLXe Brocade forniscono un networking trasparente e un'estensione di livello 2 tra i siti. I backbone DCX 8510 Brocade offrono un'infrastruttura SAN ridondante, compresa l'estensione delle fabric. Vantaggi principali La soluzione aumenta l'availability delle applicazioni SAP tramite: l'eliminazione dei single point of failure a tutti i livelli nell'ambiente per creare un sistema SAP distribuito e con High Availability; la fornitura di data center active-active che supportano RPO e RTO vicini allo zero e una business continuity mission-critical. Altri vantaggi includono: la fornitura di ambienti di storage convalidati e affidabili per SAP da parte di Symmetrix VMAX 10K; la gestione completamente automatica degli errori; il maggiore utilizzo delle risorse hardware e software: utilizzo active-active di entrambi i data center; bilanciamento automatico del carico tra i data center; manutenzione senza tempi di inattività; la gestione con High Availability SAP semplificata; l'implementazione semplificata di Oracle RAC su cluster a grandi distanze; la riduzione dei costi tramite l'aumento dell'automazione e dell'utilizzo dell'infrastruttura; il trasferimento facile e veloce dei dati tra gli storage array. 6

7 Introduzione Obiettivo Nel presente white paper viene descritta una soluzione che aumenta l'availability delle applicazioni SAP creando data center active-active in siti geograficamente separati ed eliminando i single point of failure a tutti i livelli nell'ambiente. Negli ambienti SAP, l'interruzione del business può essere dovuta a guasti tecnici, logici e logistici. Questa soluzione gestisce la business continuity da una prospettiva tecnica. Ambito L'ambito del white paper è: introdurre le tecnologie di abilitazione principali; descrivere l'architettura e la progettazione della soluzione; descrivere la modalità di configurazione dei componenti chiave; presentare i risultati dei test eseguiti per dimostrare l'eliminazione dei single point of failure a tutti i livelli nell'ambiente; identificare i vantaggi aziendali principali della soluzione. Audience Terminologia Il presente white paper è rivolto agli amministratori di base SAP, agli Oracle DBA, agli Storage Administrator, agli IT Architect e ai responsabili tecnici della progettazione, creazione e gestione delle applicazioni SAP mission-critical nei panorami 24x7. Nel presente white paper vengono utilizzati i termini inclusi nella Tabella 1. Tabella 1. Terminologia Termine AAS ABAP ACFS ASCS ASM CIFS CNA CRM DI DPS DRS dvswitch DWDM ERP ERS FAST VP FCoE FEC FRA HA HAIP Descrizione 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 Converged Network Adapter Cluster Resource Manager Dialog Instance Dynamic Path Selection VMware vsphere Distributed Resource Scheduler Switch distribuito vsphere Dense Wavelength Division Multiplexing Enterprise Resource Planning Enqueue Replication Server Fully Automated Storage Tiering for Virtual Pools Fibre Channel over Ethernet Forward Error Correction Flash Recovery Area High Availability Highly Available virtual IP 7

8 Termine 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 Descrizione Host Bus Adapter SAP Internet Demonstration and Evaluation System Inter-Switch Link Link Aggregation Control Protocol Link Aggregation Group Link Layer Discovery Protocol Logical Unit of Work Multi-Chassis Trunking Multi-Protocol Label Switching Multipathing Plug-in Network Attached Storage Network File System Near-Line SAS (Serial Attached SCSI) Oracle Cluster Registry Oracle RAC su cluster a grandi distanze Real Application Clusters Remote Function Call Recovery Point Objective Recovery Time Objective Storage Area Network STONITH Block Device Small Form-factor Pluggable SUSE Linux Enterprise Server SUSE Linux Enterprise High Availability Extension Subscription Management Tool Single Point Of Failure Shoot The Other Node In The Head Transparent Application Failover Top-of-Rack Virtual Cluster Switch Virtual Link Aggregation Group LAN virtuale Disco virtuale Virtual Machine File System VMware High Availability Virtual Private LAN Service Virtual Private Network Virtual Routing and Forwarding Virtual Storage Integrator 8

9 Solution overview Introduzione Implementazioni SAP: sfida e soluzione Le implementazioni SAP tradizionali dispongono di diversi single point of failure (SPOF), tra cui: servizi centrali; server di accodamento*; server di messaggistica*; database server; implementazione su un singolo sito; storage su disco locale. * In questa soluzione, i server di accodamento e messaggistica vengono implementati come servizi nell'istanza ABAP SAP Central Services (ASCS). Nel presente white paper viene illustrata una soluzione per l'aumento dell'availability delle applicazioni SAP. L'architettura e i componenti della soluzione creano una soluzione in cluster active-active per l'intero stack SAP per migliorare l'affidabilità e l'availability e semplificare l'implementazione e la gestione dell'ambiente. Questa soluzione offre i seguenti vantaggi. Elimina i single point of failure a tutti i livelli nell'ambiente per creare un sistema SAP con High Availability. Fornisce data center active-active per abilitare la business continuity mission-critical. Figura 1 illustra i single point of failure in un ambiente SAP e i componenti della soluzione utilizzati per gestirli. Figura 1. Implementazioni SAP: sfida e soluzione 9

10 Architettura della soluzione Nelle seguenti sezioni vengono descritte le soluzioni implementate a ogni livello dell'ambiente per fornire High Availability e business continuity, come illustrato nella Figura 2. Figura 2. Passaggio alla High Availability: vista logica High Availability a livello di storage Tutto lo storage richiesto da ogni server nell'ambiente è stato trasferito agli storage array di classe enterprise VMAX 10K e VMAX 20K. I backbone 8510 Brocade sono stati implementati per fornire una fabric SAN ridondante per l'accesso allo storage. Viene sfruttato il tempo di attività comprovato del 99,999% fornito dagli array e dai backbone SAN, comprese le funzionalità avanzate di gestibilità e business continuity. Figura 3. HA dello storage High Availability del database Il database server è il repository di dati per l'applicazione SAP. Per questa soluzione, il database back-end è stato convertito da un database istanza singola Oracle in un cluster Oracle RAC a quattro nodi. In questo modo il database server viene eliminato come single point of failure. Figura 4. HA del database 10

11 High Availability dell'applicazione SAP Gli application server SAP sono stati virtualizzati completamente con VMware ESXi TM 5.0. Ciascuna delle virtual machine SAP è stata implementata con SLES for SAP Applications 11 SP1 come sistema operativo guest. SUSE Linux Enterprise High Availability Extension e SAP Enqueue Replication Server (ERS) sono stati inoltre implementati per proteggere sia il server di messaggistica sia il server di accodamento SAP. In questo modo ABAP SAP Central Services (ASCS) viene eliminato come single point of failure. Figura 5. HA dell'applicazione SAP High Availability del data center La soluzione cluster con High Availability descritta sopra protegge SAP nel data center. Per la High Availability tra data center, la soluzione utilizza la tecnologia di virtualizzazione dello storage EMC VPLEX Metro, come illustrato nella Figura 6. La tecnologia di clustering active-active VPLEX Metro Access Anywhere esclusiva consente l'accesso in lettura e scrittura ai volumi distribuiti su distanze sincrone. Eseguendo il mirroring dei dati nei siti, VPLEX consente agli utenti in entrambi i siti di accedere contemporaneamente alle stesse informazioni. Figura 6. HA del data center Questa soluzione combina VPLEX Metro con SUSE Linux Enterprise High Availability Extension (a livello del sistema operativo) e Oracle RAC (a livello del database) per rimuovere il data center come single point of failure e fornire una solida strategia di business continuity per le applicazioni mission-critical. 11

12 Oracle RAC su cluster a grandi distanze su VPLEX fornisce i seguenti vantaggi. VPLEX semplifica la gestione di Extended Oracle RAC, man mano che la High Availability nei vari siti viene integrata a livello dell'infrastruttura. Per i DBA Oracle, l'installazione, la configurazione e la manutenzione sono esattamente le stesse di quelle usate per l'implementazione di Oracle RAC su un singolo sito. VPLEX elimina la necessità del mirroring basato su host dei dischi ASM e i cicli CPU host utilizzati. Con VPLEX, i gruppi di dischi ASM vengono configurati con una ridondanza esterna e sono protetti dal mirroring distribuito VPLEX. Gli host devono connettersi solo al cluster VPLEX locale e l'i/o viene inviato soltanto una volta dal nodo. Tuttavia gli host hanno l'accesso completo in lettura e scrittura allo stesso database in entrambi i siti. Con il mirroring basato su host dei gruppi di dischi ASM, ogni I/O di scrittura deve essere inviato due volte, una volta a ogni mirror. Non è necessario implementare un voting disk Oracle su un terzo sito che funga da dispositivo quorum a livello dell'applicazione. VPLEX consente di creare i consistency group che proteggeranno più database e/o applicazioni come unità. La soluzione utilizza VPLEX Witness per monitorare la connettività tra i due cluster VPLEX e garantire la continuous availability in caso di errore della partizione di rete tra cluster o errore del cluster. VPLEX Witness viene implementato su una virtual machine in un terzo dominio di errore separato (sito C). High Availability della rete In ogni data center è stata creata una fabric Ethernet con la tecnologia Virtual Cluster Switching (VCS) di Brocade, che offre un livello di accesso self-healing e resiliente con l'inoltro di tutti i link. I Virtual Link Aggregation Group (vlag) connettono le fabric VCS ai router core MLXe Brocade che estendono la rete di livello 2 nei due data center. 12

13 Figura 7 mostra l'architettura fisica di tutti i livelli della soluzione, compresi i componenti della rete. Figura 7. Architettura della soluzione 13

14 Livelli di protezione Tabella 2 riepiloga i livelli di High Availability (HA) che la soluzione utilizza per eliminare i single point of failure. Tabella 2. High Availability locale High Availability locale Protezione Sito Componenti protetti VMware HA e VMware DRS A e B Virtual machine SAP SUSE Linux Enterprise HAE e SAP Enqueue Replication Server Più istanze di dialogo SAP A e B A e B Server di accodamento SAP, server di messaggistica SAP Processi operativi SAP (DIA, UPD, UP2, SPO) VMware A, B e C Virtualizzazione dei server Oracle RAC A e B Oracle Database Oracle Clusterware A e B File system condiviso SAP Oracle ACFS A e B Home directory SAP Oracle, directory globale SAP, directory di trasporto SAP, directory SAP ASCS EMC Symmetrix VMAX 20K A Storage locale, RAID, multipath EMC Symmetrix VMAX 10K B Storage locale, RAID, multipath VPLEX Metro estende quindi la High Availability con un'architettura di clustering che supera le limitazioni del data center e consente ai server di più data center di avere accesso in lettura e scrittura agli storage device a blocchi condivisi. Questa trasformazione del data center eleva la High Availability tradizionale a un nuovo livello di business continuity mission-critical. Figura 8 illustra il design a High Availability, con VPLEX Witness e Cross-Cluster Connect implementati per fornire il massimo livello di resilienza. Figura 8. HA locale con VPLEX per l'abilitazione della business continuity remota 14

15 Ciascuna delle tecnologie illustrate nella Figura 8 viene descritta nei dettagli nelle sezioni pertinenti del white paper. Database e profilo del carico di lavoro Tabella 3 illustra nei dettagli il database e il profilo del carico di lavoro per la soluzione. Tabella 3. Database e profilo del carico di lavoro Caratteristiche del profilo Numero di database 1 Dettagli Tipo database Dimensione database Nome database Oracle RAC Profilo carico di lavoro SAP OLTP 500 GB VSE 4 nodi fisici Processi order-to-cash personalizzati SAP Risorse hardware Tabella 4 illustra nei dettagli le risorse hardware per la soluzione. Tabella 4. Ambiente hardware della soluzione Obiettivo Quantità Configurazione Storage (sito A) 1 Symmetrix serie VMAX 20K con Enginuity: 2 engine 171 unità FC da 450 GB 52 unità SATA da 2 TB Storage (sito B) 1 Symmetrix serie VMAX 10K con Enginuity: 1 engine 30 unità NL-SAS da 2 TB 79 unità SAS da 600 GB Federation distribuita storage 2 Cluster VPLEX Metro con: 2 engine VS2 Database server Oracle RAC 4 4 CPU a otto core, 128 GB di RAM Server VMware ESXi per SAP 4 2 CPU a quattro core, 128 GB di RAM VMware ESXi Server per VPLEX Witness Piattaforma di switching e routing di rete 2 2 CPU a due core, 48 GB di RAM 2 Backbone DCX 8510 Brocade con: Scheda di estensione FC Fx blade FC a 48 porte con supporto della velocità di linea FC pari a 16 Gb Router MLXe Brocade 4 VDX 6720 Brocade in modalità VCS 15

16 Risorse software Tabella 5 illustra nei dettagli le risorse software per la soluzione. Tabella 5. Ambiente software della soluzione Software Versione Obiettivo EMC Enginuity SR Enginuity 5876 Q Ambiente operativo per Symmetrix VMAX EMC VPLEX GeoSynchrony 5.1 Patch 2 Ambiente operativo VPLEX EMC VPLEX Witness 5.1 Patch 2 Componente di monitoraggio e arbitraggio per la gestione dell'errore del cluster VPLEX e della perdita di comunicazione tra cluster EMC Unisphere TM 5.1 Software di gestione VPLEX EMC Unisphere T Software di gestione VMAX EMC Virtual Storage Integrator (VSI) Integrazione dello storage VMware EMC PowerPath/VE 5.7 P01 (build 2) Software di multipathing SLES for SAP Applications, compreso SUSE Linux Enterprise High Availability Extension 11 SP1 Sistema operativo per tutti i server nell'ambiente VMware vsphere 5.0 aggiornamento 1 Hypervisor contenente tutte le virtual machine Oracle Database 11g (con Oracle RAC e Oracle Grid Infrastructure) Enterprise Edition Database e software cluster Oracle SAP ERP 6.04 Sistema SAP ERP IDES 16

17 Infrastruttura di storage EMC Introduzione Panoramica Nella presente sezione viene descritta l'infrastruttura di storage per la soluzione. Un array Symmetrix VMAX 20K fornisce la piattaforma di storage nel sito A. Un array Symmetrix VMAX 10K fornisce la piattaforma di storage nel sito B. I due storage array vengono implementati con una configurazione LUN corrispondente. EMC Symmetrix VMAX 10K Symmetrix VMAX 10K è una nuova piattaforma storage di livello enterprise, sviluppata per fornire funzionalità di storage virtuale high-end leader a un numero crescente di organizzazioni IT e service provider con requisiti di storage elevati e risorse limitate. VMAX 10K è progettato per un'installazione, una configurazione e un utilizzo facili. È ideale per i clienti che richiedono prestazioni migliori in modalità di errore e rappresenta un punto di ingresso ottimale per un'infrastruttura di storage basata su Symmetrix. Sfruttando la Virtual Matrix Architecture, VMAX 10K fornisce affidabilità, availability e serviceability di livello enterprise. VMAX 10K prevede la preconfigurazione per facilitare la configurazione lo stesso giorno in cui si riceve l'array, con un processo di installazione che richiede meno di quattro ore. VMAX 10K è un sistema con provisioning virtuale al 100%. Virtual Provisioning fornisce a un host, un'applicazione o un file system l'illusione di avere a disposizione più storage di quanto ne venga fornito fisicamente. Lo storage fisico viene allocato solo in fase di scrittura dei dati, anziché durante la configurazione iniziale dell'applicazione. Vengono eliminati i calcoli manuali ed è inoltre possibile abbattere i costi associati all'alimentazione e al raffreddamento grazie alla riduzione della capacità di storage inattiva all'interno dell'array. L'aggiunta di FAST VP per lo storage multi-tier completamente automatizzato rende l'installazione e le operazioni quotidiane più facili per le organizzazioni IT con personale e risorse IT limitate. Sfruttando l'integrazione leader del settore con VMware di EMC, VMAX 10K offre ora uno storage di livello enterprise ancora più efficiente grazie alla nuova integrazione con la piattaforma per infrastrutture cloud VMware vsphere 5. EMC Virtual Storage Integrator (VSI) per VMware semplifica il processo di integrazione dello storage EMC in un ambiente virtualizzato. L'ambiente operativo EMC Enginuity fornisce l'intelligenza necessaria per il controllo di tutti i componenti disponibili in un array VMAX 10 K. Enginuity L'ambiente operativo della service release Enginuity 5876 Q fornisce l'intelligenza necessaria per il controllo di tutti i componenti disponibili in uno storage array EMC Symmetrix. Enginuity è un ambiente operativo di storage intelligente, multi-tasking e preventivo, che controlla il flusso dei dati di storage. È interamente dedicato alle operazioni di storage ed è ottimizzato per i livelli di servizio necessari negli ambienti high-end. 17

18 Questa release di Enginuity si concentra su: facilità di gestione; multi-tenancy; ottimizzazione; VMAX 10K. EMC Symmetrix VMAX 20K EMC Unisphere for VMAX VMAX 20K offre un equilibro perfetto tra facilità di utilizzo, prestazioni, High Availability e prezzo per le aziende più piccole o le aziende mid-tier superiori che richiedono una progettazione dello storage multi-controller. Fornisce livelli maggiori di scala, capacità e prestazioni per le aziende con requisiti più stringenti. Tutti i sistemi VMAX si basano sulla Virtual Matrix Architecture leader del settore, eseguono lo stesso codice Enginuity e condividono una singola interfaccia per la gestione centralizzata: EMC Unisphere for VMAX. Unisphere for VMAX è un'interfaccia grafica avanzata che fornisce un'esperienza utente EMC comune nelle piattaforme di storage. Consente ai clienti di eseguire il provisioning di, gestire e monitorare facilmente gli ambienti VMAX, come illustrato nella Figura 9. Figura 9. Unisphere for VMAX 18

19 Configurazione VMAX Layout dello storage Per la soluzione, VPLEX Metro, Oracle Extended RAC e i volumi SAP vengono organizzati con Virtual Provisioning. Questa configurazione prevede il posizionamento dei file di dati e file di log Oracle in thin pool separati e consente di utilizzare una protezione RAID distinta. I file di dati risiedono in un pool protetto tramite RAID 5 e i redo log in un pool protetto tramite RAID 1. Lo storage non è stato preallocato ad alcun dispositivo, eccetto i dispositivi dei REDO log Oracle. EMC consiglia di preallocare questi dispositivi al momento della creazione, con un'allocazione persistente. In questo modo lo storage è disponibile anticipatamente e, se Zero Space Reclaim viene eseguito sul pool in qualsiasi fase, la capacità preallocata non viene riassegnata allo spazio libero del pool. Figura 10 è una rappresentazione logica di come il layout di storage corrisponde ai gruppi di dischi ASM Oracle. Figura 10. Gruppi di storage e gruppi di dischi ASM Tabelle dei dispositivi Tabella 6 illustra la dimensione e il numero di dispositivi configurati per ogni gruppo di dischi ASM. Tabella 6. Dimensioni dei dispositivi Storage group Numero di dispositivi OCR 5 8 FRA 4 16 REDO 8 16 DATI ACFS 4 16 Dimensione dispositivo (GB) 19

20 Tabella 7 mostra la dimensione e il numero di dispositivi configurati per VPLEX Metro. Tabella 7. Dimensione e numero dei dispositivi configurati per VPLEX Metro Dispositivo VPLEX Numero di dispositivi Metadati VPLEX 2 80 Volume di log VPLEX 2 20 Backup di metadati VPLEX 2 80 Dimensione dispositivo (GB) 20

21 Infrastruttura EMC VPLEX Metro Introduzione Panoramica Nella presente sezione viene descritta l'infrastruttura VPLEX Metro per la soluzione, che comprende i componenti riportati di seguito: cluster EMC VPLEX Metro in ogni data center (sito A e sito B); EMC VPLEX Witness in un dominio di errore separato (sito C). EMC VPLEX EMC VPLEX è una soluzione di virtualizzazione di storage per gli storage array EMC e non EMC. È disponibile in tre configurazioni diverse, ognuna adatta a requisiti specifici di High Availability e data mobility, come illustrato nella Figura 11. VPLEX Local VPLEX Metro VPLEX Geo Figura 11. Topologie VPLEX Per una descrizione dettagliata di queste configurazioni VPLEX, fare riferimento ai documenti elencati in Riferimenti a pagina 70. EMC VPLEX Metro Questa soluzione utilizza VPLEX Metro, che impiega un'architettura di clustering esclusiva per aiutare i clienti a superare le limitazioni del data center e consentire ai server in più data center di avere l'accesso in lettura e scrittura agli storage device a blocchi condivisi. VPLEX Metro fornisce l'accesso a livello di blocchi active-active ai dati in due siti a distanze sincrone con un RTT (Round-Trip Time) pari a 5 ms al massimo. EMC VPLEX Witness VPLEX Witness è un server esterno facoltativo, installato come virtual machine in un dominio di errore separato rispetto ai cluster VPLEX. VPLEX Witness si connette a entrambi i cluster VPLEX tramite VPN sulla rete IP di gestione. Richiede un RTT che non ecceda 1 secondo. Confrontando le sue osservazioni con le informazioni fornite regolarmente dai cluster, VPLEX Witness consente ai cluster di distinguere tra gli errori delle partizioni di rete tra i cluster e gli errori del cluster e riprendere automaticamente l'i/o nel sito appropriato. 21

22 La semantica della gestione degli errori di VPLEX Witness è applicabile solo ai volumi distribuiti in un consistency group e solo quando le regole di detach identificano un cluster preferito statico per il consistency group (vedere Consistency group di VPLEX a pagina 23 per ulteriori dettagli). EMC Unisphere for VPLEX È possibile gestire e amministrare un ambiente VPLEX con l'interfaccia grafica basata su web di Unisphere for VPLEX (come illustrato nella Figura 12) oppure connettersi direttamente a un management server e avviare una sessione di VPlexcli (interfaccia a riga di comando VPLEX). Figura 12. EMC Unisphere for VPLEX High Availability di EMC VPLEX VPLEX Metro include l'applicazione e la data mobility e, quando configurato insieme a VPLEX Witness, fornisce un'infrastruttura a High Availability per le applicazioni in cluster, ad esempio Oracle RAC. Consente di creare un cluster esteso o uno stretched cluster come se fosse un cluster locale e rimuove il data center come single point of failure. Inoltre, mentre i dati e le applicazioni sono attivi in entrambi i siti, la soluzione fornisce una semplice strategia di business continuity. Grazie alla configurazione di VPLEX Cross-Cluster Connect è possibile raggiungere un livello addirittura superiore di availability. In questo caso ogni host è collegato ai cluster VPLEX in entrambi i siti. In questo modo, nella remota eventualità di un errore totale del cluster VPLEX, l'host ha un percorso alternativo per il cluster VPLEX rimanente. 22

23 Strutture di storage logico VPLEX VPLEX incapsula i dispositivi dello storage array fisico tradizionali e applica livelli di astrazione logica a queste LUN esportate, come illustrato nella Figura 13. Volume virtuale Dispositivo Dispositivo Extent Volume di storage Figura 13. Strutture di storage logico VPLEX Un volume di storage è una LUN esportata da un array e incapsulata da VPLEX. Un'extent è il meccanismo che VPLEX utilizza per dividere i volumi di storage e può utilizzare la capacità, totale o parziale, del volume di storage sottostante. Un device incapsula un'extent o combina più extent o altri device in un unico device di grandi dimensioni con un tipo RAID specifico. Un device distribuito è un device che incapsula altri device da due cluster VPLEX separati. Al livello superiore delle strutture di storage VPLEX vi sono i volumi virtuali. Questi vengono creati da un device di livello superiore (un device o un device distribuito) e utilizzano sempre la massima capacità del device di livello superiore. I volumi virtuali sono gli elementi che VPLEX espone agli host utilizzando le porte frontend. VPLEX presenta un volume virtuale a un host tramite una vista di storage. VPLEX può incapsulare i device negli storage array eterogenei, tra cui thin device con provisioning virtuale e LUN tradizionali. Consistency group di VPLEX I consistency group aggregano i volumi virtuali in modo che le stesse regole di detach e altre proprietà possano essere applicate a tutti i volumi nel gruppo. Vi sono due tipi di consistency group. Consistency group sincroni: vengono utilizzati in VPLEX Local e VPLEX Metro per applicare le stesse regole di detach e altre proprietà a un gruppo di volumi in una configurazione. In questo modo vengono semplificate la configurazione e l'amministrazione su sistemi di grandi dimensioni. I consistency group sincroni utilizzano la memorizzazione nella cache writethrough (nota come modalità di cache sincrona) e con VPLEX Metro sono supportati su cluster separati da un massimo di 5 ms di latenza. VPLEX Metro invia le scritture ai volumi di storage back-end e riconosce una scrittura nell'applicazione solo quando la riconoscono i volumi di storage back-end in entramb i cluster. Consistency group asincroni: vengono utilizzati per i volumi distribuiti in VPLEX Geo, dove i cluster possono essere separati da un massimo di 50 ms di latenza. 23

24 Regole di detach Le regole di detach sono regole predefinite che determinano la semantica dell'elaborazione I/O per un consistency group quando la connettività con un cluster remoto viene interrotta, ad esempio in caso di errore della partizione di rete o del cluster remoto. I consistency group sincroni supportano le seguenti regole di detach per determinare il comportamento del cluster durante un errore. La regola di preferenza statica identifica un cluster preferito. La regola neutra prevede la sospensione dell'i/o in entrambi i cluster. Quando la connettività tra cluster viene interrotta, la regola di detach configurata viene richiamata automaticamente. Tuttavia VPLEX Witness può essere implementato per ignorare la regola di preferenza statica e garantire che il cluster non preferito rimanga attivo se il cluster preferito restituisce un errore. Data mobility VPLEX Panoramica La funzionalità di data mobility VPLEX consente di eseguire la migrazione degli elementi di storage, extent o dispositivi, senza interruzioni nei cluster o tra di essi. La data mobility offre i seguenti vantaggi: il consolidamento dei data center; la migrazione veloce dei dati tra data center; il trasferimento e il riposizionamento di applicazioni e dati a distanza; la migrazione dei dati tra array differenti per: riposizionare un dispositivo "ad alta priorità" da uno storage più lento a uno più veloce; riposizionare un dispositivo "a bassa priorità" da uno storage più veloce a uno più lento; ritirare un volume di storage o uno storage array. Migrazioni delle extent Le migrazioni delle extent consentono di trasferire i dati tra extent nello stesso cluster. I volumi di storage possono essere situati sullo stesso array o su array diversi. Figura 14 illustra la migrazione delle extent. Figura 14. Migrazione delle extent su un cluster VPLEX 24

25 Migrazione dei device I device non distribuiti di tipo RAID 0, RAID 1 o RAID C possono utilizzare la migrazione dei device per trasferire i dati tra device sullo stesso cluster o su cluster diversi. I device possono essere creati su una o più extent oppure uno o più device. Figura 15 illustra la migrazione dei device. Figura 15. Migrazione di un device nei cluster VPLEX o tra di essi Questa soluzione utilizza i device distribuiti. Per questo tipo di device, le migrazioni delle extent vengono utilizzate per eseguire la migrazione dell'extent sottostante su ogni istanza del device. Le migrazioni dei device tra i device distribuiti non sono supportate. Configurazione della data mobility Di seguito sono riportati i prerequisiti per il device o l'extent di destinazione. Il device o l'extent di destinazione deve essere di dimensioni uguali o superiori a quelle del device o dell'extent di origine. Se il device o l'extent di destinazione è più grande dell'origine, non è possibile utilizzare lo spazio in eccesso. Sul device di destinazione non devono esservi volumi esistenti. I job di mobility delle extent e dei device possono essere creati, eseguiti e monitorati dai punti seguenti. CLI di VPLEX: le migrazioni possono essere eseguite come job una sola volta o come job batch con file del piano di migrazione riutilizzabili. Fare riferimento a EMC VPLEX CLI Guide per ulteriori informazioni. Interfaccia grafica di Unisphere for VPLEX: l'interfaccia grafica non supporta i job di mobility batch. Tuttavia è possibile eseguire la migrazione di più extent/dispositivi con una procedura guidata. Su un cluster VPLEX possono essere in corso contemporaneamente fino a 25 migrazioni locali e 25 migrazioni distribuite. Eventuali migrazioni oltre questi limiti vengono accodate fino al completamento di una migrazione esistente. 25

26 Figura 16 illustra la creazione di più job di mobility delle extent con la procedura guidata Extent Mobility in Unisphere for VPLEX. Mostra inoltre i job in esecuzione e il loro stato. Figura 16. Creazione e monitoraggio dei job di mobility delle extent Data mobility in questa soluzione Questa soluzione utilizza un'infrastruttura VPLEX Metro esistente. Nell'ambito di un aggiornamento tecnologico sono stati eseguiti lo swapping degli storage array back-end e la sostituzione con array VMAX. I job di data mobility VPLEX sono stati utilizzati per la migrazione di dati senza interruzioni dagli array originali a quelli nuovi. 26

27 I sistemi, in questo caso gli ESXi server e le virtual machine, erano accesi e disponibili tramite la migrazione, come illustrato nella Figura 17. Figura 17. ESXi server, virtual machine e datastore disponibili durante la migrazione Configurazione della soluzione VPLEX Metro Strutture di storage Figura 18 mostra la struttura di storage fisico e logico utilizzata da VPLEX Metro nel contesto di questa soluzione. In ogni sito vi è un mapping one-to-one tra i volumi di storage, le extent e i devicei. Tutti i device del cluster-1 vengono sottoposti al mirroring remoto sul cluster-2, in una configurazione RAID 1 distribuita, per creare device distribuiti. Questi device distribuiti vengono incapsulati dai volumi virtuali, che vengono quindi presentati agli host tramite viste di storage. Figura 18. Strutture di storage fisico e logico VPLEX per la soluzione 27

28 Consistency group I consistency group sono particolarmente importanti per i database e le relative applicazioni. Di seguito sono riportati alcuni esempi. Fedeltà dell'ordine di scrittura: per mantenere l'integrità dei dati, tutte le LUN del database Oracle (ad esempio, file di dati, file di controllo e file di log) devono essere sistemate insieme in un unico consistency group. Dipendenza transazionale: spesso più database hanno dipendenze a livello delle transazioni, ad esempio quando un'applicazione invia transazioni a più database e si aspetta che i database siano coerenti tra loro. Tutte le LUN che richiedono che la dipendenza I/O venga conservata devono risiedere in un unico consistency group. Dipendenza delle applicazioni: Oracle RAC mantiene i file di votazione e Oracle Cluster Registry (OCR) in un set di dischi che deve essere accessibile per mantenere la disponibilità del database. I dischi del database e OCR devono risiedere in un unico consistency group. Per la soluzione, un unico consistency group sincrono, Extended_Oracle_RAC_CG, include tutti i volumi virtuali che contengono i file binari di Oracle Database 11g, i gruppi di dischi ASM Oracle e i file di votazione e OCR. Nella regola di detach per il consistency group, il cluster-1 è il cluster preferito. Processo di configurazione Per la soluzione, le strutture di storage logico VPLEX Metro sono configurate nel modo descritto di seguito ( Figura 19 - Figura 23 mostrano estratti delle procedure guidate di configurazione fornite dalla VPLEX Management Console). Volume di storage: un volume di storage è una LUN esportata da un array e incapsulata da VPLEX. Figura 19 mostra diversi volumi di storage creati nel sito A, come visualizzato nella VPLEX Management Console. Figura 19. Volumi di storage EMC VPLEX (sito A) Extent: nella soluzione vi è un mapping one-to-one tra le extent e i volumi di storage, come illustrato nella Figura 19 e nella Figura 20. Figura 20. Procedura guidata EMC VPLEX Extent Creation 28

29 Dispositivo: nella soluzione vi è un mapping one-to-one tra i dispositivi e le extent. Figura 21 mostra l'opzione utilizzata per configurare questo mapping one-to-one. Figura 21. Procedura guidata EMC VPLEX Device Creation Device distribuito: nella soluzione, i device distribuiti sono stati creati tramite il mirroring remoto di un device in una configurazione RAID 1 distribuita, come illustrato nella Figura 22. Figura 22. Procedura guidata EMC VPLEX Device Creation Volume virtuale: nella soluzione, tutti i device di livello superiore sono device distribuiti. Questi device vengono incapsulati dai volumi virtuali, che VPLEX presenta agli host tramite viste di storage. Le viste di storage definiscono quali host accedono a quali volumi virtuali su quali porte VPLEX. Consistency group: Figura 23 mostra il consistency group creato per la soluzione, ovvero Extended_Oracle_RAC_CG. Figura 23. Procedura guidata EMC VPLEX Create Consistency Group 29

30 Configurazione di VPLEX Witness La soluzione utilizza VPLEX Witness per monitorare la connettività tra i due cluster VPLEX e garantire la continuous availability in caso di errore della partizione di rete tra cluster o errore del cluster. È considerata una configurazione di VPLEX Metro HA in quanto l'availability di storage è garantita nel sito integro. VPLEX Witness viene implementato in un terzo dominio di errore separato (sito C) e connesso ai cluster VPLEX nei siti A e B. Rispetto a questi siti, il sito C è situato a una distanza con una latenza inferiore a 1 secondo. Dopo che VPLEX Witness è stato installato e configurato, la VPLEX Management Console visualizza lo stato dei componenti witness del cluster, come illustrato nella Figura 24. Figura 24. Componenti e stato di EMC VPLEX Witness Monitoraggio delle prestazioni VPLEX VPLEX 5.1 consente un monitoraggio avanzato delle prestazioni tramite il dashboard per il monitoraggio delle prestazioni. Questo dashboard fornisce una vista personalizzabile delle prestazioni del sistema VPLEX e consente di visualizzare e confrontare aspetti diversi delle prestazioni di sistema, fino al livello del director. Attualmente sono disponibili numerose metriche diverse, tra cui quelle riportate di seguito: grafico della latenza front-end; grafico della larghezza di banda front-end; grafico del throughput front-end; grafico dell'utilizzo delle CPU; grafico dello stato di ricostruzione; grafico delle prestazioni del link WAN; grafico della latenza back-end. 30

31 Figura 25 mostra le prestazioni front-end e delle CPU sul cluster-1 (VPLEX del sito A) quando le statistiche Oracle sono state raccolte nel database VSE SAP. Figura 25. Dashboard per il monitoraggio delle prestazioni VPLEX 31

32 Infrastruttura virtualizzata VMware Introduzione Panoramica Per la soluzione, gli application server SAP vengono completamente virtualizzati con VMware vsphere 5. Nella presente sezione viene descritta l'infrastruttura di virtualizzazione, che utilizza i componenti e le opzioni seguenti: VMware vsphere 5.0 aggiornamento 1; server VMware vcenter TM ; VMware vsphere vmotion ; VMware vsphere High Availability (HA); VMware vsphere Distributed Resource SchedulerTM (DRS); EMC PowerPath /VE for VMware vsphere versione 5.7; EMC Virtual Storage Integrator for VMware vsphere versione 5.1. VMware vsphere 5 VMware vsphere 5 è la piattaforma di virtualizzazione più completa, scalabile e potente del settore, con servizi di infrastruttura che trasformano l'hardware IT in una piattaforma di elaborazione condivisa dalle prestazioni elevate e servizi delle applicazioni che consentono alle organizzazioni IT di offrire i più alti livelli di availability, sicurezza e scalabilità. VMware vcenter Server VMware vcenter è la piattaforma di gestione centralizzata per gli ambienti vsphere, che prevede il controllo e la visibilità a tutti i livelli dell'infrastruttura virtuale. VMware vsphere vmotion VMware vsphere vmotion è una tecnologia VMware che supporta la migrazione live delle virtual machine nei server senza alcuna interruzione per gli utenti o perdita del servizio. Storage vmotion è una tecnologia VMware che supporta la migrazione live dello storage di una virtual machine senza alcuna interruzione nell'availability della virtual machine. Ciò consente il riposizionamento delle virtual machine live in nuovi datastore. VMware vsphere High Availability VMware vsphere High Availability (HA) è un componente vsphere che fornisce la High Availability per qualsiasi applicazione in esecuzione in una virtual machine, indipendentemente dal sistema operativo o dalla configurazione hardware sottostante. VMware vsphere Distributed Resource Scheduler VMware vsphere Distributed Resource Scheduler (DRS) bilancia dinamicamente e automaticamente la distribuzione del carico e il posizionamento delle virtual machine in più ESXi server. 32

33 EMC PowerPath/VE EMC PowerPath/VE for VMware vsphere offre funzionalità di multipathing PowerPath per ottimizzare gli ambienti virtuali di VMware vsphere. Installa un modulo kernel sull'host ESXi e funge da plug-in di multipathing (MPP) che fornisce funzionalità avanzate di gestione dei percorsi agli host ESXi. EMC Virtual Storage Integrator for VMware vsphere EMC Virtual Storage Integrator (VSI) for VMware vsphere è un plug-in del client VMware vsphere che fornisce una singola interfaccia utilizzata per la gestione dello storage EMC nell'ambiente vsphere. Offre un'esperienza utente unificata e flessibile, che consente di aggiornare ogni funzionalità separatamente e aggiungere rapidamente nuove funzioni in risposta ai requisiti dei clienti in evoluzione. Quando PowerPath/VE è installato su un host ESXi, VSI presenta dettagli di multipathing importanti per i dispositivi, quali la policy di bilanciamento del carico, il numero di percorsi attivi e il numero di percorsi inattivi. Implementazioni di VMware su VPLEX Metro EMC VPLEX Metro offre l'accesso simultaneo allo stesso set di dispositivi in due siti fisicamente separati e fornisce l'infrastruttura active-active che attiva gli stretched cluster geograficamente distribuiti, basati su VMware vsphere. L'utilizzo della tecnologia Virtual Link Aggregation Group (vlag) di Brocade consente l'estensione delle VLAN, e quindi delle subnet, in data center fisici diversi. Grazie all'implementazione delle funzioni e dei componenti di VMware vsphere con VPLEX Metro, è possibile ottenere la seguente funzionalità. vmotion: capacità di eseguire la migrazione live di virtual machine tra siti in previsione di eventi pianificati, ad esempio la manutenzione hardware. Storage vmotion: capacità di eseguire la migrazione dello storage di una virtual machine senza alcuna interruzione nell'availability della virtual machine. Ciò consente il riposizionamento delle virtual machine live in nuovi datastore. VMware DRS: distribuzione automatica del carico e posizionamento delle virtual machine nei siti tramite l'utilizzo di gruppi DRS e regole di affinità. VMware HA: un ambiente VPLEX Metro configurato con VPLEX Witness è considerato una configurazione di VPLEX Metro HA, in quanto garantisce l'availability dello storage nel sito integro in caso di guasto del sito. La combinazione di VPLEX Metro HA con una tecnologia di failover clustering host come VMware HA fornisce il riavvio automatico delle applicazioni per qualsiasi disastro a livello del sito. Figura 26 illustra questa architettura HA. 33

34 Figura 26. VMware HA con VPLEX Witness: vista logica VPLEX Metro HA Cross-Cluster Connect: la protezione del cluster VMware HA può essere aumentata ulteriormente con l'aggiunta di una connessione cross-cluster tra i server VMware ESXi locali e il cluster VPLEX sul sito remoto. Gli eventi di non disponibilità dei dati locali, che VMware vsphere 5.0 non riconosce, possono verificarsi quando non vi è un'interruzione totale dell'attività del sito. La configurazione cross-connect degli ambienti vsphere con i cluster VPLEX fornisce la protezione da questi eventi e garantisce che le virtual machine in errore passino automaticamente al sito integro. VPLEX Cross-Cluster Connect è disponibile per una latenza indotta da distanza massima di 1 ms. Questa soluzione utilizza VPLEX Metro HA con Cross-Cluster Connect per massimizzare l'availability delle virtual machine VMware, come illustrato nella Figura Per informazioni dettagliate, consultare il TechBook EMC: EMC VPLEX Metro Witness Technology and High Availability. 34

35 Figura 27. VMware HA con VPLEX Witness e Cross-Cluster Connect: vista logica Configurazione dello stretched cluster di VMware VMware ed EMC supportano una configurazione dello stretched cluster che include host ESXi di più siti 2. Per la soluzione, un singolo cluster vsphere viene esteso tra i siti A e B con un volume virtuale VPLEX distribuito con VMware HA e VMware DRS. Vi sono quattro host nel cluster, due in ogni sito. VPLEX Metro HA Cross-Cluster Connect fornisce una maggiore resilienza alla configurazione. In vcenter è facile visualizzare la configurazione di questo cluster, sito A e sito B, e le relative funzionalità abilitate, come illustrato nella Figura 28. Questa vista mostra inoltre la memoria, la CPU e le risorse di storage disponibili per il cluster. Figura 28. Cluster vsphere con HA e DRS abilitati 2 Per i requisiti e gli scenari dettagliati, consultare l'articolo della knowledgebase di VMware : Using VPLEX Metro with VMware HA 35

36 Ogni ESXi server è configurato con due adattatori fisici 10 GbE per fornire il failover di rete e prestazioni elevate. Uno switch distribuito vsphere (dvswitch) 3 fornisce un unico switch comune in tutti gli host. Gli adattatori fisici 10 GbE (detti anche adattatori uplink) vengono assegnati al dvswitch. Al dvswitch vengono assegnati due gruppi di porte distribuiti: dvportgroupsiteab: per il traffico di rete della virtual machine; rete di gestione: per il traffico VMkernel e, in particolare, il traffico vmotion. Figura 29 mostra la configurazione del dvswitch. Poiché sia gli switch distribuiti vsphere 5.0 sia gli switch VCS Brocade supportano il Link Layer Discovery Protocol (LLDP), le proprietà degli switch fisici associati possono essere facilmente identificate anche da vcenter. Figura 29. Configurazione del dvswitch e dettagli dell'lldp Il datastore EXT_SAP_VPLEX_DS01 è stato creato su un volume distribuito VPLEX da 1 TB e presentato agli host ESXi nello stretched cluster. Tutte le virtual machine sono state sottoposte a migrazione in questo datastore, con Storage vmotion, perché hanno bisogno di condividere i dischi virtuali o venire spostate, tramite vmotion, da un sito all'altro. Figura 30 mostra i dettagli della configurazione per il datastore. 3 Un dvswitch fornisce una configurazione di rete che comprende tutti gli host membro e consente alle virtual machine di mantenere una configurazione di rete coerente man mano che eseguono la migrazione tra host. Per ulteriori informazioni, consultare il documento VMware vsphere Networking ESXi

37 Figura 30. Datastore EXT_SAP_VPLEX_DS01 e host e virtual machine associati Configurazione di VMware vsphere HA Abilitazione di VMware vsphere HA e VMware vsphere DRS vsphere HA sfrutta più host ESXi, configurati come un cluster, per garantire il ripristino rapido da interruzioni dell'attività e una High Availability efficiente in termini di costo per le applicazioni in esecuzione sulle virtual machine. 4 vsphere HA protegge l'availability delle applicazioni nei modi descritti di seguito. Fornisce la protezione da un guasto del server riavviando le virtual machine su altri ESXi server nel cluster. Fornisce la protezione da un errore dell'applicazione monitorando continuamente una virtual machine ed effettuandone il reset in caso di errore del sistema operativo guest. Per la soluzione sono stati attivati sia vsphere HA sia DRS, come illustrato nella Figura 31. Figura 31. Procedura guidata vsphere HA 4 Per ulteriori informazioni, consultare il documento VMware vsphere Availability ESXi

38 VM Monitoring VM Monitoring è stato configurato per riavviare singole virtual machine se l'heartbeat non viene ricevuto entro 60 secondi. Opzioni di riavvio delle virtual machine L'opzione VM Restart Priority per le quattro virtual machine SAP è stata impostata su High. In questo modo si garantisce che queste virtual machine vengano accese per prime in caso di interruzione dell'attività. Figura 32 mostra questa impostazione e l'impostazione Host Isolation Response (predefinita). Figura 32. Impostazioni VM Restart Priority e Host Isolation Response Heartbeat di datastore Quando si crea un cluster vsphere HA, un singolo host viene automaticamente scelto come host master. L'host master monitora lo stato di tutte le virtual machine protette e degli host slave. Quando l'host master non è in grado di comunicare con un host slave, utilizza l'heartbeat di datastore per determinare se l'host slave ha restituito un errore, si trova in una partizione di rete o è isolato a livello di rete. Per soddisfare i requisiti di vsphere HA per l'heartbeat di datastore, un secondo datastore, EXT_SAP_VPLEX_HA_HB, è stato creato su un volume distribuito VPLEX da 20 GB e presentato a tutti gli host ESXi, come illustrato nella Figura 33. In un ambiente di produzione, vcenter seleziona automaticamente due o più datastore per questo scopo, in base alla visibilità dell'host. Figura 33. Stato del cluster HA vsphere: datastore heartbeat 38

39 Configurazione di VMware vsphere DRS Gruppi di virtual machine e gruppi di host VMware DRS I gruppi di virtual machine e i gruppi di host DRS semplificano la gestione delle risorse host ESXi. Queste funzionalità non erano obbligatorie per questa soluzione. Regole di affinità VMware DRS DRS utilizza le regole di affinità per controllare il posizionamento delle virtual machine sugli host in un cluster. DRS fornisce due tipi di regola di affinità. Una regola di affinità VM-host specifica una relazione di affinità tra un gruppo di virtual machine e un gruppo di host. Una regola di affinità VM-VM specifica se determinate virtual machine devono venire eseguite sullo stesso host o mantenute su host separati. Tabella 8 e Figura 34 mostrano la regola di affinità VM-VM utilizzata dalla soluzione. Tabella 8. Regola di affinità VMware DRS Regola di affinità VM-VM SAPASCS Separate Mantenere le virtual machine SAPASCS2 e SAPASCS3 su host separati. Figura 34. Regola di affinità VM-VM DRS per il cluster vplex_esxi_metro_ha EMC Virtual Storage Integrator e VPLEX EMC Virtual Storage Integrator (VSI) migliora la visibilità diretta di VPLEX dall'interfaccia grafica di vcenter. Le funzionalità Storage Viewer e Path Management sono accessibili dalla scheda EMC VSI, come illustrato nella Figura 35. Nella soluzione i volumi distribuiti VPLEX ospitano il datastore Virtual Machine File System (VMFS) EXT_SAP_VPLEX_DS01 e Storage Viewer fornisce i dettagli dei volumi virtuali, dei volumi di storage e dei percorsi del datastore. Come illustrato nella Figura 35, le LUN che formano il datastore sono quattro volumi VPLEX Metro RAID 1 distribuiti da 256 GB, accessibili tramite PowerPath. Figura 35. VSI Storage Viewer: datastore 39

40 Architettura del sistema SAP Introduzione Panoramica Nella presente sezione viene illustrata l'architettura del sistema SAP implementata per la soluzione nei due data center. L'APL SAP utilizza i componenti SAP e SUSE seguenti. Applicazione SAP SAP Enhancement Package 4 for SAP ERP 6.0 IDES SAP NetWeaver Application Server for ABAP 7.01 SAP Enqueue Replication Server Sistema operativo SLES for SAP Applications 11 SP1 SUSE Linux Enterprise High Availability Extension Il sistema SAP viene eseguito in un ambiente ibrido, con i servizi SAP sulle virtual machine e il database sui server fisici. Tutte le istanze SAP vengono installate sulle virtual machine VMware vsphere con SLES for SAP Applications come sistema operativo. Il database sottostante è un database Oracle RAC fisico su ASM. Gli ambienti VMware e Oracle sono descritti in sezioni separate del white paper (vedere Infrastruttura virtualizzata VMware e Architettura del database ). SAP ERP 6.0 SAP ERP 6.0, dotato della piattaforma tecnologica SAP NetWeaver, è un'applicazione Enterprise Resource Planning (ERP) completamente integrata, di livello superiore che soddisfa le esigenze aziendali core delle medie e grandi imprese in tutti i settori e tutti i mercati. Fornisce un insieme esauriente di processi aziendali interfunzionali, integrati e può fungere da piattaforma solida del processo aziendale che supporta la crescita continua, l'innovazione e l'eccellenza operativa. SAP IDES (Internet Demonstration and Evaluation System) supporta le demo, il test e la valutazione funzionale basati su client e dati preconfigurati. IDES contiene i dati delle applicazioni per vari scenari aziendali, con processi aziendali progettati che riflettono requisiti aziendali reali e hanno accesso a numerose caratteristiche realistiche. Questa soluzione utilizza IDES per rappresentare una società modello per motivi di test. SLES for SAP Applications SLES è un sistema operativo del server estremamente affidabile, scalabile e sicuro, creato per supportare le applicazioni fisiche, virtuali e cloud. È una piattaforma Linux preferita per SAP. SLES for SAP Applications, basato sulla più recente tecnologia SLES, è ottimizzato per tutti gli appliance e le soluzioni software SAP NetWeaver mission-critical. SAP e SUSE convalidano e certificano SLES for SAP Applications insieme per eliminare potenziali incompatibilità software. Questa partnership integra strettamente il carico di lavoro dell'applicazione con il sistema operativo ed elimina la possibilità di incompatibilità quando le patch vengono applicate alle applicazioni o al sistema operativo. 40

41 SUSE Linux Enterprise High Availability Extension SLES for SAP Applications include SUSE Linux Enterprise High Availability Extension, che offre il clustering di servizi e applicazioni con High Availability, file system e file system in cluster, Network Attached Storage (NAS), file system di rete, volume manager, SAN e driver, e i mezzi per gestire il funzionamento di tutti questi componenti insieme. SUSE Linux Enterprise High Availability Extension fornisce una soluzione di clustering integrata per le implementazioni di Linux fisiche e virtuali, consentendo l'implementazione di cluster Linux con High Availability ed eliminando i single point of failure. Configurazione del sistema SAP Architettura del sistema SAP La soluzione implementa un'architettura del sistema SAP con High Availability, come illustrato nella Figura 36. Figura 36. Architettura del sistema SAP 41

42 Il server di accodamento e il server di messaggistica sono separati dall'istanza centrale e implementati come servizi nell'istanza ASCS 5. SAP ERS è installato come parte dell'architettura HA per garantire una perdita del blocco delle applicazioni pari a zero e proteggere ulteriormente il server di accodamento 6. Sono installate due istanze di dialogo per fornire processi operativi ridondanti quali dialogo (DIA), sfondo (BGD), aggiornamento (UPD), spool (SPO) e gateway. Considerazioni sulla progettazione chiave Il sistema SAP implementato per la soluzione comprende le funzionalità di progettazione chiave descritte di seguito. L'istanza ASCS viene installata con un nome host virtuale (SAPVIPE) per separarla dal nome host della virtual machine. L'istanza ERS viene installata con un numero diverso (01) per evitare confusione quando sia ASCS sia ERS sono sotto controllo a livello di cluster. Le patch SAP, i parametri, le impostazioni di base e le impostazioni di bilanciamento del carico vengono tutti installati e configurati secondo la guida all'installazione SAP e le note SAP elencate alla pagina 70. In questa soluzione vengono adottate le best practice VMware per SAP 7. I processi di aggiornamento SAP (UPD/UP2) vengono configurati sulle istanze degli application server aggiuntivi. Il profilo dell'istanza SAP ASCS, i profili di avvio e dell'istanza ERS e i profili delle istanze di dialogo vengono aggiornati in base alle configurazioni ERS. Consultare Appendice: configurazioni di esempio per le configurazioni di esempio. I file system condivisi SAP, compresi /sapmnt/<sid> (disponibile in tutte le istanze SAP) e /usr/sap/<sid>/ascs00 (disponibile per i nodi di cluster SAP, l'istanza ASCS e l'istanza ERS), vengono archiviati su Oracle ASM Cluster File System (ACFS) e montati come share Network File System (NFS) sulle virtual machine SAP. Questi file system condivisi vengono presentati come risorse NFS con High Availability gestite da Oracle Clusterware. Alcune funzionalità IDES, ad esempio la sincronizzazione con il sistema GTS esterno, vengono disattivate per eliminare le interfacce esterne non necessarie che non rientrano nell'ambito della soluzione. Lo storage per l'intero ambiente SAP viene incapsulato e virtualizzato per questa soluzione. Lo storage viene distribuito nei due siti e reso disponibile per i server SAP tramite VPLEX Metro. 5 Il server di accodamento gestisce i blocchi logici con l'obiettivo di ridurre al minimo la durata di un blocco di database. Diversamente dai blocchi di database, un blocco SAP può esistere in diverse LUW del database. Il server di messaggistica informa tutti i server (istanze) in un sistema SAP dell'esistenza degli altri server. Altri client (ad esempio, i client SAPlogon e RFC con bilanciamento del carico) possono inoltre contattarlo per informazioni sul bilanciamento del carico. 6 SAP ERS fornisce un meccanismo di replica per il server di accodamento tenendo una copia della tabella di blocco nel segmento di memoria condivisa corrispondente. L'installazione di ERS per Linux non fa parte del processo SAPInst standard. Per istruzioni per l'installazione, consultare il portale di assistenza di SAP Enqueue Replication Server all'indirizzo help.sap.com. 7 Per informazioni complete, consultare: SAP Solutions on VMware: Best Practices Guide. 42

43 Configurazione di SUSE Linux Enterprise High Availability Extension Architettura della virtual machine SAP con SUSE Linux Enterprise High Availability Extension La soluzione utilizza SUSE Linux Enterprise High Availability Extension per proteggere i servizi centrali (server di messaggistica e server di accodamento) nei due nodi di cluster sviluppati sulle virtual machine VMware. VMware High Availability (VMware HA) protegge tutte le virtual machine SAP, compresi ASCS e l'application server aggiuntivo (AAS). Figura 37 mostra questa architettura. Figura 37. Architettura del cluster SAP ASCS con SUSE Linux Enterprise HAE Tra i componenti chiave di SUSE Linux Enterprise High Availability Extension implementati in questa soluzione figurano: OpenAIS 8 /Corosync 9 per la gestione dei cluster con High Availability con il supporto del failover a più nodi; gli agent di risorse (indirizzo IP virtuale, master/slave e SAPInstance) per monitorare e controllare l'availability delle risorse; l'interfaccia grafica della High Availability e vari strumenti della riga di comando. 8 OpenAIS è un'implementazione aperta della specifica AIS (Application Interface Specification) fornita dal Service Availability Forum (SA Forum). 9 Corosync Cluster Engine è un sistema di comunicazione di gruppo con funzionalità aggiuntive per l'implementazione della High Availability nelle applicazioni. 43

44 Tabella 9 mostra la configurazione delle virtual machine SAP. Tabella 9. Virtual machine SAP Ruolo VM Quantità CPU virtuali Memoria (GB) Disco di avvio sistema operativo (GB) Nome VM SAP ASCS SAPASCS2 SAP ERS SAPASCS3 SAP AAS SAPDI SAPDI2 Processo di installazione e configurazione Nel white paper di SUSE Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack viene illustrato come installare e configurare il software SUSE e SAP NetWeaver. Appendice: configurazioni di esempio fornisce un file di configurazione di esempio che supporta le funzioni e le funzionalità convalidate da questa soluzione. I valori temporali (timeout, intervalli e cosìvia) contenuti qui vanno considerati come valori "iniziali" da mettere a punto e ottimizzare per il proprio ambiente. Per la soluzione, SUSE Linux Enterprise High Availability Extension è stato installato e configurato con YaST e l'interfaccia grafica di Pacemaker. Di seguito è riportato un riepilogo del processo di installazione e configurazione. 1. Configurare un server SMT interno (per motivi di sicurezza) per aggiornare tutti i pacchetti software alle ultime versioni. 2. Nel modulo YaST Software Management selezionare Patterns > High Availability per installare High Availability Extension, come illustrato nella Figura

45 Figura 38. Installazione di SUSE Linux Enterprise High Availability Extension 3. Nel modulo YaST Cluster configurare le impostazioni di base del cluster, come illustrato nella Figura 39. Figura 39. Configurazione delle impostazioni di base del cluster 45

46 4. Nell'interfaccia grafica di Pacemaker configurare le impostazioni globali del cluster, come illustrato nella Figura 40. Figura 40. Configurazione delle impostazioni globali del cluster 5. Nell'interfaccia grafica di Pacemaker aprire la categoria Resources e configurare le risorse IPaddr2, master/slave e SAPInstance, come illustrato nella Figura 41. Figura 41. Configurazione delle risorse 46

47 6. Nell'interfaccia grafica di Pacemaker configurare le dipendenze delle risorse, come illustrato nella Figura 42. Figura 42. Configurazione delle dipendenze delle risorse 7. Nell'interfaccia grafica di Pacemaker avviare il cluster e verificare che il cluster e tutti gli agent di risorse funzionino correttamente, come illustrato nella Figura 43. Figura 43. Verifica dello stato del cluster 47

48 Considerazioni sulla progettazione chiave Configurazione del dispositivo STONITH SBD (STONITH Block Device) e STONITH (Shoot The Other Node In The Head) attivano l'isolamento (dei nodi) in un cluster tramite lo storage condiviso. Questa soluzione utilizza una partizione di un disco virtuale (VMDK) come dispositivo SBD STONITH. 10 Pertanto entrambi i nodi di cluster hanno bisogno di accedere simultaneamente a questo disco virtuale. Il disco virtuale è archiviato nello stesso datastore delle virtual machine SAP. Questo viene sottoposto a provisioning e protetto da VPLEX ed è disponibile in entrambi i siti. Per impostazione predefinita VMFS impedisce a più virtual machine di accedere a e scrivere sullo stesso VMDK. Tuttavia è possibile abilitare la condivisione mediante la configurazione dell'opzione multi-autore 11, come illustrato nella Figura 44. Figura 44. Opzione multi-autore Il dispositivo SBD è protetto da VPLEX ed è accessibile tramite il software di multipathing EMC PowerPath/VE. I parametri di timeout per il dispositivo SBD devono essere configurati in modo da tenere conto del timeout del cluster Oracle RAC sottostante e con il processo di isolamento VLEX. Figura 45 mostra la configurazione utilizzata per questa soluzione. Figura 45. Configurazione del dispositivo SBD 10 SBD è fondamentale per la gestione degli scenari di split-brain nel cluster. Per questa soluzione viene configurato un singolo dispositivo SBD. Questa configurazione con un singolo dispositivo SBD ha solo lo scopo di test. Per la configurazione di produzione, consultare il white paper Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability Simple Stack. 11 Per informazioni dettagliate, consultare l'articolo della knowledgebase di VMware : Disabling simultaneous write protection provided by VMFS using the multiwriter flag. 48

49 Configurazione master/slave L'agent di risorse SAPInstance controlla l'istanza ASCS, nonché l'istanza ERS appropriata. È configurato come risorsa master/slave che estende i ruoli della risorsa da started e stopped a master e slave. Un'istanza master di livello superiore avvia l'istanza SAP ASCS. L'istanza slave di livello inferiore avvia l'istanza ERS. La modalità master/slave fa sìche un'istanza ASCS non venga mai avviata sullo stesso nodo di ERS. Figura 46 mostra la configurazione dell'agent di risorse SAPInstance. Figura 46. Configurazione dell'agent di risorse SAPInstance Figura 47 mostra la configurazione dell'agent di risorse master/slave. Figura 47. Configurazione dell'agent di risorse master/slave 49

50 Vincoli delle risorse L'istanza ASCS e l'ip virtuale corrispondente sono vincolati tra loro con vincoli di collocazione e ordine appropriati. Figura 48 mostra la configurazione dei vincoli di collocazione e ordine delle risorse. Figura 48. Configurazione dei vincoli di collocazione e ordine delle risorse Concetto di polling SUSE Linux Enterprise High Availability Extension può monitorare costantemente lo stato dei processi SAP su ogni nodo di cluster e prendere le decisioni corrette per alzare/abbassare il livello rispettivamente dell'istanza ASCS e dell'istanza ERS. Non è necessario implementare il concetto di polling SAP. Verificare che questa funzionalità NON sia abilitata nel profilo dell'istanza ERS. Per il profilo di un'istanza ERS di esempio, vedere Profilo di un'istanza ERS di esempio a pagina

51 Architettura del database Oracle Introduzione Panoramica In questa sezione vengono illustrati la griglia e il database alla base delle applicazioni SAP nella soluzione. Il database ha origine come singola istanza Oracle Database 11g fisica. Per eliminare il database server come single point of failure, è stata eseguita la migrazione del database istanza singola in un cluster Oracle RAC 11g fisico a quattro nodi con il database Oracle che risiede su ASM. La soluzione utilizza i componenti e le opzioni Oracle seguenti: Oracle Database 11g Release 2 Enterprise Edition; Oracle Automatic Storage Management (ASM) e Oracle ASM Cluster File System (ACFS); Oracle Clusterware; Oracle Real Applications Clusters (RAC) 11g su cluster a grandi distanze. Oracle Database 11g R2 Oracle Database 11g Release 2 Enterprise Edition offre prestazioni, scalabilità, sicurezza e affidabilità leader del settore per una gamma di server in cluster o singoli server con sistema operativo Windows, Linux o UNIX. Fornisce funzioni esaurienti per le applicazioni di elaborazione delle transazioni, business intelligence e content management. Oracle ASM e Oracle ACFS Oracle ASM è un disk manager e un file system di database con riconoscimento cluster, integrato. Le funzionalità di gestione del volume e del file system ASM sono integrate con il kernel del database Oracle. In Oracle Database 11g R2, Oracle ASM è stato inoltre esteso per includere il supporto del posizionamento dei file di votazione e OCR nei gruppi di dischi ASM. Oracle ACFS, una funzionalità di ASM in Oracle Database 11g, estende la funzione ASM in modo che funga da file system cluster di utilizzo generale. I file binari del database Oracle possono risiedere su ACFS, cosìcome i file di supporto quali i log di traccia e alert e i file di applicazioni non Oracle come SAP ERP. I server non Oracle possono accedere ai volumi ACFS con i protocolli NAS standard del settore come NFS e Common Internet File System (CIFS). Oracle Clusterware Oracle Clusterware è una soluzione portatile per la gestione dei cluster integrata con il database Oracle. Fornisce l'infrastruttura necessaria per eseguire Oracle RAC, compresi Cluster Management Services e High Availability Services. A un'applicazione non Oracle può essere assegnata una High Availability nel cluster con Oracle Clusterware. Oracle Grid Infrastructure In Oracle Database 11g R2, Oracle Grid Infrastructure combina Oracle ASM e Oracle Clusterware in un singolo insieme di file binari, separati dal software del database. Questa infrastruttura fornisce ora tutti i servizi di cluster e storage necessari per eseguire un database Oracle RAC. 51

52 Oracle Real Application Clusters 11g Oracle RAC è principalmente una soluzione a High Availability per le applicazioni del database Oracle nel data center. Consente a più istanze Oracle di accedere a un singolo database. Il cluster è composto da un gruppo di server indipendenti che cooperano come singolo sistema e condividono lo stesso insieme di dischi di storage. Ogni istanza viene eseguita su un server separato nel cluster. RAC è in grado di fornire High Availability, scalabilità, fault tolerance, bilanciamento del carico e vantaggi delle prestazioni e rimuove qualsiasi single point of failure dalla soluzione del database. Oracle RAC su cluster a grandi distanze Oracle RAC su cluster a grandi distanze (Oracle Extended RAC) è un'architettura che consente ai server nel cluster di risiedere in siti fisicamente separati. In questo modo viene rimosso il data center come single point of failure. Oracle Extended RAC consente a tutti i nodi nel cluster, indipendentemente dal sito, di essere attivi. Fornisce High Availability e business continuity durante un guasto del sito o della rete nel modo descritto di seguito. Lo storage e i dati rimangono disponibili e attivi nel sito integro. I servizi Oracle eseguono il bilanciamento del carico e il failover nei nodi Oracle RAC nel sito integro. Oracle Transparent Application Failover (TAF) consente il failover automatico delle sessioni nei nodi Oracle RAC nel sito integro. Le applicazioni di terze parti poste sotto il controllo di Oracle Clusterware possono eseguire il bilanciamento del carico e il failover nei nodi Oracle RAC nel sito integro, ad esempio NFS o Apache httpd. I nodi Oracle RAC nel sito integro continuano a elaborare le transazioni. Secondo Oracle, l'architettura Oracle Extended RAC si adatta meglio dove i due data center sono relativamente vicini (a una distanza non superiore ai 100 km) 12. Oracle RAC e VPLEX Configurazione di Oracle ACFS Normalmente Oracle RAC viene eseguito in un data center locale a causa del potenziale impatto della latenza indotta da distanza e della complessità e delle spese generali relative all'estensione di Oracle RAC nei data center con mirroring basato su host tramite Oracle ASM. Con EMC VPLEX Metro, tuttavia, un'implementazione di Oracle Extended RAC, dalla prospettiva del Database Administrator Oracle, diventa un processo di installazione e configurazione standard di Oracle RAC 13. Questa soluzione utilizza quattro volumi ACFS montati nel cluster Oracle RAC, come illustrato nella Tabella 10. Tre di questi volumi, SAPMNT, USRSAPTRANS e ASCS00, sono stati quindi esportati come share NFS nei server SAP, con un indirizzo IP virtuale e una risorsa NFS con High Availability sotto il controllo di Oracle Clusterware. 12 Consultare il white paper di Oracle: Oracle Real Application Clusters (RAC) on Extended Distance Clusters. 13 Consultare il white paper di EMC: Oracle Extended RAC with EMC VPLEX Metro Best Practices Planning. 52

53 Tabella 10. Volumi e mount point di Oracle ACFS Volume ACFS Dimensione (GB) Mount point Descrizione SAP_O_HOME 16 /oracle/vse/112 ORACLE_HOME per VSE del database, condiviso su tutti i nodi Oracle RAC SAPMNT 16 /sapmnt/vse Directory globale SAP, in cui sono archiviati kernel e profili, condivisa su tutte le virtual machine SAP USRSAPTRANS 16 /usr/sap/trans Directory di trasporto SAP, in cui sono archiviati i file di trasporto, condivisa su tutte le virtual machine dell'istanza di dialogo SAP ASCS00 16 /usr/sap/vse/ascs00 Directory dell'istanza SAP ASCS, in cui sono archiviati i file correlati all'istanza, condivisa sui nodi di cluster SUSE Linux Enterprise High Availability Extension Oracle Extended RAC su VPLEX Metro Figura 49 fornisce una rappresentazione logica dell'implementazione di Oracle Extended RAC su VPLEX Metro per la soluzione. Figura 49. Oracle Extended RAC su EMC VPLEX Metro 53

54 Configurazione del gruppo di dischi ASM Oracle Tabella 11 mostra la configurazione e il layout del gruppo di dischi ASM. Tabella 11. Configurazione e dimensione del gruppo di dischi ASM Oracle Gruppo di dischi ASM* N. di dischi Dimensione gruppo di dischi (GB) Ridondanza OCR 5 40 Normale EA_SAP_ACFS 4 64 Esterna EA_SAP_DATA Esterna EA_SAP_REDO 4 64 Esterna EA_SAP_REDOM 4 64 Esterna EA_SAP_FRA Esterna * Il prefisso EA_SAP_ viene utilizzato per identificare in modo univoco i gruppi di dischi ASM correlati all'applicazione SAP in Extended Oracle RAC. Connessione da SAP a Oracle RAC Per consentire a SAP di connettersi al database Oracle RAC, tnsnames.ora era situato in ognuna delle virtual machine SAP (SAPDI1 e SAPDI2), come illustrato nella Figura 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)) Figura 50. Voce del file tnsnames.ora di esempio per il database Oracle RAC Transparent Application Failover (TAF) è una funzionalità lato client che consente ai client di riconnettersi alle istanze integre se un'istanza del database restituisce un errore. TAF può essere configurato con una stringa di connessione specificata lato client o attributi del servizio lato server. Nella soluzione, il servizio del database VSE.sse.ea.emc.com era configurato per TAF su Oracle RAC. Era inoltre configurato sul lato client per consentire a SAP di utilizzare TAF. TAF è stato configurato per stabilire connessioni al momento del failover e permettere agli utenti con cursori aperti di continuare a eseguire il fetch delle stesse dopo la mancata riuscita di determinate operazioni. 54

55 Infrastruttura di rete Brocade Introduzione Panoramica Nella presente sezione vengono descritte le reti IP e SAN implementate per la soluzione nei due data center e l'estensione di livello 2 tra i data center. L'infrastruttura di rete viene creata con i componenti Brocade seguenti. Rete IP Switch per data center VDX 6720 Brocade Router serie MLX Brocade CNA 1020 Brocade SAN Backbone DCX 8510 Brocade HBA 825 Brocade VDX 6720 Brocade Lo switch per data center VDX 6720 Brocade è uno switch con porta fissa 10 GbE wire-speed, con latenza bassissima e dalle prestazioni elevate. È specificamente progettato per migliorare l'utilizzo della rete, massimizzare l'availability delle applicazioni, aumentare la scalabilità e semplificare notevolmente l'architettura di rete nei data center virtualizzati. Con un'ampia serie di funzionalità di livello 2, VDX 6720 Brocade è una piattaforma ideale per le implementazioni tradizionali di switch Top-of-Rack (ToR). Grazie alla tecnologia VCS Fabric di Brocade, VDX 6720 Brocade consente alle organizzazioni di creare fabric Ethernet per data center, rivoluzionando la progettazione delle reti di livello 2 e fornendo un elemento fondamentale intelligente per i data center ottimizzati per il cloud. Serie MLX Brocade I router serie MLX Brocade sono progettati per attivare le reti ottimizzate per il cloud fornendo una densità wire-speed 100 GbE, 10 GbE e 1 GbE leader del settore; funzionalità avanzate IPv4, IPv6, Multi-VRF, Multi-Protocol Label Switching (MPLS) ed Ethernet di supporto; e switching di livello 2 avanzato. Sfruttando la serie MLX Brocade, i data center mission-critical possono supportare maggiore traffico, raggiungere una virtualizzazione superiore e fornire servizi basati su cloud di valore elevato utilizzando meno infrastruttura per semplificare le operazioni e ridurre i costi. Inoltre la serie MLX Brocade è in grado di ridurre la complessità in grandi reti universitarie riducendo i livelli core e di aggregazione e fornendo la connettività tra i siti con MPLS/VPLS. Tutti i router della serie MLX Brocade consentono di ridurre i costi di alimentazione e raffreddamento con il consumo energetico e la dissipazione di calore più bassi della classe. Progettato per il networking senza interruzioni, la serie MLX Brocade comprende Multi-Chassis Trunking (MCT), che fornisce oltre 30 TB/s di larghezza di banda a doppio chassis, link di routing active-active completi e un flusso ininterrotto di traffico in caso di failover dei nodi. Le organizzazioni possono raggiungere una resilienza elevata tramite switch fabric completamente ridondanti, moduli di gestione, alimentatori e sistemi di raffreddamento. Per garantire un'ulteriore availability della rete e delle applicazioni, il sistema operativo Brocade IronWare comprende un failover di gestione senza perdita di dati e aggiornamenti software. 55

56 Backbone DCX 8510 Brocade Le reti devono evolvere per supportare le esigenze crescenti di ambienti estremamente virtualizzati e architetture di private cloud. Oggi Fibre Channel (FC) è lo standard effettivo per lo storage networking nel data center. L'introduzione di Fibre Channel da 16 Gb/s estende la durata di questa tecnologia solida, affidabile e dalle prestazioni elevate. Ciò consente alle organizzazioni di continuare a sfruttare gli investimenti IT esistenti man mano che risolvono le problematiche aziendali più difficili. I backbone DCX 8510 Brocade rappresentano l'infrastruttura di switching Fibre Channel da 16 Gb/s più potente del settore e sono l'elemento fondamentale più affidabile, scalabile e dalle prestazioni elevate per il private cloud storage e gli ambienti estremamente virtualizzati. Sono progettati per aumentare la flessibilità del business, fornire l'accesso ininterrotto alle informazioni e ridurre i costi dell'infrastruttura e quelli amministrativi. La funzionalità FC 16 Gb di DCX 8510 Brocade offre vantaggi notevoli per la connettività SAN Metro da un data center all'altro. 16 Gb fornisce FC con il massimo throughput e la minima latenza per le implementazioni che utilizzano connessioni Fibre Channel tra data center. Velocità di linea FC 10 Gb facoltativa per un utilizzo della linea ottimale se una rete DWDM viene implementata tra i siti. Questa funzionalità richiede una licenza. Trunking Inter-Switch Link (ISL) a livello di frame facoltativo che consente un utilizzo elevato rispetto al trunking DPS standard. Questa funzionalità richiede una licenza. Compressione facoltativa per gli ISL tra i data center. Ciò fornisce una maggiore larghezza di banda per le implementazioni in cui il numero di connessioni da sito a sito è limitato. Crittografia al volo dei dati facoltativa per gli ISL tra i data center per le implementazioni che richiedono livelli elevatissimi di sicurezza dei dati. Rilevamento e ripristino della perdita di credito buffer-to-buffer. Correzione anticipata degli errori automatica, che corregge in modo proattivo fino a 11 errori bit per frame FC a 2112 bit. La modalità di diagnostica per le porte ISL tra i data center può essere utilizzata su qualsiasi porta ISL (offline) e offre le funzionalità seguenti: test di loopback elettrici e ottici; test di saturazione dei link; accuratezza della misurazione della distanza del link entro 5 m quando in uso con SFP+ da 8 Gb e 50 m quando in uso con SFP+ da 10 GbE. 56

57 Configurazione della rete IP Per la soluzione, la rete IP in ogni data center viene creata con due switch VDX 6720 Brocade in una configurazione VCS. Tutti i server sono connessi alla rete con connessioni 10 GbE ridondanti fornite da CNA 1020 Brocade. I due switch VDX Brocade in ogni sito sono connessi a un router della serie MLX Brocade tramite un Virtual Link Aggregation Group (vlag). I router della serie MLX Brocade estendono la rete di livello 2 tra i due data center. Nota Un vlag è un servizio fabric che consente a un Link Aggregation Group (LAG) di avere origine da più switch VDX Brocade. Allo stesso modo di un LAG standard, un vlag utilizza il Link Aggregation Control Protocol (LACP) per controllare il bundle di diverse porte fisiche insieme per formare un singolo canale logico. Oracle RAC fa affidamento su un IP virtuale con High Availability (interconnessione HAIP o RAC) per la comunicazione di rete privata. Con HAIP, il carico del traffico di interconnessione viene bilanciato nell'insieme di interfacce identificate come rete privata. Per la soluzione viene utilizzata una VLAN separata, VLAN 10. VLAN 20 ha gestito tutto il traffico pubblico. Tutto il traffico tra il sito A e il sito B viene instradato tramite i router MLX Brocade con più porte configurate come un LAG. Figura 51 mostra l'infrastruttura della rete IP. Figura 51. Reti IP della soluzione 57

58 Configurazione della rete SAN La SAN in ogni data center viene creata con i backbone DCX 8510 Brocade, come illustrato nella Figura 52. Tutti i server sono connessi alla SAN con connessioni 8 Gb ridondanti fornite da HBA 825 Brocade. La connessione VPLEX-VPLEX tra i data center utilizza più connessioni FC tra i backbone DCX 8510 Brocade. Questi vengono usati nella modalità active-active con il failover. Figura 52. Reti SAN della soluzione 58

59 High Availability e business continuity: test e convalida Introduzione Errore del processo del servizio di accodamento SAP Il team addetto alla convalida EMC inizialmente ha installato e convalidato l'ambiente senza schemi di protezione della High Availability o della business continuity. L'ambiente è stato quindi trasformato nella soluzione di business continuity mission-critical descritta nel presente white paper. Sono stati eseguiti i seguenti test per convalidare la soluzione e dimostrare l'eliminazione di tutti i single point of failure dall'ambiente: errore del processo del servizio di accodamento SAP; errore della virtual machine dell'istanza SAP ASCS; errore del nodo Oracle RAC; guasto del sito; isolamento dei cluster VPLEX. Scenario di test Questo scenario di test conferma che, se il processo del servizio di accodamento restituisce un errore, il cluster SUSE Linux Enterprise High Availability Extension trasforma l'istanza SAP ERS in un'istanza ASCS completamente funzionale e subentra alla tabella di blocco senza interruzioni per l'utente finale. Per testare questo scenario di errore, abbiamo terminato il processo di accodamento sul nodo ASCS attivo eseguendo il comando kill: kill -9 <ID processo> Comportamento del sistema Il sistema risponde all'errore del processo del servizio di accodamento nel modo seguente. 1. L'agent di risorse SAPInstance rileva e segnala l'errore, come illustrato nella Figura 53. Figura 53. L'agent di risorse SAPInstance rileva e segnala l'errore 59

60 2. L'agent di risorse master/slave trasforma il nodo slave precedente (SAPASCS2) nel nodo master, che ospita i servizi ASCS, e avvia ERS come slave sull'altro nodo (SAPASCS3) quando ricollega il cluster (vedere Figura 54). Figura 54. L'agent di risorse master/slave inverte i nodi master e slave 3. La tabella del blocco replicato viene ripristinata, come illustrato nella Figura 55. Figura 55. Tabella del blocco replicato ripristinata Risultato L'utente finale non rileva l'errore del processo di accodamento, a meno che non sia in esecuzione un'operazione di accodamento. In questo caso registra un tempo di risposta delle transazioni più lungo durante lo switchover. I nuovi utenti possono accedere al sistema immediatamente dopo lo switchover del server di messaggistica. Non è richiesto alcun intervento amministrativo. 60

61 Errore della virtual machine dell'istanza SAP ASCS Scenario di test Questo scenario di test conferma che, in caso di interruzione imprevista dell'attività dell'esxi server (equivalente a un errore della virtual machine), il cluster High Availability Extension trasforma l'istanza SAP ERS in un'istanza ASCS completamente funzionale e subentra alla tabella di blocco senza interruzioni per l'utente finale. Per testare questo scenario di errore, abbiamo spento (tramite la console fisica remota) l'esxi server che ospita la virtual machine dell'istanza SAP ASCS. Abbiamo quindi riavviato il server senza attivare la modalità di manutenzione. Comportamento del sistema Il sistema risponde all'errore della virtual machine nel modo seguente. 1. SAPASCS2 non è più disponibile nel client vsphere (vedere Figura 56). Figura 56. La virtual machine restituisce un errore 2. L'agent di risorse SAPInstance rileva e segnala l'errore (vedere Figura 57). Figura 57. L'agent di risorse SAPInstance rileva e segnala l'errore 61

62 3. VMware HA riavvia la virtual machine SAPASCS2 in errore sull'host ESXi integro, come illustrato nella Figura 58. Figura 58. VMware HA riavvia la virtual machine in errore 4. L'agent di risorse master/slave trasforma il nodo slave precedente (SAPASCS3) nel nodo master, che ospita i servizi ASCS, e avvia ERS come slave sull'altro nodo (SAPASCS2) quando ricollega il cluster (vedere Figura 59). Figura 59. L'agent di risorse master/slave inverte i nodi master e slave 5. La tabella del blocco replicato viene ripristinata (vedere Figura 60). Figura 60. Tabella del blocco replicato ripristinata 62

63 Risultato L'utente finale non rileva l'errore del processo di accodamento, a meno che non sia in esecuzione un'operazione di accodamento. In questo caso registra un tempo di risposta delle transazioni più lungo durante lo switchover. I nuovi utenti possono accedere al sistema immediatamente dopo lo switchover del server di messaggistica. Non è richiesto alcun intervento amministrativo. Errore del nodo Oracle RAC Scenario di test Questo scenario di test conferma che, in caso di errore imprevisto del nodo RAC, le istanze SAP si connettono automaticamente ad altri nodi RAC. Gli utenti finali possono continuare le transazioni senza interruzioni, a meno che le transazioni non confermate (a livello del database) non vengano eseguite sul nodo RAC in errore. Per testare questo scenario di errore, abbiamo riavviato il server per generare un errore del nodo Oracle. Comportamento del sistema Il sistema risponde all'errore del nodo RAC nel modo seguente. 1. Il nodo RAC va offline e l'istanza VSE003 non è disponibile, come illustrato nella Figura 61. Figura 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 Il nodo RAC va offline 2. Il processo operativo dell'istanza SAP si connette a un'altra istanza RAC, come illustrato nella Figura 62.. Figura 62. L'istanza SAP si connette a un altro nodo RAC 63

64 Risultato L'utente finale registra un tempo di risposta delle transazioni più lungo quando il processo operativo dell'istanza di dialogo si riconnette a un altro nodo RAC. Le transazioni non confermate vengono sottoposte a rollback a livello del database per garantire la coerenza dei dati. L'utente finale riceve un messaggio di errore del sistema (dump breve) e deve riavviare la transazione. Non è richiesto alcun intervento amministrativo. Guasto del sito Scenario di test Questo scenario di test conferma che, in caso di guasto completo del sito, i nodi RAC integri conservano le operazioni del database. Per testare questo scenario di errore, abbiamo simulato un guasto completo del sito A, compresi il cluster VPLEX, l'esxi server, la rete e i componenti del nodo Oracle RAC. VPLEX Witness è rimasto disponibile sul sito C. Sul sito B, il cluster-2 VPLEX è rimasto in comunicazione con VPLEX Witness. Figura 63 mostra lo stato dell'ambiente prima del guasto del sito. Figura 63. Stato dell'ambiente prima del guasto del sito A Comportamento del sistema Il sistema risponde al guasto del sito nel modo seguente. Quando il sito A restituisce un errore, VPLEX Witness garantisce che la regola di detach del consistency group, che definisce il cluster-1 come cluster preferito, venga sovrascritta e che lo storage gestito dal cluster-2 VPLEX sul sito B rimanga disponibile. I nodi RAC sse-ea-erac-n03 e sse-ea-erac-n04 sul sito B rimangono disponibili. Quando gli ESXi server sul sito A restituiscono un errore, VMware HA riavvia SAPASCS3 e SAPDI1 sul sito B. SAPASCS3 viene riavviato su un host ESXi diverso rispetto a SAPASCS2, come previsto dalla regola di affinità VM-VM definita. SUSE Linux Enterprise High Availability Extension rileva l'errore del nodo di cluster SAPASCS3. Poiché ERS era in esecuzione su questo nodo, il cluster si limita a riavviare ERS quando SAPASCS3 ricollega il cluster. La tabella di blocco viene conservata e rimane in funzione. Gli utenti finali su SAPDI1 perdono le loro sessioni a causa del guasto dell'esxi server. Durante il processo di riavvio, i nuovi utenti vengono indirizzati a SAPDI2. Quando SAPDI1 viene riavviato sul sito B, gli utenti possono accedere di nuovo a SAPDI1. 64