it-swarm.it

Qual è la configurazione RAID consigliata per un database Oracle?

RAID (array ridondanti di dischi economici) viene fornito con diverse configurazioni (RAID-0, RAID-1 ...). Qual è la configurazione RAID consigliata che dovrei impostare e utilizzare durante l'installazione di un database Oracle. Il database verrà utilizzato principalmente come data warehouse.

16
Eddie Awad

Dipende. Quando si guarda un data warehouse, se non si ha in mente un progetto specifico, la gestione automatica dell'archiviazione può essere un percorso eccellente.

Considera la discussione in AskTom , Forum OTN , Forum OTN 2 e Forum OTN .

Non esiste un modo giusto per gestire le cose e le risposte cambiano in base a una serie di fattori hardware e di rete. Per scoprire da soli, precaricare un data warehouse di esempio (solo uno o due concerti, abbastanza per giocare) su una macchina basata su ASM, su un SAN con il Raid virtualizzato da Linux e su una macchina raid basata su hardware.

Sincronizzando i risultati delle query su tutti e tre gli ambienti, sarete in grado di scoprire quale metodologia funziona meglio per le vostre prestazioni. Ho distribuito database usando ASN e raid virtuali basati su Linux, e un raid virtuale si è comportato in modo leggermente migliore (alcuni anni fa.) Tuttavia, sospetto che fosse in parte il modo in cui sono state impostate le unità.

Non esiste una risposta giusta singolare. Se puoi fornirci maggiori dettagli sulle dimensioni e i requisiti di prestazione, potrebbe essere possibile esplorare vari casi di test.

--Modificare--

Ogni " gruppo disco " può essere costituito da uno o più dischi, directory o file sul sottosistema appropriato. Oracle raccomanda "Per prestazioni e affidabilità ottimali, scegli un dispositivo RAID o un volume logico su più di un dispositivo fisico e implementa la metodologia stripe-and-mirror-everything (SAME)." quando si posizionano i file su un filesystem. Sembra che Oracle stia raccomandando RAID 1 + 0.

Gruppi di dischi gestiti ASM, tuttavia, "Un normale gruppo di dischi di ridondanza richiede un minimo di due gruppi di errori (o due dispositivi del disco) se si utilizza il mirroring bidirezionale. Lo spazio su disco effettivo in un normale gruppo di dischi di ridondanza è la metà della somma di lo spazio su disco in tutti i suoi dispositivi "apparentemente fornisce automaticamente il mirroring.

Questi stessi dispositivi possono essere costituiti da dispositivi RAID e così via. Nei test pratici durante l'installazione di data warehouse RAID, un semplice RAID 5 virtuale sul filesystem ha fornito prestazioni accettabili e ASM aggiuntivo non ha aggiunto alcun vantaggio in termini di prestazioni. In questo tipo di attività di ottimizzazione, identificare prima le risorse e quindi testare ogni possibile configurazione, poiché a volte i risultati possono essere estremamente controintuitivi.

13

Se hai due unità fisiche:

RAID0: veloce ma senza ridondanza. Qualsiasi errore dell'unità ucciderà l'intero array. Alcune persone mettono l'archiviazione temporanea su RAID0 (ad esempio tempdb sotto MSSQL) ma lo considererei comunque pericoloso poiché mentre non perderai alcun dato significativo se l'array che cade su di te avrà un'interruzione del server fino a quando la situazione non viene riparata.

RAID1: scegli se hai due unità. Non vi è alcun vantaggio in termini di prestazioni di scrittura sebbene si possa vedere un aumento delle prestazioni di lettura con un buon controller. La caratteristica chiave di RAID1 sta sopravvivendo a una delle unità che muoiono.

Se hai tre unità fisiche:

Le opzioni disponibili sono RAID5, RAID10 non standard a 3 unità (o RAID1E come i controller IBM fanno riferimento ad esso) se supportato. Ovviamente potresti usare RAID1 e mantenere l'unità extra come riserva quando uno degli altri si guasta, ma dovresti comunque conservare i pezzi di ricambio in un ambiente mission-critical, quindi è ovvio.

