White paper
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
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
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
2
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
3
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
4
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
5
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
6
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 missioncritical". 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
7
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
8
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
9
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à activepassive 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
10

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
11
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
12
•
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
13
•
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
14
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
15
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
16
− 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
17
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
18
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Ì
Snapshot VMware supportate
SÌ
NO
Convalida del cliente, nessun
articolo della knowledgebase
VMware di supporto
Best practice per la virtualizzazione di Oracle
19
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
20
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
21
•
•
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
22
•
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
23
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
24
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
25
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
26
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
27
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
28
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
29
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 activeactive 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 missioncritical 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
30
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
31
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
32
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-OrchestratorDatasheet.pdf
[18] Documentazione su VMware vCenter Orchestrator URL:
https://www.vmware.com/support/pubs/orchestrator_pubs.html
Best practice per la virtualizzazione di Oracle
33
[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/h2529vmware-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-vnxvmware-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.
Best practice per la virtualizzazione di Oracle
34

Condizioni di Fornitura specifiche del contratto PAH-ULA

Curriculum Vitae - Leda Santosuosso

Athena Quanto WO 3y su Google e Oracle

La tua energia tua nergia en

+Oracle 11G-icindekiler

EMC DATA DOMAIN AGGIORNAMENTO DEL CUSTOMER SUPPORT

Specifiche tecniche di EMC VNX-F All