Značajan broj Enterprise aplikacija i virtualizacijskih sustava ima vlastite mehanizme za izgradnju rješenja otpornih na greške. Konkretno, Oracle RAC (Oracle Real Application Cluster) je klaster od dva ili više Oracle poslužitelja baze podataka koji rade zajedno kako bi uravnotežili opterećenje i pružili toleranciju na pogreške na razini poslužitelja/aplikacije. Za rad u ovom načinu rada potrebna vam je zajednička pohrana, koja je obično sustav pohrane.
Kao što smo već raspravljali u jednom od naših , sam sustav za pohranu, unatoč prisutnosti dupliciranih komponenti (uključujući kontrolere), još uvijek ima točke kvara - uglavnom u obliku jednog skupa podataka. Stoga, za izgradnju Oracle rješenja s povećanim zahtjevima pouzdanosti, shema "N poslužitelja - jedan sustav za pohranu" mora biti komplicirana.
Prvo, naravno, moramo odlučiti od kojih se rizika pokušavamo osigurati. U ovom članku nećemo razmatrati zaštitu od prijetnji poput "stigao je meteorit". 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 tzv. Cross-Rack disaster recovery rješenje, kada se zaštita gradi na razini serverskih ormara. Sami ormari mogu se nalaziti u istoj prostoriji ili u različitim, ali obično unutar iste zgrade.
Ovi ormari moraju sadržavati sav potreban set opreme i softvera koji će omogućiti rad Oracle baza podataka bez obzira na stanje “susjeda”. Drugim riječima, korištenjem rješenja za oporavak od katastrofe Cross-Rack eliminiramo rizike kvara:
- Oracle aplikacijski poslužitelji
- Sustavi za pohranu
- Preklopni sustavi
- Potpuni kvar cijele opreme u kabinetu:
- Odbijanje napajanja
- Kvar sustava hlađenja
- Vanjski čimbenici (ljud, priroda, itd.)
Dupliciranje Oracle poslužitelja podrazumijeva sam princip rada Oracle RAC-a i implementira se kroz aplikaciju. Dupliciranje sklopnih postrojenja također nije problem. Ali s dupliciranjem sustava za pohranu, sve nije tako jednostavno.
Najjednostavnija opcija je replikacija podataka iz glavnog sustava za pohranu na rezervni. Sinkroni ili asinkroni, ovisno o mogućnostima sustava za pohranu. Kod asinkrone replikacije odmah se postavlja pitanje osiguravanja konzistentnosti podataka u odnosu na Oracle. Ali čak i ako postoji integracija softvera s aplikacijom, u svakom slučaju, u slučaju kvara na glavnom sustavu pohrane, bit će potrebna ručna intervencija administratora kako bi se klaster prebacio na pričuvnu pohranu.
Složenija opcija su "virtualizatori" softvera i/ili hardvera za pohranu koji će eliminirati probleme s dosljednošću i ručnu intervenciju. Ali složenost implementacije i naknadne administracije, kao i vrlo nepristojna cijena takvih rješenja, mnoge plaši.
AccelStor NeoSapphire™ All Flash array rješenje savršeno je za scenarije kao što je Cross-Rack oporavak od katastrofe koristeći Shared-Nothing arhitekturu. Ovaj model je sustav za pohranu s dva čvora koji koristi vlasničku tehnologiju FlexiRemap® za rad s flash diskovima. Zahvaljujući NeoSapphire™ H710 može pružiti performanse do 600K IOPS@4K nasumičnog pisanja i 1M+ IOPS@4K nasumičnog čitanja, što je nedostižno pri korištenju klasičnih sustava za pohranu temeljenih na RAID-u.
Ali glavna značajka NeoSapphire™ H710 je izvođenje dva čvora u obliku zasebnih kućišta, od kojih svaki ima svoju kopiju podataka. Sinkronizacija čvorova provodi se preko vanjskog InfiniBand sučelja. Zahvaljujući ovoj arhitekturi, moguće je distribuirati čvorove na različite lokacije na udaljenosti do 100m, čime se osigurava Cross-Rack rješenje za oporavak od katastrofe. Oba čvora rade potpuno sinkrono. Sa strane glavnog računala, H710 izgleda kao običan sustav za pohranu s dva kontrolera. Stoga nema potrebe za izvođenjem dodatnih softverskih ili hardverskih opcija ili posebno složenih postavki.
Ako usporedimo sva gore opisana rješenja za oporavak od katastrofe Cross-Rack, tada se opcija iz AccelStora značajno izdvaja od ostalih:
AccelStor NeoSapphire™ Shared Nothing Arhitektura
Softverski ili hardverski sustav za pohranu "virtualizera".
Rješenje temeljeno na replikaciji
dostupnost
Kvar poslužitelja
Nema zastoja
Nema zastoja
Nema zastoja
Kvar prekidača
Nema zastoja
Nema zastoja
Nema zastoja
Kvar sustava za pohranu
Nema zastoja
Nema zastoja
Stanke
Kvar cijelog kabineta
Nema zastoja
Nema zastoja
Stanke
Cijena i složenost
Cijena rješenja
Nisko*
Visok
Visok
Složenost implementacije
Низкая
Visok
Visok
*AccelStor NeoSapphire™ još uvijek je All Flash polje, koje po definiciji ne košta "3 kopejke", pogotovo jer ima dvostruku rezervu kapaciteta. Međutim, uspoređujući konačni trošak rješenja temeljenog na njemu sa sličnim od drugih dobavljača, trošak se može smatrati niskim.
Topologija za povezivanje aplikacijskih poslužitelja i All Flash array čvorova izgledat će ovako:
Prilikom planiranja topologije, također se visoko preporučuje dupliciranje upravljačkih sklopki i međusobno povezivanje poslužitelja.
Ovdje i dalje ćemo govoriti o povezivanju putem Fibre Channela. Ako koristite iSCSI, sve će biti isto, prilagođeno vrstama prekidača koji se koriste i malo drugačijim postavkama polja.
Pripremni radovi na nizu
Korištena oprema i softver
Specifikacije poslužitelja i preklopnika
Komponente
Opis
Oracle Database 11g poslužitelji
dva
Poslužiteljski operativni sustav
Oracle Linux
Verzija Oracle baze podataka
11 g (RAC)
Procesori po poslužitelju
Dva 16-jezgrena Intel® Xeon® CPU E5-2667 v2 na 3.30 GHz
Fizička memorija po poslužitelju
128GB
FC mreža
16Gb/s FC s multipathingom
FC HBA
Emulex Lpe-16002B
Namjenski javni 1GbE priključci za upravljanje klasterom
Intel ethernet adapter RJ45
16Gb/s FC prekidač
Brokat 6505
Namjenski privatni 10GbE priključci za sinkronizaciju podataka
Intel X520
Specifikacija AccelStor NeoSapphire™ All Flash Array
Komponente
Opis
Skladišni sustav
NeoSapphire™ model visoke dostupnosti: H710
Slikovna verzija
4.0.1
Ukupan broj pogona
48
Veličina pogona
1.92TB
Vrsta pogona
SSD
FC ciljni priključci
16x 16Gb portova (8 po čvoru)
Upravljačke luke
1GbE ethernet kabel koji se povezuje s hostovima preko ethernet preklopnika
Port za otkucaje srca
1GbE ethernet kabel koji povezuje dva čvora za pohranu
Port za sinkronizaciju podataka
56Gb/s InfiniBand kabel
Prije nego što možete koristiti niz, morate ga inicijalizirati. Prema zadanim postavkama, kontrolna adresa oba čvora je ista (192.168.1.1). Morate se povezati na njih jedan po jedan i postaviti nove (već različite) adrese za upravljanje i postaviti vremensku sinkronizaciju, nakon čega se portovi za upravljanje mogu povezati u jednu mrežu. Nakon toga, čvorovi se kombiniraju u HA par dodjeljivanjem podmreža za Interlink veze.
Nakon dovršetka inicijalizacije, možete upravljati nizom iz bilo kojeg čvora.
Zatim stvaramo potrebne količine i objavljujemo ih na poslužiteljima aplikacija.
Toplo se preporučuje stvaranje više volumena za Oracle ASM jer će to povećati broj ciljeva za poslužitelje, što će u konačnici poboljšati ukupnu izvedbu (više o redovima čekanja u drugom ).
Testna konfiguracija
Naziv volumena za pohranu
Veličina volumena
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
Ponovi01
100GB
Ponovi02
100GB
Ponovi03
100GB
Ponovi04
100GB
Ponovi05
100GB
Ponovi06
100GB
Ponovi07
100GB
Ponovi08
100GB
Ponovi09
100GB
Ponovi10
100GB
Neka objašnjenja o načinima rada polja i procesima koji se odvijaju u izvanrednim 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 sinkroniziraju iz starije verzije u mlađu, nakon čega se broj mlađe verzije usklađuje, tj. to znači da su kopije identične. Razlozi zašto se verzije mogu razlikovati:
- Zakazano ponovno pokretanje jednog od čvorova
- Nesreća na jednom od čvorova zbog iznenadnog gašenja (napajanje, pregrijavanje itd.).
- Izgubljena InfiniBand veza s nemogućnošću sinkronizacije
- Pad na jednom od čvorova zbog oštećenja podataka. Ovdje ćete morati stvoriti novu HA grupu i dovršiti sinkronizaciju skupa podataka.
U svakom slučaju, čvor koji ostaje online povećava svoj broj verzije za jedan kako bi sinkronizirao svoj skup podataka nakon ponovnog uspostavljanja veze s parom.
Ako se veza preko Ethernet veze izgubi, Heartbeat se privremeno prebacuje na InfiniBand i vraća se natrag u roku od 10 sekundi kada se uspostavi.
Postavljanje hostova
Kako biste osigurali toleranciju na greške i poboljšali performanse, morate omogućiti MPIO podršku za niz. Da biste to učinili, trebate dodati retke u datoteku /etc/multipath.conf, a zatim ponovno pokrenuti uslugu višestruke staze
Skriveni tekstuređaji {
uređaj {
dobavljač "AStor"
path_grouping_policy "group_by_prio"
path_selector "duljina čekanja 0"
path_checker "tur"
karakteristike "0"
hardware_handler "0"
prije "konst"
failback odmah
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
}
}
Dalje, kako bi ASM radio s MPIO putem ASMLiba, trebate promijeniti datoteku /etc/sysconfig/oracleasm i zatim pokrenuti /etc/init.d/oracleasm scandisks
Skriveni tekst
# ORACLEASM_SCANORDER: Usklađivanje uzoraka za naručivanje skeniranja diska
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Uparivanje uzoraka za isključivanje diskova iz skeniranja
ORACLEASM_SCANEXCLUDE="sd"
Primijetiti
Ako ne želite koristiti ASMLib, možete koristiti UDEV pravila, koja su osnova za ASMLib.
Počevši od verzije 12.1.0.2 baze podataka Oracle, opcija je dostupna za instalaciju kao dio softvera ASMFD.
Neophodno je osigurati da su diskovi stvoreni za Oracle ASM usklađeni s veličinom bloka s kojim polje fizički radi (4K). U protivnom može doći do problema s performansama. Stoga je potrebno izraditi volumene s odgovarajućim parametrima:
parted /dev/mapper/device-name mklabel gpt mkpart primarni 2048s 100% align-check optimal 1
Distribucija baza podataka po stvorenim volumenima za našu testnu konfiguraciju
Naziv volumena za pohranu
Veličina volumena
Mapiranje LUN-ova volumena
Pojedinosti o uređaju ASM Volume
Veličina jedinice dodjele
Podaci01
200GB
Mapirajte sve volumene pohrane na sve podatkovne priključke sustava za pohranu
Redundancija: Normalna
Ime: DGDATA
Namjena: Datoteke s podacima
4MB
Podaci02
200GB
Podaci03
200GB
Podaci04
200GB
Podaci05
200GB
Podaci06
200GB
Podaci07
200GB
Podaci08
200GB
Podaci09
200GB
Podaci10
200GB
Grid01
1GB
Redundancija: Normalna
Ime: DGGRID1
Svrha: Mreža: CRS i glasovanje
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundancija: Normalna
Ime: DGGRID2
Svrha: Mreža: CRS i glasovanje
4MB
Grid05
1GB
Grid06
1GB
Ponovi01
100GB
Redundancija: Normalna
Naziv: DGREDO1
Svrha: Ponovi dnevnik niti 1
4MB
Ponovi02
100GB
Ponovi03
100GB
Ponovi04
100GB
Ponovi05
100GB
Ponovi06
100GB
Redundancija: Normalna
Naziv: DGREDO2
Svrha: Ponovi dnevnik niti 2
4MB
Ponovi07
100GB
Ponovi08
100GB
Ponovi09
100GB
Ponovi10
100GB
Postavke baze podataka
- Veličina bloka = 8K
- Swap prostor = 16GB
- Onemogući AMM (Automatsko upravljanje memorijom)
- Onemogući Transparent Huge Pages
Ostale postavke
# 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
✓ meka rešetka nproc 2047
✓ tvrda rešetka nproc 16384
✓ grid soft nofile 1024
✓ tvrda mreža bez datoteke 65536
✓ grid soft stack 10240
✓ rešetkasti tvrdi skup 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 “/kao sysdba”
promijeniti sustav skupa procesi=2000 opseg=spfile;
promijeniti sistemski set open_cursors=2000 scope=spfile;
promijeniti sistem set session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
Test neuspjeha
U svrhu demonstracije, HammerDB je korišten za emulaciju OLTP učitavanja. HammerDB konfiguracija:
Broj skladišta
256
Ukupni broj transakcija po korisniku
1000000000000
Virtualni korisnici
256
Rezultat je bio 2.1M TPM, što je daleko od ograničenja performansi polja , ali je “plafon” za trenutnu hardversku konfiguraciju poslužitelja (prvenstveno zbog procesora) i njihov broj. Svrha ovog testa još uvijek je pokazati toleranciju na pogreške rješenja u cjelini, a ne postići maksimalne performanse. Stoga ćemo jednostavno graditi na ovoj brojci.
Ispitajte kvar na jednom od čvorova
Domaćini su izgubili dio staza do pohrane, nastavljajući raditi kroz preostale s drugim čvorom. Performanse su pale na nekoliko sekundi zbog ponovne izgradnje staza, a zatim su se vratile na normalu. Nije bilo prekida usluge.
Test kvara ormara sa svom opremom
U ovom slučaju, izvedba je također pala na nekoliko sekundi zbog restrukturiranja putanja, a zatim se vratila na polovicu izvorne vrijednosti. Rezultat je prepolovljen od početnog zbog isključenja jednog aplikacijskog poslužitelja iz rada. Nije bilo ni prekida usluge.
Ako postoji potreba za implementacijom Cross-Rack rješenja za oporavak od katastrofe otpornog na greške za Oracle po razumnoj cijeni i s malo implementacije/administriranja, tada Oracle RAC i arhitektura rade zajedno bit će jedna od najboljih opcija. Umjesto Oracle RAC-a može postojati bilo koji drugi softver koji omogućuje klasteriranje, isti DBMS ili virtualizacijski sustavi, na primjer. Princip konstruiranja rješenja ostat će isti. A krajnji rezultat je nula za RTO i RPO.
Izvor: www.habr.com