Značný počet podnikových aplikácií a virtualizačných systémov má svoje vlastné mechanizmy na vytváranie riešení odolných voči chybám. Konkrétne Oracle RAC (Oracle Real Application Cluster) je klaster dvoch alebo viacerých databázových serverov Oracle, ktoré spolupracujú na vyvážení zaťaženia a poskytovaní odolnosti voči chybám na úrovni servera/aplikácie. Na prácu v tomto režime potrebujete zdieľané úložisko, čo je zvyčajne úložný systém.
Ako sme už rozoberali v jednom z našich , samotný úložný systém má napriek prítomnosti duplicitných komponentov (vrátane radičov) stále miesta zlyhania – najmä vo forme jedného súboru údajov. Na vytvorenie riešenia Oracle so zvýšenými požiadavkami na spoľahlivosť je preto potrebné skomplikovať schému „N serverov – jeden úložný systém“.
Najprv sa, samozrejme, musíme rozhodnúť, proti akým rizikám sa snažíme poistiť. V tomto článku sa nebudeme zaoberať ochranou pred hrozbami, ako je „meteorit prišiel“. Budovanie geograficky rozptýleného riešenia obnovy po havárii teda zostane témou jedného z nasledujúcich článkov. Tu sa pozrieme na takzvané Cross-Rack riešenie obnovy po havárii, kedy je ochrana postavená na úrovni serverových skríň. Samotné skrinky môžu byť umiestnené v rovnakej miestnosti alebo v rôznych miestnostiach, ale zvyčajne v tej istej budove.
Tieto skrine musia obsahovať celú potrebnú sadu zariadení a softvéru, ktoré umožnia prevádzku databáz Oracle bez ohľadu na stav „suseda“. Inými slovami, pomocou riešenia obnovy po havárii Cross-Rack eliminujeme riziká zlyhania:
- Aplikačné servery Oracle
- Skladovacie systémy
- Spínacie systémy
- Úplné zlyhanie všetkých zariadení v skrini:
- Odmietnutie moci
- Porucha chladiaceho systému
- Vonkajšie faktory (človek, príroda atď.)
Duplikácia serverov Oracle zahŕňa samotný princíp fungovania Oracle RAC a je implementovaná prostredníctvom aplikácie. Duplikácia spojovacích zariadení tiež nie je problém. Ale s duplikáciou úložného systému nie je všetko také jednoduché.
Najjednoduchšou možnosťou je replikácia dát z hlavného úložného systému do záložného. Synchrónne alebo asynchrónne, v závislosti od možností úložného systému. Pri asynchrónnej replikácii okamžite vyvstáva otázka zabezpečenia konzistencie údajov vo vzťahu k Oracle. Ale aj keď existuje softvérová integrácia s aplikáciou, v každom prípade v prípade zlyhania hlavného úložného systému bude potrebný manuálny zásah administrátorov, aby sa klaster prepol na záložné úložisko.
Komplexnejšou možnosťou sú softvérové a/alebo hardvérové „virtualizátory“ úložísk, ktoré eliminujú problémy s konzistenciou a manuálne zásahy. Ale zložitosť nasadenia a následnej správy, ako aj veľmi neslušná cena takýchto riešení mnohých odstraší.
Riešenie AccelStor NeoSapphire™ All Flash pole je ideálne pre scenáre, ako je obnova po havárii Cross-Rack pomocou architektúry Shared-Nothing. Tento model je dvojuzlový úložný systém, ktorý využíva proprietárnu technológiu FlexiRemap® na prácu s flash diskami. Vďaka NeoSapphire™ H710 je schopný poskytnúť výkon až 600 4 IOPS@1K náhodného zápisu a 4M+ IOPS@XNUMXK náhodného čítania, čo je nedosiahnuteľné pri použití klasických úložných systémov založených na RAID.
Ale hlavnou črtou NeoSapphire™ H710 je vykonávanie dvoch uzlov vo forme samostatných prípadov, z ktorých každý má svoju vlastnú kópiu údajov. Synchronizácia uzlov sa vykonáva cez externé rozhranie InfiniBand. Vďaka tejto architektúre je možné distribuovať uzly na rôzne miesta na vzdialenosť až 100 m, čím poskytuje riešenie obnovy po havárii Cross-Rack. Oba uzly fungujú úplne synchrónne. Zo strany hostiteľa vyzerá H710 ako obyčajný úložný systém s dvoma ovládačmi. Preto nie je potrebné vykonávať žiadne ďalšie softvérové alebo hardvérové možnosti alebo obzvlášť zložité nastavenia.
Ak porovnáme všetky vyššie opísané riešenia obnovy po havárii Cross-Rack, potom možnosť od AccelStor výrazne vyniká od ostatných:
AccelStor NeoSapphire™ Shared Nothing Architecture
Softvérový alebo hardvérový „virtualizačný“ úložný systém
Riešenie založené na replikácii
dostupnosť
Zlyhanie servera
Žiadne prestoje
Žiadne prestoje
Žiadne prestoje
Porucha spínača
Žiadne prestoje
Žiadne prestoje
Žiadne prestoje
Porucha úložného systému
Žiadne prestoje
Žiadne prestoje
Prestoje
Porucha celej skrinky
Žiadne prestoje
Žiadne prestoje
Prestoje
Náklady a zložitosť
Náklady na riešenie
nízka*
Vysoký
Vysoký
Zložitosť nasadenia
nízky
Vysoký
Vysoký
*AccelStor NeoSapphire™ je stále pole All Flash, ktoré podľa definície nestojí „3 kopejky“, najmä preto, že má dvojnásobnú kapacitnú rezervu. Pri porovnaní konečných nákladov na riešenie, ktoré je na ňom založené, s podobnými od iných predajcov však možno náklady považovať za nízke.
Topológia na pripojenie aplikačných serverov a všetkých uzlov poľa Flash bude vyzerať takto:
Pri plánovaní topológie sa tiež dôrazne odporúča duplikovať prepínače správy a prepojiť servery.
Tu a ďalej budeme hovoriť o pripojení cez Fibre Channel. Ak použijete iSCSI, všetko bude rovnaké, upravené pre typy použitých prepínačov a mierne odlišné nastavenia polí.
Prípravné práce na poli
Použité vybavenie a softvér
Špecifikácie serverov a prepínačov
Komponenty
Popis
Servery Oracle Database 11g
dva
Operačný systém servera
Oracle Linux
Verzia databázy Oracle
11 g (RAC)
Procesory na server
Dva 16 jadrá Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Fyzická pamäť na server
128GB
FC sieť
16Gb/s FC s multipathingom
FC HBA
Emulex Lpe-16002B
Vyhradené verejné 1GbE porty pre správu klastrov
Ethernetový adaptér Intel RJ45
16Gb/s FC prepínač
Brokát 6505
Vyhradené súkromné 10GbE porty na synchronizáciu dát
Intel X520
Špecifikácia všetkých flash poľa AccelStor NeoSapphire™
Komponenty
Popis
Úložný systém
Model s vysokou dostupnosťou NeoSapphire™: H710
Verzia obrázka
4.0.1
Celkový počet jednotiek
48
Veľkosť disku
1.92TB
Typ jednotky
SSD
FC cieľové porty
16x 16Gb porty (8 na uzol)
Manažérske porty
Ethernetový kábel 1GbE, ktorý sa pripája k hostiteľom cez ethernetový prepínač
Port srdcového tepu
1GbE ethernetový kábel spájajúci dva úložné uzly
Port na synchronizáciu údajov
Kábel InfiniBand 56 Gb/s
Pred použitím poľa ho musíte inicializovať. Štandardne je riadiaca adresa oboch uzlov rovnaká (192.168.1.1). Musíte sa k nim pripojiť jeden po druhom a nastaviť nové (už iné) adresy správy a nastaviť časovú synchronizáciu, po ktorej je možné porty Management pripojiť do jednej siete. Potom sa uzly kombinujú do páru HA priradením podsietí pre prepojenia.
Po dokončení inicializácie môžete pole spravovať z ľubovoľného uzla.
Ďalej vytvoríme potrebné zväzky a zverejníme ich na aplikačných serveroch.
Dôrazne sa odporúča vytvoriť viacero zväzkov pre Oracle ASM, pretože to zvýši počet cieľov pre servery, čo v konečnom dôsledku zlepší celkový výkon (viac o frontách v inom ).
Testovacia konfigurácia
Názov úložného zväzku
Veľkosť zväzku
Údaje01
200GB
Údaje02
200GB
Údaje03
200GB
Údaje04
200GB
Údaje05
200GB
Údaje06
200GB
Údaje07
200GB
Údaje08
200GB
Údaje09
200GB
Údaje10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Znovu01
100GB
Znovu02
100GB
Znovu03
100GB
Znovu04
100GB
Znovu05
100GB
Znovu06
100GB
Znovu07
100GB
Znovu08
100GB
Znovu09
100GB
Znovu10
100GB
Niektoré vysvetlenia o prevádzkových režimoch poľa a procesoch vyskytujúcich sa v núdzových situáciách
Súbor údajov každého uzla má parameter „číslo verzie“. Po prvotnej inicializácii je rovnaká a rovná sa 1. Ak je z nejakého dôvodu číslo verzie iné, tak sa dáta vždy synchronizujú zo staršej verzie na mladšiu, potom sa zarovná číslo mladšej verzie, t.j. to znamená, že kópie sú identické. Dôvody, prečo sa verzie môžu líšiť:
- Naplánovaný reštart jedného z uzlov
- Nehoda na jednom z uzlov v dôsledku náhleho vypnutia (napájanie, prehriatie atď.).
- Stratené pripojenie InfiniBand s nemožnosťou synchronizácie
- Zlyhanie jedného z uzlov v dôsledku poškodenia údajov. Tu budete musieť vytvoriť novú skupinu HA a dokončiť synchronizáciu súboru údajov.
V každom prípade uzol, ktorý zostane online, zvýši číslo svojej verzie o jeden, aby sa po obnovení spojenia s párom synchronizoval súbor údajov.
Ak dôjde k strate pripojenia cez ethernetové spojenie, Heartbeat sa dočasne prepne na InfiniBand a vráti sa späť do 10 sekúnd po jeho obnovení.
Nastavenie hostiteľov
Ak chcete zabezpečiť odolnosť voči chybám a zlepšiť výkon, musíte povoliť podporu MPIO pre pole. Ak to chcete urobiť, musíte do súboru /etc/multipath.conf pridať riadky a potom reštartovať službu multipath
Skrytý textzariadenia {
zariadenie {
predajca "AStor"
path_grouping_policy "group_by_prio"
path_selector "queue-length 0"
path_checker "tur"
funkcie "0"
hardware_handler "0"
prio "konšt"
zlyhanie okamžite
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names áno
detect_prio áno
rr_min_io_rq 1
no_path_retry 0
}
}
Ďalej, aby ASM fungovalo s MPIO cez ASMLib, musíte zmeniť súbor /etc/sysconfig/oracleasm a potom spustiť /etc/init.d/oracleasm scandisks
Skrytý text
# ORACLEASM_SCANORDER: Zodpovedajúce vzory na objednávku skenovania disku
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Vzory zhody na vylúčenie diskov z kontroly
ORACLEASM_SCANEXCLUDE="sd"
Poznámka
Ak nechcete používať ASMLib, môžete použiť pravidlá UDEV, ktoré sú základom pre ASMLib.
Počnúc verziou 12.1.0.2 databázy Oracle je táto možnosť dostupná na inštaláciu ako súčasť softvéru ASMFD.
Je nevyhnutné zabezpečiť, aby disky vytvorené pre Oracle ASM boli zarovnané s veľkosťou bloku, s ktorým pole fyzicky pracuje (4K). V opačnom prípade sa môžu vyskytnúť problémy s výkonom. Preto je potrebné vytvoriť zväzky s príslušnými parametrami:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimum 1
Distribúcia databáz cez vytvorené zväzky pre našu testovaciu konfiguráciu
Názov úložného zväzku
Veľkosť zväzku
Mapovanie objemu LUN
Podrobnosti zariadenia ASM Volume
Veľkosť alokačnej jednotky
Údaje01
200GB
Mapujte všetky úložné objemy na všetky dátové porty úložného systému
Redundancia: Normálna
Názov: DGDATA
Účel: Dátové súbory
4MB
Údaje02
200GB
Údaje03
200GB
Údaje04
200GB
Údaje05
200GB
Údaje06
200GB
Údaje07
200GB
Údaje08
200GB
Údaje09
200GB
Údaje10
200GB
Grid01
1GB
Redundancia: Normálna
Názov: DGGRID1
Účel: Mriežka: CRS a hlasovanie
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundancia: Normálna
Názov: DGGRID2
Účel: Mriežka: CRS a hlasovanie
4MB
Grid05
1GB
Grid06
1GB
Znovu01
100GB
Redundancia: Normálna
Názov: DGREDO1
Účel: Zopakujte denník vlákna 1
4MB
Znovu02
100GB
Znovu03
100GB
Znovu04
100GB
Znovu05
100GB
Znovu06
100GB
Redundancia: Normálna
Názov: DGREDO2
Účel: Zopakujte denník vlákna 2
4MB
Znovu07
100GB
Znovu08
100GB
Znovu09
100GB
Znovu10
100GB
Nastavenia databázy
- Veľkosť bloku = 8K
- Výmenný priestor = 16 GB
- Zakázať AMM (automatickú správu pamäte)
- Zakázať priehľadné obrovské stránky
Iné nastavenia
# 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 XNUMX
✓ 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 # toto nenastavujte, ak používate Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000 XNUMX
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ mriežka hard nproc 16384
✓ mriežka soft nofile 1024
✓ mriežka hard nofile 65536
✓ mriežka soft stack 10240
✓ pevný zásobník mriežky 32768
✓ Oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ Oracle soft stack 10240
✓ pevný zásobník Oracle 32768
✓ mäkký memlock 120795954
✓ pevný memlock 120795954
sqlplus „/as sysdba“
zmeniť procesy systémovej sady=2000 rozsah=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 zlyhania
Na demonštračné účely sa na emuláciu zaťaženia OLTP použil HammerDB. Konfigurácia HammerDB:
Počet skladov
256
Celkový počet transakcií na používateľa
1000000000000
Virtuálni používatelia
256
Výsledkom bolo 2.1 milióna TPM, čo je ďaleko od výkonnostného limitu poľa , ale je „stropom“ pre aktuálnu hardvérovú konfiguráciu serverov (predovšetkým kvôli procesorom) a ich počet. Účelom tohto testu je stále demonštrovať chybovú odolnosť riešenia ako celku a nie dosiahnuť maximálny výkon. Preto budeme jednoducho stavať na tomto čísle.
Test na zlyhanie jedného z uzlov
Hostitelia stratili časť ciest k úložisku a pokračovali v práci cez zostávajúce s druhým uzlom. Výkon na niekoľko sekúnd klesol kvôli prestavbe ciest a potom sa vrátil do normálu. K prerušeniu služby nedošlo.
Test zlyhania skrinky so všetkým vybavením
Výkon v tomto prípade tiež na pár sekúnd klesol kvôli reštrukturalizácii ciest a potom sa vrátil na polovicu pôvodnej hodnoty. Výsledok bol oproti pôvodnému polovičný z dôvodu vyradenia jedného aplikačného servera z prevádzky. Nedošlo ani k prerušeniu služby.
Ak je potrebné implementovať riešenie obnovy po havárii Cross-Rack odolné voči chybám pre Oracle za rozumnú cenu a s malým úsilím nasadenia/správy, potom Oracle RAC a architektúra spolupracujú. bude jednou z najlepších možností. Namiesto Oracle RAC môže existovať akýkoľvek iný softvér, ktorý poskytuje klastrovanie, napríklad rovnaké DBMS alebo virtualizačné systémy. Princíp konštrukcie riešenia zostane rovnaký. A spodný riadok je nula pre RTO a RPO.
Zdroj: hab.com