RAID5 offre più spazio di RAID10 (vale la pena due unità invece di una e mezza) ma presenta un potenziale problema di prestazioni di scrittura poiché per ogni blocco scritto il controller deve leggere il blocco di parità, aggiornarlo e riscriverlo. Questo problema di prestazioni di scrittura può essere raddoppiato per le scritture del database in quanto vi sono almeno due scritture per ogni aggiornamento: una nel registro delle transazioni e una nelle aree dati effettive. Dato che lo spazio è poco costoso in questi giorni, consiglierei RAID10 a 3 unità se supportato per le migliori prestazioni di scrittura. Il software RAID di Linux offre questo, così come molti controller IBM (lo chiamano RAID1E). Potresti trovarlo anche con altri nomi in quanto non è considerato un accordo standard, quindi non ha un nome standard.

Sia R5 che R10-over-tre offrono la stessa ridondanza (ogni unità può guastarsi alla volta e l'array sopravvive) e parametri di performance di lettura simili (simili a un array RAID0 a due unità).

Se hai quattro unità fisiche:

Se si crea un solo array, ci sono due opzioni (ignorando le varianti "con hot spare"): RAID6 e RAID10 "tradizionale" (un RAID0 di RAID1).

Entrambi offrono lo stesso spazio (due unità dei quattro). RAID6 offre una ridondanza migliore in quanto due unità possono guastarsi in un momento in cui RAID10 può sopravvivere solo a quattro delle sei possibili situazioni sparite da due unità. Entrambi forniscono prestazioni di lettura simili ma RAID6 ha un problema di prestazioni di scrittura simile a quello di RAID5 (lo stesso su un buon controller, sebbene possa essere più lento di RAID5 su un controller difettoso o con RAID software a seconda del sistema operativo e delle capacità di controllo I/O. RAID10 è di solito preferito per i database per motivi di prestazioni: se è necessaria la ridondanza aggiuntiva, è possibile utilizzare sei unità e disporre di un RAID1 o 2 RAID1 a 3 unità.

Una volta che hai quattro o più unità anche se le cose diventano più interessanti in quanto potresti avere una coppia separata di array RAID1. Ciò può offrire significativi vantaggi in termini di prestazioni con i dischi rotanti mantenendo i tuoi archivi di dati su un array e i registri delle transazioni su un altro - questo può ridurre considerevolmente i movimenti della testa in alcuni casi e i tempi di ricerca dovuti all'accesso "casuale" sono un vero killer delle prestazioni. Per un data warehouse, supponendo che ciò significhi che vedrà pochissime scritture relativamente parlando, dividere i log delle transazioni dai file di dati potrebbe essere di beneficio più limitato, ma potresti comunque voler considerare più array e invece suddividere i dati su di essi per prestazioni di lettura potenzialmente migliori .

Se hai più di quattro unità:

Le opzioni si spalancano qui e dipende davvero da quali sono i tuoi dati e quali sono i tuoi aggiornamenti/carichi previsti/modelli previsti. Ad esempio, una volta che i nostri servizi vengono eseguiti su unità da 12 ~ 70 Gb:

  • 4x come RAID10 per le aree di sistema (sistema operativo, SQL Server (nel nostro caso MSSQL), swap, tempdb).
  • 4x come RAID10 per i file di dati
  • 4x come RAID10 per i registri delle transazioni

Tempdb viene mantenuto sull'array di sistema. Potremmo spostarlo negli altri due array ed eseguire l'array di sistema come 2 unità in RAID1 poiché la velocità extra non è molto necessaria per i blocchi di sistema (poiché ciò è davvero significativo solo durante l'avvio o lo scambio e ci assicuriamo che ci sia abbastanza RAM perché non debba mai scambiarsi), ma con il modo in cui paghiamo il provider di hosting per quel set di macchine non ci costerebbe meno far cadere le due unità. passare all'array di sistema, prima di essere copiato nelle posizioni di backup off-server, off-site e off-line.

Naturalmente questo è gravemente eccessivo per alcuni database (non avrebbe senso eseguire un piccolo server di blog in questo modo!) Ma la nostra app principale funziona molto bene con questa disposizione.

Se si dispone di sei unità, è possibile prendere in considerazione tre array RAID1 o due array RAID10 a tre unità.

generalmente

Sfortunatamente non esiste una vera "best practice" semplice in quanto dipende molto dalle dimensioni del sistema e dai modelli di utilizzo. Le uniche regole generali che posso pensare o sono:

  • evitare RAID5 e 6 a meno che non si conosca il problema delle prestazioni di scrittura non influirà in modo significativo
  • con quattro o più unità basate su disco rotante, considera la possibilità di dividere le cose su più array per ridurre i movimenti della testa (il pieno vantaggio di più array non si applicherà ai buoni SSD in quanto non ci sono movimenti fisici della testa da considerare, anche se potresti vedere qualche differenza a seconda di la scrittura del controller degli SSD che combina la strategia e così via)
  • prova, prova e riprova: è sempre bene provare a trovare il tempo per verificare che la disposizione scelta sia davvero ottimale

RAID hardware o software?

In passato le prestazioni del RAID software erano inferiori a quelle dell'hardware RAID per RAID 5 a causa dei calcoli di parità e di tutte le disposizioni dovute a interfacce lente tra le unità e la CPU. Con le moderne CPU il problema del calcolo della parità non è realmente un problema, ma se si dispone di unità molto veloci l'hardware RAID può ancora vincere se la velocità totale delle unità può arrivare ovunque vicino (entro un ordine di grandezza, a una supposizione) a quanto velocemente la macchina può parlare con il controller del disco. Se si dispone di un array RAID1 a quattro unità (ovvero quattro copie degli stessi dati per molta ridondanza) con RAID software ogni operazione di scrittura comporterà l'invio da parte del sistema operativo di quattro lotti di dati al controller I/O, possibilmente in sequenza - con un hardware controller il sistema operativo invia solo una richiesta di scrittura e il controller invia quella alle quattro unità, probabilmente in parallelo.

Un buon RAID hardware può offrire anche altri vantaggi: alcuni controller ad alta specifica hanno cache di scrittura con backup della batteria in modo che le scritture in sospeso non vengano perse in un'interruzione di corrente anche se l'UPS si guasta, ad esempio.

Il software RAID è ovviamente più economico e più portatile, quindi non sei legato a un controller particolare se devi spostare gli array a causa di un guasto del controller/macchina.

Il RAID hardware economico solitamente combina gli aspetti negativi del software e del RAID hardware con pochi (o nessuno) dei vantaggi di entrambi, quindi è meglio evitare.

Tendo a utilizzare il software RAID sui nostri server dev, test e UAT e un buon RAID hardware per server che eseguono servizi live rivolti ai clienti/al pubblico.

10
David Spillett

" Oracle Oracle Performance Tuning Guide" ha un capitolo dedicato a I/O Configuration . In breve:

  • Usa striping (RAID hardware, RAID software, ASM)
  • Non utilizzare RAID5 per l'archiviazione e la ripetizione dei registri
  • Allinea la dimensione del blocco del filesystem e la dimensione del blocco DB
5
Benoit

In alcuni casi, JBOD è la risposta corretta (ovvero non RAID).

Il problema è che, se si dispone di gruppi RAID troppo grandi, non si ha la flessibilità di specificare come è disposta l'archiviazione fisica all'interno del database, ad esempio assicurarsi che gli indici e i record per una tabella siano archiviati su mandrini separati, e assicurandoti di bilanciare le scritture su tutti i tuoi dischi.

È possibile utilizzare lo striping (RAID0) per bilanciare le scritture, ma se è tutto un grande gruppo, non è possibile separare gli indici rispetto ai record.

Il mirroring (RAID1) è tollerante agli errori ed è più veloce per le letture (come è possibile leggere da qualsiasi mandrino non occupato), ma può essere più lento per le scritture poiché è necessario attendere che entrambe le copie siano state scritte.

Non andrei mai RAID5 o RAID6 su un database. Se i dati sono importanti, acquista più dischi e vai con RAID1; RAID5/6 è lento (specialmente nel software) e con le dimensioni del disco rigido di oggi potrebbero essere necessari giorni per ricostruire dopo aver sostituito i dischi guasti per un grande gruppo di dischi. .. per non parlare del fatto che il modo in cui la maggior parte dei sistemi RAID5/6 gestisce gli errori di parità è semplicemente ricalcolare la parità ... ma le probabilità sono, la colpa è nei dati, non la parità, ma non hai idea di dove sia stata la colpa. (sfortunatamente, non penso che ci sia qualcosa come LOCKSS per i database)

...

Il layout più interessante che ho visto sul database riguardava in realtà avere due partizioni per mandrino: la parte più interna del disco veniva utilizzata per il database di produzione, le sezioni superiori del disco venivano utilizzate per i backup. (e si sono assicurati che non fosse stato eseguito il backup di una partizione sullo stesso mandrino; penso che esistessero più database, quindi ognuno ha eseguito il backup sui dischi da uno diverso). Ciò dava loro il vantaggio di distribuire le cose su più mandrini durante il giorno di lavoro e, di notte, eseguivano i backup.

Immagino che ci sarebbe un recupero più lento se qualcosa andasse storto e tu avessi bisogno di ripristinarlo, dato che avresti alcune letture dal disco esterno mentre i database sono in uso durante il giorno, ma ci sono sempre dei compromessi in tutto.

...

Quindi, comunque, il punto che sto cercando di chiarire: non esiste una risposta adatta a ogni situazione. Se così fosse, i DBA sarebbero senza lavoro e le aziende comprerebbero dispositivi di database pre-costruiti.

I database di cui mi occupo sono quelli che il mio capo chiama "WORN": Scrivi una volta, Leggi mai; scherza, ma "data warehouse" può significare qualsiasi livello di attività ... ne ho visti alcuni caricati dal nastro ogni notte/settimana (ed erano solo copie dell'istanza OLTP, e ci ha aiutato a verificare che i nastri fossero buoni) e su di essi venivano eseguiti enormi lavori di analisi, e altri in cui vi è un flusso costante di input e letture occasionali, ma nessuna vera concorrenza per le risorse.

4
Joe

La mia raccomandazione per i server è sempre RAID 5 . Il tempo e gli sforzi spesi per recuperare il tuo primo disco rigido guasto saranno sempre memorabili. Se si configurano array RAID, si consiglia vivamente di standardizzare su una singola dimensione di unità e di riporre 2 dischi rigidi di riserva nella stanza del server. Un'unità si guasta? Inserire una delle sostituzioni (e consentire la ricostruzione dell'array). Ho visto le matrici RAID andare giù difficile perché una seconda unità è andata male mentre aspettavano che arrivasse la prima (la consegna del giorno successivo era ancora troppo tardi ).

3
Tangurena

Quanti dati stai pianificando di utilizzare e con quale frequenza leggi e scrivi dal sistema? C'è molta pianificazione in questo, abbastanza da permettere ad alcune persone di dedicare un'intera carriera accademica all'argomento.

Normalmente ti direi di andare su Wikipedia e leggere l'articolo prima di continuare, poiché ci sono alcuni tipi di RAID e ognuno è meglio usato in un posto diverso.

Le basi vanno così:

RAID0

Buono per i giocatori di video. Male per chiunque altro. Non sarebbe male usarlo per un server di cache che non ha bisogno di conservare i dati per un certo periodo di tempo. Quando un disco si guasta, il sistema è inattivo. Gioco finito.

RAID1

Ottimo per affidabilità. Non molta espandibilità. Abbastanza buono sulla velocità.

RAID5

Il mix preferito tra RAID0 e RAID1 (sorta di).

Ora, dopo questo, diventa davvero quasi qualcosa che dovrebbe essere chiesto su ServerFault a causa del fatto che è la configurazione del server più che la progettazione del database. Discutere sempre delle prestazioni del server con l'amministratore del server. Ecco a cosa servono. Se questa non fosse una beta privata, voterei per chiudere per migrare lì.

2
jcolebrand