Multe aplicații Enterprise și sisteme de virtualizare au propriile mecanisme pentru construirea soluțiilor de reziliență. În special, Oracle RAC (Oracle Real Application Cluster) reprezintă un cluster format din două sau mai multe servere de baze de date Oracle care lucrează împreună pentru a asigura echilibrarea încărcăturii și reziliența la nivel de server/aplicație. Pentru a funcționa în acest mod, este necesar un stocaj comun, din care de obicei este responsabilă o SAI.
Așa cum am discutat deja într-unul din , însă, SAI-ul în sine, în ciuda existenței componentelor duplicate (inclusiv a controlerelor), are totuși puncte de eșec – în principal, sub forma unui set unic de date. Prin urmare, pentru a construi o soluție Oracle cu cerințe ridicate de fiabilitate, schema „N servere – o SAI” trebuie să fie complicată.
Mai întâi, desigur, trebuie să ne dăm seama de la ce riscuri încercăm să ne protejăm. În cadrul acestui articol, nu vom aborda protecția împotriva amenințărilor de tip „a căzut un meteorit”. Așadar, construirea unei soluții de recuperare în caz de dezastru dispersate teritorial va rămâne subiectul unuia dintre articolele următoare. Aici vom analiza așa-numita soluție de recuperare în caz de dezastru Cross-Rack, când protecția se construiește la nivel de rack-uri de servere. Rack-urile pot fi situate fie în aceeași cameră, fie în diferite, dar de obicei în cadrul unei singure clădiri.
Aceste rack-uri trebuie să conțină întreaga echipare și software necesare care să permită funcționarea bazelor de date Oracle, indiferent de starea „vecinului”. Cu alte cuvinte, utilizând soluția de recuperare în caz de dezastru Cross-Rack, exclus riscurile în cazul unei defecțiuni:
- Serverele aplicației Oracle
- Sistemele de stocare
- Sistemele de comutare
- Pierderea totală a întregii echipamente din rack:
- Defecțiune de alimentare
- Defecțiune a sistemului de răcire
- Factori externi (om, natură etc.)
Duplicarea serverelor Oracle implică însăși esența funcționării Oracle RAC și se realizează prin intermediul aplicației. Duplicarea echipamentelor de comutare nu reprezintă o problemă. Însă cu duplicarea sistemului de stocare nu este atât de simplu.
Cea mai simplă variantă este replicarea datelor de la sistemul de stocare principal la cel de rezervă. Aceasta poate fi sincronă sau asincronă, în funcție de Capacitățile sistemului de stocare. În cazul replicării asincrone, imediat apare întrebarea privind asigurarea consistenței datelor cu Oracle. Chiar și în cazul unei integrații software cu aplicația, în orice situație, în cazul unei avarii la sistemul de stocare principal, va fi necesară intervenția administratorilor în mod manual pentru a comuta clusterul pe stocarea de rezervă.
O variantă mai complexă este utilizarea „virtualizatorilor” software și/sau hardware pentru sistemul de stocare, care elimină problemele de consistență și intervenția manuală. Totuși, complexitatea desfășurării și a administrării ulterioare, precum și costul destul de ridicat al acestor soluții îi descurajează pe mulți.
Exact pentru astfel de scenarii, cum ar fi recuperarea în caz de dezastru Cross-Rack, soluția All Flash AccelStor NeoSapphire™ se potrivește perfect. folosind arhitectura Shared-Nothing. Acest model reprezintă un sistem de stocare cu două noduri, utilizând propria tehnologie FlexiRemap® pentru a lucra cu unități flash. Datorită NeoSapphire™ H710 este capabil să ofere performanțe de până la 600K IOPS@4K scriere aleatorie și 1M+ IOPS@4K citire aleatorie, ceea ce este ineficient cu sistemele RAID clasice.
Dar caracteristica principală a NeoSapphire™ H710 este execuția a două noduri sub formă de carcase separate, fiecare având propriul set de date. Sincronizarea nodurilor se efectuează printr-o interfață externă InfiniBand. Datorită acestei arhitecturi, nodurile pot fi amplasate în locații diferite la o distanță de până la 100m, asigurând astfel soluția de recuperare în caz de dezastru Cross-Rack. Ambele noduri funcționează complet în mod sincron. Din partea gazdelor, H710 arată ca un sistem de stocare cu două controlere obișnuite. Prin urmare, nu este necesar să se efectueze opțiuni software sau hardware suplimentare și setări deosebit de complicate.
Dacă comparăm toate soluțiile de mai sus pentru recuperarea în caz de dezastru Cross-Rack, varianta de la AccelStor se remarcă semnificativ față de celelalte:
AccelStor NeoSapphire™ Arhitectura Shared Nothing
Virtualizator software sau hardware pentru sistemul de stocare
Soluție bazată pe replicare
Disponibilitate
Dezvoltarea serverului
Fără downtime
Fără downtime
Fără downtime
Dezvoltarea comutatorului
Fără downtime
Fără downtime
Fără downtime
Dezvoltarea sistemului de stocare
Fără downtime
Fără downtime
Downtime
Dezvoltarea întregului rack
Fără downtime
Fără downtime
Downtime
Cost și complexitate
Costul soluției
Scăzut*
Ridicată
Ridicată
Complexitate de desfășurare
Mic
Ridicată
Ridicată
*AccelStor NeoSapphire™ este totuși un sistem de stocare All Flash, care prin definiție nu costă „3 bani”, cu atât mai mult având un rezervă de capacitate dublă. Totuși, comparând costul final al soluției bazate pe acesta cu cele similare de la alți furnizori, prețul poate fi considerat scăzut.
Topologia de conectare a serverelor de aplicații și nodurilor All Flash va arăta astfel:
Atunci când planificați topologia, este de asemenea extrem de recomandat să realizați duplicarea comutatoarelor de gestionare și interconexiune a serverelor.
Aici și mai departe se va discuta despre conectarea prin Fibre Channel. În cazul utilizării iSCSI, va fi tot același lucru, cu ajustările necesare pentru tipurile de comutatoare utilizate și câteva setări diferite ale sistemului de stocare.
Lucrări pregătitoare la sistemul de stocare
Echipamentele și software-ul utilizat
Specificații ale serverelor și comutatoarelor
Componente
Descriere
Servere Oracle Database 11g
Două
Sistem de operare al serverului
Oracle Linux
Versiunea bazei de date Oracle
11g (RAC)
Procesoare per server
Două CPU Intel® Xeon® E5-2667 v2 @ 3.30GHz cu 16 nuclee
Memorie fizică pe server
128GB
Rețea FC
FC de 16Gb/s cu multipath
FC HBA
Emulex Lpe-16002B
Porturi publice dedicate 1GbE pentru managementul clusterului
Adaptor ethernet Intel RJ45
Comutator FC de 16Gb/s
Brocade 6505
Porturi private dedicate 10GbE pentru sincronizarea datelor
Intel X520
Specificația sistemului de stocare AccelStor NeoSapphire™ All Flash
Componente
Descriere
Sistem de stocare
Model de disponibilitate înaltă NeoSapphire™: H710
Versiunea imaginii
4.0.1
Numărul total de unități
48
Dimensiunea unității
1.92TB
Tipul unității
SSD
Porturi de țintă FC
16x porturi de 16Gb (8 per nod)
Porturi de management
Cablul ethernet 1GbE conectând la gazde printr-un comutator ethernet
Port de monitorizare
Cablul ethernet 1GbE conectând între două noduri de stocare
Port de sincronizare a datelor
Cablul InfiniBand de 56Gb/s
Înainte de a începe utilizarea sistemului de stocare, acesta trebuie inițializat. Implicit, adresa de management a ambelor noduri este aceeași (192.168.1.1). Trebuie să vă conectați alternativ la ele și să stabiliți adrese de management noi (deja diferite) și să configurați sincronizarea timpului, după care porturile de management pot fi conectate într-o rețea unificată. Apoi, se realizează gruparea nodurilor într-o pereche HA prin alocarea subnet-urilor pentru conexiunile Interlink.
După finalizarea inițializării, sistemul de stocare poate fi gestionat de la oricare nod.
Apoi creăm volumele necesare și le publicăm pentru serverele de aplicații.
Este extrem de recomandat să creați mai multe volume pentru Oracle ASM, deoarece aceasta va crește numărul de ținte pentru servere, ceea ce, în cele din urmă, va îmbunătăți performanța generală (mai multe despre cozi într-o altă parte). ).
Configurația de testare
Numele volumului de stocare
Dimensiunea volumului
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
Unele explicații referitoare la modurile de operare ale array-ului și la procesele care au loc în situații neprevăzute
Fiecare nod are un parametru «număr versiune» în setul de date. După inițializarea inițială, acesta este același și egal cu 1. Dacă din diverse motive numărul versiunii este diferit, datele sunt întotdeauna sincronizate de la versiunea superioară la cea inferioară, după care numărul versiunii inferioare se aliniază, adică acest lucru înseamnă că copiile sunt identice. Motivele pentru care versiunile pot fi diferite sunt:
- Reboot-ul planificat al uneia dintre noduri
- O defecțiune pe unul dintre noduri din cauza unei opriri bruște (alimentare, supraîncălzire etc.).
- Dezactivarea conexiunii InfiniBand fără posibilitatea de sincronizare
- O defecțiune pe unul dintre noduri din cauza deteriorării datelor. Aici va fi necesară crearea unui nou grup HA și o sincronizare completă a setului de date.
În oricare caz, nodul care rămâne online își crește numărul versiunii cu unu, astfel încât după restaurarea conexiunii cu perechea să poată sincroniza setul său de date.
Dacă are loc o deconectare pe linia Ethernet, Heartbeat comută temporar pe InfiniBand și revine înapoi în termen de 10s la restabilirea conexiunii.
Configurarea gazdelor
Pentru a asigura redundanța și a crește performanța, este necesar să activați suportul MPIO pentru array. Pentru aceasta, trebuie adăugați în fișierul /etc/multipath.conf liniile, după care se va reporni serviciul multipath.
Text ascunsdevices {
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
}
}
În continuare, pentru ca ASM să funcționeze cu MPIO prin ASMLib, este necesară modificarea fișierului /etc/sysconfig/oracleasm și apoi executarea /etc/init.d/oracleasm scandisks.
Text ascuns
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER=«dm»
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE=«sd»
Notă
Dacă nu doriți să folosiți ASMLib, puteți utiliza regulile UDEV, care sunt baza pentru ASMLib.
Începând cu versiunea 12.1.0.2 Oracle Database opțiunea este disponibilă pentru instalare ca parte a software-ului ASMFD.
Este necesar să se asigure că discurile create pentru Oracle ASM sunt aliniate în raport cu dimensiunea blocului cu care funcționează fizic array-ul (4K). Altfel, pot apărea probleme cu performanța. 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 optimal 1
Distribuirea bazelor de date pe volumele create pentru configurația noastră de test
Numele volumului de stocare
Dimensiunea volumului
Maparea LUN-urilor volumelor
Detalii despre dispozitivul volumului ASM
Dimensiunea unității de alocare
Data01
200GB
Mapează toate volumele de stocare la toate porturile de date ale sistemului de stocare
Redundanță: Normal
Nume: DGDATA
Scop: Fișiere de date
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundanță: Normal
Nume: DGGRID1
Scop: Grid: CRS și votare
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundanță: Normal
Nume: DGGRID2
Scop: Grid: CRS și votare
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redundanță: Normal
Nume: DGREDO1
Scop: Jurnal redoing fir 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundanță: Normal
Nume: DGREDO2
Scop: Jurnal redoing fir 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Setări bază de date
- Dimensiunea blocului = 8K
- Spațiu swap = 16GB
- Dezactivează AMM (Gestionarea automată a memoriei)
- Dezactivează paginile uriașe transparente
Alte setări
# 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 reziliență
Pentru demonstrare, a fost folosit HammerDB pentru a emula o încărcare OLTP. Configurarea HammerDB:
Numărul de depozite
256
Totalul tranzacțiilor pe utilizator
1000000000000
Utilizatori virtuali
256
În rezultatul obținut, s-a înregistrat un indicator de 2.1M TPM, care este departe de limita de performanță a aranjamentului , dar reprezintă „tavanul” pentru configurația hardware actuală a serverelor (în principal din cauza procesoarelor) și a numărului lor. Scopul acestui test este totuși demonstrarea rezilienței soluției în ansamblu, și nu atingerea maximelor de performanță. Prin urmare, ne vom baza doar pe această cifră.
Test de eșec al uneia dintre noduri
Hosturile au pierdut o parte din căile către stocare, continuând să funcționeze prin căile rămase cu al doilea nod. Performanța a scăzut timp de câteva secunde din cauza reconstrucției căilor, apoi a revenit la valorile normale. Nu a avut loc o întrerupere a serviciului.
Test de eșec al raftului cu tot echipamentul
În acest caz, performanța a scăzut de asemenea timp de câteva secunde din cauza reconstrucției căilor, apoi a revenit la jumătate din valoarea inițială. Rezultatul a fost redus la jumătate din valoarea inițială datorită excluderii unui server de aplicație. Nici o întrerupere a serviciului nu a avut loc.
Dacă aveți nevoie de o soluție de recuperare în caz de dezastru Cross-Rack pentru Oracle, care să fie accesibilă ca preț și cu eforturi reduse de implementare/administrație, atunci colaborarea dintre Oracle RAC și arhitectură va fi una dintre cele mai bune opțiuni. În loc de Oracle RAC, poate fi orice alt software care suportă clusterizarea, aceleași DBMS-uri sau sisteme de virtualizare, de exemplu. Principiul de construcție al soluției va rămâne același. Iar valoarea finală va fi zero pentru RTO și RPO.
Sursa: habr.com
