Značný počet podnikových aplikací a virtualizačních systémů má své vlastní mechanismy pro vytváření řešení odolných vůči chybám. Konkrétně Oracle RAC (Oracle Real Application Cluster) je shluk dvou nebo více databázových serverů Oracle, které spolupracují na vyvážení zatížení a zajištění odolnosti proti chybám na úrovni serveru/aplikace. Pro práci v tomto režimu potřebujete sdílené úložiště, což je obvykle úložný systém.
Jak jsme již probrali v jednom z našich , samotný úložný systém má i přes přítomnost duplicitních komponent (včetně řadičů) stále místa selhávání – především v podobě jediné sady dat. Proto, aby bylo možné vytvořit řešení Oracle se zvýšenými požadavky na spolehlivost, musí být schéma „N serverů - jeden úložný systém“ komplikované.
Nejprve se samozřejmě musíme rozhodnout, proti jakým rizikům se snažíme pojistit. V tomto článku se nebudeme zabývat ochranou proti hrozbám, jako je „meteorit dorazil“. Vytvoření geograficky rozptýleného řešení pro obnovu po havárii tedy zůstane tématem pro jeden z následujících článků. Zde se podíváme na tzv. Cross-Rack řešení pro obnovu po havárii, kdy je ochrana postavena na úrovni serverových skříní. Samotné skříně mohou být umístěny ve stejné místnosti nebo v různých místnostech, ale obvykle ve stejné budově.
Tyto skříně musí obsahovat celou potřebnou sadu zařízení a softwaru, které umožní provoz databází Oracle bez ohledu na stav „souseda“. Jinými slovy, pomocí řešení pro obnovu po havárii Cross-Rack eliminujeme rizika selhání:
- Aplikační servery Oracle
- Skladovací systémy
- Spínací systémy
- Úplné selhání všech zařízení ve skříni:
- Odmítnutí moci
- Selhání chladicího systému
- Vnější faktory (člověk, příroda atd.)
Duplikace serverů Oracle implikuje samotný princip fungování Oracle RAC a je implementována prostřednictvím aplikace. Duplikace spojovacích zařízení také není problém. Ale s duplikací úložného systému není vše tak jednoduché.
Nejjednodušší možností je replikace dat z hlavního úložného systému na záložní. Synchronní nebo asynchronní, v závislosti na možnostech úložného systému. S asynchronní replikací okamžitě vyvstává otázka zajištění konzistence dat ve vztahu k Oracle. Ale i když existuje softwarová integrace s aplikací, v každém případě bude v případě selhání hlavního úložného systému nutný manuální zásah administrátorů, aby se cluster přepnul na záložní úložiště.
Složitější možností jsou softwarové a/nebo hardwarové „virtualizátory“ úložiště, které eliminují problémy s konzistencí a manuální zásahy. Ale složitost nasazení a následné správy, stejně jako velmi neslušná cena takových řešení, mnohé odstraší.
Řešení AccelStor NeoSapphire™ All Flash pole je ideální pro scénáře, jako je obnova po havárii Cross-Rack pomocí architektury Shared-Nothing. Tento model je dvouuzlový úložný systém, který využívá proprietární technologii FlexiRemap® pro práci s flash disky. Díky NeoSapphire™ H710 je schopen poskytovat výkon až 600K IOPS@4K náhodného zápisu a 1M+ IOPS@4K náhodné čtení, což je nedosažitelné při použití klasických úložných systémů na bázi RAID.
Ale hlavním rysem NeoSapphire™ H710 je provádění dvou uzlů ve formě samostatných případů, z nichž každý má svou vlastní kopii dat. Synchronizace uzlů se provádí prostřednictvím externího rozhraní InfiniBand. Díky této architektuře je možné distribuovat uzly na různá místa na vzdálenost až 100 m, čímž poskytuje řešení pro obnovu po havárii Cross-Rack. Oba uzly pracují zcela synchronně. Ze strany hostitele vypadá H710 jako obyčejný úložný systém se dvěma řadiči. Není tedy potřeba provádět žádné další softwarové nebo hardwarové možnosti nebo zvlášť složitá nastavení.
Pokud porovnáme všechna výše popsaná řešení pro obnovu po havárii Cross-Rack, pak možnost od AccelStor znatelně vyčnívá z ostatních:
AccelStor NeoSapphire™ Shared Nothing Architecture
Softwarový nebo hardwarový „virtualizační“ úložný systém
Řešení založené na replikaci
Dostupnost
Selhání serveru
Žádné prostoje
Žádné prostoje
Žádné prostoje
Selhání spínače
Žádné prostoje
Žádné prostoje
Žádné prostoje
Selhání úložného systému
Žádné prostoje
Žádné prostoje
Prostoje
Porucha celé skříně
Žádné prostoje
Žádné prostoje
Prostoje
Náklady a složitost
Náklady na řešení
Nízký*
Vysoký
Vysoký
Složitost nasazení
Nízká
Vysoký
Vysoký
*AccelStor NeoSapphire™ je stále pole All Flash, které podle definice nestojí „3 kopecky“, zejména proto, že má dvojnásobnou kapacitní rezervu. Při porovnání konečných nákladů na řešení na něm založeném s podobnými od jiných dodavatelů však lze náklady považovat za nízké.
Topologie pro připojení aplikačních serverů a všech uzlů pole Flash bude vypadat takto:
Při plánování topologie se také důrazně doporučuje duplikovat přepínače správy a propojit servery.
Zde a dále budeme hovořit o připojení přes Fibre Channel. Pokud použijete iSCSI, bude vše stejné, upravené pro typy použitých přepínačů a mírně odlišné nastavení pole.
Přípravné práce na poli
Použité vybavení a software
Specifikace serveru a přepínače
Komponenty
popis
Servery Oracle Database 11g
Dvě
Operační systém serveru
Oracle Linux
Verze databáze Oracle
11g (RAC)
Procesory na server
Dva 16jádrové procesory Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Fyzická paměť na server
128GB
FC síť
16Gb/s FC s multipathingem
FC HBA
Emulex Lpe-16002B
Vyhrazené veřejné 1GbE porty pro správu clusteru
Ethernetový adaptér Intel RJ45
16Gb/s FC switch
Brokát 6505
Vyhrazené privátní 10GbE porty pro synchronizaci dat
Intel X520
AccelStor NeoSapphire™ Všechny specifikace Flash Array
Komponenty
popis
Úložný systém
NeoSapphire™ model vysoké dostupnosti: H710
Verze obrázku
4.0.1
Celkový počet jednotek
48
Velikost disku
1.92TB
Typ pohonu
SSD
FC cílové porty
16x 16Gb porty (8 na uzel)
Porty pro správu
Ethernetový kabel 1GbE pro připojení k hostitelům přes ethernetový přepínač
Port srdečního tepu
Ethernetový kabel 1GbE propojující dva úložné uzly
Port pro synchronizaci dat
Kabel InfiniBand 56 Gb/s
Než budete moci použít pole, musíte jej inicializovat. Ve výchozím nastavení je řídicí adresa obou uzlů stejná (192.168.1.1). Musíte se k nim připojit jeden po druhém a nastavit nové (již jiné) adresy pro správu a nastavit synchronizaci času, po které lze porty Management připojit do jedné sítě. Poté jsou uzly spojeny do páru HA přiřazením podsítí pro propojení Interlink.
Po dokončení inicializace můžete pole spravovat z libovolného uzlu.
Dále vytvoříme potřebné svazky a publikujeme je na aplikační servery.
Důrazně se doporučuje vytvořit více svazků pro Oracle ASM, protože to zvýší počet cílů pro servery, což v konečném důsledku zlepší celkový výkon (více o frontách v jiném ).
Testovací konfigurace
Název svazku úložiště
Velikost svazku
Data 01
200GB
Data 02
200GB
Data 03
200GB
Data 04
200GB
Data 05
200GB
Data 06
200GB
Data 07
200GB
Data 08
200GB
Data 09
200GB
Data 10
200GB
Mřížka01
1GB
Mřížka02
1GB
Mřížka03
1GB
Mřížka04
1GB
Mřížka05
1GB
Mřížka06
1GB
Znovu 01
100GB
Znovu 02
100GB
Znovu 03
100GB
Znovu 04
100GB
Znovu 05
100GB
Znovu 06
100GB
Znovu 07
100GB
Znovu 08
100GB
Znovu 09
100GB
Znovu 10
100GB
Některá vysvětlení provozních režimů pole a procesů vyskytujících se v nouzových situacích
Sada dat každého uzlu má parametr „číslo verze“. Po prvotní inicializaci je stejná a rovná se 1. Pokud je z nějakého důvodu číslo verze jiné, tak se data vždy synchronizují ze starší verze na mladší, načež se zarovná číslo mladší verze, tzn. to znamená, že kopie jsou totožné. Důvody, proč se verze mohou lišit:
- Naplánovaný restart jednoho z uzlů
- Nehoda na jednom z uzlů v důsledku náhlého vypnutí (napájení, přehřátí atd.).
- Ztratilo se připojení InfiniBand s nemožností synchronizace
- Selhání jednoho z uzlů kvůli poškození dat. Zde budete muset vytvořit novou HA skupinu a dokončit synchronizaci datové sady.
V každém případě uzel, který zůstane online, zvýší své číslo verze o jedna, aby po obnovení spojení s párem synchronizoval svůj datový soubor.
Pokud dojde ke ztrátě připojení přes ethernetové spojení, Heartbeat se dočasně přepne na InfiniBand a vrátí se zpět do 10 sekund po jeho obnovení.
Nastavení hostitelů
Chcete-li zajistit odolnost proti chybám a zlepšit výkon, musíte pro pole povolit podporu MPIO. Chcete-li to provést, musíte do souboru /etc/multipath.conf přidat řádky a poté restartovat službu multipath
Skrytý textzařízení {
přístroj {
prodejce "AStor"
path_grouping_policy "group_by_prio"
path_selector "queue-length 0"
path_checker "tur"
funkce "0"
hardware_handler "0"
prio "konst"
okamžité obnovení selhání
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names ano
detect_prio ano
rr_min_io_rq 1
no_path_retry 0
}
}
Dále, aby ASM fungovalo s MPIO přes ASMLib, musíte změnit soubor /etc/sysconfig/oracleasm a poté spustit /etc/init.d/oracleasm scandisks
Skrytý text
# ORACLEASM_SCANORDER: Odpovídající vzory pro objednání skenování disku
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Odpovídající vzory pro vyloučení disků z kontroly
ORACLEASM_SCANEXCLUDE="sd"
Poznámka
Pokud nechcete používat ASMLib, můžete použít pravidla UDEV, která jsou základem pro ASMLib.
Počínaje verzí 12.1.0.2 Oracle Database je tato možnost dostupná pro instalaci jako součást softwaru ASMFD.
Je nutné zajistit, aby disky vytvořené pro Oracle ASM byly zarovnány s velikostí bloku, se kterou pole fyzicky pracuje (4K). Jinak mohou nastat problémy s výkonem. Proto je nutné vytvořit svazky s příslušnými parametry:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimální 1
Distribuce databází napříč vytvořenými svazky pro naši testovací konfiguraci
Název svazku úložiště
Velikost svazku
Mapování svazku LUN
Detail zařízení ASM Volume
Velikost alokační jednotky
Data 01
200GB
Mapujte všechny úložné svazky na všechny datové porty úložného systému
Redundance: Normální
Název: DGDATA
Účel:Datové soubory
4MB
Data 02
200GB
Data 03
200GB
Data 04
200GB
Data 05
200GB
Data 06
200GB
Data 07
200GB
Data 08
200GB
Data 09
200GB
Data 10
200GB
Mřížka01
1GB
Redundance: Normální
Název: DGGRID1
Účel:Mřížka: CRS a hlasování
4MB
Mřížka02
1GB
Mřížka03
1GB
Mřížka04
1GB
Redundance: Normální
Název: DGGRID2
Účel:Mřížka: CRS a hlasování
4MB
Mřížka05
1GB
Mřížka06
1GB
Znovu 01
100GB
Redundance: Normální
Název: DGREDO1
Účel: Zopakujte protokol vlákna 1
4MB
Znovu 02
100GB
Znovu 03
100GB
Znovu 04
100GB
Znovu 05
100GB
Znovu 06
100GB
Redundance: Normální
Název: DGREDO2
Účel: Zopakujte protokol vlákna 2
4MB
Znovu 07
100GB
Znovu 08
100GB
Znovu 09
100GB
Znovu 10
100GB
Nastavení databáze
- Velikost bloku = 8K
- Odkládací prostor = 16 GB
- Zakázat AMM (automatickou správu paměti)
- Zakázat průhledné obrovské stránky
Další nastavení
# 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, pokud používáte Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000 XNUMX
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ mřížka soft nofile 1024
✓ grid hard nofile 65536
✓ mřížka soft stack 10240
✓ pevný zásobník mříž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“
alter system set process=2000 scope=spfile;
změnit systémovou sadu open_cursors=2000 scope=spfile;
změnit systémovou sadu session_cached_cursors=300 scope=spfile;
alter system set db_files=8192 scope=spfile;
Test selhání
Pro demonstrační účely byl HammerDB použit k emulaci zatížení OLTP. Konfigurace HammerDB:
Počet skladů
256
Celkový počet transakcí na uživatele
1000000000000
Virtuální uživatelé
256
Výsledkem bylo 2.1 milionu TPM, což je daleko od limitu výkonu pole , ale je „stropem“ pro aktuální hardwarovou konfiguraci serverů (především kvůli procesorům) a jejich počet. Účelem tohoto testu je stále demonstrovat odolnost řešení jako celku proti chybám, nikoli dosáhnout maximálního výkonu. Proto budeme jednoduše stavět na tomto čísle.
Test na selhání jednoho z uzlů
Hostitelé ztratili část cest k úložišti a pokračovali v práci přes zbývající s druhým uzlem. Výkon na několik sekund klesl kvůli přestavbě cest a poté se vrátil do normálu. K přerušení provozu nedošlo.
Test poruchy skříně s veškerým vybavením
V tomto případě také výkon na pár sekund klesl kvůli restrukturalizaci cest a poté se vrátil na polovinu původní hodnoty. Výsledek byl oproti původnímu poloviční z důvodu vyřazení jednoho aplikačního serveru z provozu. Nedošlo ani k přerušení provozu.
Pokud je potřeba implementovat řešení pro obnovu po havárii Cross-Rack odolné proti chybám pro Oracle za rozumnou cenu a s malým úsilím při nasazení/administraci, pak Oracle RAC a architektura spolupracují. bude jednou z nejlepších možností. Místo Oracle RAC může existovat jakýkoli jiný software, který poskytuje clustering, například stejné DBMS nebo virtualizační systémy. Princip konstrukce řešení zůstane stejný. A spodní řádek je nula pro RTO a RPO.
Zdroj: www.habr.com