White paper

Abstract

Nel presente white paper vengono illustrate le best practice per la virtualizzazione dei database Oracle mediante soluzioni EMC e VMware™. L'ampia gamma di argomenti trattati consente di fornire le linee guida per la virtualizzazione di Oracle e per il miglioramento dell'infrastruttura virtualizzata corrente. Luglio 2014

Best practice per la virtualizzazione di Oracle Oracle Solutions Marketing per EMC

• Concetti di virtualizzazione dello storage

− Fibre Channel, NAS, iSCSI • Provisioning dello storage in vSphere

− RDM fisico, RDM virtuale e VMFS • Prestazioni, consolidamento, facilità di provisioning, gestibilità e

availability

Best practice per la virtualizzazione di Oracle 2

Copyright © 2014 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 nessun 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. Oracle è un marchio di Oracle Corporation negli Stati Uniti e in altri Paesi. VMware, ESX, ESXi, vSphere e VMware vCenter sono marchi o marchi registrati di VMware, Inc. negli Stati Uniti e/o in altre giurisdizioni. Tutti gli altri marchi citati nel presente documento appartengono ai rispettivi proprietari. Intel e Xeon sono marchi di Intel Corporation negli Stati Uniti e/o in altri Paesi. Part Number H13097

Best practice per la virtualizzazione di Oracle 3

Sommario

Executive summary .................................................................................................. 4 Audience ............................................................................................................................ 4

Benefits of Virtualizing Oracle using VMware vSphere .............................................. 4 Cost Savings ...................................................................................................................... 4 Virtualization Agility ........................................................................................................... 6 High Availability ................................................................................................................. 7 Support and Certification ................................................................................................... 7 Customer References .......................................................................................................... 9

Storage Virtualization .............................................................................................. 9 Dedicated Storage Infrastructure for Databases ................................................................ 10 Multipathing ..................................................................................................................... 10 Storage Protocols ............................................................................................................. 12 Provisioning Storage in vSphere ....................................................................................... 15

EMC Best Practices for Virtualizing Oracle .............................................................. 20 Performance ..................................................................................................................... 20

FAST VP ........................................................................................................................ 20 FAST Cache ................................................................................................................... 22 Paravirtual SCSI (PVSCSI) Adapters .............................................................................. 23

Consolidation ................................................................................................................... 24 Ease of Provisioning ......................................................................................................... 24

vCloud Automation Center ............................................................................................ 25 vCenter Orchestrator .................................................................................................... 25 Puppet ......................................................................................................................... 26

Manageability .................................................................................................................. 26 OEM 12c Plug-in for EMC VMAX and VNX ...................................................................... 26 EMC’s Oracle Workload Profile Assessments – AWR & Statspack .................................. 28 DBClassify: A Professional Services Option .................................................................. 29

Availability ....................................................................................................................... 30

Everything Oracle at EMC Community ..................................................................... 32

Conclusion ............................................................................................................ 32

References ............................................................................................................ 33 Other References .............................................................................................................. 34

Best practice per la virtualizzazione di Oracle 4

Executive Summary

Le EMC Proven Solutions e le tecnologie EMC assicurano valore elevato e integrazione trasparente con la virtualizzazione ad aziende, data center IT, team di DBA e proprietari di applicazioni. Il successo della virtualizzazione delle applicazioni e dei database Oracle™ si basa su best practice definite da EMC e dai partner. Le best practice permettono ai clienti di aggiungere agilità, flessibilità, resilienza e prestazioni alle loro infrastrutture con maggiore facilità. Nel presente documento vengono esaminate le best practice per l'implementazione di Oracle su un'infrastruttura EMC mediante la virtualizzazione VMware.

Audience Il presente white paper è rivolto a Oracle Database Administrator (DBA), amministratori VMware, Storage Administrator, IT Architect e responsabili tecnici della progettazione, creazione e gestione di database Oracle, infrastruttura e data center.

Vantaggi della virtualizzazione di Oracle mediante VMware vSphere Il modello IT-as-a-Service (ITaaS) è un obiettivo di numerose organizzazioni che mirano a diventare più agili nell'erogazione di servizi e più competitive migliorando il time-to-market. La tendenza è sviluppare un'infrastruttura virtualizzata per ridurre i costi di manutenzione del database e incrementare la gestibilità, la flessibilità e l'High Availability. A tale scopo, i data center IT stanno progettando infrastrutture virtualizzate che offrono il consolidamento delle risorse fisiche e l'automazione delle operazioni di manutenzione ordinaria.

Risparmio sui costi Lo slancio tecnologico della virtualizzazione è dirompente da diversi anni. Tuttavia, l'attenzione si è spostata dai vantaggi offerti dalla virtualizzazione alla definizione di un'architettura IT-as-a-Service (ITaaS) e Database-as-a-Service (DBaaS). Il consolidamento è uno degli imperativi chiave della virtualizzazione, che consente al data center di utilizzare meno hardware e di ridurre le spese CAPEX e OPEX. Il valore del consolidamento e il risparmio sui costi conseguente all'utilizzo di un numero inferiore di risorse hardware erano argomenti sufficientemente convincenti per spingere le aziende a iniziare il percorso di virtualizzazione, ma alcuni team di DBA che gestivano database mission-critical erano critici nei confronti della virtualizzazione Oracle interrogandosi, tra l'altro, sulle prestazioni. I database Oracle rappresentano un investimento notevole e, in alcuni casi, si riteneva che il risparmio sui costi offerti dalla virtualizzazione non giustificasse l'introduzione di un altro livello in un'infrastruttura fisica già stabile. Nel corso del tempo, tuttavia, le aziende che per prime hanno adottato la virtualizzazione si sono trasformate in maggioranza e ora stanno attivamente adottando il modello DBaaS. Questa trasformazione è un processo che inizia con poche applicazioni e cresce con l'accettazione della virtualizzazione come piattaforma stabile di consolidamento per i database Oracle mission-critical. Un'altra tendenza, nota come "consolidamento delle prestazioni", ha accelerato la virtualizzazione poiché l'integrazione di queste tendenze assicura una piattaforma ottimale per i sistemi di produzione. EMC offre soluzioni mirate al miglioramento delle prestazioni, come FAST VP e FAST Cache, che offrono prestazioni di storage più elevate utilizzando un numero inferiore di unità disco. Ad esempio in un documento recente, EMC VNX™ Scaling Performance for Oracle 12c RAC on VMware vSphere, utilizzando solo cinque Flash drive, FAST Cache multi-core ha aumentato del 93% il

Best practice per la virtualizzazione di Oracle 5

numero di transazioni al minuto (TPM) e ha ridotto la latenza del 91% per gli eventi di attesa di lettura sequenziale di file DB. La combinazione dei vantaggi offerti dalle tendenze di virtualizzazione e prestazioni ha permesso ai team di DBA di virtualizzare i database e di definire l'architettura dell'infrastruttura di database ottimizzata. In un articolo di David Floyer, Wikibon, Virtualization of Oracle Evolves to Best Practices Production Systems, viene descritto l'impatto sui costi di un'infrastruttura di database ottimizzata. Nell'articolo il costo di un database core Oracle tradizionale viene confrontato al costo di un database core ottimizzato. I costi nell'analisi del database core tradizionale sono inferiori ($ 27.716 per ogni core) perché non includono i costi relativi alla virtualizzazione e alla storage architecture ottimizzata utilizzando le Flash drive. Il database core ottimizzato è più costoso del 17,8% ($ 32.671 per ogni core) perché include il costo della virtualizzazione e delle Flash drive. Secondo Wikibon "...il costo complessivo (con riferimento al costo di implementazione del sistema di database di latenza ottimizzata) è notevolmente inferiore perché il numero di core può essere diminuito da 192 a 120, con una riduzione del 37,5%. "[15] L'articolo evidenzia come le aziende possono ridurre i costi combinando le tendenze di virtualizzazione e prestazioni in un sistema di database di latenza ottimizzata che utilizza contemporaneamente meno risorse hardware e assicura prestazioni più elevate.

Figura 1: mostra il risparmio sui costi associato all'implementazione del sistema di database di latenza ottimizzata rispetto al sistema di database tradizionale. Fonte: Wikibon, aprile 2013, Virtualization of Oracle Evolves to Best Practice for Production Systems

Best practice per la virtualizzazione di Oracle 6

Agilità della virtualizzazione L'agilità tecnica è la capacità di cambiare lo stack di applicazioni per aumentare resilienza, efficienza e coordinamento e automatizzare le attività comuni per dedicare più tempo ad altre iniziative di crescita. La funzionalità di virtualizzazione, nota come migrazione in tempo reale, consente il trasferimento di una virtual machine da un server a un altro mentre l'applicazione è in esecuzione e senza perdita di dati. VMware vMotion è uno degli esempi migliori per dimostrare come la virtualizzazione di Oracle consenta di aggiungere agilità ai database mission-critical. In uno studio recente di Principled Technologies, Demonstrating vMotion Capabilities with Oracle RAC on VMware vSphere è stato evidenziato come l'uso di vMotion in parallelo con i database virtualizzati di grandi dimensioni assicuri notevole velocità senza registrare perdite di dati. La migrazione di questi nodi Oracle RAC virtualizzati è stata eseguita con carichi di lavoro pesanti utilizzando vMotion e nel corso di tutti i test non si sono verificate operazioni di fencing o di espulsione. Ciò dimostra che la virtualizzazione VMware fornisce il 100% di astrazione tra l'hardware e il sistema operativo e la piattaforma è molto matura per le applicazioni mission-critical. Di seguito è riportata la configurazione testata in questo studio.

Figura 2: architettura testata nello studio di Principled Technologies "Demostrating vMotion Capabilities with Oracle RAC on VMware vSphere"

Lo studio ha dimostrato quanto segue:

L'uso di vMotion in un singolo nodo Oracle RAC virtualizzato di grandi dimensioni ha richiesto 130 secondi.

L'uso di vMotion in due nodi Oracle RAC virtualizzati di grandi dimensioni ha richiesto 155 secondi.

L'uso di vMotion in tre nodi (ossia tutti i nodi) Oracle RAC virtualizzati ha richiesto 180 secondi.

Best practice per la virtualizzazione di Oracle 7

Secondo Principled Technologies, "i test hanno evidenziato che, utilizzando hardware di server Cisco UCS e storage EMC VMAX™, VMware vSphere con vMotion ha facilitato il trasferimento di database di grandi dimensioni e di altri carichi di lavoro da un server a un altro in un cluster, senza tempo di inattività delle applicazioni. Eseguendo database di grandi dimensioni su virtual machine VMware vSphere, si possono sfruttare i vantaggi di VMware vMotion in termini di massima agilità e flessibilità nella gestione dei carichi di lavoro dei database mission-critical". La virtualizzazione aggiunge resilienza all'infrastruttura e permette la manutenzione dell'hardware automatizzata e proattiva utilizzando vMotion, che è il fondamento delle altre tecnologie, come i cluster High Availability (HA) e Distributed Resource Scheduler (DRS). vMotion, DRS e HA gestiscono insieme gran parte dei componenti dell'agilità: resilienza, efficienza, coordinamento e automazione.

High Availability Per esaminare il lato di resilienza dell'agilità, verrà presa in esame VMware High Availability (HA). Mediante VMware l'amministratore può creare cluster HA. I cluster sono raggruppamenti logici di servizi per i server. Ad esempio, un amministratore di virtualizzazione può creare un cluster logico costituito da tre server in cui sono in esecuzione database Oracle virtualizzati. I cluster HA appena creati monitorano i guasti, come la perdita di una scheda di rete e di un server, e riavviano automaticamente le virtual machine su altri host del cluster senza intervento manuale. I cluster HA consentono di ridurre il tempo di inattività delle applicazioni e automatizzare la protezione dell'applicazione virtualizzata senza dover modificare il sistema operativo guest. I cluster VMware HA con VPLEX™ Metro forniscono una soluzione con High Availability all'interno di un data center o tra più data center. VPLEX Metro è una connessione sincrona tra due siti per federare gli storage array. Nell'architettura VPLEX Metro viene eseguito il mirroring di tutti i dati in modalità sincrona attraverso due storage array. Con VPLEX Metro, un datastore VMFS può essere distribuito o "esteso" tra più storage array e VMware HA può essere attivo in entrambi i siti. Questa soluzione che utilizza VPLEX Metro e i cluster VMware HA è nota come "HA federata". In caso di interruzione non pianificata dell'attività, i database Oracle virtualizzati vengono riavviati automaticamente nel data center integro senza perdita di dati e senza che sia necessario eseguire il ripristino. Il white paper Using VPLEX Metro with VMware High Availability and Fault Tolerance for Ultimate Availability fornisce informazioni su questo argomento ed è rivolto ai DBA, agli amministratori di VMware e agli altri professionisti interessati all'automazione e alla resilienza geografica.

