Značajan broj Enterprise aplikacija i virtualizacijskih sistema ima svoje mehanizme za izgradnju rješenja otpornih na greške. Konkretno, Oracle RAC (Oracle Real Application Cluster) je klaster dva ili više Oracle servera baze podataka koji rade zajedno kako bi uravnotežili opterećenje i obezbijedili toleranciju grešaka na nivou servera/aplikacije. Da biste radili u ovom režimu, potrebna vam je zajednička memorija, koja je obično sistem za skladištenje.
Kao što smo već raspravljali u jednom od naših , sam sistem skladištenja, uprkos prisustvu dupliranih komponenti (uključujući i kontrolere), još uvek ima tačaka kvara - uglavnom u obliku jednog skupa podataka. Stoga, da bi se izgradilo Oracle rešenje sa povećanim zahtevima za pouzdanost, šema „N serveri – jedan sistem skladištenja“ mora biti komplikovana.
Prvo, naravno, moramo odlučiti od kojih rizika pokušavamo da se osiguramo. U ovom članku nećemo razmatrati zaštitu od prijetnji poput "meteorit je stigao". Stoga će izgradnja geografski raspršenog rješenja za oporavak od katastrofe ostati tema za jedan od sljedećih članaka. Ovdje ćemo se osvrnuti na takozvano Cross-Rack rješenje za oporavak od katastrofe, kada je zaštita izgrađena na nivou serverskih ormara. Sami ormari mogu biti smješteni u istoj prostoriji ili u različitim, ali obično unutar iste zgrade.
Ovi ormari moraju sadržavati cijeli neophodan set opreme i softvera koji će omogućiti rad Oracle baza podataka bez obzira na stanje „susjeda“. Drugim riječima, koristeći Cross-Rack rješenje za oporavak od katastrofe, eliminiramo rizike od neuspjeha:
- Oracle aplikacijski serveri
- Sistemi skladištenja
- Preklopni sistemi
- Potpuni kvar sve opreme u ormaru:
- Odbijanje napajanja
- Kvar rashladnog sistema
- Vanjski faktori (ljud, priroda, itd.)
Dupliranje Oracle servera podrazumijeva sam princip rada Oracle RAC-a i implementira se kroz aplikaciju. Dupliranje sklopnih objekata također nije problem. Ali s dupliciranjem sustava za pohranu, sve nije tako jednostavno.
Najjednostavnija opcija je replikacija podataka iz glavnog skladišnog sistema u rezervni. Sinhroni ili asinhroni, ovisno o mogućnostima sustava za pohranu podataka. Kod asinhrone replikacije, odmah se postavlja pitanje osiguravanja konzistentnosti podataka u odnosu na Oracle. Ali čak i ako postoji softverska integracija sa aplikacijom, u svakom slučaju, u slučaju kvara na glavnom sistemu skladištenja, biće potrebna ručna intervencija administratora kako bi se klaster prebacio na rezervnu memoriju.
Složenija opcija su softverski i/ili hardverski "virtualizatori" za skladištenje koji će eliminisati probleme konzistentnosti i ručne intervencije. Ali složenost implementacije i naknadne administracije, kao i vrlo nepristojna cijena takvih rješenja, plaši mnoge.
AccelStor NeoSapphire™ All Flash rješenje je savršeno za scenarije kao što je Cross-Rack oporavak od katastrofe koristeći arhitekturu Shared-Nothing. Ovaj model je sistem za skladištenje sa dva čvora koji koristi vlasničku tehnologiju FlexiRemap® za rad sa fleš diskovima. Hvala za NeoSapphire™ H710 je sposoban da pruži performanse do 600K IOPS@4K nasumično upisivanje i 1M+ IOPS@4K nasumično čitanje, što je nedostižno kada se koriste klasični RAID sistemi za skladištenje podataka.
Ali glavna karakteristika NeoSapphire™ H710 je izvođenje dva čvora u obliku zasebnih kućišta, od kojih svaki ima svoju kopiju podataka. Sinhronizacija čvorova se vrši preko eksternog InfiniBand interfejsa. Zahvaljujući ovoj arhitekturi, moguće je distribuirati čvorove na različite lokacije na udaljenosti do 100m, čime se pruža Cross-Rack rješenje za oporavak od katastrofe. Oba čvora rade potpuno sinhrono. Sa strane domaćina, H710 izgleda kao običan sistem za skladištenje sa dva kontrolera. Stoga, nema potrebe za dodatnim softverskim ili hardverskim opcijama ili posebno složenim podešavanjima.
Ako uporedimo sva gore opisana rješenja za oporavak od katastrofe Cross-Rack, tada se opcija AccelStor-a primjetno izdvaja od ostalih:
Arhitektura AccelStor NeoSapphire™ Shared Nothing
Softverski ili hardverski “virtualizator” sistem za skladištenje
Rješenje zasnovano na replikaciji
Dostupnost
Greška servera
Nema zastoja
Nema zastoja
Nema zastoja
Kvar prekidača
Nema zastoja
Nema zastoja
Nema zastoja
Kvar sistema za skladištenje podataka
Nema zastoja
Nema zastoja
Zaustavljanje
Neispravnost cijelog kabineta
Nema zastoja
Nema zastoja
Zaustavljanje
Cijena i složenost
Trošak rješenja
nisko*
Vysokaya
Vysokaya
Složenost implementacije
Nizkaâ
Vysokaya
Vysokaya
*AccelStor NeoSapphire™ je još uvijek All Flash niz, koji po definiciji ne košta “3 kopejke”, pogotovo jer ima dvostruku rezervu kapaciteta. Međutim, kada se uporedi konačni trošak rješenja zasnovanog na njemu sa sličnim od drugih dobavljača, trošak se može smatrati niskim.
Topologija za povezivanje servera aplikacija i svih čvorova Flash polja će izgledati ovako:
Prilikom planiranja topologije, također se preporučuje dupliranje upravljačkih prekidača i servera za međusobno povezivanje.
Ovdje i dalje ćemo govoriti o povezivanju putem Fibre Channel-a. Ako koristite iSCSI, sve će biti isto, prilagođeno tipovima prekidača koji se koriste i malo drugačijim postavkama niza.
Pripremni radovi na nizu
Korištena oprema i softver
Specifikacije servera i prekidača
Komponente
Opis
Oracle Database 11g serveri
Dva
Serverski operativni sistem
oracle linux
Verzija Oracle baze podataka
11 g (RAC)
Procesori po serveru
Dva 16 jezgra Intel® Xeon® CPU E5-2667 v2 na 3.30 GHz
Fizička memorija po serveru
128GB
FC mreža
16Gb/s FC sa multipathingom
FC HBA
Emulex Lpe-16002B
Namjenski javni 1GbE portovi za upravljanje klasterima
Intel Ethernet adapter RJ45
16Gb/s FC prekidač
Brokat 6505
Namjenski privatni 10GbE portovi za sinhronizaciju podataka
Intel X520
AccelStor NeoSapphire™ All Flash Array specifikacija
Komponente
Opis
Sistem za skladištenje
NeoSapphire™ model visoke dostupnosti: H710
Verzija slike
4.0.1
Ukupan broj pogona
48
Veličina pogona
1.92TB
Tip pogona
SSD
FC ciljni portovi
16x 16Gb portova (8 po čvoru)
Upravljački portovi
1GbE eternet kabl koji se povezuje na hostove preko eternet prekidača
Port za otkucaje srca
1GbE Ethernet kabl koji povezuje dva čvora za skladištenje
Port za sinhronizaciju podataka
56Gb/s InfiniBand kabl
Prije nego što možete koristiti niz, morate ga inicijalizirati. Podrazumevano, kontrolna adresa oba čvora je ista (192.168.1.1). Na njih se morate povezati jedan po jedan i postaviti nove (već različite) adrese upravljanja i podesiti vremensku sinhronizaciju, nakon čega se portovi za upravljanje mogu povezati na jednu mrežu. Nakon toga, čvorovi se kombinuju u HA par dodeljivanjem podmreža za interlink veze.
Nakon što je inicijalizacija završena, možete upravljati nizom iz bilo kojeg čvora.
Zatim kreiramo potrebne volumene i objavljujemo ih na poslužiteljima aplikacija.
Veoma je preporučljivo kreirati više volumena za Oracle ASM jer će to povećati broj ciljeva za servere, što će u konačnici poboljšati ukupne performanse (više o redovima čekanja u drugom ).
Testna konfiguracija
Naziv volumena pohrane
Veličina jačine
Podaci01
200GB
Podaci02
200GB
Podaci03
200GB
Podaci04
200GB
Podaci05
200GB
Podaci06
200GB
Podaci07
200GB
Podaci08
200GB
Podaci09
200GB
Podaci10
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
Neka objašnjenja o režimima rada niza i procesima koji se dešavaju u vanrednim situacijama
Skup podataka svakog čvora ima parametar "broj verzije". Nakon početne inicijalizacije isti je i jednak 1. Ako je iz nekog razloga broj verzije drugačiji, tada se podaci uvijek sinhronizuju sa starije verzije na mlađu, nakon čega se poravnava broj mlađe verzije, tj. to znači da su kopije identične. Razlozi zašto se verzije mogu razlikovati:
- Planirano ponovno pokretanje jednog od čvorova
- Nesreća na jednom od čvorova zbog iznenadnog isključivanja (napajanje, pregrijavanje, itd.).
- Izgubljena InfiniBand veza sa nemogućnošću sinhronizacije
- Pad na jednom od čvorova zbog oštećenja podataka. Ovdje ćete morati kreirati novu HA grupu i dovršiti sinhronizaciju skupa podataka.
U svakom slučaju, čvor koji ostaje online povećava broj svoje verzije za jedan kako bi sinkronizirao svoj skup podataka nakon što se veza s parom obnovi.
Ako se veza preko Ethernet veze izgubi, Heartbeat se privremeno prebacuje na InfiniBand i vraća se u roku od 10 sekundi kada se vrati.
Postavljanje hostova
Da biste osigurali toleranciju grešaka i poboljšali performanse, morate omogućiti MPIO podršku za niz. Da biste to uradili, morate dodati redove u /etc/multipath.conf datoteku, a zatim ponovo pokrenuti multipath uslugu
Skriveni tekstuređaji {
uređaj {
prodavac "AStor"
path_grouping_policy "group_by_prio"
path_selector "dužina reda 0"
path_checker "tur"
karakteristike "0"
hardware_handler "0"
prio "const"
hitan povratak
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names da
detektirati_prio da
rr_min_io_rq 1
no_path_retry 0
}
}
Zatim, da bi ASM radio sa MPIO preko ASMLib-a, morate promijeniti datoteku /etc/sysconfig/oracleasm i zatim pokrenuti /etc/init.d/oracleasm scandisks
Skriveni tekst
# ORACLEASM_SCANORDER: Usklađivanje uzoraka za narudžbu skeniranja diska
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Uparivanje uzoraka za isključivanje diskova iz skeniranja
ORACLEASM_SCANEXCLUDE="sd"
primjedba
Ako ne želite da koristite ASMLib, možete koristiti UDEV pravila, koja su osnova za ASMLib.
Počevši od verzije 12.1.0.2 Oracle baze podataka, opcija je dostupna za instalaciju kao dio ASMFD softvera.
Imperativ je osigurati da diskovi kreirani za Oracle ASM budu usklađeni s veličinom bloka s kojom niz fizički radi (4K). U suprotnom može doći do problema sa performansama. Stoga je potrebno kreirati volumene s odgovarajućim parametrima:
parted /dev/mapper/device-name mklabel gpt mkpart primarni 2048s 100% align-check optimalno 1
Distribucija baza podataka po kreiranim volumenima za našu testnu konfiguraciju
Naziv volumena pohrane
Veličina jačine
Mapiranje LUN-ova volumena
ASM Volume Device Device
Veličina jedinice alokacije
Podaci01
200GB
Mapirajte sve zapremine skladištenja na sve portove podataka sistema za skladištenje
Redundantnost: Normalna
Naziv:DGDATA
Svrha: Datoteke sa podacima
4MB
Podaci02
200GB
Podaci03
200GB
Podaci04
200GB
Podaci05
200GB
Podaci06
200GB
Podaci07
200GB
Podaci08
200GB
Podaci09
200GB
Podaci10
200GB
Grid01
1GB
Redundantnost: Normalna
Naziv: DGGRID1
Svrha: Mreža: CRS i glasanje
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundantnost: Normalna
Naziv: DGGRID2
Svrha: Mreža: CRS i glasanje
4MB
Grid05
1GB
Grid06
1GB
Redo01
100GB
Redundantnost: Normalna
Naziv: DGREDO1
Svrha: Ponoviti dnevnik niti 1
4MB
Redo02
100GB
Redo03
100GB
Redo04
100GB
Redo05
100GB
Redo06
100GB
Redundantnost: Normalna
Naziv: DGREDO2
Svrha: Ponoviti dnevnik niti 2
4MB
Redo07
100GB
Redo08
100GB
Redo09
100GB
Redo10
100GB
Postavke baze podataka
- Veličina bloka = 8K
- Swap prostor = 16 GB
- Onemogućite AMM (automatsko upravljanje memorijom)
- Onemogućite Transparentne ogromne stranice
Ostala podešavanja
# 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 # ne postavljajte ovo ako koristite Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ mekana mreža nproc 2047
✓ tvrda mreža nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ mekana mreža 10240
✓ tvrda mreža 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
✓ mekani memlock 120795954
✓ tvrdi memlock 120795954
sqlplus “/as sysdba”
alter system set processs=2000 opseg=spfile;
alter system set open_cursors=2000 opseg=spfile;
alter system set session_cached_cursors=300 opseg=spfile;
alter system set db_files=8192 scope=spfile;
Test neuspjeha
U svrhu demonstracije, HammerDB je korišten za emulaciju OLTP opterećenja. HammerDB konfiguracija:
Broj skladišta
256
Ukupno transakcija po korisniku
1000000000000
Virtuelni korisnici
256
Rezultat je bio 2.1M TPM, što je daleko od granice performansi niza , ali je “plafon” za trenutnu hardversku konfiguraciju servera (prvenstveno zbog procesora) i njihov broj. Svrha ovog testa je i dalje da pokaže toleranciju na greške rješenja u cjelini, a ne da postigne maksimalnu učinkovitost. Stoga ćemo se jednostavno nadovezati na ovu brojku.
Testirajte kvar jednog od čvorova
Domaćini su izgubili dio staza do skladišta, nastavljajući raditi kroz preostale s drugim čvorom. Performanse su pale na nekoliko sekundi zbog obnavljanja staza, a zatim su se vratile u normalu. Nije bilo prekida u radu.
Ispitivanje kvara ormara sa svom opremom
U ovom slučaju, performanse su također pale na nekoliko sekundi zbog restrukturiranja staza, a zatim su se vratile na polovinu prvobitne vrijednosti. Rezultat je prepolovljen u odnosu na početni zbog isključenja jednog poslužitelja aplikacija iz rada. Nije bilo ni prekida u servisu.
Ako postoji potreba za implementacijom rješenja za oporavak od katastrofe koje je tolerantno na greške za Oracle po razumnoj cijeni i uz malo napora za implementaciju/administraciju, tada Oracle RAC i arhitektura rade zajedno biće jedna od najboljih opcija. Umjesto Oracle RAC-a, može postojati bilo koji drugi softver koji obezbjeđuje grupisanje, na primjer isti DBMS ili virtualizacijski sistemi. Princip konstruisanja rješenja će ostati isti. A donja linija je nula za RTO i RPO.
izvor: www.habr.com