Un numero considerevole di applicazioni enterprise e sistemi di virtualizzazione dispone di meccanismi propri per costruire soluzioni fault-tolerant. In particolare, Oracle RAC (Oracle Real Application Cluster) è un cluster composto da due o più server di database Oracle che lavorano insieme per bilanciare il carico e garantire la tolleranza ai guasti a livello di server/applicazione. Per operare in questa modalità è necessario uno storage condiviso, generalmente fornito da uno storage area network (SAN).
Come già discusso in uno dei nostri , lo storage area network, nonostante la presenza di componenti duplicati (inclusi i controller), presenta comunque dei punti di guasto, principalmente rappresentati da un unico insieme di dati. Pertanto, per costruire una soluzione Oracle con requisiti di affidabilità elevati, lo schema “N server – uno storage area network” deve essere complicato.
Innanzitutto, è fondamentale stabilire quali rischi stiamo cercando di mitigare. In questo articolo, non tratteremo la protezione da minacce come 'l'arrivo di un meteorite'. Pertanto, la costruzione di una soluzione di disaster recovery geograficamente distribuita sarà oggetto di articoli futuri. Qui ci concentreremo sulla cosiddetta soluzione di Cross-Rack disaster recovery, in cui la protezione viene realizzata a livello di armadi per server. Gli armadi possono trovarsi sia nella stessa stanza che in diverse, ma di solito all'interno dello stesso edificio.
Questi armadi devono contenere tutta l'attrezzatura e il software necessari per garantire il funzionamento dei database Oracle indipendentemente dallo stato del 'vicino'. In altre parole, utilizzando una soluzione di Cross-Rack disaster recovery, possiamo eliminare i rischi in caso di malfunzionamento:
- Server delle applicazioni Oracle
- Sistemi di archiviazione
- Sistemi di commutazione
- Guasto totale dell'intera attrezzatura nell'armadio:
- Guasto di alimentazione
- Guasto del sistema di raffreddamento
- Fattori esterni (umani, naturali, ecc.)
La duplicazione dei server Oracle implica il principio di funzionamento di Oracle RAC ed è realizzata tramite un'applicazione. Anche la duplicazione dei mezzi di commutazione non presenta problemi. Tuttavia, la duplicazione del sistema di storage è più complicata.
La soluzione più semplice è la replicazione dei dati da un sistema di storage principale a uno secondario. Sia sincrona che asincrona, a seconda delle possibilità del sistema di storage. Nel caso della replicazione asincrona, si pone immediatamente la questione della coerenza dei dati rispetto a Oracle. Ma anche se esiste un'integrazione software con l'applicazione, in ogni caso, in caso di guasto del sistema di storage principale, sarà necessario l'intervento manuale degli amministratori per switchare il cluster su uno storage secondario.
Una soluzione più complessa consiste in "virtualizzatori" software e/o hardware per il sistema di storage che eliminano i problemi di coerenza e l'intervento manuale. Tuttavia, la complessità di implementazione e la successiva amministrazione, insieme ai costi piuttosto elevati di tali soluzioni, allontanano molti.
Proprio per scenari come il disaster recovery Cross-Rack, la soluzione All Flash array AccelStor NeoSapphire™ è estremamente adatta. utilizzando un'architettura Shared-Nothing. Questo modello rappresenta un sistema di storage a due nodi che utilizza la propria tecnologia FlexiRemap® per lavorare con memorie flash. Grazie a NeoSapphire™ H710 può garantire prestazioni fino a 600K IOPS@4K scrittura casuale e oltre 1M IOPS@4K lettura casuale, cosa non raggiungibile con sistemi di storage RAID-based tradizionali.
Ma la caratteristica principale di NeoSapphire™ H710 è che le due nodi sono realizzati in contenitori separati, ognuno dei quali ha una propria copia dei dati. La sincronizzazione dei nodi avviene attraverso un'interfaccia esterna InfiniBand. Grazie a questa architettura, è possibile posizionare i nodi in diverse località a una distanza massima di 100 m, fornendo così una soluzione di disaster recovery Cross-Rack. Entrambi i nodi operano completamente in modalità sincrona. Dal punto di vista degli host, H710 appare come un comune sistema di storage a due controller. Pertanto, non è necessario eseguire ulteriori opzioni software e hardware o configurazioni particolarmente complesse.
Confrontando tutte le soluzioni di recupero disaster recovery Cross-Rack sopra descritte, l'opzione di AccelStor si distingue chiaramente dalle altre:
AccelStor NeoSapphire™ Architettura Shared Nothing
Virtualizzatore software o hardware per sistemi di archiviazione
Soluzione basata sulla replica
Disponibilità
Guasto del server
Nessun downtime
Nessun downtime
Nessun downtime
Guasto dello switch
Nessun downtime
Nessun downtime
Nessun downtime
Guasto del sistema di archiviazione
Nessun downtime
Nessun downtime
Downtime
Guasto di tutta la rack
Nessun downtime
Nessun downtime
Downtime
Costo e complessità
Costo della soluzione
Basso*
Alto
Alto
Complesso da implementare
Basso
Alto
Alto
*AccelStor NeoSapphire™ è comunque un array All Flash, che per definizione non costa 'tre spiccioli', specialmente avendo un doppio margine di capacità. Tuttavia, confrontando il costo finale della soluzione basata su di esso con quelli di altri fornitori, il costo può essere considerato basso.
La topologia di connessione dei server applicativi e dei nodi dell'array All Flash sarà la seguente:
Durante la pianificazione della topologia, è estremamente consigliato duplicare anche gli switch di gestione e di interconnessione dei server.
Qui e oltre, si parlerà di connessione tramite Fibre Channel. Nel caso venga utilizzato iSCSI, sarà tutto lo stesso, con l'adeguamento ai tipi di switch utilizzati e alcune impostazioni leggermente diverse dell'array.
Lavoro preparatorio sull'array
Attrezzature e software utilizzati
Specifiche di server e switch
Componenti
Descrizione
Server Oracle Database 11g
Due
Sistema operativo del server
Oracle Linux
Versione del database Oracle
11g (RAC)
Processori per server
Due CPU Intel® Xeon® E5-2667 v2 a 16 core @ 3.30GHz
Memoria fisica per server
128GB
Rete FC
FC da 16Gb/s con multipathing
FC HBA
Emulex Lpe-16002B
Porte pubbliche dedicate da 1GbE per la gestione del cluster
Adattatore ethernet Intel RJ45
Switch FC da 16Gb/s
Brocade 6505
Porte private dedicate da 10GbE per la sincronizzazione dei dati
Intel X520
Specifiche del sistema di storage AccelStor NeoSapphire™ All Flash
Componenti
Descrizione
Sistema di archiviazione
Modello ad alta disponibilità NeoSapphire™: H710
Versione dell'immagine
4.0.1
Numero totale di drive
48
Dimensione del drive
1.92TB
Tipo di drive
SSD
Porte target FC
16 porte da 16Gb (8 per nodo)
Porte di gestione
Cavo ethernet 1GbE collegato agli host tramite uno switch ethernet
Porta heartbeat
Cavo ethernet 1GbE collegato tra due nodi di archiviazione
Porta di sincronizzazione dei dati
Cavo InfiniBand da 56Gb/s
Prima di usare il sistema di archiviazione, è necessario inizializzarlo. Di default l'indirizzo di gestione di entrambi i nodi è lo stesso (192.168.1.1). È necessario collegarsi a ciascun nodo in sequenza e assegnare nuovi indirizzi di gestione (già diversi) e configurare la sincronizzazione dell'ora. Dopo ciò, le porte di gestione possono essere collegate a una rete unica. Successivamente, i nodi vengono uniti in una coppia HA assegnando subnet per le connessioni Interlink.
Dopo aver completato l'inizializzazione, è possibile gestire il sistema di archiviazione da qualsiasi nodo.
Successivamente, creiamo i volumi necessari e li pubblichiamo per i server delle applicazioni.
Si consiglia vivamente di creare più volumi per Oracle ASM, poiché ciò aumenterà il numero di target per i server, migliorando alla fine le prestazioni complessive (maggiori informazioni sulle code saranno fornite in seguito). ).
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
Redo01
100GB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Alcune spiegazioni sui modi di funzionamento del sistema di archiviazione e sui processi che avvengono in situazioni straordinarie.
Ogni nodo del set di dati ha un parametro "numero di versione". Dopo l'inizializzazione iniziale, esso è identico e pari a 1. Se per qualche motivo il numero di versione è diverso, i dati vengono sempre sincronizzati dalla versione più recente a quella più vecchia, dopo di che il numero della versione più vecchia viene allineato, ovvero questo significa che le copie sono identiche. Le ragioni per cui le versioni potrebbero differire includono:
- Riavvio programmato di uno dei nodi.
- Guasto di uno dei nodi a causa di un'interruzione improvvisa (alimentazione, surriscaldamento, ecc.).
- Interruzione della connessione InfiniBand senza possibilità di sincronizzazione.
- Guasto su uno dei nodi a causa di dati danneggiati. Qui sarà necessario creare un nuovo gruppo HA e sincronizzare completamente il set di dati.
In ogni caso, il nodo che rimane online aumenta il suo numero di versione di uno, per poi sincronizzare il suo set di dati dopo il ripristino della connessione con il paio.
Se si verifica un'interruzione della connessione tramite il link Ethernet, Heartbeat passa temporaneamente a InfiniBand e torna indietro entro 10 secondi al ripristino.
Configurazione degli host
Per garantire l'alta disponibilità e aumentare le prestazioni, è necessario abilitare il supporto MPIO per il sistema. A tale scopo, bisogna aggiungere nel file /etc/multipath.conf le righe, dopodiché riavviare il servizio multipath.
Testo nascostodispositivi {
device {
vendor «AStor»
path_grouping_policy «group_by_prio»
path_selector «queue-length 0»
path_checker «tur»
features «0»
hardware_handler «0»
prio «const»
failback immediate
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names yes
detect_prio yes
rr_min_io_rq 1
no_path_retry 0
}
}
Successivamente, affinché ASM funzioni con MPIO tramite ASMLib, è necessario modificare il file /etc/sysconfig/oracleasm e poi eseguire /etc/init.d/oracleasm scandisks.
Testo nascosto
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER=«dm»
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE=«sd»
Nota
Se non si desidera utilizzare ASMLib, è possibile utilizzare le regole UDEV, che sono alla base di ASMLib.
A partire dalla versione 12.1.0.2, l'opzione Oracle Database è disponibile per l'installazione come parte del software ASMFD.
È fondamentale assicurarsi che i dischi creati per Oracle ASM siano allineati con la dimensione del blocco utilizzata fisicamente dal sistema di archiviazione (4K). Altrimenti, potrebbero verificarsi problemi di prestazioni. Pertanto, è necessario creare volumi con le seguenti impostazioni:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Distribuzione dei database sui volumi creati per la nostra configurazione di test
Nome del volume di archiviazione
Dimensione del volume
Mappatura dei LUN di volume
Dettagli del dispositivo di volume ASM
Dimensione dell'unità di allocazione
Data01
200GB
Mappa tutti i volumi di archiviazione ai sistemi 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: Grid: CRS e Voting
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Ridondanza: Normale
Nome: DGGRID2
Scopo: Grid: CRS e Voting
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Ridondanza: Normale
Nome: DGREDO1
Scopo: Log di redo del thread 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Ridondanza: Normale
Nome: DGREDO2
Scopo: Log di redo del thread 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Configurazioni del database
- Dimensione del blocco = 8K
- Spazio di swap = 16GB
- Disabilita AMM (Gestione automatica della memoria)
- Disabilita 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 impostare questo se stai usando Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ grid soft stack 10240
✓ stack del sistema 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ oracle soft stack 10240
✓ oracle hard stack 32768
✓ soft memlock 120795954
✓ hard memlock 120795954
sqlplus “/as sysdba”
alter system set processes=2000 scope=spfile;
alter system set open_cursors=2000 scope=spfile;
alter system set session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
Test di tolleranza ai guasti
Per dimostrare si è utilizzato HammerDB per emulare un carico OLTP. Configurazione di HammerDB:
Numero di Magazzini
256
Transazioni Totali per Utente
1000000000000
Utenti Virtuali
256
Il risultato ottenuto è stato di 2,1 milioni TPM, lontano dal limite di prestazione del sistema , ma è un 'tetto' per l'attuale configurazione hardware dei server (soprattutto a causa dei processori) e del loro numero. L'obiettivo di questo test è comunque dimostrare la tolleranza ai guasti della soluzione nel suo complesso, piuttosto che raggiungere i massimi di prestazione. Pertanto, ci baseremo semplicemente su questo valore.
Test di guasto di uno dei nodi
I host hanno perso parte dei percorsi verso lo storage, continuando a funzionare tramite i restanti con il secondo nodo. Le prestazioni sono calate per alcuni secondi a causa della ristrutturazione dei percorsi, per poi tornare ai livelli normali. Non ci sono stati intervalli di inattività.
Test di guasto del rack con tutta l'attrezzatura
In questo caso, anche le prestazioni sono diminuite per alcuni secondi a causa della riorganizzazione dei percorsi, per poi tornare alla metà del valore iniziale. Il risultato è diminuito della metà rispetto all'iniziale a causa dell'esclusione di un server applicazioni. Non si è verificata alcuna interruzione del servizio.
Se ci sono esigenze per l'implementazione di una soluzione di disaster recovery Cross-Rack per Oracle a un costo ragionevole e con pochi sforzi di distribuzione/amministrazione, allora la collaborazione tra Oracle RAC e l'architettura sarà una delle migliori opzioni. Al posto di Oracle RAC può esserci qualsiasi altro software che prevede la clustering, le stesse DBMS o sistemi di virtualizzazione, ad esempio. Il principio di costruzione della soluzione rimarrà lo stesso. E il risultato finale sarà un valore zero per RTO e RPO.
Fonte: habr.com
