Un numero considerevole di applicazioni aziendali e sistemi di virtualizzazione dispongono di meccanismi propri per la creazione di soluzioni con tolleranza agli errori. Nello specifico, Oracle RAC (Oracle Real Application Cluster) è un cluster di due o più server di database Oracle che lavorano insieme per bilanciare il carico e fornire tolleranza agli errori a livello di server/applicazione. Per funzionare in questa modalità, è necessario uno spazio di archiviazione condiviso, che di solito è un sistema di archiviazione.
Come abbiamo già discusso in uno dei nostri , il sistema di storage stesso, nonostante la presenza di componenti duplicati (inclusi i controller), presenta ancora punti di guasto, principalmente sotto forma di un unico set di dati. Pertanto, per creare una soluzione Oracle con requisiti di affidabilità maggiori, lo schema "N server - un sistema di storage" deve essere complicato.
Innanzitutto, ovviamente, dobbiamo decidere contro quali rischi vogliamo assicurarci. In questo articolo non prenderemo in considerazione la protezione contro minacce del tipo “è arrivato un meteorite”. Pertanto, la creazione di una soluzione di ripristino di emergenza geograficamente dispersa rimarrà un argomento per uno dei seguenti articoli. Qui esamineremo la cosiddetta soluzione di ripristino di emergenza Cross-Rack, quando la protezione è costruita a livello degli armadietti dei server. Gli armadi stessi possono essere collocati nella stessa stanza o in stanze diverse, ma solitamente all'interno dello stesso edificio.
Questi armadi devono contenere l'intero set necessario di apparecchiature e software che consentiranno il funzionamento dei database Oracle indipendentemente dallo stato del “vicino”. In altre parole, utilizzando la soluzione di disaster recovery Cross-Rack, eliminiamo i rischi di fallimento:
- Server di applicazioni Oracle
- Sistemi di stoccaggio
- Sistemi di commutazione
- Guasto completo di tutte le apparecchiature nell'armadio:
- Rifiuto del potere
- Guasto al sistema di raffreddamento
- Fattori esterni (uomo, natura, ecc.)
La duplicazione dei server Oracle implica il principio stesso di funzionamento di Oracle RAC e viene implementata tramite un'applicazione. Anche la duplicazione degli impianti di commutazione non costituisce un problema. Ma con la duplicazione del sistema di archiviazione, tutto non è così semplice.
L'opzione più semplice è la replica dei dati dal sistema di storage principale a quello di backup. Sincrono o asincrono, a seconda delle capacità del sistema di archiviazione. Con la replica asincrona sorge immediatamente la questione di garantire la coerenza dei dati in relazione a Oracle. Ma anche se è presente l'integrazione del software con l'applicazione, in ogni caso, in caso di guasto del sistema di storage principale, sarà necessario l'intervento manuale degli amministratori per convertire il cluster nello storage di backup.
Un'opzione più complessa sono i “virtualizzatori” di storage software e/o hardware che elimineranno i problemi di coerenza e l'intervento manuale. Ma la complessità dell’implementazione e della successiva amministrazione, nonché il costo davvero indecente di tali soluzioni, spaventano molti.
La soluzione array AccelStor NeoSapphire™ All Flash è perfetta per scenari come il ripristino di emergenza Cross-Rack utilizzando l'architettura Shared-Nothing. Questo modello è un sistema di archiviazione a due nodi che utilizza la tecnologia proprietaria FlexiRemap® per funzionare con le unità flash. Grazie a NeoSapphire™ H710 è in grado di fornire prestazioni fino a 600 IOPS@4K in scrittura casuale e 1 milione+ IOPS@4K in lettura casuale, valori irraggiungibili quando si utilizzano i classici sistemi di storage basati su RAID.
Ma la caratteristica principale di NeoSapphire™ H710 è l'esecuzione di due nodi sotto forma di casi separati, ognuno dei quali ha la propria copia dei dati. La sincronizzazione dei nodi viene effettuata tramite l'interfaccia InfiniBand esterna. Grazie a questa architettura è possibile distribuire i nodi in luoghi diversi a una distanza massima di 100 m, fornendo così una soluzione di disaster recovery Cross-Rack. Entrambi i nodi funzionano in modo completamente sincrono. Dal lato host, l'H710 sembra un normale sistema di archiviazione a doppio controller. Non è quindi necessario eseguire alcuna opzione software o hardware aggiuntiva o impostazioni particolarmente complesse.
Se confrontiamo tutte le soluzioni di ripristino di emergenza Cross-Rack sopra descritte, l'opzione di AccelStor si distingue notevolmente dalle altre:
Architettura AccelStor NeoSapphire™ che non condivide nulla
Sistema di archiviazione “virtualizzatore” software o hardware
Soluzione basata sulla replica
Disponibilità
Errore del server
Nessun tempo morto
Nessun tempo morto
Nessun tempo morto
Errore del cambio
Nessun tempo morto
Nessun tempo morto
Nessun tempo morto
Guasto del sistema di archiviazione
Nessun tempo morto
Nessun tempo morto
I tempi di inattività
Guasto dell'intero cabinet
Nessun tempo morto
Nessun tempo morto
I tempi di inattività
Costo e complessità
Costo della soluzione
Basso*
Alto
Alto
Complessità di distribuzione
basso
Alto
Alto
*AccelStor NeoSapphire™ è ancora un array All Flash, che per definizione non costa "3 centesimi", soprattutto perché ha una riserva di capacità doppia. Tuttavia, quando si confronta il costo finale di una soluzione basata su di essa con soluzioni simili di altri fornitori, il costo può essere considerato basso.
La topologia per la connessione dei server delle applicazioni e dei nodi dell'array All Flash sarà simile alla seguente:
Quando si pianifica la topologia, è inoltre altamente consigliabile duplicare gli switch di gestione e interconnettere i server.
Qui e oltre parleremo della connessione tramite Fibre Channel. Se utilizzi iSCSI, tutto sarà uguale, adattato ai tipi di switch utilizzati e alle impostazioni dell'array leggermente diverse.
Lavori preparatori sull'array
Attrezzature e software utilizzati
Specifiche del server e dello switch
Componenti
descrizione
Server Oracle Database 11g
due
Sistema operativo server
Oracle Linux
Versione database Oracle
11 g (RAC)
Processori per server
Due CPU Intel® Xeon® E16-5 v2667 a 2 core a 3.30 GHz
Memoria fisica per server
128GB
Rete FC
FC da 16 Gb/s con multipath
FC HBA
Emulex Lpe-16002B
Porte 1GbE pubbliche dedicate per la gestione dei cluster
Adattatore Ethernet RJ45 Intel
Switch FC da 16 Gb/s
Broccato 6505
Porte 10GbE private dedicate per la sincronizzazione dei dati
Intel X520
Specifiche dell'array All Flash AccelStor NeoSapphire™
Componenti
descrizione
Sistema di archiviazione
Modello ad alta disponibilità NeoSapphire™: H710
Versione dell'immagine
4.0.1
Numero totale di unità
48
Dimensioni unità
1.92TB
Tipo di azionamento
SSD
Porte di destinazione FC
16 porte da 16 Gb (8 per nodo)
Porte di gestione
Il cavo Ethernet 1GbE che si collega agli host tramite uno switch Ethernet
Porta del battito cardiaco
Il cavo Ethernet 1GbE che collega due nodi di archiviazione
Porta di sincronizzazione dei dati
Cavo InfiniBand da 56Gb/s
Prima di poter utilizzare un array, è necessario inizializzarlo. Per impostazione predefinita, l'indirizzo di controllo di entrambi i nodi è lo stesso (192.168.1.1). È necessario connettersi ad essi uno per uno e impostare nuovi indirizzi di gestione (già diversi) e impostare la sincronizzazione dell'ora, dopodiché le porte di gestione possono essere collegate a un'unica rete. Successivamente, i nodi vengono combinati in una coppia HA assegnando sottoreti per le connessioni Interlink.
Una volta completata l'inizializzazione, è possibile gestire l'array da qualsiasi nodo.
Successivamente, creiamo i volumi necessari e li pubblichiamo sui server delle applicazioni.
Si consiglia vivamente di creare più volumi per Oracle ASM in quanto ciò aumenterà il numero di destinazioni per i server, il che in definitiva migliorerà le prestazioni complessive (maggiori informazioni sulle code in un altro ).
Configurazione di prova
Nome del volume di archiviazione
Dimensione del volume
Data01
200GB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Ripeti01
100GB
Ripeti02
100GB
Ripeti03
100GB
Ripeti04
100GB
Ripeti05
100GB
Ripeti06
100GB
Ripeti07
100GB
Ripeti08
100GB
Ripeti09
100GB
Ripeti10
100GB
Alcune spiegazioni sulle modalità operative dell'array e sui processi che si verificano in situazioni di emergenza
Il set di dati di ciascun nodo ha un parametro "numero di versione". Dopo l'inizializzazione iniziale, è lo stesso e uguale a 1. Se per qualche motivo il numero di versione è diverso, i dati vengono sempre sincronizzati dalla versione precedente a quella più recente, dopodiché il numero della versione più recente viene allineato, ad es. ciò significa che le copie sono identiche. Motivi per cui le versioni potrebbero essere diverse:
- Riavvio pianificato di uno dei nodi
- Un incidente su uno dei nodi a causa di uno spegnimento improvviso (alimentazione, surriscaldamento, ecc.).
- Connessione InfiniBand persa con impossibilità di sincronizzazione
- Un arresto anomalo su uno dei nodi a causa della corruzione dei dati. Qui dovrai creare un nuovo gruppo HA e completare la sincronizzazione del set di dati.
In ogni caso, il nodo che rimane online aumenta di uno il proprio numero di versione per sincronizzare il proprio set di dati una volta ripristinata la connessione con la coppia.
Se la connessione tramite il collegamento Ethernet viene persa, Heartbeat passa temporaneamente a InfiniBand e ritorna indietro entro 10 secondi quando viene ripristinata.
Configurazione degli host
Per garantire la tolleranza agli errori e migliorare le prestazioni, è necessario abilitare il supporto MPIO per l'array. Per fare ciò, è necessario aggiungere righe al file /etc/multipath.conf e quindi riavviare il servizio multipath
Testo nascostodispositivi {
dispositivo {
venditore "AStor"
path_grouping_policy "group_by_prio"
path_selector "lunghezza coda 0"
path_checker "tur"
caratteristiche "0"
gestore_hardware "0"
prio "const"
failback immediato
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names sì
rileva_prio sì
rr_min_io_rq 1
no_percorso_riprova 0
}
}
Successivamente, affinché ASM funzioni con MPIO tramite ASMLib, è necessario modificare il file /etc/sysconfig/oracleasm e quindi eseguire lo scandisks /etc/init.d/oracleasm
Testo nascosto
# ORACLEASM_SCANORDER: modelli di corrispondenza per ordinare la scansione del disco
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: modelli corrispondenti per escludere i dischi dalla scansione
ORACLEASM_SCANEXCLUDE="SD"
Nota
Se non vuoi usare ASMLib, puoi usare le regole UDEV, che sono la base per ASMLib.
A partire dalla versione 12.1.0.2 di Oracle Database, l'opzione è disponibile per l'installazione come parte del software ASMFD.
È fondamentale garantire che i dischi creati per Oracle ASM siano allineati con la dimensione del blocco con cui opera fisicamente l'array (4K). In caso contrario, potrebbero verificarsi problemi di prestazioni. Pertanto è necessario creare volumi con i parametri appropriati:
parted /dev/mapper/nome-dispositivo mklabel gpt mkpart primario 2048s 100% controllo allineamento ottimale 1
Distribuzione dei database sui volumi creati per la nostra configurazione di test
Nome del volume di archiviazione
Dimensione del volume
Mappatura dei LUN del volume
Dettagli dispositivo volume ASM
Dimensione dell'unità di allocazione
Data01
200GB
Mappare tutti i volumi di archiviazione sul sistema di archiviazione su tutte le porte dati
Ridondanza: normale
Nome:DGDATA
Scopo: file di dati
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Ridondanza: normale
Nome: DGGRID1
Scopo:Griglia: CRS e votazione
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Ridondanza: normale
Nome: DGGRID2
Scopo:Griglia: CRS e votazione
4MB
Grid05
1GB
Grid06
1GB
Ripeti01
100GB
Ridondanza: normale
Nome: DGREDO1
Scopo: Rifare il log del thread 1
4MB
Ripeti02
100GB
Ripeti03
100GB
Ripeti04
100GB
Ripeti05
100GB
Ripeti06
100GB
Ridondanza: normale
Nome: DGREDO2
Scopo: Rifare il log del thread 2
4MB
Ripeti07
100GB
Ripeti08
100GB
Ripeti09
100GB
Ripeti10
100GB
Impostazioni del database
- Dimensione del blocco = 8K
- Spazio di scambio = 16 GB
- Disabilita AMM (gestione automatica della memoria)
- Disattiva le pagine enormi trasparenti
Altre impostazioni
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # non impostarlo se stai usando Linux x86
✓ vm.vfs_cache_pressione=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ griglia morbida nproc 2047
✓ griglia dura nproc 16384
✓ griglia morbida nofile 1024
✓ griglia rigida nofile 65536
✓ griglia soft stack 10240
✓ griglia hard stack 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ Oracle SoftNofile 1024
✓ Oracle HardNofile 65536
✓ Oracle Soft Stack 10240
✓ stack rigido Oracle 32768
✓ memoria morbida 120795954
✓ memoria rigida 120795954
sqlplus “/as sysdba”
alterare i processi impostati sul sistema = 2000 ambito = spfile;
altera il sistema imposta open_cursors=2000 scope=spfile;
altera il set di sistema session_cached_cursors=300 scope=spfile;
altera il set di sistema db_files=8192 scope=spfile;
Prova di fallimento
A scopo dimostrativo, HammerDB è stato utilizzato per emulare un carico OLTP. Configurazione HammerDB:
Numero di magazzini
256
Transazioni totali per utente
1000000000000
Utenti virtuali
256
Il risultato è stato un TPM di 2.1 milioni, ben lontano dal limite prestazionale dell'array , ma rappresenta un "tetto" per l'attuale configurazione hardware dei server (principalmente a causa dei processori) e il loro numero. Lo scopo di questo test è comunque quello di dimostrare la tolleranza agli errori della soluzione nel suo complesso e non di ottenere le massime prestazioni. Pertanto, ci baseremo semplicemente su questa cifra.
Testare il guasto di uno dei nodi
Gli host hanno perso parte dei percorsi verso lo storage, continuando a lavorare su quelli rimanenti con il secondo nodo. Le prestazioni sono diminuite per alcuni secondi a causa della ricostruzione dei percorsi, per poi tornare alla normalità. Non c'è stata alcuna interruzione del servizio.
Test di guasto del cabinet con tutte le apparecchiature
Anche in questo caso le prestazioni sono scese per qualche secondo a causa della ristrutturazione dei tracciati, per poi tornare alla metà del valore originale. Il risultato è stato dimezzato rispetto a quello iniziale a causa dell'esclusione dal funzionamento di un application server. Non vi è stata alcuna interruzione del servizio.
Se è necessario implementare una soluzione di disaster recovery Cross-Rack tollerante agli errori per Oracle a un costo ragionevole e con un impegno minimo di distribuzione/amministrazione, Oracle RAC e l'architettura funzionano insieme sarà una delle migliori opzioni. Al posto di Oracle RAC può esserci qualsiasi altro software che fornisca il clustering, ad esempio gli stessi DBMS o i sistemi di virtualizzazione. Il principio su cui si basa la costruzione della soluzione rimarrà lo stesso. E il risultato finale è zero per RTO e RPO.
Fonte: habr.com