emc mission-critical business continuity for sap · pdf filesap ... fec forward error...

White paper

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

BUSINESS CONTINUITY MISSION-CRITICAL EMC PER SAP EMC VPLEX, EMC Symmetrix serie VMAX 10K con Enginuity

Gestione semplificata per High Availability e business continuity Implementazioni SAP mission-critical resilienti Data center active-active

Business continuity mission-critical EMC per SAP EMC VPLEX, EMC Symmetrix serie VMAX 10K con Enginuity

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 H11069

3 Business continuity mission-critical EMC per SAP EMC VPLEX, EMC Symmetrix serie VMAX 10K con Enginuity

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

Livelli di protezione ........................................................................................................................ 14

Database e profilo del carico di lavoro ........................................................................................... 15

Risorse hardware ........................................................................................................................... 15

Risorse software ............................................................................................................................ 16

Infrastruttura di storage EMC ............................................................................................................. 17

Introduzione .................................................................................................................................. 17

EMC Symmetrix VMAX 10K ............................................................................................................. 17

Enginuity ........................................................................................................................................ 17

EMC Symmetrix VMAX 20K ............................................................................................................. 18

EMC Unisphere for VMAX ............................................................................................................... 18

Configurazione VMAX ..................................................................................................................... 19

Infrastruttura EMC VPLEX Metro ......................................................................................................... 21

Introduzione .................................................................................................................................. 21

Data mobility VPLEX ....................................................................................................................... 24

Configurazione della soluzione VPLEX Metro .................................................................................. 27

Configurazione di VPLEX Witness ................................................................................................... 30

Monitoraggio delle prestazioni VPLEX ............................................................................................ 30

Infrastruttura virtualizzata VMware .................................................................................................... 32

Introduzione .................................................................................................................................. 32

Implementazioni di VMware su VPLEX Metro .................................................................................. 33

Configurazione dello stretched cluster di VMware .......................................................................... 35

Configurazione di VMware vSphere HA ........................................................................................... 37

Configurazione di VMware vSphere DRS ......................................................................................... 39

EMC Virtual Storage Integrator e VPLEX .......................................................................................... 39


4

Architettura del sistema SAP .............................................................................................................. 40

Introduzione .................................................................................................................................. 40

Configurazione del sistema SAP ..................................................................................................... 41

Configurazione di SUSE Linux Enterprise High Availability Extension .............................................. 43

Architettura del database Oracle ........................................................................................................ 51

Introduzione .................................................................................................................................. 51

Oracle RAC e VPLEX ........................................................................................................................ 52

Configurazione di Oracle ACFS ....................................................................................................... 52

Oracle Extended RAC su VPLEX Metro ............................................................................................. 53

Configurazione del gruppo di dischi ASM Oracle ............................................................................ 54

Infrastruttura di rete Brocade ............................................................................................................. 55

Introduzione .................................................................................................................................. 55

Configurazione della rete IP ........................................................................................................... 57

Configurazione della rete SAN ........................................................................................................ 58

High Availability e business continuity: test e convalida .................................................................... 59

Introduzione .................................................................................................................................. 59

Errore del processo del servizio di accodamento SAP ..................................................................... 59

Errore della virtual machine dell'istanza SAP ASCS ........................................................................ 61

Errore del nodo Oracle RAC ............................................................................................................ 63

Guasto del sito ............................................................................................................................... 64

Isolamento dei cluster VPLEX ......................................................................................................... 65

Conclusioni ........................................................................................................................................ 68

Riepilogo ....................................................................................................................................... 68

Risultati ......................................................................................................................................... 68

Riferimenti ......................................................................................................................................... 70

EMC ............................................................................................................................................... 70

Oracle ............................................................................................................................................ 70

VMware .......................................................................................................................................... 70

SUSE .............................................................................................................................................. 71

SAP ................................................................................................................................................ 71

Appendice: configurazioni di esempio ................................................................................................ 72

Configurazione di esempio CRM ..................................................................................................... 72

Profilo di un'istanza ASCS di esempio ............................................................................................ 72

Profilo di un'istanza ERS di esempio .............................................................................................. 73

Profilo dI AVVIO ERS di esempio ..................................................................................................... 73

Profilo di un'istanza DI di esempio ................................................................................................. 74


Executive summary

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.

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, AccessAnywhereTM, 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.

Business case

Solution overview


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.

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.

Vantaggi principali


