Konsiderinda nombro da Enterprise-aplikoj kaj virtualigsistemoj havas siajn proprajn mekanismojn por konstruado de misfunkciaj solvoj. Specife, Oracle RAC (Oracle Real Application Cluster) estas areto de du aŭ pli da Oracle datumbazserviloj laborantaj kune por ekvilibrigi ŝarĝon kaj disponigi misfunkciadon sur la servilo/apliknivelo. Por labori en ĉi tiu reĝimo, vi bezonas komunan stokadon, kiu kutime estas stokadosistemo.
Kiel ni jam diskutis en unu el niaj , la stoksistemo mem, malgraŭ la ĉeesto de duobligitaj komponantoj (inkluzive de regiloj), ankoraŭ havas punktojn de fiasko - ĉefe en la formo de ununura aro de datumoj. Tial, por konstrui Oracle-solvon kun pliigitaj fidindecpostuloj, la skemo "N-serviloj - unu stoka sistemo" devas esti komplika.
Unue, kompreneble, ni devas decidi kontraŭ kiuj riskoj ni provas certigi. En ĉi tiu artikolo, ni ne konsideros protekton kontraŭ minacoj kiel "meteorito alvenis." Do konstrui geografie disigitan katastrofan solvon restos temo por unu el la sekvaj artikoloj. Ĉi tie ni rigardos la tiel nomatan Cross-Rack-katastrofan solvon, kiam protekto estas konstruita ĉe la nivelo de servilaj kabinetoj. La kabinetoj mem povas troviĝi en la sama ĉambro aŭ en malsamaj, sed kutime ene de la sama konstruaĵo.
Ĉi tiuj kabinetoj devas enhavi la tutan necesan aron de ekipaĵo kaj programaro, kiuj certigos la funkciadon de Oracle-datumbazoj sendepende de la stato de la "najbaro". Alivorte, uzante la Cross-Rack-katastrofan reakiro, ni forigas la riskojn de fiasko:
- Oracle-Aplikaj Serviloj
- Stoksistemoj
- Ŝaltaj sistemoj
- Kompleta fiasko de ĉiuj ekipaĵoj en la kabineto:
- Potenca rifuzo
- Malsukceso de la malvarmiga sistemo
- Eksteraj faktoroj (homo, naturo, ktp.)
Duobligo de Oracle-serviloj implicas la tre funkciantan principon de Oracle RAC kaj estas efektivigita per aplikaĵo. Duobligo de ŝanĝinstalaĵoj ankaŭ ne estas problemo. Sed kun duobligo de la stokadsistemo, ĉio ne estas tiel simpla.
La plej simpla opcio estas reproduktado de datumoj de la ĉefa stokada sistemo al la rezerva. Sinkrona aŭ nesinkrona, depende de la kapabloj de la stokadsistemo. Kun nesinkrona reproduktado, la demando tuj ekestas certigi datuman konsistencon rilate al Orakolo. Sed eĉ se ekzistas programaro integriĝo kun la aplikaĵo, ĉiukaze, se estas malsukceso en la ĉefa stokadosistemo, mana interveno de administrantoj estos postulata por ŝanĝi la areton al rezerva stokado.
Pli kompleksa opcio estas programaro kaj/aŭ aparataro stokado "virtualiziloj", kiuj eliminos konsekvencproblemojn kaj manan intervenon. Sed la komplekseco de deplojo kaj posta administrado, same kiel la tre maldeca kosto de tiaj solvoj, malkuraĝigas multajn.
La solvo de tabelo AccelStor NeoSapphire™ All Flash estas perfekta por scenaroj kiel ekzemple Cross-Rack katastrofa reakiro uzante Shared-Nothing-arkitekturon. Ĉi tiu modelo estas du-noda stokadsistemo, kiu uzas proprietan FlexiRemap®-teknologion por labori kun poŝmemoriloj. Danke al NeoSapphire™ H710 kapablas liveri rendimenton ĝis 600K IOPS@4K hazarda skribo kaj 1M+ IOPS@4K hazarda legado, kio estas neatingebla kiam vi uzas klasikajn RAID-bazitajn stokadsistemojn.
Sed la ĉefa trajto de NeoSapphire™ H710 estas la ekzekuto de du nodoj en la formo de apartaj kazoj, ĉiu el kiuj havas sian propran kopion de la datumoj. Sinkronigo de nodoj estas efektivigita per la ekstera InfiniBand-interfaco. Danke al ĉi tiu arkitekturo, eblas distribui nodojn al malsamaj lokoj je distanco de ĝis 100m, tiel provizante Cross-Rack katastrofa reakiro solvo. Ambaŭ nodoj funkcias tute sinkrone. De la gastiganta flanko, la H710 aspektas kiel ordinara du-regila stokadsistemo. Tial, ne necesas fari iujn ajn aldonajn opciojn de programaro aŭ aparataro aŭ precipe kompleksajn agordojn.
Se ni komparas ĉiujn Cross-Rack-katastrofajn solvojn priskribitajn supre, tiam la opcio de AccelStor rimarkeble elstaras de la resto:
AccelStor NeoSapphire™ Shared Nothing Architecture
Programaro aŭ aparataro "virtualiganto" stokadosistemo
Solvo bazita en reproduktado
Disponibilidad
Servila fiasko
Neniu Malfunkcio
Neniu Malfunkcio
Neniu Malfunkcio
Ŝaltilo fiasko
Neniu Malfunkcio
Neniu Malfunkcio
Neniu Malfunkcio
Fiasko de la stokada sistemo
Neniu Malfunkcio
Neniu Malfunkcio
Malfrua tempo
Tuta kabineta fiasko
Neniu Malfunkcio
Neniu Malfunkcio
Malfrua tempo
Kosto kaj komplekseco
Solvokosto
Malalta*
Высокая
Высокая
Deploja komplekseco
Malalta
Высокая
Высокая
*AccelStor NeoSapphire™ estas ankoraŭ All Flash-aro, kiu laŭdifine ne kostas "3 kopekojn", precipe ĉar ĝi havas duoblan kapacitan rezervon. Tamen, kiam oni komparas la finan koston de solvo bazita sur ĝi kun similaj de aliaj vendistoj, la kosto povas esti konsiderata malalta.
La topologio por konekti aplikaĵservilojn kaj All Flash-arajn nodojn aspektos jene:
Planante la topologion, estas ankaŭ tre rekomendite duobligi administrajn ŝaltilojn kaj interkonekti servilojn.
Ĉi tie kaj plu ni parolos pri konekto per Fibre Channel. Se vi uzas iSCSI, ĉio estos la sama, alĝustigita por la specoj de ŝaltiloj uzataj kaj iomete malsamaj tabelaj agordoj.
Prepara laboro sur la tabelo
Ekipaĵo kaj programaro uzata
Specifoj pri Servilo kaj Ŝaltilo
Komponantoj
Priskribo
Serviloj Oracle Database 11g
Du
Servila operaciumo
Oracle Linukso
Versio de Oracle datumbazo
11 g (RAC)
Procesoroj per servilo
Du 16 kernoj Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Fizika memoro per servilo
128GB
FC-reto
16 Gb/s FC kun multivoja
FC HBA
Emulex Lpe-16002B
Dediĉitaj publikaj 1GbE-havenoj por administrado de clusteroj
Intel-eterreta adaptilo RJ45
16Gb/s FC-ŝaltilo
Brokado 6505
Dediĉitaj privataj 10GbE-havenoj por datumsinkronigo
Intel X520
AccelStor NeoSapphire™ All Flash Array Specifo
Komponantoj
Priskribo
Stokada sistemo
NeoSapphire™ alta havebleca modelo: H710
Bilda versio
4.0.1
Tuta nombro da diskoj
48
Drive grandeco
1.92TB
Stirado tipo
SSD
FC-celaj havenoj
16x 16Gb-havenoj (8 per nodo)
Administraj havenoj
La 1GbE-eterreta kablo konektanta al gastigantoj per eterreta ŝaltilo
Korbata haveno
La 1GbE-eterreta kablo konektanta inter du stokaj nodoj
Datensinkroniga haveno
56 Gb/s InfiniBand-kablo
Antaŭ ol vi povas uzi tabelon, vi devas pravalorigi ĝin. Defaŭlte, la kontroladreso de ambaŭ nodoj estas la sama (192.168.1.1). Vi devas konekti al ili unu post alia kaj agordi novajn (jam malsamajn) administradadresojn kaj agordi tempan sinkronigon, post kio la Administraj havenoj povas esti konektitaj al ununura reto. Poste, la nodoj estas kombinitaj en HA-paron asignante subretojn por Interlink-ligoj.
Post komencado estas kompleta, vi povas administri la tabelon de iu ajn nodo.
Poste ni kreas la necesajn volumojn kaj publikigas ilin al aplikaĵserviloj.
Estas tre rekomendite krei plurajn volumojn por Oracle ASM ĉar ĉi tio pliigos la nombron da celoj por la serviloj, kio finfine plibonigos ĝeneralan rendimenton (pli pri atendovicoj en alia ).
Testa agordo
Stoka Volumo Nomo
Volumo Grandeco
Datumoj01
200GB
Datumoj02
200GB
Datumoj03
200GB
Datumoj04
200GB
Datumoj05
200GB
Datumoj06
200GB
Datumoj07
200GB
Datumoj08
200GB
Datumoj09
200GB
Datumoj10
200GB
Krado01
1GB
Krado02
1GB
Krado03
1GB
Krado04
1GB
Krado05
1GB
Krado06
1GB
Refari01
100GB
Refari02
100GB
Refari03
100GB
Refari04
100GB
Refari05
100GB
Refari06
100GB
Refari07
100GB
Refari08
100GB
Refari09
100GB
Refari10
100GB
Kelkaj klarigoj pri la operaciaj modoj de la tabelo kaj la procezoj okazantaj en krizaj situacioj
La datumaro de ĉiu nodo havas parametron "versionumero". Post komenca inicialigo, ĝi estas la sama kaj egala al 1. Se ial la versio numero estas malsama, tiam datumoj ĉiam estas sinkronigitaj de la pli malnova versio al la pli juna, post kio la nombro de la pli juna versio estas vicigita, t.e. tio signifas, ke la kopioj estas identaj. Kialoj kial versioj povas esti malsamaj:
- Planita rekomenco de unu el la nodoj
- Akcidento sur unu el la nodoj pro subita haltigo (elektroprovizo, trovarmiĝo, ktp.).
- Perdita InfiniBand-konekto kun malkapablo sinkronigi
- Kraŝo sur unu el la nodoj pro datuma korupto. Ĉi tie vi devos krei novan HA-grupon kaj kompletigi sinkronigon de la datumaro.
Ĉiukaze, la nodo, kiu restas enreta, pliigas sian version-numeron je unu por sinkronigi sian datuman aron post kiam la konekto kun la paro estas restarigita.
Se la konekto tra la Ethernet-ligo estas perdita, Heartbeat provizore ŝanĝas al InfiniBand kaj revenas ene de 10 sekundoj kiam ĝi estas restarigita.
Starigante gastigantojn
Por certigi misfunkciadon kaj plibonigi rendimenton, vi devas ebligi MPIO-subtenon por la tabelo. Por fari tion, vi devas aldoni liniojn al la dosiero /etc/multipath.conf, kaj poste rekomenci la multivojan servon
Kaŝita tekstoaparatoj {
aparato {
vendisto "AStor"
path_grouping_policy "group_by_prio"
path_selector "queu-longo 0"
path_checker "tur"
prezentas "0"
aparataro_traktilo "0"
prio "konst"
malsukceso tuja
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names jes
detect_prio jes
rr_min_io_rq 1
no_path_retry 0
}
}
Poste, por ke ASM funkciu kun MPIO per ASMLib, vi devas ŝanĝi la dosieron /etc/sysconfig/oracleasm kaj poste ruli /etc/init.d/oracleasm scandisks.
Kaŝita teksto
# ORACLEASM_SCANORDER: Kongruaj ŝablonoj por ordigi diskan skanadon
ORACLEASM_SCANORDER = "dm"
# ORACLEASM_SCANEXCLUDE: Kongruaj ŝablonoj por ekskludi diskojn de skanado
ORACLEASM_SCANEXCLUDE="sd"
Примечание
Se vi ne volas uzi ASMLib, vi povas uzi la UDEV-regulojn, kiuj estas la bazo por ASMLib.
Komencante kun versio 12.1.0.2 de Oracle Database, la opcio disponeblas por instalo kiel parto de la ASMFD-programaro.
Nepras certigi, ke la diskoj kreitaj por Oracle ASM estas vicigitaj kun la blokgrandeco, kun kiu la tabelo fizike funkcias (4K). Alie, agado problemoj povas okazi. Tial necesas krei volumojn kun la taŭgaj parametroj:
parted /dev/mapper/device-name mklabel gpt mkpart primara 2048s 100% vicigi-kontrolo optimuma 1
Distribuado de datumbazoj tra kreitaj volumoj por nia testa agordo
Stoka Volumo Nomo
Volumo Grandeco
Volumaj LUN-oj mapado
ASM-Voluma Aparato Detalo
Asigno Unueco Grandeco
Datumoj01
200GB
Mapu ĉiujn stokajn volumojn al stokadsistemo ĉiuj datenhavenoj
Redundo: Normala
Nomo: DGDATA
Celo: Datumoj
4MB
Datumoj02
200GB
Datumoj03
200GB
Datumoj04
200GB
Datumoj05
200GB
Datumoj06
200GB
Datumoj07
200GB
Datumoj08
200GB
Datumoj09
200GB
Datumoj10
200GB
Krado01
1GB
Redundo: Normala
Nomo: DGGRID1
Celo:Krado: CRS kaj Voĉdonado
4MB
Krado02
1GB
Krado03
1GB
Krado04
1GB
Redundo: Normala
Nomo: DGGRID2
Celo:Krado: CRS kaj Voĉdonado
4MB
Krado05
1GB
Krado06
1GB
Refari01
100GB
Redundo: Normala
Nomo: DGRADO1
Celo: Refari protokolon de fadeno 1
4MB
Refari02
100GB
Refari03
100GB
Refari04
100GB
Refari05
100GB
Refari06
100GB
Redundo: Normala
Nomo: DGRADO2
Celo: Refari protokolon de fadeno 2
4MB
Refari07
100GB
Refari08
100GB
Refari09
100GB
Refari10
100GB
Datumbazaj Agordoj
- Grando de bloko = 8K
- Interŝanĝa spaco = 16GB
- Malebligu AMM (Aŭtomata Memoradministrado)
- Malebligu Travideblajn Grandegajn Paĝojn
Aliaj agordoj
# 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 agordu ĉi tion se vi uzas Linukson x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ krado mola nproc 2047
✓ krado malmola nproc 16384
✓ krado mola nofile 1024
✓ krado malmola nofile 65536
✓ krado mola stako 10240
✓ krado malmola stako 32768
✓ orakolo mola nproc 2047
✓ orakolo malmola nproc 16384
✓ orakolo mola nofile 1024
✓ orakolo malmola nofile 65536
✓ orakolo mola stako 10240
✓ orakolo malmola stako 32768
✓ mola memlock 120795954
✓ malmola memlock 120795954
sqlplus "/as sysdba"
alter system set processes=2000 scope=spfile;
alter system set open_cursors=2000 scope=spfile;
ŝanĝi sisteman aron session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
Malsukcesa testo
Por pruvceloj, HammerDB estis uzata por kopii OLTP-ŝarĝon. HammerDB-agordo:
Nombro de Stokejoj
256
Sumaj Transakcioj por Uzanto
1000000000000
Virtualaj Uzantoj
256
La rezulto estis 2.1M TPM, kio estas malproksime de la rendimentolimo de la tabelo , sed estas "plafono" por la nuna aparatara agordo de serviloj (ĉefe pro procesoroj) kaj ilia nombro. La celo de ĉi tiu testo ankoraŭ estas montri la misfunkciadon de la solvo entute, kaj ne atingi maksimuman rendimenton. Tial ni simple konstruos sur ĉi tiu figuro.
Testo pri fiasko de unu el la nodoj
La gastigantoj perdis parton de la vojoj al la stokado, daŭrante labori tra la ceteraj kun la dua nodo. Efikeco malpliiĝis dum kelkaj sekundoj pro la padoj rekonstruitaj, kaj poste revenis al normalo. Ne estis interrompo en servo.
Testo pri fiasko de kabineto kun ĉiuj ekipaĵoj
En ĉi tiu kazo, rendimento ankaŭ malpliiĝis dum kelkaj sekundoj pro la restrukturado de la vojoj, kaj poste revenis al duono de la originala valoro. La rezulto estis duonigita de la komenca pro la ekskludo de unu aplika servilo de operacio. Ankaŭ ne estis interrompo en servo.
Se necesas efektivigi mistoleran Cross-Rack-katastrofan reakiro-solvon por Oracle je akceptebla kosto kaj kun malmulte da deplojo/administrado, tiam Oracle RAC kaj arkitekturo funkcias kune. estos unu el la plej bonaj elektoj. Anstataŭ Oracle RAC, povas ekzisti ajna alia programaro kiu disponigas clustering, la samajn DBMS aŭ virtualigajn sistemojn, ekzemple. La principo de konstruado de la solvo restos la sama. Kaj la fundo estas nulo por RTO kaj RPO.
fonto: www.habr.com