Supporto e certificazione La questione del supporto e della certificazione Oracle alla virtualizzazione è stata trattata in altre occasioni, ma qui presentiamo una breve panoramica indicando i riferimenti alla documentazione di supporto. Riguardo al supporto Oracle è opportuno iniziare con la domanda "Per quali prodotti Oracle fornirà il supporto?" La risposta è semplice: Oracle supporta i propri prodotti. Solo se il team di supporto Oracle riterrà che la richiesta di supporto non riguardi un proprio prodotto, indirizzerà la risoluzione a un'altra parte dello stack. Oracle può reindirizzare il supporto al sistema operativo, alle schede di rete (e driver associati), al software di sicurezza, al software di controllo delle modifiche, alle schede HBA (e driver associati) e persino alla virtualizzazione, inclusa la Oracle Virtual Machine. Questo approccio non è esclusivo di Oracle: la maggior parte delle aziende, se la causa del problema risiede nei propri prodotti, offre supporto. In generale, il supporto Oracle è stato efficace per i clienti che hanno adottato la virtualizzazione

Best practice per la virtualizzazione di Oracle 8

di Oracle e la maggior parte dei timori, delle incertezze e dei dubbi viene espressa nel corso di discussioni di vendita finalizzate a scoraggiare i clienti dall'adottare la virtualizzazione. Nella curva di adozione della tecnologia, siamo nella fase della maggioranza ritardataria e in genere il supporto non rappresenta un problema come in passato. La domanda chiave relativa alla certificazione è molto simile a quella del supporto: "Per quali prodotti Oracle fornirà la certificazione?" Come molti DBA esperti sanno, per determinare il sistema operativo per cui il database o un altro prodotto è certificato, occorre esaminare la Oracle Certification Matrix. Ad eccezione dell'hardware, della virtualizzazione e delle partnership Oracle, la Certification Matrix utilizza solo il sistema operativo incluso nei propri criteri di selezione. Oracle convalida pertanto i suoi prodotti con i sistemi operativi e non procede ulteriormente nello stack. Questo approccio non è nuovo e i DBA stanno collaborando con i team che si occupano di rete e storage per convalidare anche il funzionamento di tutti i componenti, come le schede NIC e HBA, con il sistema operativo certificato. Lo stesso approccio è stato adottato per la virtualizzazione poiché i DBA Oracle devono collaborare con gli amministratori vSphere per verificare se il sistema operativo di destinazione è certificato da VMware. A meno che non si stia utilizzando hardware Oracle, ciò potrebbe essere vero per l'infrastruttura di database corrente, compresi le schede NIC, HBA e altri prodotti software, non presenti nella Certification Matrix Oracle. EMC, insieme a numerosi partner, sta migliorando la comunicazione e collaborando con i clienti per creare il consenso sulla virtualizzazione di Oracle aiutando anche i clienti. Alcuni documenti di supporto sono: • VMware Oracle Support Policy

• Understanding Oracle Certification, Support and Licensing for VMware Environments

• Virtualizing Oracle with VMware

Understanding Oracle Certification, Support and Licensing for VMware Environments

Webcast: House of Brick and GE Discuss Implementing a 100% Oracle Virtualization Strategy

Read Virtualizing Business Critical Applications with VMware

Nel documento, Understanding Oracle Certification, Support and Licensing for VMware Environments, appendice 3, viene fornita una panoramica del supporto VMware per i prodotti Oracle in esecuzione su VMware. Nel documento si afferma che "il supporto VMware accetta la responsabilità per qualsiasi problema correlato a Oracle segnalato da un cliente. In virtù di tale responsabilità, il supporto VMware guiderà la risoluzione del problema indipendentemente dal vendor (VMware, Oracle o altri) che è responsabile della risoluzione". Il supporto VMware agirà pertanto per conto del cliente per risolvere i problemi relativi al software Oracle in esecuzione su VMware. Questa indicazione è chiara perché la dichiarazione mostra che VMware supporta la sua tecnologia e i suoi clienti. In questo modo si eliminano situazioni in cui le responsabilità vengono attribuite all'una o all'altra parte o quelle che talvolta vengono definite come "blame storm", durante le quali si cerca di indicare la virtualizzazione come causa di un problema.

Best practice per la virtualizzazione di Oracle 9

Le referenze dei clienti La virtualizzazione degli ambienti Oracle mediante VMware vSphere è diventata molto comune, se non standard, soprattutto negli ambienti non di produzione (ad esempio in quelli di test/sviluppo). Attualmente una percentuale molto ampia di server RAC e database Oracle viene virtualizzata con VMware vSphere. Un elenco completo di riferimenti per i clienti Oracle di EMC è disponibile qui. Di seguito è riportato un esempio.

American Tire Distributors American Tire Distributors, uno dei più grandi fornitori di pneumatici statunitensi per il mercato degli pneumatici di ricambio, sta registrando una crescita esponenziale. Per gestire questa crescita, ATD ha intrapreso un percorso aggressivo verso il private cloud, scegliendo EMC e VMware per consolidare i propri server di database Oracle in un ambiente private cloud. Grazie allo storage EMC, i tempi di elaborazione back-end sono più veloci del 65% e l'utilizzo dei database è migliorato del 97% impiegando VMware su VNX. American Tire Distributors utilizza anche il backup Data Domain per ottenere backup 2 volte più veloci e restore 9 volte più veloci. Profilo del cliente, webcast e testimonianza video

Esprinet Esprinet è un distributore all'ingrosso leader dell'IT e dell'elettronica di consumo in Italia e Spagna. Data la crescita del business, Esprinet ha creato un ambiente complesso che include storage HP, IBM ed EMC per supportare diversi aspetti. Questa articolata infrastruttura richiedeva tempi lunghi e costi elevati di gestione e aveva bisogno di una capacità maggiore. Le prestazioni inoltre risultavano scarse. Esprinet ha deciso di consolidare la maggior parte dello storage IBM e tutto lo storage HP su EMC VNX, implementando EMC FAST Suite, inclusa l'infrastruttura Oracle virtualizzata mediante VMware vSphere. Con FAST Cache, l'azienda soddisfa l'80% delle richieste di I/O dalle Flash drive utilizzando al contempo un numero di unità disco inferiore del 33%. Profilo del cliente

Virtualizzazione dello storage Tradizionalmente, i database di produzione e le applicazioni mission-critical vengono virtualizzati per ultimi perché la loro importanza per il business richiede una transizione senza interruzioni o rischi. VMware, fondata nel 1998, è una piattaforma di virtualizzazione molto matura e collaudata come piattaforma tecnologica aziendale leader nella trasformazione cloud delle applicazioni DB di produzione del Tier-1 per più del 55% nel 2013 e, secondo le previsioni, per il 75% nel 2016.[1] Raramente i proprietari di applicazioni hanno dubbi sul motivo per cui virtualizzare, sono interessati piuttosto alla "modalità con cui ottenere il provisioning automatizzato delle applicazioni", noto anche come IT-as-a-Service (ITaaS) o Database-as-a-Service (DBaaS) per i database. Conoscere i livelli di virtualizzazione è una delle considerazioni chiave per la virtualizzazione dei database Oracle. Il livello più basso del modello di virtualizzazione è lo storage e per i database Oracle lo storage è uno degli aspetti più importanti della progettazione dell'infrastruttura cloud per le applicazioni. I DBA Oracle sono particolarmente interessati ai seguenti aspetti: prestazioni, affidabilità, gestibilità e protezione dello storage. Gli amministratori VMware collaborano a stretto contatto con gli Storage Administrator e i DBA per allineare la scelta di physical Raw Device Map (pRDM), virtual Raw Device Map (vRDM), Network Attached Storage (NAS), Internet Small Computer System Interface (iSCSI) e Virtual Machine File System (VMFS) ai requisiti di prestazioni e gestione dell'applicazione. La progettazione della storage architecture negli aspetti relativi alla

Best practice per la virtualizzazione di Oracle 10

virtualizzazione e soprattutto il database è un fattore chiave per la virtualizzazione delle applicazioni mission-critical. L'analisi dei protocolli di storage offrirà un punto di partenza per la progettazione della virtual storage architecture.

Infrastruttura di storage dedicata per i database Le applicazioni e i database di produzione dovrebbero prevedere un'infrastruttura di storage dedicata nelle schede HBA, nelle porte switch, nei cavi e nei dischi. La virtualizzazione è molto efficace nel consolidare le risorse dei server e nel promuovere un maggiore utilizzo, ma le stesse procedure di consolidamento non devono essere applicate alla progettazione dello storage che supporta i database di produzione. Lo storage dedicato assicura prestazioni prevedibili, risoluzione rapida dei problemi delle prestazioni e migliore storage management.

Multipathing Per utilizzare il multipathing, sono necessarie due o più schede HBA, oltre a uno storage array che supporta il multipathing. Ad esempio a partire da Enginuity 5876 e Solutions Enable v7.4 for Symmtrix™ VMAX, gli array supportano il Native Multipathing (NMP).[2] È consigliabile che lo Storage Administrator e il responsabile della virtualizzazione collaborino per definire quale dei seguenti tre tipi di multipathing è supportato e più adatto ai database Oracle: • Active-active: le richieste di I/O possono essere inviate a una LUN mediante qualsiasi porta o

processo dello storage array. Gli storage array VNX di nuova generazione dispongono della gestione dei percorsi active-active con accesso simmetrico per assicurare il multipathing ottimale. In genere, la proprietà di una LUN da parte di uno storage processor implicava l'utilizzo del modello pseudo active/active, ossia, per lo storage si disponeva di un percorso ottimale e di un percorso non ottimale e quest'ultimo poteva causare il thrashing (i dati vengono inviati tramite il percorso non ottimale causando un trespass e devono essere trasferiti al service processor (SP) proprietario prima che possa verificarsi una conferma). Un trespass grave è chiamato thrashing e non è altrettanto efficace rispetto a un vero multipathing active-active. La modalità active-active con accesso simmetrico nella nuova generazione di VNX migliora il multipathing gestendo solo i metadati tra gli storage processor. Funziona nel modo seguente: SP comunica tramite un'interfaccia di gestione per richiedere un blocco su un Logical Block Access (LBA). In base a questo nuovo meccanismo LBA, solo i flussi di metadati tra i processori e l'SP proprietario possono mantenere la fedeltà dell'ordine di scrittura, un aspetto particolarmente importante per i database Oracle.

• Pseudo active-active: noto anche come Asymmetric Logical Unit Access (ALUA). Come descritto in precedenza, i dati possono essere trasferiti mediante qualsiasi percorso, tuttavia se quello utilizzato non è ottimale viene generato un trespass. La velocità dei dati nel percorso ottimale è infatti notevolmente superiore rispetto a quella del percorso non ottimale.

• Active-passive: i dati utilizzano un percorso active e, in caso di errore, il controllo passa al percorso passive.

Una volta definiti brevemente i tre tipi di multipathing, esaminiamo l'aspetto della definizione della Path Selection Policy (PSP). VMware consente all'amministratore virtuale di scegliere fra queste tre policy PSP:

Fisso: i dati vengono inviati nel percorso ottimizzato; questa policy viene utilizzata in genere per gli array ALUA o pseudo active-active.

MRU (Most Recently Used): utilizzata in genere con la modalità active-passive perché i dati vengono inviati su un percorso fino a quando si verifica un errore, quindi il percorso passive assume il controllo.