Introduzione

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.

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.

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 Descrizione

AAS SAP Additional Application Server

ABAP SAP Advanced Business Application Programming

ACFS Oracle ASM Cluster File System

ASCS ABAP SAP Central Services

ASM Oracle Automatic Storage Management

CIFS Common Internet File System

CNA Converged Network Adapter

CRM Cluster Resource Manager

DI Dialog Instance

DPS Dynamic Path Selection

DRS VMware vSphere Distributed Resource Scheduler

dvSwitch Switch distribuito vSphere

DWDM Dense Wavelength Division Multiplexing

ERP Enterprise Resource Planning

ERS Enqueue Replication Server

FAST VP Fully Automated Storage Tiering for Virtual Pools

FCoE Fibre Channel over Ethernet

FEC Forward Error Correction

FRA Flash Recovery Area

HA High Availability

HAIP Highly Available virtual IP

Obiettivo

Ambito

Audience

Terminologia


8

Termine Descrizione

HBA Host Bus Adapter

IDES SAP Internet Demonstration and Evaluation System

ISL Inter-Switch Link

LACP Link Aggregation Control Protocol

LAG Link Aggregation Group

LLDP Link Layer Discovery Protocol

LUW Logical Unit of Work

MCT Multi-Chassis Trunking

MPLS Multi-Protocol Label Switching

MPP Multipathing Plug-in

NAS Network Attached Storage

NFS Network File System

NL-SAS Near-Line SAS (Serial Attached SCSI)

OCR Oracle Cluster Registry

Oracle Extended RAC Oracle RAC su cluster a grandi distanze

RAC Real Application Clusters

RFC Remote Function Call

RPO Recovery Point Objective

RTO Recovery Time Objective

SAN Storage Area Network

SBD STONITH Block Device

SFP Small Form-factor Pluggable

SLES SUSE Linux Enterprise Server

SLE HAE SUSE Linux Enterprise High Availability Extension

SMT Subscription Management Tool

SPOF Single Point Of Failure

STONITH Shoot The Other Node In The Head

TAF Transparent Application Failover

ToR Top-of-Rack

VCS Virtual Cluster Switch

vLAG Virtual Link Aggregation Group

vLAN LAN virtuale

VMDK Disco virtuale

VMFS Virtual Machine File System

VMware HA VMware High Availability

VPLS Virtual Private LAN Service

VPN Virtual Private Network

VRF Virtual Routing and Forwarding

VSI Virtual Storage Integrator


Solution overview

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

Introduzione


10

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

Architettura della soluzione


High Availability dell'applicazione SAP

Gli application server SAP sono stati virtualizzati completamente con VMware ESXiTM 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.


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.


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

Figura 7. Architettura della soluzione


14

‎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

A e B Server di accodamento SAP, server di messaggistica SAP

Più istanze di dialogo SAP A e B 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

Livelli di protezione


Ciascuna delle tecnologie illustrate nella ‎Figura 8 viene descritta nei dettagli nelle sezioni pertinenti del white paper.

‎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 Dettagli

Numero di database 1

Tipo database SAP OLTP

Dimensione database 500 GB

Nome database VSE

Oracle RAC 4 nodi fisici

Profilo carico di lavoro Processi order-to-cash personalizzati SAP

‎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

2 2 CPU a due core, 48 GB di RAM

Piattaforma di switching e routing di rete

2 Backbone DCX 8510 Brocade con:

Scheda di estensione FC Fx8-24

2 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

Database e profilo del carico di lavoro

Risorse hardware


16

‎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 Q4 2012

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 UnisphereTM 5.1 Software di gestione VPLEX

EMC Unisphere T1.5.0.151 Software di gestione VMAX

EMC Virtual Storage Integrator (VSI)

5.0.0.95 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 11.2.0.3

Database e software cluster Oracle

SAP ERP 6.04 Sistema SAP ERP IDES

Risorse software


Infrastruttura di storage EMC

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.

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.

L'ambiente operativo della service release Enginuity 5876 Q4 2012 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.

Introduzione

EMC Symmetrix VMAX 10K

Enginuity


18

Questa release di Enginuity si concentra su:

facilità di gestione;

multi-tenancy;

ottimizzazione;

VMAX 10K.

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

EMC Symmetrix VMAX 20K

EMC Unisphere for 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 Dimensione dispositivo (GB)

OCR 5 8

FRA 4 16

