Un numeru considerableu di l'applicazioni Enterprise è i sistemi di virtualizazione anu i so meccanismi propii per a custruzzione di soluzioni toleranti à i difetti. In particulare, Oracle RAC (Oracle Real Application Cluster) hè un cluster di dui o più servitori di basa di dati Oracle chì travaglianu inseme per equilibrà a carica è furnisce a tolleranza di difetti à u livellu di u servitore / applicazione. Per travaglià in questu modu, avete bisognu di un almacenamentu cumunu, chì hè di solitu un sistema di almacenamento.
Comu avemu digià discututu in unu di i nostri , u sistema d'almacenamiento stessu, malgradu a presenza di cumpunenti duplicati (cumpresi i cuntrolli), anu sempre punti di fallimentu - principarmenti in a forma di una sola serie di dati. Dunque, per custruisce una soluzione Oracle cù esigenze di affidabilità aumentate, u schema "N servers - one storage system" deve esse cumplicatu.
Prima, sicuru, avemu bisognu di decide di quale risichi avemu da pruvà à assicurà. In questu articulu, ùn cunsideremu micca a prutezzione contru minacce cum'è "un meteorite hè ghjuntu". Dunque, a custruzzione di una soluzione di ricuperazione di disastru dispersa geograficamente resterà un tema per unu di l'articuli seguenti. Quì avemu da circà à a suluzione chjamata Cross-Rack di ricuperazione di disastru, quandu a prutezzione hè custruita à u livellu di l'armarii di u servitore. L'armarii stessi ponu esse situati in a stessa stanza o in diverse, ma di solitu in u stessu edifiziu.
Questi cabinetti deve cuntene tuttu u settore necessariu di l'equipaggiu è u software chì permettenu l'operazione di basa di dati Oracle, indipendentemente da u statu di u "vicinu". In altre parolle, utilizendu a suluzione di ripresa di disastru Cross-Rack, eliminemu i risichi di fallimentu:
- Servitori di applicazioni Oracle
- Sistemi di almacenamiento
- Sistemi di cambiamentu
- Fallu cumpletu di tutti l'equipaggiu in u cabinet:
- Rifiu di putenza
- fallimentu di u sistema di raffreddamentu
- Fattori esterni (umani, natura, etc.)
A duplicazione di i servitori Oracle implica u principiu di u funziunamentu di Oracle RAC è hè implementatu attraversu una applicazione. A duplicazione di facilità di cambiamentu ùn hè ancu micca un prublema. Ma cù a duplicazione di u sistema di almacenamiento, tuttu ùn hè micca cusì simplice.
L'opzione più simplice hè a replicazione di dati da u sistema di almacenamentu principale à a copia di salvezza. Sincronu o asincronu, secondu e capacità di u sistema di almacenamiento. Cù a replicazione asincrona, a quistione hè immediata di assicurà a coherenza di dati in relazione à Oracle. Ma ancu s'ellu ci hè una integrazione di u software cù l'applicazione, in ogni casu, in casu di fallimentu in u sistema di almacenamentu principale, l'intervenzione manuale di l'amministratori serà necessaria per cambià u cluster à l'almacenamiento di salvezza.
Una opzione più cumplessa hè i "virtualizers" di almacenamiento di software è / o hardware chì elimineranu i prublemi di coerenza è l'intervenzione manuale. Ma a cumplessità di l'implementazione è l'amministrazione sussegwente, è ancu u costu assai indecente di tali suluzioni, spaventa assai.
A soluzione di array AccelStor NeoSapphire™ All Flash hè perfetta per scenarii cum'è a ripresa di disastru Cross-Rack usendu l'architettura Shared-Nothing. Stu mudellu hè un sistema di almacenamentu di dui nodi chì usa a tecnulugia FlexiRemap® patentata per travaglià cù unità flash. Grazie à NeoSapphire™ H710 hè capace di furnisce prestazioni finu à 600K IOPS@4K scrittura casuale è 1M+ IOPS@4K lettura aleatoria, chì hè inaccessibile quandu si usanu sistemi di almacenamentu classici basati in RAID.
Ma a funzione principale di NeoSapphire™ H710 hè l'esekzione di dui nodi in forma di casi separati, ognunu di i quali hà a so propria copia di e dati. A sincronizazione di i nodi hè realizatu attraversu l'interfaccia esterna InfiniBand. Grazie à questa architettura, hè pussibule distribuisce nodi in diverse lochi à una distanza di finu à 100 m, fornendu cusì una soluzione di ricuperazione di disastru Cross-Rack. I dui nodi operanu in modu sincronu. Da u latu di l'ospiti, l'H710 s'assumiglia à un sistema di almacenamentu ordinariu di dual controller. Per quessa, ùn ci hè bisognu di eseguisce qualsiasi opzioni di software o hardware supplementari o paràmetri particularmente cumplessi.
Se paragunemu tutte e soluzioni di ricuperazione di disastru Cross-Rack descritte sopra, allora l'opzione di AccelStor si distingue notevolmente da u restu:
AccelStor NeoSapphire™ hà spartutu nunda di architettura
Sistema di almacenamentu "virtualizatore" di software o hardware
Soluzione basata in replicazione
Disponibilidad
fallimentu di u servitore
Nisun tempu di fermu
Nisun tempu di fermu
Nisun tempu di fermu
fallimentu di cambià
Nisun tempu di fermu
Nisun tempu di fermu
Nisun tempu di fermu
fallimentu di u sistema di almacenamentu
Nisun tempu di fermu
Nisun tempu di fermu
Invalide
fallimentu tutale di u cabinet
Nisun tempu di fermu
Nisun tempu di fermu
Invalide
Costu è cumplessità
U costu di suluzione
Bassu*
Высокая
Высокая
A cumplessità di implementazione
Low
Высокая
Высокая
*AccelStor NeoSapphire ™ hè sempre un array All Flash, chì per definizione ùn costa micca "3 kopecks", soprattuttu perchè hà una riserva di doppia capacità. Tuttavia, quandu paragunate u costu finali di una suluzione basatu annantu à questu cù simili di altri venditori, u costu pò esse cunsideratu bassu.
A topologia per cunnette i servitori di l'applicazioni è i nodi di array All Flash sarà cusì:
Quandu a pianificazione di a topologia, hè ancu assai cunsigliatu per duplicà i switches di gestione è i servitori di interconnect.
Quì è più avanti parleremu di cunnessione via Fibre Channel. Se utilizate iSCSI, tuttu serà u listessu, aghjustatu per i tipi di switches utilizati è paràmetri di array ligeramente diffirenti.
U travagliu preparatoriu nantu à a matrice
L'equipaggiu è u software utilizatu
Specificazioni di u Servitore è Switch
Cumpunenti
discrizzione
Servitori Oracle Database 11g
Dui
Sistema upirativu di u servitore
oracle linux
Versione di basa di dati Oracle
11 g (RAC)
Processori per servitore
Dui 16 core Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Memoria fisica per servitore
128GB
rete FC
16 Gb/s FC cù multipathing
FC HBA
Emulex Lpe-16002B
Porti publichi 1GbE dedicati per a gestione di cluster
Adattatore ethernet Intel RJ45
Switch FC 16 Gb/s
Brocatu 6505
Porti privati 10GbE dedicati per a sincronizazione di dati
Intel X520
AccelStor NeoSapphire™ All Flash Array Specification
Cumpunenti
discrizzione
Sistema di almacenamentu
Mudellu d'alta dispunibilità NeoSapphire™: H710
Versione di l'imagine
4.0.1
U numeru tutale di unità
48
Dimensione di u drive
1.92TB
Unità di Drive
SSD
Porti di destinazione FC
16x porti 16Gb (8 per node)
Porti di gestione
U cable ethernet 1GbE cunnessu à l'ospiti via un switch ethernet
Portu di u battu di u core
U cable ethernet 1GbE chì cunnetta trà dui nodi di almacenamiento
Portu di sincronizazione di dati
Cavo InfiniBand 56 Gb/s
Prima di pudè utilizà un array, duvete inizializà. Per automaticamente, l'indirizzu di cuntrollu di i dui nodi hè u stessu (192.168.1.1). Avete bisognu di cunnette cù elli unu per unu è stabilisce novi (dighjà diversi) indirizzi di gestione è stabilisce a sincronizazione di u tempu, dopu chì i porti di Gestione ponu esse cunnessi à una sola reta. Dopu, i nodi sò cumminati in un paru HA assignendu subnets per e cunnessione Interlink.
Dopu chì l'inizializazione hè cumpleta, pudete gestisce l'array da qualsiasi node.
In seguitu, creamu i volumi necessarii è i publichi in i servitori di l'applicazioni.
Hè ricumandemu assai di creà volumi multipli per Oracle ASM, postu chì questu aumenterà u nùmeru di miri per i servitori, chì in fine migliurà u rendiment generale (più nantu à fila in un altru. ).
Pruvate a cunfigurazione
Nome di u Volume di Storage
Dimensione Volume
Dati01
200GB
Dati02
200GB
Dati03
200GB
Dati04
200GB
Dati05
200GB
Dati06
200GB
Dati07
200GB
Dati08
200GB
Dati09
200GB
Dati10
200GB
Griglia 01
1GB
Griglia 02
1GB
Griglia 03
1GB
Griglia 04
1GB
Griglia 05
1GB
Griglia 06
1GB
Rifà 01
100GB
Rifà 02
100GB
Rifà 03
100GB
Rifà 04
100GB
Rifà 05
100GB
Rifà 06
100GB
Rifà 07
100GB
Rifà 08
100GB
Rifà 09
100GB
Rifà 10
100GB
Alcune spiegazioni nantu à i modi operativi di l'array è i prucessi chì si trovanu in situazioni d'emergenza
U settore di dati di ogni nodu hà un paràmetru di "numeru di versione". Dopu à l'inizializazione iniziale, hè uguali è uguali à 1. Se per qualchì mutivu u numeru di versione hè diversu, allora i dati sò sempre sincronizati da a versione più vechja à a più ghjovana, dopu chì u numeru di a versione più ghjovana hè allinata, i.e. questu significa chì e copie sò identiche. Motivi per chì e versioni ponu esse diverse:
- Reboot pianificatu di unu di i nodi
- Un accidentu nantu à unu di i nodi per un arrestu bruscu (furnimentu di energia, surriscaldamentu, etc.).
- Cunnessione InfiniBand persa cù incapacità di sincronizà
- Un crash in unu di i nodi per via di corruzzione di dati. Quì avete bisognu di creà un novu gruppu HA è a sincronizazione cumpleta di u settore di dati.
In ogni casu, u node chì ferma in linea aumenta u so numeru di versione da unu per sincronizà u so settore di dati dopu chì a cunnessione cù a coppia hè restaurata.
Se a cunnessione nantu à u ligame Ethernet hè persa, Heartbeat cambia temporaneamente à InfiniBand è torna in 10 seconde quandu hè restauratu.
Stabbilimentu di l'ospiti
Per assicurà a tolleranza di difetti è migliurà u rendiment, deve attivà u supportu MPIO per l'array. Per fà questu, avete bisognu di aghjunghje linee à u schedariu /etc/multipath.conf, è dopu ripigliate u serviziu multipath.
Testu oculatudispusitivi {
dispusitivu {
venditore "AStor"
path_grouping_policy "group_by_prio"
path_selector "queue-length 0"
path_checker "tur"
caratteristiche "0"
hardware_handler "0"
prio "const"
fallimentu immediata
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names sì
detect_prio sì
rr_min_io_rq 1
no_path_retry 0
}
}
Dopu, per chì ASM travaglia cù MPIO via ASMLib, avete bisognu di cambià u schedariu /etc/sysconfig/oracleasm è poi eseguite /etc/init.d/oracleasm scandisks.
Testu oculatu
# ORACLEASM_SCANORDER: Modelli currispondenti per urdinà a scansione di discu
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Modelli currispondenti per escludiri i dischi da a scansione
ORACLEASM_SCANEXCLUDE="sd"
Vita
Se ùn vulete micca aduprà ASMLib, pudete aduprà e regule UDEV, chì sò a basa per ASMLib.
Partendu da a versione 12.1.0.2 di Oracle Database, l'opzione hè dispunibule per a stallazione cum'è parte di u software ASMFD.
Hè imperativu per assicurà chì i dischi creati per Oracle ASM sò allinati cù a dimensione di bloccu chì l'array opera fisicamente cù (4K). Altrimenti, i prublemi di rendiment ponu accade. Dunque, hè necessariu di creà volumi cù i paràmetri adattati:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1
Distribuzione di basa di dati in volumi creati per a nostra cunfigurazione di prova
Nome di u Volume di Storage
Dimensione Volume
Mappatura di LUN di volumi
ASM Volume Detail Device
Dimensione unità di allocazione
Dati01
200GB
Mappa tutti i volumi di almacenamiento à u sistema di almacenamentu tutti i porti di dati
Redundancy: Normale
Nome: DGDATA
Scopu: File di dati
4MB
Dati02
200GB
Dati03
200GB
Dati04
200GB
Dati05
200GB
Dati06
200GB
Dati07
200GB
Dati08
200GB
Dati09
200GB
Dati10
200GB
Griglia 01
1GB
Redundancy: Normale
Nome: DGGRID1
Purpose: Griglia: CRS è Votu
4MB
Griglia 02
1GB
Griglia 03
1GB
Griglia 04
1GB
Redundancy: Normale
Nome: DGGRID2
Purpose: Griglia: CRS è Votu
4MB
Griglia 05
1GB
Griglia 06
1GB
Rifà 01
100GB
Redundancy: Normale
Nome : DGREDO1
Scopu: Rifà u logu di u filu 1
4MB
Rifà 02
100GB
Rifà 03
100GB
Rifà 04
100GB
Rifà 05
100GB
Rifà 06
100GB
Redundancy: Normale
Nome : DGREDO2
Scopu: Rifà u logu di u filu 2
4MB
Rifà 07
100GB
Rifà 08
100GB
Rifà 09
100GB
Rifà 10
100GB
Impostazioni di basa di dati
- Dimensione di u bloccu = 8K
- Spaziu di scambiu = 16 GB
- Disattivà AMM (Gestione Automatica di Memoria)
- Disattivà e pagine enormi trasparenti
Altri paràmetri
# 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 # ùn mette micca questu s'è vo aduprate Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ griglia dura nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ grid soft stack 10240
✓ griglia dura 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;
cambia u sistema di u sistema session_cached_cursors = 300 scope = spfile;
altera u sistema set db_files = 8192 scope = spfile;
Test di fallimentu
Per scopi di dimostrazione, HammerDB hè stata utilizata per emulà una carica OLTP. Configurazione HammerDB:
Numero di magazzini
256
Total Transacciones per User
1000000000000
Utenti Virtuali
256
U risultatu era un TPM 2.1M, chì hè luntanu da u limitu di rendiment di l'array , ma hè un "tettu" per a cunfigurazione hardware attuale di i servitori (principalmente per via di i prucessori) è u so numeru. U scopu di sta prova hè sempre di dimustrà a tolleranza di difetti di a suluzione in tuttu, è micca di ottene u massimu rendiment. Dunque, avemu da custruì solu nantu à sta figura.
Test per fallimentu di unu di i nodi
L'ospiti anu persu una parte di i camini à l'almacenamiento, cuntinuendu à travaglià cù u restu cù u sicondu node. A prestazione hè cascata per uni pochi di sicondi per via di i camini chì sò stati ricustruiti, è dopu tornanu à a normale. Ùn ci era micca interruzzione in u serviziu.
Test di fallimentu di l'armadiu cù tutti l'equipaggiu
In questu casu, u rendiment hè ancu cascatu per uni pochi di seconde per via di a ristrutturazione di i camini, è poi torna à a mità di u valore originale. U risultatu hè statu dimezzatu da l'iniziale per via di l'esclusione di un servitore d'applicazione da l'operazione. Ùn ci era micca interruzzione in u serviziu.
Se ci hè bisognu di implementà una soluzione di ricuperazione di disastru Cross-Rack tolerante à i difetti per Oracle à un costu raghjone è cù pocu sforzu di implementazione / amministrazione, allora Oracle RAC è l'architettura travaglianu inseme. serà una di e migliori opzioni. Invece di Oracle RAC, pò esse qualsiasi altru software chì furnisce clustering, u stessu DBMS o sistemi di virtualizazione, per esempiu. U principiu di a custruzzione di a suluzione ferma u listessu. È u fondu hè zero per RTO è RPO.
Source: www.habr.com