Best practice per la virtualizzazione di Oracle 11

Round Robin (RR): viene inviata una quantità fissa di dati, I/O o byte in un percorso e viene eseguita la stessa operazione per il percorso successivo. In genere questa modalità viene preferita per il multipathing active-active.

Conoscere il multipathing supportato dall'array e l'applicazione della policy PSP corrispondente è utile per validare la configurazione per il database virtualizzato. Oltre alla gestione dei percorsi nativa, VMware include EMC PowerPath Virtual Edition (VE) che assicura prestazioni migliori aggiungendo funzionalità come il bilanciamento dinamico del carico, la facilità di gestione e le funzioni di ripristino e failover. PowerPath VE risiede nell'hypervisor ESXi, sotto le virtual machine e sopra lo storage e, a causa della sua posizione nello stack, PowerPath VE è un'installazione server one–time che offre vantaggi alle VM eterogenee. Le applicazioni di produzione e i database Oracle richiedono in genere opzioni di ripristino e resilienza migliori per prevenire la perdita del servizio, rendendo queste due funzionalità di PowerPath VE considerazioni chiave: • Funzioni automatiche di ripristino e failover: in caso di errore del percorso, PowerPath

reindirizza automaticamente i dati sul percorso integro migliore e riequilibra l'I/O in tutti i restanti percorsi. Non è necessario alcun intervento manuale e quando il percorso in cui si è verificato l'errore è disponibile, PowerPath lo aggiunge automaticamente al pool e riequilibra nuovamente l'I/O.

• Bilanciamento intelligente del carico: per analizzare i percorsi e determinare quello ottimale, PowerPath utilizza statistiche e algoritmi. Rileva pertanto i colli di bottiglia e reindirizza dinamicamente l'I/O per mantenere il livello di prestazioni previsto dal database Oracle.

Nell'immagine riportata di seguito è illustrato l'uso di PowerPath VE:

Figura 3: architettura per la resilienza e le prestazioni ottimali di VM PowerPath

Best practice per la virtualizzazione di Oracle 12

Nel report di convalida di ESG Lab, Automated Path Optimization for VMware Virtual Environment, vengono convalidati i vantaggi di PowerPath VE sia a livello di prestazioni sia a livello di ripristino e failover automatici. Ad esempio, PowerPath VE consente il 25% in più di IOPS in un carico di lavoro OLTP rispetto al Native Multipathing.[3] I vantaggi a livello di resilienza e prestazioni di PowerPath VE sono considerazioni chiave per la storage architecture dei database Oracle.

Protocolli di storage Gli amministratori di database e gli Storage Administrator possono scegliere tra diversi protocolli di storage per le applicazioni, ognuno con specifici punti di forza e sfide. Il protocollo iSCSI utilizza TCP per il trasferimento dei comandi SCSI sulla rete per la connessione ai block device nello storage. Il protocollo Network Attached Storage (NAS) utilizza TCP per presentare i servizi per file sullo storage array che agisce come file server. Infine esiste il protocollo Fibre Channel, forse quello più utilizzato con i database Oracle per la connessione diretta tra l'host e lo storage di livello enterprise.

Fibre Channel Un server host si connette alla rete SAN (Storage Area Network) in genere utilizzando due Host Bus Adapter (HBA) a un sistema di storage ad alte prestazioni. Il protocollo Fibre Channel (FC) viene utilizzato per trasferire i comandi SCSI consentendo al server di collegarsi allo storage sottostante. Alcuni componenti dell'architettura SAN sono: • HBA: schede PCIe del server che eseguono l'offload del protocollo FC dall'host per il

collegamento tramite switch allo storage array.

• Switch: gestiscono il routing del traffico da e verso lo storage array e vengono utilizzati per limitare l'accesso del server allo storage, il cosiddetto "zoning". Le zone vengono create per un gruppo di server che devono accedere allo stesso storage condiviso. Ad esempio, Oracle Real Application Clusters (RAC) è un gruppo di server che necessitano dell'accesso agli stessi file di database, operazione che può essere eseguita creando una zona. Lo zoning consente ai server di condividere lo stesso storage e impedisce che accedano ad altro storage.

• LUN Masking: viene utilizzata dallo Storage Administrator per configurare i server in modo che accedano alle LUN o, al contrario, che le LUN non siano visibili.

• Cavi, storage processor e unità disco a stato solido e meccanici.

L'uso di due HBA offre l'opportunità di abilitare il multipathing, una tecnica in cui vengono utilizzati più percorsi tra l'host e lo storage per aumentare la larghezza di banda e scalare le prestazioni delle applicazioni. Nei database e nelle altre applicazioni aziendali Oracle le prestazioni sono determinanti per il rapido trasferimento di informazioni e il multipathing è pertanto un fattore chiave per la storage architecture.

Linee guida su Fibre Channel

In questa sezione esamineremo, in ordine di priorità partendo dall'alto, le linee guida più importanti da seguire per definire la storage architecture dei database Oracle. • Utilizzare le schede HBA supportate più veloci e garantire che le velocità siano

costantemente le stesse tra le schede. Fare riferimento alla knowledgebase VMware, articolo 1006602.

Best practice per la virtualizzazione di Oracle 13

• Verificare l'impostazione di profondità della coda consigliata per le schede di questo tipo con il vendor della scheda HBA. Fare riferimento alla knowledgebase VMware, articolo 2072070: EMC VMAX and DMX Symmetrix Storage Array recommendation for optimal performance on VMware ESXi/ESX.

• Per Oracle RAC, ricercare Setting the Maximum Outstanding Disk Requests for virtual machines. Fare riferimento alla knowledgebase VMware, articolo 1268 e alla documentazione su ESXi e vCenter Server 5.

Network Attached Storage NAS è il data storage a livello di file a cui si accede tramite una rete a un gateway su un computer o su sistemi aziendali come EMC serie VNX. Uno dei punti di forza dell'utilizzo dello storage NAS è che consente a un gruppo eterogeneo di client di accedere agli stessi file sullo storage. I sistemi enterprise come VNX consentono ai client Microsoft Windows, Linux e UNIX di condividere file in ambienti multiprotocollo Network File System (NFS) e Common Internet File System (CIFS).[4] In tempi recenti, NAS è diventato sempre più comune per diversi motivi, tra cui quelli indicati di seguito: • Progettazione di storage semplificata: NFS consente di ridurre la complessità

perché il business non deve analizzare in dettaglio opzioni come pRDM, vRDM e VMFS. Inoltre, l'uso dello storage di livello enterprise implica che sono disponibili tutte le funzionalità basate sull'array come snapshot, cloni, replica e le tecnologie di accelerazione, come il tiering automatizzato e il Flash caching dinamico.

• Fast Ethernet: lo sviluppo rapido di Fast Ethernet implica che i clienti potranno usufruire delle prestazioni offerte dallo standard 40GbE o persino 100GbE poiché i prezzi scenderanno rendendo molto competitivo il costo per gigabyte.

• Direct NFS (dNFS) di Oracle: l'implementazione del client dNFS è semplice e le prestazioni del database sono elevate perché la connessione NFS viene gestita dai binari del database.

Nella soluzione comprovata, EMC VNX Scaling Performance for Oracle 12c RAC on VMware vSphere 5.5, le reti di interconnessione dei cluster RAC e dello storage utilizzano lo standard 10 GbE e il client dNFS del database Oracle. I test delle prestazioni nella soluzione hanno evidenziato che l'architettura RAC a 4 nodi è stata in grado di supportare più di 239.000 transazioni al minuto (TPM) senza FAST Cache e più di 744.000 TPM con FAST Cache (il Fully Automated Storage Tiering utilizza unità allo stato solido (SDD), note in genere come Flash drive, per inserire i dati più utilizzati dinamicamente nella cache). La lista riportata di seguito include alcune best practice per l'utilizzo dello storage NAS con i database Oracle virtualizzati.

Linee guida su NAS Questa lista elenca alcune best practice per utilizzare lo storage NAS con i database Oracle virtualizzati. • Isolare il traffico NFS: con le soluzioni di storage di rete come NFS una considerazione

importante sono le prestazioni prevedibili che possono essere ottenute dedicando la rete di produzione ai server di produzione. A tale scopo, è necessario isolare il traffico del server utilizzando Virtual LAN (VLAN) o switch dedicati.

Best practice per la virtualizzazione di Oracle 14

• Fast Ethernet: utilizzare l'Ethernet più veloce supportato sia per VMware vSphere sia per lo storage EMC.

• Frame Jumbo: implementare i frame jumbo implica cambiare la dimensione MTU predefinita da 1500 in 9000. Una MTU maggiore aumenta il throughput, genera un numero inferiore di pacchetti di rete di dimensioni maggiori e può ridurre l'utilizzo della CPU del server. Per supportare i frame jumbo, è necessario configurare questi livelli: Virtual Machine, Virtual Distributed Switch (VDS), switch fisico e data mover VNX.

• Implementare Oracle dNFS.

Oracle ha ottimizzato il suo client dNFS per aumentare il throughput e le prestazioni complessive scavalcando il sistema operativo e l'utilizzo di I/O asincrono. Il client dNFS utilizza Direct I/O per migliorare le prestazioni eliminando i blocchi di ordinamento delle scritture del sistema operativo, scavalcando le cache del SO e riducendo l'utilizzo della CPU di sistema. L'I/O asincrono consente di continuare l'elaborazione delle letture e delle scritture senza le attese associate in genere ai blocchi di ordinamento delle scritture. Altri vantaggi sono: • High Availability: dNFS supporta fino a quattro percorsi di rete paralleli al sistema NAS e

bilancia automaticamente il carico di I/O tra tutti i percorsi di rete disponibili. In caso di errore della rete, qualsiasi pacchetto perso verrà rinviato automaticamente nei percorsi di rete integri.

• Facilità di amministrazione: dNFS consente al DBA Oracle di configurare il client facilmente sia per la singola istanza sia per Oracle RAC.

Altre raccomandazioni sullo storage NAS:

• Se si utilizzano più di otto volumi NFS, esaminare l'heap di rete e le dimensioni massime TCP/IP VMware. Le opzioni NFS avanzate vengono definite nella knowledgebase VMware, articolo 1007909.

iSCSI Il protocollo Internet Small Computer System Interface (iSCSI) utilizza TCP per il trasporto dei pacchetti SCSI per la connessione ai block device sulla rete. I vantaggi offerti sono l'uso della rete esistente e di hardware con costi inferiori (schede di rete) risultando relativamente meno costoso rispetto ad altre soluzioni. Con il protocollo iSCSI è possibile aggiungere facilmente ulteriore larghezza di banda tramite l'aggregazione di porte e collegando i link per assicurare la scalabilità in linea con carichi di lavoro crescenti. Le aziende possono scegliere tra due implementazioni di questo protocollo: • iSCSI software: l'elaborazione del traffico iSCSI su TCP/IP viene eseguita dalle CPU dei

server. L'elaborazione server del traffico iSCSI può richiedere un utilizzo intenso del processore, soprattutto quando i percorsi di rete sono sottoscritti in eccesso. Il comportamento del TCP/IP su percorsi di rete sottoscritti in eccesso è eliminare i pacchetti e inviarli di nuovo determinando un ulteriore utilizzo del processore del server.

• iSCSI assistito da hardware: TCP/IP Offload Engine o TOE è un chip nella scheda di rete che elabora il traffico iSCSI. Il percorso consigliato per supportare il protocollo iSCSI è l'offload di TCP/IP dai processori dei server al chip TOE nella scheda di rete.

Best practice per la virtualizzazione di Oracle 15

Linee guida su iSCSI

• Isolare il traffico iSCSI: come già accennato, la sottoscrizione eccessiva dei percorsi di rete causerà l'eliminazione dei pacchetti di TCP/IP con conseguente congestione e impatto sulle prestazioni. La progettazione di una rete dedicata per il traffico iSCSI consente di ridurre, se non eliminare l'impatto del traffico di rete non di produzione che potrebbe causare una congestione.

• Fast Ethernet: utilizzare l'Ethernet più veloce supportato sia per VMware vSphere sia per lo storage EMC.