REDO 8 16

DATI 16 128

ACFS 4 16

Configurazione VMAX


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 Dimensione dispositivo

(GB)

Metadati VPLEX 2 80

Volume di log VPLEX 2 20

Backup di metadati VPLEX 2 80


Infrastruttura EMC VPLEX Metro

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.

Introduzione


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.


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.

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 front-end. 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 write-through (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 entrambi 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.

Volume virtuale

Dispositivo

Dispositivo

Extent

Volume di storage


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.

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

Data mobility VPLEX


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.


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.


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

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

Configurazione della soluzione VPLEX Metro


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


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


30

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

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.

Configurazione di VPLEX Witness

Monitoraggio delle prestazioni VPLEX


‎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


32

Infrastruttura virtualizzata VMware

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 vCenterTM;

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.

Introduzione


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.

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.

Implementazioni di VMware su VPLEX Metro


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 27.1

1 Per informazioni dettagliate, consultare il TechBook EMC: EMC VPLEX Metro Witness Technology and High Availability.


Figura 27. VMware HA con VPLEX Witness e Cross-Cluster Connect: vista logica

VMware ed EMC supportano una configurazione dello stretched cluster che include host ESXi di più siti2. 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 1026692: Using VPLEX Metro with VMware HA

Configurazione dello stretched cluster di VMware


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


Figura 30. Datastore EXT_SAP_VPLEX_DS01 e host e virtual machine associati

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

Configurazione di VMware vSphere HA


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


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

Configurazione di VMware vSphere DRS

EMC Virtual Storage Integrator e VPLEX


40

Architettura del sistema SAP

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.

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.

Introduzione

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


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.

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

Configurazione del sistema SAP


42

Il server di accodamento e il server di messaggistica sono separati dall'istanza centrale e implementati come servizi nell'istanza ASCS5. 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 accodamento6. 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 SAP7.

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.

http://help.sap.com/


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:

OpenAIS8/Corosync9 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.

Configurazione di SUSE Linux Enterprise High Availability Extension


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 1 2 4 32 SAPASCS2

SAP ERS 1 2 4 32 SAPASCS3

SAP AAS 2 2 4 32 SAPDI1

2 4 32 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 38.


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


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


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


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-autore11, 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 1034165: Disabling simultaneous write protection provided by VMFS using the multi-writer flag.


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


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


Architettura del database Oracle

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.

Introduzione


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.

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

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.

Oracle RAC e VPLEX

Configurazione di Oracle ACFS


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

‎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

Oracle Extended RAC su VPLEX Metro


54

‎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 16 2.048 Esterna

EA_SAP_REDO 4 64 Esterna

EA_SAP_REDOM 4 64 Esterna

EA_SAP_FRA 4 256 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.

Configurazione del gruppo di dischi ASM Oracle


Infrastruttura di rete Brocade

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.

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.

Introduzione

Rete IP

Switch per data center VDX 6720 Brocade

Router serie MLX Brocade

CNA 1020 Brocade

SAN

Backbone DCX 8510 Brocade

HBA 825 Brocade


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.


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

Configurazione della rete IP


58

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

Configurazione della rete SAN


High Availability e business continuity: test e convalida

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

Introduzione

Errore del processo del servizio di accodamento SAP


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.


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.


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

Errore della virtual machine dell'istanza SAP ASCS


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


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.

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.


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.

oracle@sse-ea-erac-n01:~> srvctl status database -d VSE

Instance VSE001 is running on node sse-ea-erac-n01



Instance VSE003 is not running on node sse-ea-erac-n04

Figura 61. 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

Errore del nodo Oracle RAC


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.

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


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.

Guasto del sito


‎Figura 64 mostra lo stato dell'ambiente dopo il guasto del sito.

Figura 64. Stato dell'ambiente dopo il guasto del sito A

Risultato

‎Tabella 12 mostra i comportamenti previsti e osservati del sistema quando il sito A restituisce un errore.

Tabella 12. Comportamenti previsti e osservati

Sistema Stato prima del

test Comportamento

previsto Comportamento

osservato

Nodi Oracle RAC (VSE database)

sse-ea-erac-n01 (sito A)


sse-ea-erac-n03 (sito B)


Tutti disponibili

Espulso

Espulso

Disponibile

Disponibile

Espulso

Espulso

Disponibile

Disponibile

ESXi server Virtual machine

sse-ea-r710a (sito A) SAPASCS3

sse-ea-r710b (sito A) SAPDI1

sse-ea-r710c (sito B) SAPDI2

sse-ea-r710d (sito B)

SAPASCS2

Tutti disponibili

Non disponibile VMware HA riavvia il sito B


Disponibile Disponibile






Cluster VPLEX VPLEX1 – Site A – cluster-1

VPLEX2 – Site B – cluster-2 Tutti disponibili

Non disponibile

Disponibile

Non disponibile

Disponibile

Servizi SAP Enqueue Replication Server

Server di accodamento/ messaggistica

Tutti disponibili

Non disponibile

SLE HAE viene avviato di nuovo dopo il riavvio sul sito B

Disponibile

Non disponibile

SLE HAE viene avviato di nuovo dopo il riavvio sul sito B

Disponibile

Scenario di test

Questo scenario di test conferma che, in caso di isolamento di un cluster VPLEX, il database e le applicazioni SAP continuano a funzionare sul sito integro senza interruzioni.

Per testare questo scenario di errore, abbiamo simulato l'isolamento del cluster preferito sul sito A, dove sia la rete IP di gestione esterna sia la rete di comunicazione WAN VPLEX sono partizionate. La rete LAG rimane disponibile. VPLEX Witness rimane disponibile sul sito C. Sul sito B, il cluster-2 VPLEX rimane in comunicazione con VPLEX Witness.

Isolamento dei cluster VPLEX


66


Il sistema risponde all'isolamento dei cluster VPLEX nel modo seguente.

Quando VPLEX sul sito A viene isolato, 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 e i nodi RAC sse-ea-erac-n01 e sse-ea-erac-n02 sul sito A vengono espulsi.

Gli ESXi server sul sito A rimangono disponibili e le virtual machine SAPASCS2 e SAPDI1 rimangono attive a causa dell'utilizzo di VPLEX Metro HA Cross-Cluster Connect.

‎Figura 65 mostra lo stato dell'ambiente dopo l'isolamento di VPLEX sul sito A.

Figura 65. Stato dell'ambiente dopo l'isolamento di VPLEX sul sito A


Risultato

‎Tabella 13 mostra i comportamenti previsti e osservati del sistema quando VPLEX sul sito A viene isolato.

Tabella 13. Comportamenti previsti e osservati

Sistema Stato prima del test

Comportamento previsto

Comportamento osservato

Nodi Oracle RAC (VSE database)





Tutti disponibili

Espulso

Espulso

Disponibile

Disponibile

Espulso

Espulso

Disponibile

Disponibile

ESXi server

Virtual machine

sse-ea-r710a (sito A)

SAPASCS2

sse-ea-r710b (sito A)

SAPDI1

sse-ea-r710c (sito B)

SAPDI2

sse-ea-r710d (sito B)

SAPASCS3

Tutti disponibili

Tutti disponibili

Tutti disponibili

Cluster VPLEX VPLEX1 – Site A – cluster-1

VPLEX2 – Site B – cluster-2 Tutti disponibili

Non disponibile

Disponibile

Non disponibile

Disponibile

Servizi SAP Enqueue Replication Server

Server di accodamento/ messaggistica

Tutti disponibili

Tutti disponibili

Tutti disponibili


68

Conclusioni

Questa soluzione dimostra la trasformazione di un'implementazione SAP active-passive tradizionale in una soluzione di business continuity con High Availability, data center active-active e continuous availability delle applicazioni.

La soluzione combina EMC, VMware, Oracle, SUSE e i componenti a High Availability Brocade per eseguire le seguenti operazioni:

eliminare i single point of failure a tutti i livelli nell'ambiente;

fornire data center active-active che supportano RPO e RTO vicini allo zero;

abilitare la business continuity mission-critical per le applicazioni SAP.

Ogni single point of failure è stato identificato e attenuato con l'utilizzo dei componenti con fault tolerance e tecnologie di clustering con High Availability. L'utilizzo delle risorse è stato incrementato con l'abilitazione dell'accesso ai dati active-active. La gestione degli errori è stata completamente automatizzata per eliminare il single point of failure definitivo e spesso più imprevedibile dall'architettura: personale e processi.

Le piattaforme di storage di classe enterprise EMC Symmetrix serie VMAX 10K con Enginuity forniscono l'elemento fondamentale per la soluzione.

Inoltre l'utilizzo degli strumenti di gestione e monitoraggio, quali il client vSphere, EMC Virtual Storage Integrator e gli strumenti delle prestazioni VPLEX, semplifica la gestione operativa e consente il monitoraggio e il mapping dello stack dell'infrastruttura.

Oracle RAC su cluster a grandi distanze su VPLEX fornisce i seguenti vantaggi.

Gestione semplificata dell'implementazione: l'installazione, la configurazione e la manutenzione sono le stesse per l'implementazione di RAC su un singolo sito.

Gli host si connettono solo al cluster VPLEX locale, ma hanno l'accesso completo in scrittura e lettura allo stesso database in entrambi i siti.

Non è necessaria l'implementazione di voting disk Oracle e Oracle Clusterware su un terzo sito.

Elimina i costosi cicli di CPU host utilizzati dal mirroring ASM: l'I/O viene inviato solo una volta dall'host al VPLEX locale.

È possibile creare consistency group che proteggono più database o applicazioni sotto forma di unità.

Per convalidare la soluzione, il team addetto alla convalida EMC ha eseguito i seguenti test e rilevato i comportamenti indicati.

Simulazione di un errore del processo del servizio di accodamento SAP

L'applicazione continua a essere eseguita senza interruzioni.

Simulazione di un errore della virtual machine dell'istanza SAP ASCS


Riepilogo

Risultati


Simulazione di un errore del nodo Oracle RAC


Simulazione di un guasto del sito totale


Convalida della funzionalità di VPLEX Witness durante l'isolamento simulato di un cluster VPLEX


Il test dimostra come le soluzioni a High Availability VMware, SAP, SUSE e Oracle eliminano i single point of failure a livello locale.

Illustra inoltre come VPLEX Metro, combinato con SUSE Linux Enterprise High Availability Extension, Oracle Extended RAC e le soluzioni di rete Brocade, estende la High Availability per 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 Witness e Cross-Cluster Connect forniscono un livello di resilienza addirittura superiore.

Insieme, queste tecnologie consentono la trasformazione di un'implementazione del data center active-passive tradizionale in una soluzione di business continuity mission-critical con data center active-active, availability delle applicazioni 24x7, nessun single point of failure e RTO e RPO vicini allo zero.


70

Riferimenti

Per ulteriori informazioni, consultare i seguenti documenti di EMC (disponibili sul sito italy.emc.com e sul sito web del Supporto Online EMC):

EMC VPLEX Metro Witness Technology and High Availability

Utilizzo delle piattaforme di virtualizzazione VMware con EMC VPLEX - Best practice di pianificazione

Conditions for Stretched Hosts Cluster Support on EMC VPLEX Metro

Oracle Extended RAC with EMC VPLEX Metro - Best Practices Planning

EMC VPLEX with GeoSynchrony 5.0 Configuration Guide

Implementation and Planning Best Practices for EMC VPLEX—Technical Notes

EMC VPLEX with GeoSynchrony 5.0 and Point Releases CLI Guide

EMC Simple Support Matrix for EMC VPLEX and GeoSynchrony

Validating Host Multipathing with EMC VPLEX—Technical Notes

EMC VPLEX CLI Guide

Per ulteriori informazioni, consultare i seguenti documenti di Oracle:

Moving your SAP Database to Oracle Automatic Storage Management 11g Release 2: A Best Practices Guide

SAP with Oracle Real Application Clusters 11g Release 2 and Oracle Automatic Storage Management 11g Release 2: Advanced Configurations & Techniques

Configuration of SAP NetWeaver for Oracle Grid Infrastructure 11.2.0.2 and Oracle Real Application Clusters 11g Release 2: A Best Practices Guide

Oracle Real Application Clusters (RAC) on Extended Distance Clusters

Oracle Database Upgrade Guide Upgrade to Oracle Database 11g Release 2 (11.2): UNIX For Oracle Patch Set Release 11.2.0.2 and 11.2.0.3

Per ulteriori informazioni, consultare i seguenti documenti di VMware:

VMware vSphere Networking ESXi 5,0

VMware vSphere Availability ESXi 5,0

Articolo della knowledgebase di VMware 1026692: Using VPLEX Metro with VMware HA

Articolo della knowledgebase di VMware 1034165: Disabling simultaneous write protection provided by VMFS using the multi-writer flag

SAP Solutions on VMware vSphere: High Availability

SAP Solutions on VMware: Best Practices Guide

EMC

Oracle

VMware


Per ulteriori informazioni, consultare i seguenti documenti di SUSE:

SUSE Linux Enterprise High Availability Extension – High Availability Guide

Running SAP NetWeaver on SUSE Linux Enterprise Server with High Availability – Simple Stack

SAP Applications Made High Available on SUSE Linux Enterprise Server 10

Protection of Business-Critical Applications in SUSE Linux Enterprise Environments Virtualized with VMware vSphere 4 and SAP NetWeaver as an Example

Per ulteriori informazioni, consultare i documenti di SAP seguenti:

Note 1552925 – Linux: High Availability Cluster Solutions

Note 1431800 – Oracle 11.2.0: Central Technical Note

Note 105047 – Support for Oracle Functions in the SAP Environment

Note 1550133 – Oracle Automatic Storage Management (ASM)

Note 527843 – Oracle RAC Support in the SAP Environment

Note 989963 – Linux: VMware Timing Problem

Note 1122388 – Linux: VMware vSphere Configuration Guidelines

Note 1310037 – SUSE Linux Enterprise Server 11: Installation notes

SAP Installation Guide for SAP ERP 6.0 – EHP 4 Ready ABAP on Linux: Oracle - Based on SAP NetWeaver 7.0 including Enhancement Package 1

Portale di assistenza per la configurazione di SAP Enqueue Replication Server

SUSE

SAP


72

Appendice: configurazioni di esempio node SAPASCS2 \ attributes standby="off" node SAPASCS3 \ attributes standby="off" primitive rsc_IP_VSE_SAPVIPE ocf:heartbeat:IPaddr2 \ operations $id="rsc_IP_VSE_SAPVIPE-operations" \ op monitor interval="10s" timeout="20s" on_fail="restart" \ params ip="xxx.xxx.xxx.xxx" \ meta is-managed="true" primitive rsc_SAP_VSE_ASCS00_SAPVIPE ocf:heartbeat:SAPInstance \ operations $id="rsc_SAP_VSE_ASCS00_SAPVIPE-operations" \ op monitor interval="120" enabled="true" role="Master" timeout="60" start_delay="5" \ op start interval="0" timeout="180" \ op stop interval="0" timeout="240" \ op promote interval="0" role="Master" timeout="320" start_delay="0" \ op demote interval="0" role="Slave" timeout="320" start_delay="0" \ params InstanceName="VSE_ASCS00_SAPVIPE" ERS_InstanceName="VSE_ERS01_SAPASCS2" AUTOMATIC_RECOVER="true" START_PROFILE="/sapmnt/VSE/profile/START_ASCS00_SAPVIPE" ERS_START_PROFILE="/sapmnt/VSE/profile/START_ERS01_SAPASCS2" \ meta target-role="Started" primitive sbd_stonith stonith:external/sbd \ meta target-role="started" \ op monitor interval="15" timeout="15" start-delay="15" \ params sbd_device="/dev/sdb" group grp_sap_VSE rsc_IP_VSE_SAPVIPE \ meta is-managed="true" target-role="started" ms msl_sap_VSE_ASCS00_SAPVIPE rsc_SAP_VSE_ASCS00_SAPVIPE \ meta globally-unique="true" target-role="Started" clone-node-max="1" master-max="1" notify="true" colocation colocation_IP_ASCS inf: grp_sap_VSE:Started msl_sap_VSE_ASCS00_SAPVIPE:Master order ord_VSE_IP_Master : grp_sap_VSE msl_sap_VSE_ASCS00_SAPVIPE:promote symmetrical=false property $id="cib-bootstrap-options" \ dc-version="1,1.5-5bd2b9154d7d9f86d7f56fe0a74072a5a6590c60" \ cluster-infrastructure="openais" \ expected-quorum-votes="2" \ last-lrm-refresh="1329421965" \ default-resource-stickiness="1000" \ no-quorum-policy="ignore" \ stonith-timeout="180s"

SAPSYSTEMNAME = VSE SAPSYSTEM = 00 INSTANCE_NAME = ASCS00 DIR_CT_RUN = $(DIR_EXE_ROOT)/run DIR_EXECUTABLE = $(DIR_INSTANCE)/exe SAPLOCALHOST = SAPVIPE #----------------------------------------------------------------------- # SAP Message Server parameters are set in the DEFAULT.PFL #----------------------------------------------------------------------- ms/standalone = 1 ms/server_port_0 = PROT=HTTP,PORT=81$$ #----------------------------------------------------------------------- # SAP Enqueue Server #-----------------------------------------------------------------------

Configurazione di esempio CRM

Profilo di un'istanza ASCS di esempio


enque/table_size = 4096 rdisp/enqname = $(rdisp/myname) enque/snapshot_pck_ids = 100 ipc/shm_psize_34 = 0 enque/server/replication = true enque/server/max_requests = 1000 enque/enrep/stop_timeout_s = 0 enque/enrep/stop_retries = 0

SAPSYSTEM = 01 SAPSYSTEMNAME = VSE INSTANCE_NAME = ERS01 #-------------------------------------------------------------------- # Special settings for this manually set up instance #-------------------------------------------------------------------- DIR_EXECUTABLE = $(DIR_INSTANCE)/exe DIR_CT_RUN = /usr/sap/VSE/SYS/exe/run #-------------------------------------------------------------------- # Settings for enqueue monitoring tools (enqt, ensmon) #-------------------------------------------------------------------- enque/process_location = REMOTESA rdisp/enqname = $(rdisp/myname) #-------------------------------------------------------------------- # standalone enqueue details from ASCS instance #-------------------------------------------------------------------- ASCSID = 00 ASCSHOST = SAPVIPE enque/serverinst = $(ASCSID) enque/serverhost = $(ASCSHOST) #-------------------------------------------------------------------- # HA polling #-------------------------------------------------------------------- #enque/enrep/hafunc_implementation = script #enque/enrep/poll_interval = 10000 #enque/enrep/hafunc_init = #enque/enrep/hafunc_check = $(DIR_EXECUTABLE)/enqtest.sh

SAPSYSTEMNAME = VSE SAPSYSTEM = 01 INSTANCE_NAME = ERS01 #----------------------------------------------------------------------- # Special Settings for this manually set up instance #----------------------------------------------------------------------- ASCSID = 00 DIR_CT_RUN = /usr/sap/VSE/SYS/exe/run DIR_EXECUTABLE = $(DIR_INSTANCE)/exe _PF = $(DIR_PROFILE)/VSE_ERS01_SAPASCS2 SETENV_00 = LD_LIBRARY_PATH=$(DIR_EXECUTABLE) SETENV_01 = PATH=$(DIR_INSTANCE)/exe:%(PATH) #----------------------------------------------------------------------- # Copy SAP Executables #----------------------------------------------------------------------- _CPARG0 = list:$(DIR_EXECUTABLE)/ers.lst Execute_00 = immediate $(DIR_EXECUTABLE)/sapcpe$(FT_EXE) $(_CPARG0) pf=$(_PF) #----------------------------------------------------------------------- # Start enqueue replication server #----------------------------------------------------------------------- _ER = er.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME) Execute_01 = immediate rm -f $(_ER)

Profilo di un'istanza ERS di esempio

Profilo dI AVVIO ERS di esempio


74

Execute_02 = local ln -s -f $(DIR_EXECUTABLE)/enrepserver $(_ER) Restart_Program_00 = local $(_ER) pf=$(_PF) NR=$(ASCSID)

SAPSYSTEMNAME = VSE SAPSYSTEM = 00 INSTANCE_NAME = D00 DIR_CT_RUN = $(DIR_EXE_ROOT)/run DIR_EXECUTABLE = $(DIR_INSTANCE)/exe exe/saposcol = $(DIR_CT_RUN)/saposcol rdisp/wp_no_dia = 10 rdisp/wp_no_btc = 3 exe/icmbnd = $(DIR_CT_RUN)/icmbnd icm/server_port_0 = PROT=HTTP,PORT=80$$ SAPFQDN = sse.ea.emc.com SAPLOCALHOSTFULL = $(SAPLOCALHOST).$(SAPFQDN) ipc/shm_psize_10 = 136000000 ipc/shm_psize_40 = 112000000 rdisp/wp_no_vb = 1 rdisp/wp_no_vb2 = 1 rdisp/wp_no_spo = 1 enque/process_location = REMOTESA enque/serverhost = SAPVIPE enque/serverinst = 00 enque/deque_wait_answer = TRUE enque/con_timeout = 2000 enque/con_retries = 60

Profilo di un'istanza DI di esempio

emc mission-critical business continuity for sap · pdf filesap ... fec forward error...

Documents