Precejšnje število podjetniških aplikacij in virtualizacijskih sistemov ima lastne mehanizme za gradnjo rešitev, odpornih na napake. Natančneje, Oracle RAC (Oracle Real Application Cluster) je gruča dveh ali več strežnikov baz podatkov Oracle, ki delujejo skupaj za uravnoteženje obremenitve in zagotavljajo odpornost na napake na ravni strežnika/aplikacije. Za delo v tem načinu potrebujete skupno shrambo, ki je običajno sistem za shranjevanje.
Kot smo že razpravljali v enem od naših , sam sistem za shranjevanje kljub prisotnosti podvojenih komponent (vključno s krmilniki) še vedno vsebuje točke napake - predvsem v obliki enega samega niza podatkov. Zato mora biti za izgradnjo rešitve Oracle s povečanimi zahtevami glede zanesljivosti shema "N strežnikov - en sistem za shranjevanje" zapletena.
Najprej se moramo seveda odločiti, pred katerimi tveganji se poskušamo zavarovati. V tem članku ne bomo obravnavali zaščite pred grožnjami, kot je »prispel je meteorit«. Izgradnja geografsko razpršene rešitve za obnovitev po katastrofi bo torej ostala tema enega od naslednjih člankov. Tukaj si bomo ogledali tako imenovano rešitev za obnovitev po katastrofi Cross-Rack, ko je zaščita zgrajena na nivoju strežniških omar. Same omare se lahko nahajajo v istem prostoru ali v različnih, vendar običajno znotraj iste stavbe.
Te omare morajo vsebovati ves potreben nabor opreme in programske opreme, ki bo omogočala delovanje baz podatkov Oracle ne glede na stanje »soseda«. Z drugimi besedami, z uporabo rešitve za obnovitev po katastrofi Cross-Rack odpravimo tveganja okvare:
- Aplikacijski strežniki Oracle
- Skladiščni sistemi
- Preklopni sistemi
- Popolna okvara vse opreme v omari:
- Zavrnitev napajanja
- Okvara hladilnega sistema
- Zunanji dejavniki (človek, narava itd.)
Podvajanje strežnikov Oracle implicira sam princip delovanja Oracle RAC in se izvaja preko aplikacije. Tudi podvajanje stikalnih zmogljivosti ni problem. Toda s podvajanjem sistema za shranjevanje vse ni tako preprosto.
Najenostavnejša možnost je replikacija podatkov iz glavnega pomnilniškega sistema v rezervnega. Sinhroni ali asinhroni, odvisno od zmogljivosti pomnilniškega sistema. Pri asinhronem podvajanju se takoj pojavi vprašanje zagotavljanja konsistentnosti podatkov glede na Oracle. Toda tudi če obstaja integracija programske opreme z aplikacijo, bo v vsakem primeru v primeru okvare glavnega pomnilniškega sistema potrebno ročno posredovanje skrbnikov, da preklopijo gručo na rezervno shrambo.
Bolj zapletena možnost so "virtualizatorji" za shranjevanje programske in/ali strojne opreme, ki bodo odpravili težave z doslednostjo in ročno posredovanje. Toda zapletenost uvajanja in kasnejšega upravljanja ter zelo nespodobni stroški takšnih rešitev prestrašijo mnoge.
Rešitev polja AccelStor NeoSapphire™ All Flash je popolna za scenarije, kot je obnovitev po katastrofi Cross-Rack z uporabo arhitekture Shared-Nothing. Ta model je sistem za shranjevanje z dvema vozliščema, ki uporablja lastniško tehnologijo FlexiRemap® za delo z bliskovnimi pogoni. Zahvale gredo NeoSapphire™ H710 je sposoben zagotoviti zmogljivost do 600K IOPS@4K naključnega zapisovanja in 1M+ IOPS@4K naključnega branja, kar je nedosegljivo pri uporabi klasičnih sistemov za shranjevanje, ki temeljijo na RAID.
Toda glavna značilnost NeoSapphire™ H710 je izvedba dveh vozlišč v obliki ločenih primerov, od katerih ima vsak svojo kopijo podatkov. Sinhronizacija vozlišč se izvaja prek zunanjega vmesnika InfiniBand. Zahvaljujoč tej arhitekturi je možno razporediti vozlišča na različne lokacije na razdalji do 100 m in s tem zagotoviti rešitev za obnovitev po katastrofi Cross-Rack. Obe vozlišči delujeta popolnoma sinhrono. S strani gostitelja je H710 videti kot navaden sistem za shranjevanje z dvojnim krmilnikom. Zato ni treba izvajati dodatnih programskih ali strojnih možnosti ali posebej zapletenih nastavitev.
Če primerjamo vse zgoraj opisane rešitve za obnovitev po katastrofi Cross-Rack, potem možnost iz AccelStorja opazno izstopa od ostalih:
AccelStor NeoSapphire™ Shared Nothing Architecture
Sistem za shranjevanje »virtualizatorja« programske ali strojne opreme
Rešitev, ki temelji na replikaciji
Razpoložljivost
Okvara strežnika
Brez izpadov
Brez izpadov
Brez izpadov
Okvara stikala
Brez izpadov
Brez izpadov
Brez izpadov
Okvara sistema za shranjevanje
Brez izpadov
Brez izpadov
odmore
Okvara celotne omare
Brez izpadov
Brez izpadov
odmore
Stroški in kompleksnost
Cena rešitve
Nizka*
Visoka
Visoka
Kompleksnost uvajanja
Nizka
Visoka
Visoka
*AccelStor NeoSapphire™ je še vedno polje All Flash, ki po definiciji ne stane »3 kopejk«, zlasti ker ima dvojno rezervo zmogljivosti. Če pa primerjamo končno ceno rešitve, ki temelji na njej, s podobnimi rešitvami drugih proizvajalcev, se lahko stroški štejejo za nizke.
Topologija za povezovanje aplikacijskih strežnikov in vseh vozlišč polja Flash bo videti takole:
Pri načrtovanju topologije je zelo priporočljivo tudi podvajanje upravljalnih stikal in povezovanje strežnikov.
Tukaj in naprej bomo govorili o povezovanju prek Fibre Channel. Če uporabljate iSCSI, bo vse enako, prilagojeno vrstam uporabljenih stikal in nekoliko drugačnim nastavitvam polja.
Pripravljalna dela na matriki
Uporabljena oprema in programska oprema
Specifikacije strežnika in stikala
Komponente
Opis
Strežniki Oracle Database 11g
Dva
Strežniški operacijski sistem
Oracle Linux
Različica baze podatkov Oracle
11 g (RAC)
Procesorji na strežnik
Dva 16-jedrna procesorja Intel® Xeon® E5-2667 v2 @ 3.30 GHz
Fizični pomnilnik na strežnik
128GB
FC mreža
16Gb/s FC z večpotjem
FC HBA
Emulex Lpe-16002B
Namenska javna vrata 1GbE za upravljanje gruče
Intel ethernet adapter RJ45
16Gb/s FC stikalo
Brokat 6505
Namenska zasebna vrata 10GbE za sinhronizacijo podatkov
Intel X520
Specifikacija AccelStor NeoSapphire™ All Flash Array
Komponente
Opis
Skladiščni sistem
Model visoke razpoložljivosti NeoSapphire™: H710
Slikovna različica
4.0.1
Skupno število pogonov
48
Velikost pogona
1.92TB
Vrsta pogona
SSD
FC ciljna vrata
16x 16Gb vrata (8 na vozlišče)
Upravljalna vrata
Ethernetni kabel 1GbE, ki se povezuje z gostitelji prek ethernetnega stikala
Vrata srčnega utripa
Ethernetni kabel 1GbE, ki povezuje dve vozlišči za shranjevanje
Vrata za sinhronizacijo podatkov
56Gb/s InfiniBand kabel
Preden lahko uporabite matriko, jo morate inicializirati. Privzeto je nadzorni naslov obeh vozlišč enak (192.168.1.1). Povezati se morate z njimi enega za drugim in nastaviti nove (že drugačne) naslove za upravljanje ter nastaviti časovno sinhronizacijo, po kateri se lahko upravljalna vrata povežejo v eno omrežje. Nato se vozlišča združijo v par HA z dodelitvijo podomrežij za povezave Interlink.
Po končani inicializaciji lahko matriko upravljate iz katerega koli vozlišča.
Nato ustvarimo potrebne količine in jih objavimo na aplikacijskih strežnikih.
Zelo priporočljivo je ustvariti več nosilcev za Oracle ASM, saj bo to povečalo število ciljev za strežnike, kar bo na koncu izboljšalo splošno zmogljivost (več o čakalnih vrstah v drugem ).
Preizkusna konfiguracija
Ime nosilca pomnilnika
Velikost glasnosti
Podatki01
200GB
Podatki02
200GB
Podatki03
200GB
Podatki04
200GB
Podatki05
200GB
Podatki06
200GB
Podatki07
200GB
Podatki08
200GB
Podatki09
200GB
Podatki10
200GB
Mreža01
1GB
Mreža02
1GB
Mreža03
1GB
Mreža04
1GB
Mreža05
1GB
Mreža06
1GB
Ponovi01
100GB
Ponovi02
100GB
Ponovi03
100GB
Ponovi04
100GB
Ponovi05
100GB
Ponovi06
100GB
Ponovi07
100GB
Ponovi08
100GB
Ponovi09
100GB
Ponovi10
100GB
Nekaj pojasnil o načinih delovanja niza in procesih, ki se pojavljajo v izrednih razmerah
Nabor podatkov vsakega vozlišča ima parameter »številka različice«. Po začetni inicializaciji je enaka in enaka 1. Če je iz nekega razloga številka različice drugačna, se podatki vedno sinhronizirajo iz starejše različice v mlajšo, nakar se številka mlajše različice poravna, tj. to pomeni, da sta kopiji enaki. Razlogi, zakaj so različice lahko različne:
- Načrtovan ponovni zagon enega od vozlišč
- Nesreča na enem od vozlišč zaradi nenadnega izklopa (napajanje, pregrevanje itd.).
- Prekinjena povezava InfiniBand z nezmožnostjo sinhronizacije
- Zrušitev enega od vozlišč zaradi poškodbe podatkov. Tukaj boste morali ustvariti novo skupino HA in dokončati sinhronizacijo nabora podatkov.
V vsakem primeru vozlišče, ki ostane na spletu, poveča svojo številko različice za eno, da sinhronizira svoj nabor podatkov, potem ko je povezava s parom ponovno vzpostavljena.
Če se povezava prek povezave Ethernet prekine, Heartbeat začasno preklopi na InfiniBand in se vrne nazaj v 10 sekundah, ko je vzpostavljena.
Nastavitev gostiteljev
Če želite zagotoviti odpornost na napake in izboljšati zmogljivost, morate omogočiti podporo MPIO za polje. Če želite to narediti, morate dodati vrstice v datoteko /etc/multipath.conf in nato znova zagnati storitev več poti
Skrito besedilonaprave {
naprava {
prodajalec "AStor"
path_grouping_policy "group_by_prio"
path_selector "dolžina čakalne vrste 0"
path_checker "tur"
značilnosti "0"
hardware_handler "0"
pred "const"
takojšnje popravilo
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names da
detekt_prio da
rr_min_io_rq 1
no_path_retry 0
}
}
Če želite, da ASM deluje z MPIO prek ASMLib, morate spremeniti datoteko /etc/sysconfig/oracleasm in nato zagnati /etc/init.d/oracleasm scandisks
Skrito besedilo
# ORACLEASM_SCANORDER: Ujemanje vzorcev za naročilo skeniranja diska
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Ujemanje vzorcev za izključitev diskov iz pregleda
ORACLEASM_SCANEXCLUDE="sd"
Obvestilo
Če ne želite uporabljati ASMLib, lahko uporabite pravila UDEV, ki so osnova za ASMLib.
Od različice 12.1.0.2 baze podatkov Oracle je možnost na voljo za namestitev kot del programske opreme ASMFD.
Nujno je treba zagotoviti, da so diski, ustvarjeni za Oracle ASM, usklajeni z velikostjo bloka, s katerim polje fizično deluje (4K). V nasprotnem primeru lahko pride do težav z delovanjem. Zato je treba ustvariti količine z ustreznimi parametri:
parted /dev/mapper/device-name mklabel gpt mkpart primarni 2048s 100 % align-check optimal 1
Porazdelitev baz podatkov po ustvarjenih nosilcih za našo testno konfiguracijo
Ime nosilca pomnilnika
Velikost glasnosti
Preslikava nosilcev LUN
Podrobnosti naprave za glasnost ASM
Velikost enote dodelitve
Podatki01
200GB
Preslikaj vse nosilce shranjevanja v vsa podatkovna vrata sistema za shranjevanje
Redundanca: Normalna
Ime: DGDATA
Namen: Podatkovne datoteke
4MB
Podatki02
200GB
Podatki03
200GB
Podatki04
200GB
Podatki05
200GB
Podatki06
200GB
Podatki07
200GB
Podatki08
200GB
Podatki09
200GB
Podatki10
200GB
Mreža01
1GB
Redundanca: Normalna
Ime: DGGRID1
Namen: Mreža: CRS in glasovanje
4MB
Mreža02
1GB
Mreža03
1GB
Mreža04
1GB
Redundanca: Normalna
Ime: DGGRID2
Namen: Mreža: CRS in glasovanje
4MB
Mreža05
1GB
Mreža06
1GB
Ponovi01
100GB
Redundanca: Normalna
Ime: DGREDO1
Namen: Ponovi dnevnik niti 1
4MB
Ponovi02
100GB
Ponovi03
100GB
Ponovi04
100GB
Ponovi05
100GB
Ponovi06
100GB
Redundanca: Normalna
Ime: DGREDO2
Namen: Ponovi dnevnik niti 2
4MB
Ponovi07
100GB
Ponovi08
100GB
Ponovi09
100GB
Ponovi10
100GB
Nastavitve zbirke podatkov
- Velikost bloka = 8K
- Prostor za zamenjavo = 16 GB
- Onemogoči AMM (samodejno upravljanje pomnilnika)
- Onemogoči pregledne ogromne strani
Druge nastavitve
# 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 # tega ne nastavite, če uporabljate Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ mehka mreža nproc 2047
✓ trda mreža nproc 16384
✓ mehka mreža nofile 1024
✓ mreža trdi nofile 65536
✓ mehki sklad mreže 10240
✓ mrežni trdi sklad 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”
spremenite sistem nastavite procese=2000 obseg=spfile;
spremeni sistemski niz open_cursors=2000 scope=spfile;
spremeniti sistemski set session_cached_cursors=300 obseg=spfile;
spremeni sistemski niz db_files=8192 scope=spfile;
Test neuspeha
Za namene predstavitve je bil HammerDB uporabljen za posnemanje nalaganja OLTP. Konfiguracija HammerDB:
Število skladišč
256
Skupno število transakcij na uporabnika
1000000000000
Virtualni uporabniki
256
Rezultat je bil 2.1 milijona TPM, kar je daleč od meje zmogljivosti polja , vendar je "zgornja meja" za trenutno strojno konfiguracijo strežnikov (predvsem zaradi procesorjev) in njihovo število. Namen tega testa je še vedno prikazati odpornost na napake rešitve kot celote in ne doseči največjo zmogljivost. Zato bomo preprosto gradili na tej številki.
Preizkusite okvaro enega od vozlišč
Gostitelji so izgubili del poti do pomnilnika in nadaljevali z delom po preostalih z drugim vozliščem. Zmogljivost je za nekaj sekund padla zaradi ponovne izgradnje poti, nato pa se je vrnila v normalno stanje. Prekinitve storitve ni bilo.
Test okvare omarice z vso opremo
Tudi v tem primeru je zmogljivost za nekaj sekund padla zaradi prestrukturiranja poti, nato pa se je vrnila na polovico prvotne vrednosti. Rezultat je bil prepolovljen od začetnega zaradi izključitve enega aplikacijskega strežnika iz delovanja. Tudi v servisu ni bilo prekinitve.
Če obstaja potreba po uvedbi rešitve za obnovitev po katastrofi Cross-Rack, ki je odporna na napake, za Oracle po razumni ceni in z malo truda pri uvajanju/administriranju, potem Oracle RAC in arhitektura delujeta skupaj bo ena najboljših možnosti. Namesto Oracle RAC je lahko katera koli druga programska oprema, ki omogoča združevanje v gruče, na primer isti DBMS ali sistemi za virtualizacijo. Načelo izdelave rešitve bo ostalo enako. In bistvo je nič za RTO in RPO.
Vir: www.habr.com