• Frame Jumbo: implementare i frame jumbo implica cambiare la dimensione MTU predefinita da 1500 in 9000. Una MTU maggiore aumenta il throughput, genera un numero inferiore di pacchetti di rete di dimensioni maggiori e può ridurre l'utilizzo della CPU del server. Per supportare i frame jumbo, è necessario supportare questi livelli: Virtual Machine, Virtual Distributed Switch (VDS), switch fisico e data mover VNX.

• Utilizzare la policy Round Robin: sia gli storage array VNX di nuova generazione sia VMAX supportano una vera NMP active-active per l'uso con la policy PSP Round Robin. La generazione precedente di storage array VNX supporta il percorso pseudo active-active (ALUA), ossia viene applicata una PSP fissa: l'I/O verrà trasferito utilizzando il percorso ottimizzato attivo.

• Per il tuning dell'applicazione VNX OE for Block mediante VMware ESX Server con il datastore iSCSI, fare riferimento alla knowledgebase VMware, articolo 1002598: ESX/ESXi hosts might experience read or write performance issues with certain storage arrays.[14]

Provisioning dello storage in vSphere VMware consente di definire la storage architecture in modo flessibile. Tra i metodi più comuni vi sono VMFS e RDM. Ogni metodo di storage offre punti di forza specifici e la scelta può risultare complessa. Molti clienti iniziano esaminando la modalità di utilizzo attuale dello storage, ad esempio, esaminando le procedure per il provisioning dei database utilizzando cloni e snapshot basati su storage. Un'idea chiara delle funzionalità di storage utilizzate attualmente dai team di DBA è utile per decidere se adottare il metodo RDM o VMFS. Tradizionalmente, il metodo RDM era leggermente più veloce rispetto a VMFS, ma attualmente c'è poca o nessuna differenza tra i due metodi a livello di prestazioni. Di seguito esaminiamo i metodi VMFS e RDM e forniamo le linee guida utili per la selezione del tipo di storage migliore per ogni business.

Valori massimi dello storage vSphere 5.5 I valori massimi dello storage vSphere sono importanti ai fini della progettazione dell'infrastruttura di storage e sono un argomento frequente di discussione con i clienti. Sono inclusi alcuni valori massimi che possono essere applicati alla virtualizzazione dello storage di database. Esaminare il documento VMware Configuration Maximums vSphere 5.5 per un elenco completo dei valori massimi supportati da vSphere 5.5. • LUN iSCSI per server: 256

• LUN Fibre Channel per server: 256

• Mount NFS per server: 256

• Volumi VMFS per host: 256

• Dischi virtuali per host: 2.048

Best practice per la virtualizzazione di Oracle 16

VMFS VMFS è l'implementazione VMware di un file system clusterizzato con prestazioni elevate ottimizzato per le virtual machine. La struttura clusterizzata indica in VMware che più VM possono leggere e scrivere nello stesso datastore VMFS semplificando la gestione e il consolidamento dello storage. VMFS funziona su qualsiasi protocollo basato su SCSI inclusi Fibre Channel, Fibre Channel over Ethernet e iSCSI. La scelta di VMFS consente ai DBA Oracle di accedere a funzionalità come Distributed Resource Schedule (DRS), High Availability (HA), vMotion e Storage vMotion. È persino possibile utilizzare snapshot basate su storage per clonare i datastore VMFS, come mostrato nella EMC Proven Solution Upgrade to Oracle Database 12c with Oracle Multitenant Option (Pluggable Database). In questa soluzione vengono fornite istruzioni dettagliate sul processo di clonazione del datastore VMFS mediante VMAX TimeFinder™ e di utilizzo di gruppi di provisioning automatico per configurare l'accesso ESXi all'host di destinazione. Si consiglia la lettura alle aziende che utilizzano VMFS con i database Oracle. Di seguito sono riportate le considerazioni per determinare se il metodo VMFS è adatto per virtualizzare i database Oracle. • Consolidamento dello storage: i volumi VMFS possono ospitare una o più virtual

machine, tuttavia i requisiti di storage dei database Oracle tendono a essere più elevati rispetto a quelli di altre applicazioni e gli utenti di applicazioni si aspettano anche elevati livelli di servizi; pertanto il consolidamento dello storage è minore per quanto riguarda i database. I DBA Oracle devono collaborare a stretto contatto con gli Storage Administrator e gli amministratori VMware per convalidare che l'architettura del layout di storage VMFS sia stata definita in modo da fornire le prestazioni previste e rispettare gli SLA delle applicazioni per il business. In genere, la produzione deve includere un datastore VMFS dedicato per assicurare prestazioni prevedibili e i database meno critici, come quelli in sviluppo, sono candidati per un maggiore consolidamento.

• Facilità di amministrazione: in genere, gli amministratori VMware considerano la gestione dei datastore VMFS più facile rispetto a RDM. Ad esempio, l'aggiunta di una virtual machine a un datastore VMFS è un compito facile che può essere completato molto rapidamente.

• Supporto per la disabilitazione della protezione da scrittura simultanea: si consiglia di consultare la knowledgebase VMware, articolo 1034165: Disabling simultaneous write protection provided by VMFS using the multi-writer flag, specialmente nelle implementazioni di Oracle Real Application Clusters (RAC), che offre una panoramica tecnica dei casi in cui utilizzare questa funzione. Per impostazione predefinita più virtual machine nello stesso datastore non possono scrivere lo stesso file vmdk, poiché questa azione potrebbe causare il danneggiamento dei dati. Per soluzioni di clustering come Oracle RAC che mantengono la coerenza delle scritture, si consiglia di disabilitare la protezione dalla scrittura simultanea. Per effettuare questa operazione, il numero massimo di server fisici supportati è 8. Tenere conto di alcune avvertenze per la disattivazione della protezione dalla scrittura simultanea poiché non sono supportate le funzionalità di VMware riportate di seguito:

la maggior parte delle snapshot e di altre azioni che utilizzano snapshot;[5]

− la clonazione di una virtual machine su uno o più dischi configurati con il flag multi-scrittura;[5]

− Storage vMotion;[5]

− Change Block Tracking (CBT);[5]

Best practice per la virtualizzazione di Oracle 17

− la sospensione di una virtual machine;[5]

− l'hot-extending di un disco virtuale.[5]

• Oracle RAC Node Live Migration: l'uso di VMFS significa che il DBA può utilizzare vMotion per effettuare la migrazione senza interruzioni della VM da un server a un altro. Si consiglia vivamente ai DBA interessati alla convalida di terze parti di leggere un documento recente di Principled Technologies, Demostrating vMotion Capabilities with Oracle RAC on VMware vSphere, che dimostra come l'uso di vMotion con i nodi RAC utilizzati in modo intenso non comporta la perdita di dati e può essere eseguito molto rapidamente. Nello studio, il completamento di vMotion di tutti i tre nodi RAC con utilizzo elevato ha richiesto solo 180 secondi con un impatto contenuto sulle prestazioni dei database.

• Flash Read Cache (vFRC): una nuova funzionalità di vSphere 5.5 è Flash Read Cache che consente la gestione del Flash storage presente sul server. Ad esempio, le schede XtremSF di EMC sono una soluzione di storage basata su server per accelerare i carichi di lavoro, come i database Oracle, e funzionano con vFRC. Al momento della stesura del presente documento, la Compatibility Guide di VMware indica cinque schede EMC XtremSF compatibili con vFRC su ESXi 5.5 U1, inclusa la scheda PCI SSD da 1,4 TB. Nello studio recente di Principled Technologies, VMware vSphere 5.5 with vSphere Flash Read Cache: Performance with Oracle Database 12c, un carico di lavoro Online Analytical Processing (OLAP) molto esigente è stato utilizzato con Oracle 12C, server blade Cisco UCS e la scheda PCIe SSD. I risultati hanno mostrato un miglioramento delle prestazioni del carico di lavoro OLAP pari al 14% utilizzando vFRC e dopo l'uso di vMotion la cache vFRC è risultata pronta piuttosto rapidamente.

Linee guida su VMFS Di seguito sono riportate alcune considerazioni per l'implementazione di VMFS con Oracle. • Progettare l'architettura del datastore VMFS per le prestazioni, non per il consolidamento.

• Virtual Storage Integrator (VSI) è un plug-in VMware vCenter che semplifica la gestione dello storage virtualizzato abilitando la capacità di mapping delle virtual machine allo storage e il self-provisioning dello storage. EMC fornisce gratuitamente il plug-in VSI.

• Distribuire uniformemente le LUN/i dischi e utilizzare uno strumento gratuito come Oracle Workload Profile Assessment per facilitare la progettazione del layout dello storage.

RDM fisico

Raw Device Mapping (RDM) è un metodo utilizzato da VMware per connettere, mediante un file di mapping, la virtual machine allo storage device fisico. Se si ha familiarità con Unix o Linux, considerare il file di mapping come un link simbolico a un file che fornisce la risoluzione dell'indirizzo alla Logical Unit Number (LUN). Il file di mapping permette un nome descrittivo per un mapped device. Ad esempio, non è necessario fare riferimento al device con il device name, ma è possibile utilizzare il nome del file di mapping, ad esempio:

/vmfs/oracle/oradata/finprod01/finProdDisk.vmdk

Best practice per la virtualizzazione di Oracle 18

In modalità di compatibilità fisica viene utilizzata la virtualizzazione SCSI minima. VMkernel passa tutti i comandi SCSI al device, tranne per REPORT LUN. Il comando REPORT LUN viene virtualizzato perché VMkernel deve isolare la LUN per la virtual machine. Ad eccezione del comando REPORT LUN, tutti i comandi SCSI vengono trasferiti direttamente al device rendendo l'uso di pRDM una considerazione chiave per i dipartimenti IT che fanno affidamento sulle attività di storage come cloni, snapshot, replica e backup. In genere, i DBA utilizzano le funzionalità di storage per eseguire rapidamente il provisioning delle copie dei database di produzione e per la resilienza. La modifica delle procedure di storage può richiedere un investimento notevole in termini di tempo e pertanto l'uso di pRDM consente sia la virtualizzazione sia la conservazione delle procedure in base alle funzionalità di storage. Di seguito sono riportate le considerazioni per determinare se il metodo pRDM è adatto alla virtualizzazione dei database Oracle. • pRDM consente all'IT l'uso continuato delle funzionalità di storage array come

cloni, snapshot, replica e backup senza che sia necessario apportare modifiche.

• pRDM consente le migrazioni da virtuale a fisico e da fisico a virtuale. Un database Oracle può pertanto passare molto rapidamente e con impegno minimo alla virtualizzazione VMware in una migrazione da fisico a virtuale mediante pRDM. Se necessario è vero il contrario, ossia il database Oracle può passare molto rapidamente e con impegno minimo dalla virtualizzazione VMware al fisico disabilitando l'uso dei file di mapping.

• pRDM può essere migrato in vRDM: consultare la knowledgebase VMware, articolo 1006599: "Switching a raw data mapping between physical and virtual compatibility modes in ESX/ESXi".

• pRDM può essere migrato in VMDK mediante una cold migration se l'obiettivo finale è avere il database in un datastore VMFS.

• vMotion richiede ID LUN coerenti per tutti gli RDM in tutti gli host ESXi partecipanti; in caso contrario vMotion non sarà disponibile.[6]

• High Availability VMware è supportata con pRDM.

I vantaggi indicati di seguito si applicano alle modalità di compatibilità fisica e di compatibilità virtuale. • Il mapping 1 a 1 tra virtual machine e LUN significa che le altre virtual machine

non impattano sugli IOPS.

• Nomi descrittivi permanenti: come accennato, il file di mapping consente di utilizzare un nome descrittivo per il device name.

• Dynamic Name Resolution: la configurazione fisica degli storage device può cambiare, ma i cambiamenti sono trasparenti perché i file VMFS risolvono automaticamente il mapping ai device SCSI.

• Distributed File Locking: Oracle RAC e le altre soluzioni di clustering richiedono che due o più virtual machine accedano alle stesse LUN. Con il blocco dei file distribuiti su un device mapping raw, due o più virtual machine accedono alla stessa LUN in modo sicuro.

