Un numero considerevole di applicazioni Enterprise e sistemi di virtualizzazione hanno i propri meccanismi per la creazione di soluzioni a prova di guasto. 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 resilienza a livello di server/applicazione. Per operare in questo modo è necessario uno storage comune, che di solito è fornito da uno storage SAN.
Come già discusso in uno dei nostri , lo storage SAN, nonostante la presenza di componenti ridondanti (inclusi i controller), ha comunque dei punti di guasto — principalmente, sotto forma di un unico insieme di dati. Pertanto, per costruire una soluzione Oracle con requisiti di affidabilità più elevati, lo schema "N server - uno storage SAN" deve essere complicato.
Prima di tutto, è necessario determinare quali rischi stiamo cercando di coprire. Nel contesto di questo articolo non discuteremo la protezione contro minacce come "un meteorite che colpisce". Pertanto, la costruzione di una soluzione disaster recovery geograficamente distribuita rimarrà un argomento per uno dei prossimi articoli. Qui esploreremo la cosiddetta soluzione Cross-Rack disaster recovery, in cui la protezione è costruita a livello di armadi server. Gli armadi stessi possono trovarsi sia nella stessa stanza che in stanze diverse, ma di solito all'interno dello stesso edificio.
Questi armadi devono contenere tutta l'attrezzatura e il software necessari che consentano il funzionamento dei database Oracle indipendentemente dallo stato del "vicino". In altre parole, utilizzando una soluzione di Cross-Rack disaster recovery, escludiamo i rischi di guasto:
- Server applicazione Oracle
- Sistemi di storage
- Sistemi di commutazione
- Guasto totale di tutta l'attrezzatura nell'armadio:
- Guasto di alimentazione
- Guasto del sistema di raffreddamento
- Fattori esterni (umani, naturali, ecc.)
La duplicazione dei server Oracle implica il principio stesso di funzionamento di Oracle RAC e si realizza tramite l'applicazione. Anche la duplicazione dei mezzi di commutazione non rappresenta un problema. Ma la duplicazione del sistema di storage è un'altra questione.
La soluzione più semplice è la replica dei dati da uno storage principale a uno secondario. Può essere sincrona o asincrona, a seconda delle capacità dello storage. Con la replica asincrona si pone subito il problema della garanzia di coerenza dei dati rispetto a Oracle. Ma anche se c'è un'integrazione software con l'applicazione, in caso di guasto dello storage principale sarà comunque necessaria l'intervento manuale degli amministratori per commutare il cluster su uno storage secondario.
Una soluzione più complessa è data dai "virtualizzatori" software o hardware dello storage, che evitano problemi di coerenza e interventi manuali. Tuttavia, la complessità di distribuzione e successiva gestione, nonché il costo considerevole di tali soluzioni, spaventano molti.
Per scenari come il disaster recovery Cross-Rack, la soluzione All Flash array AccelStor NeoSapphire™ è particolarmente adatta. utilizzando l'architettura Shared-Nothing. Questo modello rappresenta un sistema di storage a due nodi che utilizza la propria tecnologia FlexiRemap® per lavorare con i dispositivi di archiviazione flash. Grazie a NeoSapphire™ H710 può garantire prestazioni fino a 600K IOPS@4K scritture casuali e 1M+ IOPS@4K letture casuali, cosa impossibile con gli storage basati su RAID classici.
La principale caratteristica della NeoSapphire™ H710 è l'implementazione di due nodi in caselle separate, ciascuna delle quali ha una propria copia dei dati. La sincronizzazione dei nodi avviene tramite l'interfaccia esterna InfiniBand. Grazie a questa architettura, è possibile posizionare i nodi in diverse località fino a 100 m di distanza, realizzando così una soluzione di disaster recovery Cross-Rack. Entrambi i nodi operano completamente in modalità sincrona. Dal punto di vista degli host, l'H710 appare come un normale storage a due controllori. Pertanto, non è necessario effettuare ulteriori opzioni software o hardware e impostazioni particolarmente complesse.
Se si confrontano tutte le soluzioni sopra descritte per il disaster recovery Cross-Rack, la proposta di AccelStor si distingue nettamente dalle altre:
AccelStor NeoSapphire™ Architettura Shared Nothing
Virtualizzatore software o hardware dello storage
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 storage
Nessun downtime
Nessun downtime
Downtime
Guasto dell'intero rack
Nessun downtime
Nessun downtime
Downtime
Costo e complessità
Costo della soluzione
Basso*
Alta
Alta
Complesso da distribuire
Basso
Alta
Alta
*AccelStor NeoSapphire™ è comunque un array All Flash, il cui prezzo non è certo «3 spicci», tanto più avendo una capacità doppia. Tuttavia, confrontando il costo finale della soluzione basata su di esso con analoghe di altri fornitori, il prezzo può essere considerato competitivo.
La topologia di collegamento dei server delle applicazioni e dei nodi dell'array All Flash sarà la seguente:
Nella pianificazione della topologia è altamente raccomandato creare una duplicazione degli switch di gestione e di interconnessione dei server.
Qui e oltre si parlerà di collegamento tramite Fibre Channel. In caso venga utilizzato iSCSI sarà tutto lo stesso, con l'eccezione dei tipi di switch utilizzati e alcune configurazioni diverse dell'array.
Lavoro preparatorio sull'array
Attrezzature e software utilizzati
Specifiche dei server e degli 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 da 16 core @ 3.30GHz
Memoria fisica per server
128GB
Rete FC
FC a 16Gb/s con multipathing
FC HBA
Emulex Lpe-16002B
Porte pubbliche dedicate 1GbE per la gestione del cluster
Adattatore ethernet Intel RJ45
Switch FC a 16Gb/s
Brocade 6505
Porte private dedicate 10GbE 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
Dimensione dell'unità
1.92TB
Tipo di unità
SSD
Porte target FC
16 porte da 16Gb (8 per nodo)
Porte di gestione
Cavo ethernet 1GbE che si connette agli host tramite uno switch ethernet
Porta Heartbeat
Cavo ethernet 1GbE che si collega tra due nodi di archiviazione
Porta di sincronizzazione dei dati
Cavo InfiniBand a 56Gb/s
Prima di utilizzare l'array, è necessario inizializzarlo. Per impostazione predefinita, l'indirizzo di gestione di entrambi i nodi è identico (192.168.1.1). È necessario collegarsi a ciascuno di essi e assegnare nuovi indirizzi di gestione (già diversi) e configurare la sincronizzazione dell'ora, dopo di che le porte di gestione possono essere collegate in un'unica rete. Successivamente, si procede all'unione dei nodi in una coppia HA assegnando subnet per le connessioni Interlink.
Dopo il completamento dell'inizializzazione, è possibile gestire l'array da qualsiasi nodo.
Successivamente, creiamo i volumi necessari e li pubblichiamo per i server delle applicazioni.
E' altamente raccomandato creare diversi volumi per Oracle ASM, poiché ciò aumenterà il numero di target per i server, migliorando così le prestazioni complessive (dettagli sulle code in un'altra sezione). ).
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
Alcuni chiarimenti riguardo ai modelli di funzionamento dell'array e ai processi che si verificano in situazioni anomale
Ogni nodo del set di dati ha un parametro "numero di versione". Dopo l'inizializzazione iniziale, è identico e pari a 1. Se per qualche motivo il numero di versione è diverso, si verifica sempre la sincronizzazione dei dati dalla versione più alta a quella più bassa, dopo di ché il numero della versione più bassa viene allineato, il che significa che le copie sono identiche. Le ragioni per cui le versioni potrebbero essere diverse includono:
- Riavvio programmato di uno dei nodi
- Guasto su uno dei nodi a causa di un'interruzione improvvisa (alimentazione, surriscaldamento, ecc.).
- Interruzione della connessione InfiniBand con impossibilità 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 proprio numero di versione di uno, in modo da sincronizzare il proprio set di dati una volta ripristinata la connessione con la coppia.
Se si verifica un'interruzione della connessione tramite il collegamento Ethernet, il Heartbeat passa temporaneamente a InfiniBand e ritorna indietro entro 10 secondi al ripristino.
Configurazione degli host
Per garantire l'alta disponibilità e aumentare le prestazioni, è necessario abilitare il supporto MPIO per l'array. A tal fine, è necessario aggiungere nel file /etc/multipath.conf delle 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 quindi 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 la 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 rispetto alla dimensione del blocco con cui lavora fisicamente l'array (4K). Altrimenti, potrebbero sorgere problemi di prestazioni. Pertanto, è necessario creare volumi con parametri appropriati:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Distribuzione dei database per i volumi creati per la nostra configurazione di test
Nome del volume di archiviazione
Dimensione del volume
Mappatura dei LUN dei volumi
Dettagli del dispositivo volume ASM
Dimensione dell'unità di allocazione
Data01
200GB
Mappa tutti i volumi di archiviazione a tutti i porti dati del sistema di archiviazione
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 Voto
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Ridondanza: Normale
Nome: DGGRID2
Scopo: Griglia: CRS e Voto
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
Impostazioni del database
- Dimensione del blocco = 8K
- Spazio di swap = 16GB
- Disabilita AMM (Gestione automatica della memoria)
- Disabilita le Pagine Huge 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
✓ grid hard stack 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 agli errori
Per dimostrare, è stato utilizzato HammerDB per emulare un carico di lavoro OLTP. Configurazione di HammerDB:
Numero di magazzini
256
Transazioni totali per utente
1000000000000
Utenti virtuali
256
Il risultato ottenuto è stato di 2.1M TPM, che è lontano dal limite di prestazioni del sistema , ma rappresenta 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 agli errori della soluzione nel complesso, non raggiungere i massimi in termini di prestazioni. Pertanto, ci baseremo semplicemente su questo numero.
Test di errore di uno dei nodi
Gli host hanno perso parte dei percorsi verso l'archiviazione, continuando a lavorare attraverso quelli rimanenti con il secondo nodo. Le prestazioni sono diminuite per alcuni secondi a causa della ristrutturazione dei percorsi, per poi tornare a valori normali. Non c'è stata interruzione del servizio.
Test di errore dell'armadio con tutta l'attrezzatura
In questo caso, le prestazioni sono diminuite anche per alcuni secondi a causa della ristrutturazione dei percorsi, per poi tornare a metà del valore iniziale. Il risultato è diminuito della metà a causa dell'esclusione di un server applicazioni. Non c'è stata interruzione del servizio.
Se hai bisogno di implementare una soluzione di disaster recovery Cross-Rack altamente disponibile per Oracle a un costo ragionevole e con sforzi minimi per l'implementazione e la gestione, la collaborazione tra Oracle RAC e l'architettura sarà una delle migliori opzioni. Invece di Oracle RAC, può essere utilizzato qualsiasi altro software che preveda la clusterizzazione, le stesse DBMS o sistemi di virtualizzazione, ad esempio. Il principio di costruzione della soluzione rimarrà lo stesso. E l'indicatore finale è un valore zero per RTO e RPO.
Fonte: habr.com
