Un număr considerabil de aplicații Enterprise și sisteme de virtualizare au propriile mecanisme pentru construirea de soluții tolerante la erori. Mai exact, Oracle RAC (Oracle Real Application Cluster) este un cluster de două sau mai multe servere de baze de date Oracle care lucrează împreună pentru a echilibra încărcarea și pentru a oferi toleranță la erori la nivel de server/aplicație. Pentru a lucra în acest mod, aveți nevoie de un spațiu de stocare partajat, care este de obicei un sistem de stocare.
După cum am discutat deja într-unul dintre , sistemul de stocare în sine, în ciuda prezenței componentelor duplicate (inclusiv controlere), are încă puncte de defecțiune - în principal sub forma unui singur set de date. Prin urmare, pentru a construi o soluție Oracle cu cerințe de fiabilitate sporite, schema „N servere - un sistem de stocare” trebuie să fie complicată.
În primul rând, desigur, trebuie să decidem împotriva căror riscuri încercăm să ne asigurăm. În acest articol, nu vom lua în considerare protecția împotriva amenințărilor precum „un meteorit a sosit”. Așadar, construirea unei soluții de recuperare în caz de dezastru dispersate geografic va rămâne un subiect pentru unul dintre articolele următoare. Aici ne vom uita la așa-numita soluție de recuperare în caz de dezastru Cross-Rack, când protecția este construită la nivelul dulapurilor serverelor. Dulapurile în sine pot fi amplasate în aceeași cameră sau în altele diferite, dar de obicei în cadrul aceleiași clădiri.
Aceste dulapuri trebuie să conțină întregul set necesar de echipamente și software care să permită funcționarea bazelor de date Oracle indiferent de starea „vecinului”. Cu alte cuvinte, folosind soluția de recuperare în caz de dezastru Cross-Rack, eliminăm riscurile de eșec:
- Servere de aplicații Oracle
- Sisteme de stocare
- Sisteme de comutare
- Defecțiune completă a tuturor echipamentelor din cabinet:
- Refuzul puterii
- Defecțiune a sistemului de răcire
- Factori externi (uman, natura etc.)
Duplicarea serverelor Oracle implică însuși principiul de funcționare al Oracle RAC și este implementată printr-o aplicație. Dublarea instalațiilor de comutare nu este, de asemenea, o problemă. Dar cu duplicarea sistemului de stocare, totul nu este atât de simplu.
Cea mai simplă opțiune este replicarea datelor din sistemul de stocare principal în cel de rezervă. Sincron sau asincron, în funcție de capacitățile sistemului de stocare. Cu replicarea asincronă, se pune imediat întrebarea de a asigura consistența datelor în raport cu Oracle. Dar chiar dacă există integrare software cu aplicația, în orice caz, în cazul unei defecțiuni a sistemului de stocare principal, va fi necesară intervenția manuală a administratorilor pentru a trece cluster-ul pe stocarea de rezervă.
O opțiune mai complexă sunt „virtualizatoarele” de stocare software și/sau hardware care vor elimina problemele de consistență și intervenția manuală. Dar complexitatea implementării și a administrării ulterioare, precum și costul foarte indecent al unor astfel de soluții îi sperie pe mulți.
Soluția de matrice AccelStor NeoSapphire™ All Flash este perfectă pentru scenarii precum recuperarea în caz de dezastru Cross-Rack folosind arhitectura Shared-Nothing. Acest model este un sistem de stocare cu două noduri care utilizează tehnologia proprie FlexiRemap® pentru a lucra cu unități flash. Mulțumită NeoSapphire™ H710 este capabil să ofere performanțe de până la 600K IOPS@4K de scriere aleatorie și 1M+ IOPS@4K de citire aleatorie, ceea ce este de neatins atunci când utilizați sisteme clasice de stocare bazate pe RAID.
Dar principala caracteristică a lui NeoSapphire™ H710 este execuția a două noduri sub formă de cazuri separate, fiecare dintre ele având propria copie a datelor. Sincronizarea nodurilor se realizează prin interfața externă InfiniBand. Datorită acestei arhitecturi, este posibilă distribuirea nodurilor în diferite locații la o distanță de până la 100 m, oferind astfel o soluție de recuperare în caz de dezastru Cross-Rack. Ambele noduri funcționează complet sincron. Din partea gazdei, H710 arată ca un sistem de stocare obișnuit cu dublu controler. Prin urmare, nu este nevoie să efectuați opțiuni software sau hardware suplimentare sau setări deosebit de complexe.
Dacă comparăm toate soluțiile de recuperare în caz de dezastru Cross-Rack descrise mai sus, atunci opțiunea de la AccelStor se evidențiază vizibil de restul:
Arhitectura AccelStor NeoSapphire™ Shared Nothing
Sistem de stocare „virtualizator” software sau hardware
Soluție bazată pe replicare
disponibilitate
Eroare de server
Fără oprire
Fără oprire
Fără oprire
Eșecul comutatorului
Fără oprire
Fără oprire
Fără oprire
Defecțiunea sistemului de stocare
Fără oprire
Fără oprire
Downtime
Întreaga eroare a cabinetului
Fără oprire
Fără oprire
Downtime
Cost și complexitate
Costul soluției
Scăzut*
Mare
Mare
Complexitatea implementării
scăzut
Mare
Mare
*AccelStor NeoSapphire™ este încă o matrice All Flash, care prin definiție nu costă „3 copeici”, mai ales că are o rezervă de capacitate dublă. Cu toate acestea, atunci când se compară costul final al unei soluții bazate pe aceasta cu cele similare de la alți furnizori, costul poate fi considerat scăzut.
Topologia pentru conectarea serverelor de aplicații și a nodurilor de matrice All Flash va arăta astfel:
Atunci când planificați topologia, este foarte recomandat să duplicați comutatoarele de management și să interconectați serverele.
Aici și mai departe vom vorbi despre conectarea prin Fibre Channel. Dacă utilizați iSCSI, totul va fi la fel, ajustat pentru tipurile de comutatoare utilizate și setări de matrice ușor diferite.
Lucrări pregătitoare asupra matricei
Echipamente și software utilizate
Specificații server și switch
Componente
descriere
Servere Oracle Database 11g
două
Sistem de operare server
Oracle Linux
Versiunea bazei de date Oracle
11 g (RAC)
Procesoare pe server
Două procesor Intel® Xeon® E16-5 v2667 cu 2 nuclee la 3.30 GHz
Memoria fizică pe server
128GB
Rețeaua FC
16 Gb/s FC cu multipathing
FC HBA
Emulex Lpe-16002B
Porturi publice 1GbE dedicate pentru gestionarea clusterelor
Adaptor Intel Ethernet RJ45
Comutator FC de 16 Gb/s
Brocart 6505
Porturi private 10GbE dedicate pentru sincronizarea datelor
Intel X520
Specificații AccelStor NeoSapphire™ All Flash Array
Componente
descriere
Sistem de stocare
Model de înaltă disponibilitate NeoSapphire™: H710
Versiune imagine
4.0.1
Numărul total de unități
48
Dimensiunea unității
1.92TB
Tipul de unitate
SSD
Porturile țintă FC
16 porturi de 16 Gb (8 per nod)
Porturi de management
Cablul Ethernet 1GbE care se conectează la gazde prin intermediul unui comutator Ethernet
Portul pentru bătăile inimii
Cablul Ethernet 1GbE care se conectează între două noduri de stocare
Port de sincronizare a datelor
Cablu InfiniBand de 56 Gb/s
Înainte de a putea utiliza o matrice, trebuie să o inițializați. În mod implicit, adresa de control a ambelor noduri este aceeași (192.168.1.1). Trebuie să vă conectați la ele unul câte unul și să setați noi adrese de management (deja diferite) și să configurați sincronizarea timpului, după care porturile de management pot fi conectate la o singură rețea. Ulterior, nodurile sunt combinate într-o pereche HA prin alocarea de subrețele pentru conexiunile Interlink.
După finalizarea inițializării, puteți gestiona matricea de la orice nod.
Apoi, creăm volumele necesare și le publicăm pe serverele de aplicații.
Este foarte recomandat să creați mai multe volume pentru Oracle ASM, deoarece acest lucru va crește numărul de ținte pentru servere, ceea ce va îmbunătăți în cele din urmă performanța generală (mai multe despre cozile în altă parte). ).
Testați configurația
Nume volum de stocare
Dimensiunea volumului
Date01
200GB
Date02
200GB
Date03
200GB
Date04
200GB
Date05
200GB
Date06
200GB
Date07
200GB
Date08
200GB
Date09
200GB
Date10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Reface01
100GB
Reface02
100GB
Reface03
100GB
Reface04
100GB
Reface05
100GB
Reface06
100GB
Reface07
100GB
Reface08
100GB
Reface09
100GB
Reface10
100GB
Câteva explicații despre modurile de funcționare ale matricei și procesele care apar în situații de urgență
Setul de date al fiecărui nod are un parametru „număr versiune”. După inițializarea inițială, este același și egal cu 1. Dacă din anumite motive numărul versiunii este diferit, atunci datele sunt întotdeauna sincronizate de la versiunea mai veche la cea mai tânără, după care numărul versiunii mai tinere este aliniat, adică. aceasta înseamnă că copiile sunt identice. Motive pentru care versiunile pot fi diferite:
- Repornire programată a unuia dintre noduri
- Un accident pe unul dintre noduri din cauza unei opriri bruște (alimentare, supraîncălzire etc.).
- S-a pierdut conexiunea InfiniBand cu incapacitatea de sincronizare
- O blocare pe unul dintre noduri din cauza coruperii datelor. Aici va trebui să creați un nou grup HA și să finalizați sincronizarea setului de date.
În orice caz, nodul care rămâne online își mărește numărul versiunii cu unul pentru a-și sincroniza setul de date după restabilirea conexiunii cu perechea.
Dacă conexiunea prin conexiunea Ethernet este pierdută, Heartbeat comută temporar la InfiniBand și revine înapoi în 10 secunde când este restabilită.
Configurarea gazdelor
Pentru a asigura toleranța la erori și a îmbunătăți performanța, trebuie să activați suportul MPIO pentru matrice. Pentru a face acest lucru, trebuie să adăugați linii în fișierul /etc/multipath.conf și apoi să reporniți serviciul multipath
Text ascunsdispozitive {
dispozitiv {
furnizor „AStor”
path_grouping_policy „group_by_prio”
path_selector „lungimea cozii 0”
path_checker "tur"
caracteristici „0”
hardware_handler „0”
prior "const"
failback imediat
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names da
detect_prio da
rr_min_io_rq 1
no_path_retry 0
}
}
Apoi, pentru ca ASM să funcționeze cu MPIO prin ASMLib, trebuie să modificați fișierul /etc/sysconfig/oracleasm și apoi să rulați /etc/init.d/oracleasm scandisks
Text ascuns
# ORACLEASM_SCANORDER: Potrivirea modelelor pentru a comanda scanarea discului
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Modele de potrivire pentru a exclude discurile din scanare
ORACLEASM_SCANEXCLUDE="sd"
Nota
Dacă nu doriți să utilizați ASMLib, puteți utiliza regulile UDEV, care sunt baza pentru ASMLib.
Începând cu versiunea 12.1.0.2 a bazei de date Oracle, opțiunea este disponibilă pentru instalare ca parte a software-ului ASMFD.
Este imperativ să vă asigurați că discurile create pentru Oracle ASM sunt aliniate cu dimensiunea blocului cu care funcționează fizic matricea (4K). În caz contrar, pot apărea probleme de performanță. Prin urmare, este necesar să se creeze volume cu parametrii corespunzători:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optim 1
Distribuția bazelor de date în volumele create pentru configurația noastră de testare
Nume volum de stocare
Dimensiunea volumului
Maparea LUN-urilor de volum
Detaliu dispozitiv de volum ASM
Dimensiunea unității de alocare
Date01
200GB
Mapați toate volumele de stocare către sistemul de stocare, toate porturile de date
Redundanță: normală
Nume: DGDATA
Scop: fișiere de date
4MB
Date02
200GB
Date03
200GB
Date04
200GB
Date05
200GB
Date06
200GB
Date07
200GB
Date08
200GB
Date09
200GB
Date10
200GB
Grid01
1GB
Redundanță: normală
Nume: DGGRID1
Scop: Grilă: CRS și Vot
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundanță: normală
Nume: DGGRID2
Scop: Grilă: CRS și Vot
4MB
Grid05
1GB
Grid06
1GB
Reface01
100GB
Redundanță: normală
Nume: DGRADO1
Scop: Refaceți jurnalul firului 1
4MB
Reface02
100GB
Reface03
100GB
Reface04
100GB
Reface05
100GB
Reface06
100GB
Redundanță: normală
Nume: DGRADO2
Scop: Refaceți jurnalul firului 2
4MB
Reface07
100GB
Reface08
100GB
Reface09
100GB
Reface10
100GB
Setări baze de date
- Dimensiunea blocului = 8K
- Spațiu de schimb = 16 GB
- Dezactivați AMM (gestionarea automată a memoriei)
- Dezactivați paginile mari transparente
Alte setari
# 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 # nu setați acest lucru dacă utilizați 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 de eșec
În scopuri demonstrative, HammerDB a fost folosit pentru a emula o încărcare OLTP. Configurație HammerDB:
Numărul de depozite
256
Total tranzacții per utilizator
1000000000000
Utilizatori virtuali
256
Rezultatul a fost un TPM de 2.1 milioane, care este departe de limita de performanță a matricei , dar este un „plafon” pentru configurația hardware actuală a serverelor (în primul rând datorită procesoarelor) și numărul acestora. Scopul acestui test este încă acela de a demonstra toleranța la erori a soluției în ansamblu și nu de a obține performanța maximă. Prin urmare, ne vom baza pur și simplu pe această cifră.
Testarea defecțiunii unuia dintre noduri
Gazdele au pierdut o parte din căile către stocare, continuând să lucreze prin cele rămase cu al doilea nod. Performanța a scăzut pentru câteva secunde din cauza căilor care au fost reconstruite, apoi au revenit la normal. Nu a existat nicio întrerupere în serviciu.
Test de defectare a dulapului cu toate echipamentele
În acest caz, performanța a scăzut, de asemenea, pentru câteva secunde din cauza restructurării căilor, apoi a revenit la jumătate din valoarea inițială. Rezultatul a fost redus la jumătate față de cel inițial din cauza excluderii unui server de aplicații din funcționare. Nu a existat nicio întrerupere în serviciu.
Dacă este necesar să se implementeze o soluție de recuperare în caz de dezastru Cross-Rack tolerantă la erori pentru Oracle la un cost rezonabil și cu un efort mic de implementare/administrare, atunci Oracle RAC și arhitectura lucrează împreună va fi una dintre cele mai bune opțiuni. În loc de Oracle RAC, poate exista orice alt software care oferă clustering, același DBMS sau sisteme de virtualizare, de exemplu. Principiul construirii soluției va rămâne același. Iar linia de jos este zero pentru RTO și RPO.
Sursa: www.habr.com