Best practice per la virtualizzazione di Oracle 19

Limitazioni della modalità di compatibilità fisica: • L'uso di snapshot VMware non è supportato, tuttavia i cloni e le snapshot basati sullo

storage array funzionano.

• La funzionalità Flash Read Cache (vFRC) non è supportata, ma XtremCache funziona.

Virtual RDM In modalità di compatibilità virtuale, VMkernel virtualizza quasi tutti i comandi SCSI inviando solo i comandi di LETTURA e SCRITTURA al mapped device.[6] Poiché la maggior parte dei comandi SCSI è stata virtualizzata con il masking delle caratteristiche hardware della LUN, il mapped device è esattamente lo stesso di un file di disco virtuale in un volume VMFS. La modalità di compatibilità virtuale offre quasi tutti gli stessi vantaggi di VMFS. Di seguito esaminiamo alcuni vantaggi offerti da vRDM evidenziando le differenze tra i metodi vRDM e pRDM. • L'uso di vMotion dei nodi RAC e dei database Oracle (richiede che sia impostata

la disabilitazione del flag di protezione dalla scrittura simultanea).

• Le snapshot VMware sono supportate.

• La documentazione sulla migrazione vRDM (virtual-to-physical) è in conflitto. Ad esempio, in questa discussione su VMware vSphere Storage "pRDM vs vRDM virtual/physical interchangeability", i clienti hanno testato e verificato che il trasferimento da vRDM a host fisici funziona.[7] Si raccomanda di utilizzare un ticket di supporto di VMware per verificare che sia disponibile il supporto.

• La funzionalità Flash Read Cache (vFRC) è supportata.

Nel confronto tra vRDM e pRDM, il punto decisivo è se conservare le procedure degli storage array per la gestione dei database o adottare lo storage management basato sulla virtualizzazione. Come si può notare nella tabella di seguito, vRDM e pRDM offrono entrambi funzionalità di snapshot con la differenza che con vRDM viene utilizzato vSphere e con pRDM viene utilizzato lo storage array. Le considerazioni sulle prestazioni sono simili perché un team di virtualizzazione utilizzerebbe vFRC con vRDM e il team di storage utilizzerebbe XtremCache con pRDM. In genere, la scelta dei metodi vRDM, pRDM e VMFS dipende dalle esigenze specifiche del business e del team di DBA perché la scelta non implica una perdita significativa di funzionalità.

vRDM pRDM Note

Trasferimento di comandi SCSI NO SÌ (Note) Tranne REPORT LUN Disabilitazione della protezione da scrittura simultanea richiesta per Oracle RAC

SÌ NO

Supporto vCenter SÌ SÌ Blocco distribuito: SÌ SÌ Snapshot, cloni, replica storage array SÌ SÌ Interscambiabilità virtuale-fisico: SÌ (Note) SÌ Convalida del cliente, nessun

articolo della knowledgebase VMware di supporto

Snapshot VMware supportate SÌ NO

Best practice per la virtualizzazione di Oracle 20

vRDM pRDM Note

Supporto VMware Flash Read Cache SÌ NO Supporto XtremCache NO (Note) SÌ L'implementazione vRDM deve

utilizzare vFRC vMotion supportato SÌ SÌ Richiede ID LUN coerenti per

tutti gli RDM in tutti gli host ESXi partecipanti

VMware High Availability SÌ SÌ Tabella 1: confronto tra la modalità di compatibilità virtuale (vRDM) e fisica (pRDM)

Best practice EMC per la virtualizzazione di Oracle In questa sezione esamineremo brevemente alcune soluzioni chiave di EMC che offrono vantaggi in termini di prestazioni, consolidamento, facilità di provisioning, gestibilità, availability nella virtualizzazione di Oracle.

Prestazioni La virtualizzazione dei database Oracle migliora la flessibilità, la gestibilità e il consolidamento, ma le prestazioni sono basate principalmente su tecnologie che velocizzano l'accesso ai dati. In un recente studio IOUG, Efficiency Isn’t Enough: Data Center Lead the Drive To Innovation, gli autori hanno discusso su domande come "Quali tipi di attività di gestione di database hanno impegnato la maggior parte del tempo degli intervistati ogni settimana? Le attività su cui i data manager impiegano più tempo sono la diagnosi e il tuning delle prestazioni, seguite dal mantenimento dell'uptime e della availability."[8] In fase di virtualizzazione dei database, una delle preoccupazioni principali dei DBA è dover aggiungere altro tempo per il tuning delle prestazioni e la diagnosi. Questa condizione non si verifica se il DBA collabora a stretto contatto con gli amministratori VMware e gli Storage Administrator per definire l'architettura per le prestazioni. EMC dispone di diverse tecnologie collaudate per accelerare i database che sono totalmente trasparenti per il DBA e che non richiedono ulteriore overhead di gestione, ma che possono ridurre al minimo la necessità di ulteriore tuning delle prestazioni. Il modo migliore è iniziare con una tecnologia collaudata da anni e che dipende dallo storage EMC in uso: Fully Automated Storage Tiering Virtual Pool (FAST VP) è disponibile immediatamente.

FAST VP Prima del tiering automatizzato, gli storage array erano configurati in genere come storage tier singolo. Ad esempio, uno storage array potrebbe avere tutte le unità disco Fibre Channel 10K RPM. Le prestazioni erano in gran parte determinate dal numero di unità disco e dal tipo di RAID (Redundant Array of independent Disks) per il supporto dei database. La definizione della storage architecture era un evento one-time e il DBA doveva ottenere le prestazioni massime da questo modello di storage deterministico. Le sfide includevano la gestione manuale dei file di dati, la risoluzione dei problemi di disallineamento dei dati e l'ottimizzazione delle ricerche SQL di scarsa qualità per migliorare le prestazioni del database. Fortunatamente, FAST VP trasforma la complessità insita nella gestione manuale del database di storage in una soluzione completamente automatizzata che identifica i dati molto attivi e li trasferisce nello storage tier specificato più rapido.

Best practice per la virtualizzazione di Oracle 21

Negli attuali storage array, le SSD, note anche come Flash drive ed Enterprise Flash Drive (EFD), sono il tier più veloce delle unità. Subito sotto le unità EFD ci sono tutte le unità con velocità di rotazione di 10.000 e 15.000 RPM, che sono classificate come FC e che possono essere combinate in un singolo tier. [9] In modo analogo, tutte le unità con velocità di rotazione di 7.200 RPM o inferiore sono classificate come SATA.[9] Il termine storage tier indica un gruppo di risorse simili (EFD, FC o SATA) con le stesse caratteristiche, ad esempio il tipo di protezione RAID (RAID 1, 5, 6 o senza protezione). Uno storage tier VMAX FAST VP viene utilizzato per il trasferimento di dati, noto come granularità di riposizionamento, con dimensioni di 768 KB o più spesso 7.680 KB (o 7,5 MB) tra i tier VP. Nella nuova generazione di storage array VNX OE, la granularità di riposizionamento è stata ridotta da 1 GB a 256 MB per aumentare l'efficienza di FAST VP e ridurre l'overhead dello spazio di storage.[10] La configurazione FAST VP è molto flessibile grazie a opzioni come le policy FAST che consentono allo Storage Administrator di impostare le regole di utilizzo che forniscono linee guida per il posizionamento dei dati. Si consiglia di leggere le numerose documentazioni sulle EMC Proven Solutions disponibili sulla community Everything Oracle at EMC e le note tecniche per FAST VP su Symmetrix VMAX e VNX perché descrivono in dettaglio l'installazione, il funzionamento e la configurazione di FAST VP. Di seguito sono elencate alcune linee guida sull'utilizzo di FAST VP con i database Oracle, ma, a differenza di altre raccomandazioni, si consiglia vivamente di collaborare con il tecnico EMC per la convalida della configurazione. Ogni database ha un profilo del carico di lavoro e un modello di I/O unici e pertanto queste linee guida sono il punto di partenza della collaborazione con un tecnico EMC per personalizzare la configurazione FAST VP. • Utilizzare Oracle Workload Profile Assessment (OWPA): è uno strumento, disponibile

gratuitamente per i clienti, utilizzato dai tecnici EMC per analizzare i report AWR di database. Questo approccio basato su prove ricava le statistiche dai report AWR ed è utile per determinare il numero e i tipi di unità da utilizzare nei pool FAST.

• Usare DBClassify: è un servizio per DBA e Storage Administrator in cui un tecnico EMC installa DBClassify, quindi collabora con due gruppi per mostrare, grazie a un approccio basato su prove, come FAST VP migliorerà le prestazioni. La distribuzione include raccomandazioni dettagliate per l'ottimizzazione del database e dell'infrastruttura di storage, accelerando l'adozione di storage tiering intelligente nei database di produzione e la formazione del team per l'uso continuato di DBClassify.

• Tier Advisor: è una funzione di storage utile per determinare il numero di ciascun tipo di unità eventualmente necessario.[11]

• Nella maggior parte delle Oracle Proven Solutions, sono stati utilizzati RAID 5 e RAID 10:

RAID 5 offre prestazioni in scrittura e resilienza valide con un overhead della capacità del 12,5%. Nei nostri documenti utilizziamo RAID 5 per i file di dati, CDB (applicabile a Oracle 12c), i file temp e FRA.

RAID 10 offre prestazioni in scrittura e resilienza superiori rispetto a RAID 5 con un overhead della capacità del 50%. Nei nostri documenti utilizziamo RAID 10 per i registri REDO, i log di archivio e i file CRS.

Non è consigliabile utilizzare RAID 6 a causa dell'overhead in scrittura, tranne per l'uso con il tier NL-SAS e SATA in cui può risiedere la maggior parte dei dati dei database e si ritiene necessaria una doppia protezione dei dischi. Prendere in considerazione di collocare i file FRA, i log di archivio e i backup RMAN su storage pool RAID 6.

Best practice per la virtualizzazione di Oracle 22

• Best practice generali su VMAX per FAST VP:

Le raccomandazioni RAID cambiano in base al modello VMAX, ad esempio per VMAX 10K (959) e 20K il numero ottimale di EFD è 8 per ciascun engine.[11]

Per VMAX 10K (987) o 40K il numero ottimale di EFD è 16 per ciascun engine.[11]

• Best practice generali su VNX per FAST VP:

RAID 5 in una configurazione 4 +1 è ottimale per le prestazioni ed è stata utilizzata in numerose Oracle Proven Solutions.[12]

RAID 10 in una configurazione 4 + 4 è ottimale per le prestazioni e nella nostra documentazione abbiamo anche utilizzato RAID 10 in una configurazione 2 + 2.[12]

FAST Cache FAST Cache è una funzionalità esclusiva della serie EMC VNX di storage array. Ai fini di questa analisi ci concentreremo su FAST Cache multi-core nella nuova generazione di storage array VNX, ma gli utenti interessati alla differenza tra l'implementazione originale e i vantaggi a livello di prestazioni offerti dalla nuova Fast Cache multi-core, possono leggere i blog "Part 1: Next Generation VNX – Oracle Database Storage Performance" e "EMC Multicore FAST Cache A Detailed Review". [13] FAST Cache multi-core richiede il posizionamento di Flash drive tra la cache primaria DRAM dello storage processor e le unità disco. Se richieste di I/O in entrata vengono servite dalla cache DRAM primaria, per assicurare prestazioni più veloci, si ottiene un read hit, mentre se la cache DRAM non è in grado di servire la richiesta di I/O si otterrà una read miss e FAST Cache multi-core servirà la richiesta utilizzando le Flash drive. Nel caso di una read miss, la richiesta di I/O verrà soddisfatta dalle unità disco e, in caso di utilizzo frequente, verrà quindi promossa nella cache DRAM e nei tier di prestazioni di FAST Cache. FAST VP e FAST Cache sono complementari e si integrano per offrire vantaggi all'intero storage array. Generalmente, FAST Cache dovrebbe essere posizionata per applicazioni con I/O casuali con burst frequenti poiché la maggior parte delle richieste di I/O di lettura e scrittura verrà servita da FAST Cache, migliorando le prestazioni e riducendo il carico di lavoro sui dischi rigidi back-end. Alcuni attributi che rendono FAST Cache ideale per i database sono la granularità di riposizionamento di 64 KB, il monitoraggio in tempo reale per determinare i dati che devono essere promossi e il fatto che non esistono cicli di riposizionamento associati alla promozione dei dati più utilizzati nella FAST Cache multi-core. Le chiamate di IO superiori a 128 KB superano il limite di granularità e non vengono promosse nella FAST Cache. FAST VP su VNX trasferisce i dati più utilizzati mediante la granularità di riposizionamento di 256 MB nelle Flash drive, per fornire un ulteriore livello di prestazioni prima di dover soddisfare le richieste di servizi dalle unità disco ad alta capacità più lente. In sintesi, utilizzare FAST Cache per cambiare dinamicamente i modelli di dati con frequenti burst di I/O e FAST VP per ottimizzare l'efficienza e l'utilizzo del disco. Se si dispone di un numero limitato di Flash drive e si ha la possibilità di utilizzarle per FAST VP o FAST Cache multi-core, EMC consiglia di utilizzare le unità ottimizzate FAST Cache per creare FAST Cache multi-core.[13] Di seguito sono elencate alcune linee guida sull'utilizzo di FAST Cache con i database Oracle, ma, a differenza di altre raccomandazioni, si consiglia vivamente di collaborare con il tecnico di EMC per la convalida della configurazione. • Gli storage array VNX utilizzano Service Processor (SP) e l'I/O deve essere

bilanciato nell'SP per prestazioni ottimali.

Best practice per la virtualizzazione di Oracle 23

• Distribuire le Flash drive tra tutti i bus disponibili.

• Usare Oracle Workload Profile Assessment per il dimensionamento di FAST Cache per i database Oracle.

• Se la dimensione del dataset attivo è sconosciuta, dimensionare FAST Cache su un valore pari al 5% della capacità e regolare il valore dopo la valutazione.[14]

• Evitare di attivare FAST Cache per questi carichi di lavoro:

carico di lavoro principalmente sequenziale;

file di registro Redo Oracle;

file di registro di archivio Oracle;

carico di lavoro I/O di block di grandi dimensioni.

Adattatori ParaVirtual SCSI (PVSCSI) Come suggerisce il nome, l'adattatore Paravirtual SCSI utilizza la paravirtualizzazione che permette al kernel del SO di comunicare direttamente con il livello di virtualizzazione, in questo caso l'hypervisor ESXi. Il primo passo importante nella creazione di una virtual machine è pertanto quello di selezionare il sistema operativo poiché l'adattatore PVSCSI funziona solo per sistemi operativi come Windows Server, Red Hat Enterprise Linux e alcuni altri. Per un elenco dei sistemi operativi che supportano le schede PVSCSI, fare riferimento alla knowledgebase VMware, articolo 1010398: "Configuring disks to use VMware Paravirtual SCSI (PVSCSI) adapters". I vantaggi della paravirtualizzazione sono prestazioni più elevate e minore utilizzo della CPU. Nel white paper tecnico "Achieving a Million I/O Operations per Second from a Single VMware vSphere 5.0 Host", la scheda PVSCSI assicurava in media un numero maggiore di IOPS con latenze inferiori rispetto alla scheda LSI. Nella figura 5 del documento "CPU Cost of an I/O Operation with LSI Logic SAS and PVSCSI Adapters", il risultato è stato un throughput migliore dell'8% con una riduzione dei costi della CPU del 10%. Di seguito sono riportate alcune linee guida sull'uso delle schede PVSCSI. • Utilizzare l'adattatore PVSCSI per carichi di lavoro medio-grandi che richiedono

un throughput maggiore, latenza inferiore e un costo ridotto delle CPU.

• Se la virtual machine sta eseguendo un numero contenuto di IOPS, non è necessario cambiare l'adattatore parallelo BusLogic o LSI predefinito.

Se si utilizza l'adattatore SCSI virtuale parallelo BusLogic e un sistema operativo guest Windows, prendere in considerazione l'uso del driver BusLogic personalizzato incluso nel pacchetto VMware Tools.[20]

• La profondità della coda dell'unità SCSI può incidere sulle prestazioni dei dischi. Ad esempio, nel white paper "Microsoft SQL server Best Practices and design Guidelines for EMC Storage" è stato evidenziato come sia vantaggiosa l'impostazione della profondità della coda di HBA su 64 (il valore predefinito è 32 in EXSi 5.0 e 64 in ESXi 5.1 e 5.5).[21]

Best practice per la virtualizzazione di Oracle 24

Consolidamento Le tecnologie di accelerazione dello storage EMC, come FAST VP e FAST Cache, combinate con la virtualizzazione VMware, diminuiscono il numero di unità disco e processori offrendo un valore complessivo al business grazie al consolidamento. Iniziando la discussione dalla parte superiore dello stack, i principi generali di consolidamento della virtualizzazione implicano l'uso di numero inferiore di processori più veloci e un maggiore utilizzo del processore mediante il consolidamento delle virtual machine in un numero inferiore di server. Nell'articolo Wikibon, Virtualization of Oracle Evolves to Best Practices for Production Systems, l'autore confronta il costo di implementazione di un database Oracle tradizionale con quelli di un'infrastruttura di database ottimizzata. La differenza principale tra l'implementazione di database Oracle tradizionale e l'infrastruttura di database ottimizzata è la virtualizzazione e lo storage primario con latenza ottimizzata. L'aspetto più interessante è che l'autore collega l'importanza del tempo di attesa di IO della CPU alla riduzione del numero di IO e la latenza di IO migliorando le letture e scritture fisiche nello storage. Il design di storage ottimale è quello in cui lo storage non è un collo di bottiglia o nei primi cinque eventi di attesa indicato nei report AWR. Ad esempio, se il tempo del DB è l'evento di attesa superiore, questo significa che una parte notevole dell'elaborazione è stata utilizzata con sessioni in esecuzione vicino al 100% della CPU. Il tempo del DB è definito da Oracle come la quantità di tempo trascorso (in microsecondi) eseguendo chiamate a livello utente. Il risultato principale in questo articolo è stato che il costo aggiuntivo dei miglioramenti ai server e allo storage aumentava il costo di ciascun core da $ 27.716/core a $ 32,661/core con un incremento del 17,8%. Tuttavia, come mostrato nella figura 3, il costo complessivo è notevolmente ridotto perché il numero di core può essere diminuito da 192 a 120 con una riduzione del 37,5%".[15] L'adozione di infrastrutture convergenti ottimizzate come VCE Vblock™ e altre ha permesso di creare soluzioni che offrono prestazioni estreme per un maggiore consolidamento e risparmio sui costi per il business. In base a Wikibon, alcune considerazioni sul consolidamento sono: • I server sono diventati abbastanza potenti e il software di gestione della

virtualizzazione abbastanza stabile che la best practice per l'implementazione dei database Oracle x86 è creare un'infrastruttura di storage e server virtualizzata e ottimizzata per ogni livello di servizio Oracle necessario". [15]

• "Le operazioni IT devono assicurare che vengano utilizzati server di qualità superiore per i servizi di database".

• "...la tecnologia Flash viene utilizzata in modo aggressivo per ridurre al minimo la varianza e i tempi delle risposte di I/O".

• Utilizzando VMware per creare cluster dedicati per Oracle ed evitare che le virtual machine vengano trasferite su server senza licenza, gli audit mostreranno probabilmente che l'IT ha gestito le licenze senza incorrere in ulteriori costi.

Semplicità del provisioning Il percorso di virtualizzazione offre in parte l'opportunità ai team di DBA di automatizzare le procedure manuali per un provisioning più rapido. Il provisioning manuale dei database è un processo complesso che potrebbe impegnare il team di DBA per diversi giorni o settimane. Esamineremo le soluzioni che automatizzano le attività manuali consentendo di accelerare il provisioning dei database. I componenti di seguito vengono utilizzati dall'IT EMC per l'architettura DBaaS.

Best practice per la virtualizzazione di Oracle 25

vCloud Automation Center VMware vCloud Automation Center (vCAC) fornisce un portale sicuro e un catalogo self-service agli utenti autorizzati, come gli amministratori, gli utenti business e gli sviluppatori mediante Microsoft Active Directory. Per usare un'analogia, vCAC consente agli utenti business di fare acquisti, come si farebbe su Internet, per i servizi IT interni. Ad esempio, uno sviluppatore Oracle che inizia un nuovo progetto necessita di un nuovo database. Prima di vCAC, questo processo richiedeva molto tempo perché lo sviluppatore doveva presentare una richiesta per un nuovo database e, probabilmente, discutere con il team di DBA sull'ambito, la tempistica, i requisiti di supporto e il livello di patch. Non era raro che questo processo di provisioning richiedesse una settimana o più perché l'elaborazione della richiesta necessitava di un intervento di pianificazione e manuale. vCAC cambia il provisioning delle applicazioni e dei database presentando allo sviluppatore e ad altri utenti un portale self-service di servizi IT utilizzabili con l'automazione integrata, riducendo notevolmente il tempo di provisioning. I cataloghi vengono raggruppati in modo logico per categorie di servizio, ossia le offerte correlate sono raggruppate insieme. L'uso di queste categorie velocizza la navigazione e la selezione poiché l'utente business individua rapidamente il servizio di cui necessita. È anche possibile esporre i costi relativi all'ordinazione di servizi IT e una procedura di approvazione in modo che i proprietari delle applicazioni siano in grado di gestire i servizi IP dei team. Ad esempio, lo sviluppatore seleziona una voce di catalogo, "Database Oracle di medie dimensioni", costituita da due CPU, 8 GB di RAM e 500 GB di capacità di storage array e il responsabile riceve un'e-mail automatizzata che indica in dettaglio la richiesta, il costo del build iniziale e i costi mensili ricorrenti. Per informazioni più dettagliate sull'argomento, si consiglia di leggere il manuale VMware, Foundations and Concepts, vCloud Automation Center 6.0 che offre una panoramica tecnica di questo software di gestione unificata del cloud.

vCenter Orchestrator VMware vCenter Orchestrator (vCO) automatizza le operazioni mediante le attività del Workflow Engine, come il provisioning dei database. La maggior parte dei DBA dispone di procedure nella documentazione sulla installazione, gestione ed esecuzione di backup del database. Ad esempio, in fase di provisioning di una copia della suite Oracle E-Business, alcuni passaggi includono la verifica dei requisiti tecnici, l'esecuzione di AutoConfig nel tier delle applicazioni, la sincronizzazione di appsutil sui nodi nei tier di database, l'esecuzione di AutoConfig sul tier di database e infine la gestione delle informazioni sulle snapshot come alcune attività standard.[16] Molte aziende prevedono inoltre passaggi personalizzati prima del provisioning di una copia della suite E-Business, come il masking dei dati sensibili, la rimozione dei link di database e la disattivazione degli account utente prima di aprire le applicazioni a uno sviluppatore. Mediante vCO, le procedure di provisioning dei DBA possono essere acquisite in un workflow per automatizzare e semplificare la creazione di copie della suite E-Business di produzione. Lo sviluppo di workflow complessi con vCO è un processo di build mediante drag-and-drop che include uno scripting engine per il coordinamento granulare, la gestione e il trattamento delle eccezioni. I principi di un code management valido, come il versioning, il checkpoint e la gestione centralizzata, sono inclusi in vCO e pertanto l'uso di questo strumento è facile per gli amministratori che hanno familiarità con il controllo delle modifiche. È possibile estendere vCenter Orchestrator con facilità in quanto la soluzione include il plug-in Software Development Kit (SDK) e i miglioramenti alle API REST.

Best practice per la virtualizzazione di Oracle 26

Al momento della stesura del presente documento, la versione più recente di vCO è 5.5.1. Si consiglia di leggere il data sheet VMware vCenter Orchestrator, Executing Complex IT Operations Faster and at Lower Cost [17] e la documentazione su vCenter Orchestrator per una panoramica più dettagliata.[18]

Puppet Non è raro per un team di DBA Oracle dover gestire dieci o più copie dei database di produzione e in base al numero di sistemi di produzione differenti di cui il business dispone, questo evento potrebbe implicare team più grandi che gestiscono ben più di un centinaio di database. Questo alto livello di complessità nella gestione di numerosi database rende necessaria l'automazione delle attività per assicurare un'efficiente esecuzione delle attività aziendali. Puppet è una soluzione che centralizza l'automazione delle attività tecniche per l'automazione in più team differenti. Puppet è stato sviluppato per aiutare la community di sysadmin nella costruzione e condivisione di strumenti maturi che evitano la duplicazione di tutte le risorse che risolvono lo stesso problema.[19] Sysadmins utilizza Puppet perché è possibile utilizzare il framework per automatizzare la maggior parte delle attività tecniche eseguite ed è estensibile. Puppet ha un proprio linguaggio personalizzato per eseguire script e condividere la creazione di attività. Per saperne di più su Puppet, si consiglia di leggere la documentazione su Puppet Labs.

Gestibilità EMC dispone di tre soluzioni Oracle per colmare il divario nella gestione dei database sugli storage array VMAX e VNX e due sono gratuite. In questa sezione, esamineremo la soluzione gratuita OEM 12C e Oracle Workload Profile Assessment (OWPA) e tratteremo la distribuzione professionale di DBClassify.

Plug-in OEM 12c per EMC VMAX e VNX L'obiettivo del plug-in OEM 12c è offrire al DBA una vista delle configurazioni di storage, le metriche delle prestazioni e pubblicare report. Il DBA può effettuare analisi di storage insieme ai report AWR dei database per un approccio più globale alla risoluzione dei problemi di prestazioni e pianificazione della crescita di database. Con il plug-in OEM 12c installato, il DBA ha accesso ai dettagli di configurazione dello storage VMAX e VNX e a più di 50 metriche delle prestazioni. Il DBA, dopo alcune analisi, può quindi collaborare a più stretto contatto con lo Storage Administrator. La differenza chiave è che il DBA conoscerà o avrà un'idea chiara del problema grazie all'accesso alle informazioni sullo storage mediante il plug-in OEM 12c. In uno studio di IOUG Efficiency Isn’t Enough: Data Center Lead the Drive to Innovation, è stata evidenziata l'importanza della collaborazione del DBA con lo Storage Administrator: "Gli intervistati concordano pienamente sull'importanza di migliorare la comunicazione tra DBA e Storage Administrator e la produttività nelle organizzazioni. L'80% dei responsabili di dati è d'accordo sulla necessità di migliorare questo aspetto nelle proprie organizzazioni. Più di due quinti sente profondamente questa esigenza e considera questa comunicazione "molto importante".[8]

Best practice per la virtualizzazione di Oracle 27

La collaborazione stretta tra DBA e Storage Administrator può infatti consentire di risparmiare ore, giorni o persino settimane nella risoluzione dei problemi relativi alle prestazioni, eliminando le cosiddette "blame storm". Inoltre il DBA può indirizzare l'analista del supporto in modo più accurato al potenziale problema, quando collabora con il supporto Oracle o EMC. Ad esempio, anche la possibilità di determinare che le prestazioni dello storage non sono la causa di un problema può consentire un notevole risparmio sui tempi.

Figura 4: il plug-in OEM 12 di EMC per VMAX con la schermata principale

Di seguito è riportato un elenco di azioni che è possibile eseguire: • Esaminare graficamente la configurazione dello storage per il database.

• Visualizzare le prestazioni dello storage in tempo reale e storiche è utile per il DBA.

Avviare immediatamente l'analisi delle prestazioni dello storage.

Individuare modelli di prestazioni ricorrenti.

• Impostare gli avvisi di storage, denominati "soglie", per affrontare in modo proattivo le prestazioni e soddisfare gli SLA.

• Condurre AWR di analisi e analisi dello storage in modo indipendente.

• Collaborare in modo più efficace con gli Storage Administrator.

• Utilizzare i report forniti con il plug-in o creare report personalizzati.

• Confrontare lo stato corrente della configurazione dello storage e le configurazioni salvate.

• Usare OEM (per una curva di apprendimento minima).

Best practice per la virtualizzazione di Oracle 28

Di seguito sono riportati alcuni link utili per l'installazione e l'uso del plug-in OEM 12c di EMC: • Scaricare la Guida all'installazione del plug-in da EMC Support

• Scaricare la Cloud Control Documentation Administrator’s Guide

• Oracle Enterprise Manager 12c Extensibility Exchange

• Leggere i diversi blog e le discussioni su Everything Oracle at EMC community

EMC Oracle Workload Profile Assessment: AWR e Statspack Oracle Workload Profile Assessment è un servizio offerto dai team di vendita EMC e dei partner a tutti i clienti EMC e ai potenziali clienti. Il processo comporta la distribuzione di report Statspack o AWR di database al contatto EMC o del partner che, a sua volta, esegue i report mediante uno strumento di analisi online. Dopo l'elaborazione dei report sulle prestazioni dei database, lo strumento OWPA crea un'ampia presentazione Microsoft PowerPoint. Con un set di report AWR o Statspack relativi a diversi giorni, WPA crea una vista di serie temporali del database concentrandosi sulle caratteristiche di IO del database La presentazione include metriche quali IOP in lettura e scrittura, MB/s, dimensioni di IO in lettura e scrittura, rapporto tra lettura e scrittura, latenze IO e molte altre metriche. La collaborazione è la chiave per questo strumento perché l'addetto alla vendita EMC o del partner collabora con il DBA e lo Storage Administrator per concordare sull'analisi dei risultati. In base alla nostra esperienza, i DBA possono essere interessati all'analisi di database, come l'hard parsing, lo switching dei registri REDO e lo Storage Administrator potrebbe essere interessato all'analisi della latenza di IO, gli indicatori XtremCache e EFD. Lo strumento OWPA viene offerto come modalità di collaborazione sulle prestazioni tra i team. Questo è un servizio gratuito e per iniziare sono disponibili qui alcune linee guida: • Un gruppo di 48-96 report Statespack o AWR con un intervallo di campionamento di

30 minuti o 1 ora che acquisisce i timeframe delle attività di picco. Un intervallo di campionamento più breve e un numero maggiore di report sono valori corretti.

• Fare il miglior tentativo per identificare i periodi delle attività di picco per i report: includere le ore di lavoro con maggiore utilizzo e le ore di elaborazione in batch.

• Vengono forniti script di esempio per facilitare la generazione di report AWR in formato testo (i report HTML sono supportati).

Fare clic su questo collegamento per scaricare un file zip con gli script: EMC’s Oracle Workload Profile Assessments blog by William Gaynor.

Lo strumento OWPA offre numerose altre opzioni di interesse per i DBA: hard parsing, switching dei registri REDO, scritture dei registri REDO e byte al secondo, utilizzo CPU host per sistema, utente e attesa di I/O, tablespace più attive nel tempo e tempi di risposta in lettura in millisecondi, un elenco di eventi temporizzati non di I/O che mostrano la latenza e infine le transazioni, le esecuzioni e le conferme al secondo. Inoltre, tutte le metriche vengono rappresentate graficamente in relazione al tempo. Di seguito è riportato un altro link utile per l'uso di Oracle Profile Assessment: • EMC Workload Profile Assessment for Oracle AWR Report/Statspack Gathering Procedures

Instructions.

Best practice per la virtualizzazione di Oracle 29

Questa collaborazione si estende sia al DBA sia allo Storage Administrator poiché il punto focale dello strumento OWPA è analizzare i report di database e selezionare le considerazioni sullo storage. Ad esempio, sono presenti sezioni relative all'analisi della latenza di I/O, gli indicatori storage EFD e XtemCache, i primi tablespace ed eventi temporizzati per l'I/O e non l'I/O. Con un set di report AWR o Statspack relativi a diversi giorni, OWPA costruisce una vista di serie temporali del database.

DBClassify: un'opzione Professional Services DBClassify è uno strumento incluso in un'offerta di servizi utilizzato per monitorare l'I/O di database per gli ambienti Oracle e SQL Server. La differenza è che DB Classify si integra con FAST VP per abilitare il DBA a collaborare con lo Storage Administrator nell'impostazione di policy FAST VP ottimizzate per i database. Vi sono due tipi di offerte di servizi: EMC Database Performance Tiering Assessment ed EMC Database Performance Tiering Residency. La differenza principale tra le due offerte del servizio di residenza e di valutazione è l'ambito: • EMC Database Performance Tiering Assessment è un'analisi delle prestazioni di

database completa di 3 database.

• EMC Database Performance Tiering Residency è limitata solo dal fattore tempo (160 ore in più di 4 settimane o estese in più di 3 mesi).

Il motivo per cui viene distribuito solo come servizio è che il tecnico residente affianca i DBA e gli Storage Administrator per il trasferimento di conoscenze e per accelerare lo storage tiering intelligente negli ambienti di database di produzione. Dopo la valutazione o la residenza, lo strumento DB Classify rimane al cliente e ciò è importante perché i nuovi carichi di lavoro e i cambiamenti nei carichi esistenti implicano che l'analisi continuata sarà fondamentale per sfruttare al meglio FAST VP. Di tutti gli strumenti trattati finora, DB Classify ha il massimo grado di integrazione di storage del database in quanto consente di: • Analizzare il database per formulare raccomandazioni per la creazione di storage group.

Lo Storage Administrator utilizza l'analisi intelligente definire i tier di storage FAST VP.

I DBA utilizzano al meglio i tier di storage per il layout del database.

• Ottimizza le prestazioni dei database al costo più basso.

• Abilita l'influenza della policy del database per gli ambienti FAST VP.

L'aspetto più interessante di DB Classify è la capacità di influenzare il policy engine FAST VP. I DBA possono utilizzare DB Classify per assicurarsi che determinate tabelle o processi vengano allocati nello storage tier più veloce. Ad esempio, se esiste un processo o un report non eseguito frequentemente, ma il suo completamento rapido è critico per il business, il DBA può utilizzare DB Classify per collocare le tabelle di database utilizzate dal report nel tier Flash; in questo modo l'esecuzione del report è molto veloce perché tutte le tabelle di supporto si trovano nel tier di storage più veloce. Questa funzione potrebbe avere un impatto notevole sul business perché spesso è più facile utilizzare hardware per accelerare un processo che avere a disposizione il team di sviluppo che ottimizza il codice. Per ulteriori informazioni, leggere la panoramica "EMC Database Performance Tiering Assessment" o contattare il rappresentante locale di EMC Services.

Best practice per la virtualizzazione di Oracle 30

Availability Mediante EMV VPLEX Metro, il team di DBA può utilizzare Oracle RAC esteso nei data center per assicurare la continuità delle operazioni. Sono disponibili diverse configurazioni VPLEX: • VPLEX Local consente la data mobility trasparente e senza interruzioni su array

eterogenei all'interno del data center.

• VPLEX Metro con AccessAnywhere consente l'accesso a livello di block active-active ai dati in due siti a distanze sincrone con un RTT (Round-Trip Time) pari a 5 ms al massimo.

• VPLEX MetroPoint con RecoverPoint può essere utilizzato per assicurare la protezione continua per tre siti da eventi locali e regionali. Utilizzando MetroPoint, Oracle RAC può rimanere integro in caso di guasto di due siti.

• VPLEX Geo fornisce la availability asincrona in array eterogenei tra due siti con RTTF superiore a 5 millisecondi.

Ai fini di questa discussione, esamineremo VPLEX Metro con Extended Oracle RAC. I team di DBA possono estendere Oracle RAC tra data center per assicurare la continuous availability. Utilizzando VPLEX, l'azienda può federare storage array eterogenei per il mirroring di tutte le scritture su entrambi gli storage array. VPLEX Metro garantisce la fedeltà dell'ordine di scrittura in modo che il riconoscimento di tutte le scritture tra i nodi Oracle RAC avverrà allo stesso modo come quando si utilizza uno storage array. Sia dal punto di vista del DBA che del database, VPLEX Metro è trasparente, ossia non richiede gestione, patching o complessità aggiuntiva. Extended Oracle RAC con VPLEX Metro è in grado di assicurare l'integrità in caso di errore, come ad esempio la perdita di una porta HBA, uno o più server, edificio o sito, disconnessione dalla rete, risultando un'opzione molto resiliente per applicazioni mission-critical che non possono incorrere in tempo di inattività non pianificato. Per una panoramica tecnica della soluzione, si consiglia di leggere "Oracle Real Application Clusters (RAC) on Extended Distance Clusters with EMC VPLEX Metro".

Figura 5: architettura di Oracle Extended RAC con VPLEX Metro

Best practice per la virtualizzazione di Oracle 31

Le linee guida riportate di seguito sono ricavate dal white paper per l'utilizzo di Extended Oracle RAC con VPLEX Metro, già citato in precedenza. • In genere, è preferibile un RTT di 3 ms o meno con i carichi di lavoro di database

moderati anche se la soluzione di continuous availability è certificata per un massimo di 5ms.

• Utilizzare RAID 5 per i file di dati perché questo livello di protezione offre buone prestazioni di scrittura, resilienza e richiede una capacità pari a solo il 12,5% per la protezione.

• Utilizzare RAID 1 per i file di registro REDO in quanto offre prestazioni in scrittura e resilienza migliori rispetto a RAID 5. Si noti che nel documento è stata utilizzata solo la protezione RAID esterna e non il duplexing. Il duplexing aggiunge IO alla configurazione Oracle RAC estesa ed è opportuno prendere in considerazione la protezione esterna, anziché il duplexing. Ad esempio, per una resilienza ancora maggiore, RAID 6 assicura la protezione da molteplici errori delle unità ed è una buona opzione per i registri REDO e i log di archivio.

• Prendere in considerazione l'utilizzo di più gruppi di dischi ASM, ma assicurarsi che si trovino tutti nello stesso consistency group per garantire l'ordine di scrittura. Ad esempio, nel documento sono stati utilizzati gruppi di dischi ASM:

Non esistono linee guida specifiche per il posizionamento dei file temp. L'amministratore del database può includerli con +DATA o separatamente per il monitoraggio.

− È consigliabile creare un gruppo di dischi unico solo per CRS, ad esempio: +GRID. Questo approccio che separa le LUN Clusterware dal database è utile quando si intende utilizzare tecnologie di storage, come i cloni o le snapshot, per creare copie aggiuntive del database a fini di ridestinazione.

Nel documento i gruppi di dischi +DATA, +LOG e +FRA ASM sono stati separati per consentire cloni e snapshot basati su storage da utilizzare per l'offload dei backup dalla produzione. Ad esempio, la clonazione della produzione in un host di backup è vantaggiosa perché l'IO dall'operazione di backup non avrà un impatto sullo stretched cluster Oracle RAC.

• VPLEX non esegue la compressione di rete in modo nativo, ma è possibile utilizzare la compressione su uno switch di rete.

• Creare un volume di logging VPLEX dedicato per ogni cluster Oracle RAC.

Un volume di logging dedicato implica che una risincronizzazione più veloce dell'I/O tra gli storage array dopo un errore.

Utilizzare RAID 1 per i volumi di logging VPLEX.

Configurare almeno 1 GB (preferibilmente un valore maggiore) di spazio di volume di logging per ogni 16 TB di spazio device distribuito.

La virtualizzazione di una singola istanza Oracle e di RAC estende la resilienza dell'architettura VPLEX Metro poiché il DBA può utilizzare l'HA federata. Ad esempio, nel caso di un guasto del sito o del server, i nodi RAC e i database con singola istanza Oracle, vengono riavviati automaticamente nel data center integro utilizzando VMware HA. Stretched Oracle RAC

Best practice per la virtualizzazione di Oracle 32

rimarrebbe in esecuzione, ma i nodi perduti verrebbero riavviati nel sito integro per ridurre al minimo la riduzione delle prestazioni. Al ripristino del sito o del server, è possibile utilizzare VMotion per i nodi RAC e i database virtualizzati senza interruzioni al sito e all'apparecchiatura originale. Per un'analisi dettagliata dell'aggiunta di resilienza e automazione a un'architettura Oracle VPLEX Metro, si consiglia di leggere "Using VPLEX Metro with VMware High Availability and Fault Tolerance for Ultimate Availability".

Community Everything Oracle at EMC La community Everything Oracle at EMC (EO@EMC) è una risorsa in cui i professionisti Oracle si incontrano per discutere, collaborare, scrivere sul blog e scambiarsi idee. Un dato interessante è che numerose best practice esaminate nel documento sono state definite sulla base di discussioni con i clienti e blog nella community EO@EMC. Diventare membro della community è gratuito e facile, come indicato di seguito in Starting with the ECN: Registrati per un account. I membri possono usufruire di vantaggi, tra cui partecipare alle discussioni, porre domande e, se si partecipa attivamente alle attività, è possibile ricevere un invito a entrare nel team EMC Elect. Il team EMC Elect riunisce un gruppo di persone che fanno riferimento alla community, interessate all'uso delle soluzioni EMC e che dimostrano leadership impegnando altre persone nella community. Nella community Oracle sono disponibili tutte le EMC Proven Solutions, i white paper, le architetture di riferimento sviluppate da EMC per Oracle nel corso degli ultimi tre anni. L'autore del presente documento e gli altri autori, tecnici e DBA partecipano alla community. Entrando nella community si potrà comunicare con un'ampia gamma di professionisti di database, virtualizzazione e storage che condividono la passione per la tecnologia. Anche la registrazione una volta offre l'accesso a molte altre community come: Microsoft, SAP, VMware e Isilon. Confidiamo nella tua partecipazione alla community Oracle per condividere eventuali feedback su questo documento e coinvolgere altre persone sull'uso di soluzioni EMC per Oracle.

Conclusioni Questo documento descrive alcune best practice e linee guida sull'implementazione per i database Oracle mediante la virtualizzazione VMware e le EMC Proven Solutions. EMC, VMware e i partner desiderano che la virtualizzazione del percorso Oracle venga implementata con successo e che sia basata su procedure consolidate che assicurino agilità, flessibilità, resilienza e prestazioni superiori. Una volta completata la virtualizzazione delle applicazioni mission-critical, il passo successivo è il modello ITaaS. I DBA Oracle e i proprietari di altre applicazioni sono interessati a questo modello e ad aumentare il livello di automazione del provisioning e delle operazioni di manutenzione. La collaborazione per la creazione di un modello DBaaS implica la combinazione di tutte le best practice, tra cui virtualizzazione, database, storage. Il consolidamento delle best practice può portare alla standardizzazione e infine al provisioning self-service. L'automazione dell'implementazione delle best practice è l'elemento fondamentale per la distribuzione di database e applicazioni.

Best practice per la virtualizzazione di Oracle 33

Bibliografia [1]" Production Oracle Databases reaches 55% and is Growing” Fast di David Floyer, pubblicazione il 17 settembre 2013

[2] Using EMC Symmetrix Storage in VMware vSphere Environments versione 9.0

[3] Report di ESG Lab Validation, "Automated Path Optimization for VMware Virtual Environment", pubblicazione in aprile 2012. Riferimento alla figura 6: confronto delle prestazioni, carico di lavoro con un numero elevato di IOPS

[4] "EMC VNX Scaling Performance for Oracle 12c RAC on VMware vSphere 5.5" pubblicazione a dicembre 2013

[5] "Knowledgebase VMware, articolo 1034165: "Disabling simultaneous write protection provided by VMFS using the multi-writer flag", aggiornamento il 9 aprile 2014

[6] "vSphere Storage, ESXi, vCenter Server 5.5", pubblicazione nel 2013 da VMware

[7] Discussione su VMware vSphere Storage "pRDM vs vRDM virtual / physical interchangeability" URL: https://communities.vmware.com/message/1887889, ultimo aggiornamento il 3 gennaio 2012.

[8] "Efficiency Isn’t Enough: Data Center Lead the Drive To Innovation" 2014 IOUG IT Resource Strategies Survey di Joseph McKendrick, Research Analyst and Produced by Unisphere Research a Devision of Information Today, Inc.

[9] Note tecniche EMC "FAST VP for EMC Symmetrix VMAX Theory and Best Practices for Planning and Performance" Rev. A07, pubblicazione in aprile 2014

[10] EMC Technical Notes "FAST Cache and FAST VP for VNX OE for Block", note di rilascio, rev. 01, pubblicazione il 16 agosto 2013

[11] "VMAX Performance: Best Practices for Configuring Symmetrix" di John Adams di EMC World 2013. URL: https://www.brainshark.com/emcworld/vu?pi=zGtzNuUPBzB8sLz0

[12] "EMC VNX FAST VP: VNX5400, VNX5600, VNX5800, VNX7600, & VNX8000 A Detailed Review", pubblicazione in agosto 2013

[13] "EMC VNX FAST Cache: VNX5400, VNX5600, VNX5800, VNX7600, & VNX8000 A Detailed Review", pubblicazione a ottobre 2013

[14] "EMC VNX Unified Best Practices for Performance, Applied Best Practices Guide” EMC Enterprise & Mid-range Systems Division, pubblicazione a marzo 2014

[15] Virtualization of Oracle Evolves to Best Practice for Production Systems" di Wikibon, autore David Floyer, ultimo aggiornamento il 2 maggio 2013. URL: http://wikibon.org/wiki/v/Virtualization_of_Oracle_Evolves_to_Best_Practice_for_Production_Systems

[16] "Cloning Oracle E-Business Suite with Rapid Clone" rilascio 12.2 Part Number E22953-10. URL: http://docs.oracle.com/cd/E26401_01/doc.122/e22953/T174296T601748.htm

[17] "VMware vCenter Orchestrator, Executing Complex IT Operations Faster and at Lower Cost", pubblicazione a luglio 2013. URL: https://www.vmware.com/files/pdf/products/vCenter/VMware-vCenter-Orchestrator-Datasheet.pdf

[18] Documentazione su VMware vCenter Orchestrator URL: https://www.vmware.com/support/pubs/orchestrator_pubs.html

Best practice per la virtualizzazione di Oracle 34

[19] "Puppet Labs, Puppet documentation", luglio 2013. URL: http://downloads.puppetlabs.com/docs/puppetmanual.pdf

[20] "Performance Best Practices for VMware vSphere 5.5", pubblicazione il 19 settembre 2013

[21] "Microsoft SQL Server Best Practices and Design Guidelines for EMC Storage", pubblicazione a ottobre 2013

[22] "Oracle Real Application Clusters (RAC) on Extended Distance Clusters with EMC VPLEX Metro", pubblicazione a settembre 2011

Altri riferimenti • Using EMC Symmetrix Storage in VMware vSphere Environments, versione 9.0,

URL: http://italy.emc.com/collateral/hardware/solution-overview/h2529-vmware-esx-svr-w-symmetrix-wp-ldv.pdf

• Using EMC VNX Storage with VMware vSphere Environments, versione 3.0, URL: http://italy.emc.com/collateral/hardware/technical-documentation/h8229-vnx-vmware-tb.pdf

Ringraziamenti

L'autore, Sam Lucido, desidera ringraziare Jason Kotsaftis per avere ispirato la redazione del presente documento e per la sua collaborazione costante in corso d'opera. Grazie alla visione e al supporto di Jason, l'idea è stata trasformata in un documento che, ci auguriamo, offra valore aggiunto ai nostri clienti. A volte due mani non bastano e un ulteriore aiuto può fare la differenza. George O'Toole ha assicurato la massima disponibilità e senza il suo supporto la redazione di questo documento avrebbe avuto momenti di stallo in più occasioni. Jeff Browning è tra i principali thought leader sulla virtualizzazione dei database Oracle e le sue intuizioni hanno aiutato ad approfondire molti argomenti.

Infine, il numero di collaboratori e revisori di questo documento è stato sorprendente e il loro feedback è stato fondamentale per assicurare la qualità delle informazioni. Ritengo che EMC sia un ottimo posto in cui lavorare grazie al lavoro in team. Rivolgo i miei ringraziamenti a un team speciale di collaboratori e revisori che hanno reso questo impegno coinvolgente e divertente.