Porovnání řešení Oracle RAC HA s Galera Cluster pro MySQL nebo MariaDB

Podniky neustále touží odvozovat poznatky z informací, aby mohly činit spolehlivá, chytřejší rozhodnutí založená na faktech v reálném čase. Protože firmy více spoléhají na data a databáze, jsou informace a zpracování dat jádrem mnoha obchodních operací a obchodních rozhodnutí. Víra v databázi je totální. Žádná z každodenních služeb společnosti nemůže běžet bez základních databázových platforem. V důsledku toho je nutnost škálovatelnosti a výkonu softwaru databázového systému kritičtější než kdy dříve. Hlavními výhodami clusterového databázového systému jsou škálovatelnost a vysoká dostupnost. V tomto blogu se pokusíme porovnat Oracle RAC a Galera Cluster ve světle těchto dvou aspektů. Real Application Clusters (RAC) je prémiové řešení společnosti Oracle pro shlukování databází Oracle a poskytuje vysokou dostupnost a škálovatelnost. Galera Cluster je nejoblíbenější technologie shlukování pro MySQL a MariaDB.

Přehled architektury

Oracle RAC používá software Oracle Clusterware k propojení více serverů. Oracle Clusterware je řešení pro správu clusteru, které je integrováno s databází Oracle, ale lze jej použít i s jinými službami, nejen s databází. Oracle Clusterware je dodatečný software nainstalovaný na serverech se stejným operačním systémem, který umožňuje serverům řetězit se, aby fungovaly jako jeden server.

Oracle Clusterware sleduje instanci a automaticky ji restartuje, pokud dojde k selhání. Pokud je vaše aplikace dobře navržena, nemusíte zaznamenat žádné přerušení služby. Selháním se týká pouze skupina relací (ty, které jsou připojeny k neúspěšné instanci). Výpadek lze pro koncového uživatele efektivně maskovat pomocí pokročilých funkcí RAC, jako je upozornění na rychlé aplikace a rychlé přepnutí při selhání klienta Oracle. Oracle Clusterware řídí členství v uzlech a zabraňuje symptomům rozdělení mozku, ve kterých se dvě nebo více instancí pokouší ovládnout instanci.

Galera Cluster je synchronní technologie aktivního a aktivního klastrování databází pro MySQL a MariaDB. Galera Cluster se liší od toho, co je známé jako Oracle's MySQL Cluster - NDB. Cluster MariaDB je založen na multi-master replikačním pluginu poskytovaném Codership. Od verze 5.5 je plugin Galera (wsrep API) nedílnou součástí MariaDB. Percona XtraDB Cluster (PXC) je také založen na pluginu Galera. Architektura zásuvného modulu Galera stojí na třech základních vrstvách:certifikaci, replikaci a rámci skupinové komunikace. Certifikační vrstva připravuje zápisové sady a provádí na nich certifikační kontroly, čímž zaručuje, že je lze použít. Replikační vrstva spravuje replikační protokol a poskytuje celkovou možnost objednávání. Group Communication Framework implementuje architekturu zásuvných modulů, která umožňuje ostatním systémům připojit se prostřednictvím back-end schématu gcomm.

Aby byl stav v celém clusteru identický, používá rozhraní API wsrep globální ID transakce. Jedinečný identifikátor GTID je vytvořen a přidružen ke každé transakci provedené v uzlu databáze. V Oracle RAC sdílejí různé instance databáze přístup ke zdrojům, jako jsou datové bloky ve vyrovnávací paměti, aby zařadily datové bloky do fronty. Přístup ke sdíleným zdrojům mezi instancemi RAC musí být koordinován, aby nedocházelo ke konfliktům. Aby bylo možné organizovat sdílený přístup k těmto zdrojům, distribuovaná mezipaměť uchovává informace, jako je ID datového bloku, která instance RAC obsahuje aktuální verzi tohoto datového bloku, a režim uzamčení, ve kterém každá instance obsahuje datový blok.

Klíčové koncepty úložiště dat

Oracle RAC spoléhá na architekturu distribuovaných disků. Databázové soubory, řídicí soubory a online redo logy pro databázi musí být přístupné každému uzlu v clusteru. Existuje řada způsobů konfigurace sdíleného úložiště, včetně přímo připojených disků, sítí SAN (Storage Area Network) a NAS (Network Attached Storage) a Oracle ASM. Dva nejoblíbenější jsou OCFS a ASM. Oracle Cluster File System (OCFS) je sdílený souborový systém navržený speciálně pro Oracle RAC. OCFS eliminuje požadavek, aby databázové soubory Oracle byly připojeny k logickým jednotkám, a umožňuje všem uzlům sdílet jediné zařízení Oracle Home ASM, RAW. Oracle ASM je řešení správy úložiště doporučené společností Oracle, které poskytuje alternativu ke konvenčním správcům svazků, souborovým systémům a nezpracovaným zařízením. Oracle ASM poskytuje virtualizační vrstvu mezi databází a úložištěm. Zachází s více disky jako s jednou skupinou disků a umožňuje vám dynamicky přidávat nebo odebírat jednotky a zároveň udržovat databáze online.

Pro Galera není potřeba budovat sofistikované sdílené diskové úložiště, protože každý uzel má svou plnou kopii dat. Je však dobrým zvykem zajistit spolehlivost úložiště pomocí mezipaměti pro zápis zálohované baterií.

Komunikace uzlů clusteru a mezipaměť

Oracle Real Application Clusters má sdílenou architekturu mezipaměti, využívá Oracle Grid Infrastructure k umožnění sdílení serverových a úložných zdrojů. Komunikace mezi uzly je kritickým aspektem integrity clusteru. Každý uzel musí mít alespoň dva síťové adaptéry nebo karty síťového rozhraní:jeden pro veřejné síťové rozhraní a jeden pro propojení. Každý uzel clusteru je připojen ke všem ostatním uzlům prostřednictvím privátní vysokorychlostní sítě, která se také nazývá propojení clusteru.

Soukromá síť je obvykle tvořena pomocí gigabitového Ethernetu, ale pro prostředí s velkým objemem nabízí mnoho prodejců řešení s nízkou latencí a velkou šířkou pásma navržená pro Oracle RAC. Linux také rozšiřuje způsob propojení více fyzických síťových karet do jediné virtuální síťové karty, aby byla zajištěna zvýšená šířka pásma a dostupnost.

Zatímco výchozí přístup k připojení uzlů Galera je použití jedné síťové karty na hostitele, můžete mít více než jednu kartu. ClusterControl vám s takovým nastavením může pomoci. Hlavním rozdílem je požadavek na šířku pásma na propojení. Oracle RAC dodává bloky dat mezi instancemi, takže klade větší zátěž na propojení ve srovnání se zápisovými sadami Galera (které se skládají ze seznamu operací).

S Redundant Interconnect Usage v RAC můžete identifikovat více rozhraní pro použití v privátní klastrové síti, aniž byste museli používat bonding nebo jiné technologie. Tato funkce je k dispozici počínaje Oracle Database 11gR2. Pokud používáte funkci nadměrného propojení Oracle Clusterware, musíte pro rozhraní použít adresy IPv4 (standardní nastavení je UDP).

Pro správu vysoké dostupnosti je každému uzlu clusteru přiřazena virtuální IP adresa (VIP). V případě selhání uzlu může být IP adresa neúspěšného uzlu přidělena přežívajícímu uzlu, aby aplikace mohly nadále přistupovat k databázi prostřednictvím stejné IP adresy.

Technologie Cache Fusion společnosti Oracle vyžaduje sofistikované nastavení sítě, aby se fyzická paměť v každém hostiteli spojila do jediné mezipaměti. Oracle Cache Fusion poskytuje data uložená v mezipaměti jedné instance Oracle, aby k nim měla přístup jakákoli jiná instance tím, že je přenese přes privátní síť. Také chrání integritu dat a koherenci mezipaměti přenosem zamykacích a doplňkových synchronizačních informací mimo uzly clusteru.

Kromě popsaného nastavení sítě můžete pro vaši aplikaci nastavit jednu adresu databáze – Single Client Access Name (SCAN). Primárním účelem SCAN je poskytnout snadnou správu připojení. Můžete například přidat nové uzly do clusteru, aniž byste změnili připojovací řetězec klienta. Tato funkce je způsobena tím, že Oracle bude automaticky distribuovat požadavky odpovídajícím způsobem na základě SCAN IP, které ukazují na podkladové VIP. Skenovací posluchače vytvářejí most mezi klienty a základními místními posluchači, které jsou závislé na VIP.

Pro Galera Cluster by ekvivalentem SCANu bylo přidání databázového proxy před uzly Galera. Proxy by byl jediným kontaktním místem pro aplikace, mohl by zakázat seznam neúspěšných uzlů a směrovat dotazy na zdravé uzly. Samotný proxy server může být redundantní pomocí Keepalived a Virtual IP.

Převzetí služeb při selhání a obnova dat

Hlavní rozdíl mezi Oracle RAC a MySQL Galera Cluster je v tom, že Galera nemá sdílenou architekturu. Místo sdílených disků Galera používá replikaci založenou na certifikaci se skupinovou komunikací a řazením transakcí k dosažení synchronní replikace. Databázový cluster by měl být schopen přežít ztrátu uzlu, i když toho lze dosáhnout různými způsoby. V případě Galery je kritickým aspektem počet uzlů, Galera vyžaduje kvórum, aby zůstala funkční. Tříuzlový cluster může přežít pád jednoho uzlu. S více uzly ve vašem clusteru poroste vaše dostupnost. Oracle RAC nevyžaduje kvorum, aby zůstalo funkční po havárii uzlu. Je to kvůli přístupu k distribuovanému úložišti, které udržuje konzistentní informace o stavu clusteru. Vaše datové úložiště však může být potenciálním bodem selhání vašeho plánu vysoké dostupnosti. I když je poměrně přímočarý úkol mít uzly clusteru Galera rozmístěné po geolokačních datových centrech, s RAC by to nebylo tak snadné. Oracle RAC vyžaduje další špičkové zrcadlení disků, ale základní redundance typu RAID lze dosáhnout uvnitř skupiny disků ASM.

Schémata uzamčení

V databázi pro jednoho uživatele může uživatel měnit data, aniž by se staral o jiné relace upravující stejná data ve stejnou dobu. Ve víceuživatelském databázovém prostředí s více uzly je to však složitější. Databáze pro více uživatelů musí poskytovat následující:

• souběh dat – záruka, že uživatelé mohou přistupovat k datům ve stejnou dobu,
• Konzistence dat – záruka, že každý uživatel vidí konzistentní pohled na data.

Instance klastru vyžadují tři hlavní typy souběžného zamykání:

• Souběh dat se čte v různých instancích,
• Souběh dat čte a zapisuje v různých instancích,
• Souběh dat zapisuje do různých instancí.

Oracle vám umožňuje zvolit politiku zamykání, buď pesimistickou nebo optimistickou, v závislosti na vašich požadavcích. Pro získání souběžného zamykání má RAC dvě další vyrovnávací paměti. Jsou to Global Cache Service (GCS) a Global Enqueue Service (GES). Tyto dvě služby pokrývají proces Cache Fusion, přenosy zdrojů a eskalace zdrojů mezi instancemi. GES zahrnují zámky mezipaměti, slovníkové zámky, zámky transakcí a zámky tabulek. GCS udržuje blokové režimy a blokové přenosy mezi instancemi.

V clusteru Galera má každý uzel své úložiště a vyrovnávací paměti. Když je transakce spuštěna, jsou zapojeny místní databázové zdroje daného uzlu. Při potvrzení jsou operace, které jsou součástí této transakce, vysílány jako součást sady pro zápis do zbytku skupiny. Protože všechny uzly mají stejný stav, bude sada zápisu buď úspěšná na všech uzlech, nebo selže na všech uzlech.

Galera Cluster používá na úrovni clusteru optimistickou kontrolu souběžnosti, která se může objevit v transakcích, které vedou ke zrušení COMMIT. První závazek vyhrává. Když dojde k přerušení na úrovni clusteru, Galera Cluster oznámí chybu uváznutí. To může, ale nemusí mít vliv na architekturu vaší aplikace. Vysoký počet řádků k replikaci v jedné transakci by ovlivnil odezvy uzlů, ačkoli existují techniky, jak se takovému chování vyhnout.

Požadavky na hardware a software

Konfigurace hardwaru obou clusterů nevyžaduje silné zdroje. Minimální konfiguraci clusteru Oracle RAC by uspokojily dva servery se dvěma CPU, fyzickou pamětí alespoň 1,5 GB RAM, množstvím odkládacího prostoru rovnajícímu se velikosti RAM a dvěma síťovými kartami Gigabit Ethernet. Minimální konfigurace uzlu Galery jsou tři uzly (jeden z uzlů může být arbitr, gardb), každý s 1GHz jednojádrovým CPU 512 MB RAM, 100 Mbps síťová karta. I když se jedná o minimum, můžeme s jistotou říci, že v obou případech byste pravděpodobně chtěli mít více zdrojů pro svůj produkční systém.

Každý uzel ukládá software, takže si budete muset připravit několik gigabajtů úložiště. Oracle i Galera mají schopnost jednotlivě opravovat uzly tak, že je jeden po druhém odstraní. Tato průběžná oprava zabraňuje úplnému výpadku aplikace, protože vždy jsou k dispozici databázové uzly pro zpracování provozu.

Je důležité zmínit, že produkční cluster Galera může snadno běžet na virtuálních počítačích nebo na základním holém kovu, zatímco RAC by potřeboval investice do sofistikovaného sdíleného úložiště a optické komunikace.

Monitorování a správa

Oracle Enterprise Manager je oblíbený přístup k monitorování Oracle RAC a Oracle Clusterware. Oracle Enterprise Manager je systém jednotné správy založený na webu Oracle pro monitorování a správu vašeho databázového prostředí. Je součástí licence Oracle Enterprise License a měla by být nainstalována na samostatném serveru. Monitorování a správa řízení klastru se provádí kombinací příkazů crsctl a srvctl, které jsou součástí binárních souborů klastru. Níže naleznete několik příkladů příkazů.

Kontrola stavu prostředků clusteru:

    crsctl status resource -t (or shorter: crsctl stat res -t)

Příklad:

$ crsctl stat res ora.test1.vip
NAME=ora.test1.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=ONLINE on test1

Zkontrolujte stav zásobníku Oracle Clusterware:

    crsctl check cluster

Příklad:

$ crsctl check cluster -all
*****************************************************************
node1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
*****************************************************************
node2:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Zkontrolujte stav služeb Oracle High Availability Services a Oracle Clusterware stack na místním serveru:

    crsctl check crs

Příklad:

$ crsctl check crs
CRS-4638: Oracle High Availablity Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Zastavte službu Oracle High Availability Services na místním serveru.

    crsctl stop has

Zastavte službu Oracle High Availability Services na místním serveru.

    crsctl start has

Zobrazuje stav aplikací uzlů:

    srvctl status nodeapps

Zobrazuje informace o konfiguraci pro všechny SCAN VIP

    srvctl config scan

Příklad:

srvctl config scan -scannumber 1
SCAN name: testscan, Network: 1
Subnet IPv4: 192.51.100.1/203.0.113.46/eth0, static
Subnet IPv6: 
SCAN 1 IPv4 VIP: 192.51.100.195
SCAN VIP is enabled.
SCAN VIP is individually enabled on nodes:
SCAN VIP is individually disabled on nodes:

Nástroj Cluster Verification Utility (CVU) provádí systémové kontroly při přípravě na instalaci, aktualizace oprav nebo jiné systémové změny:

    cluvfy comp ocr

Příklad:

Verifying OCR integrity
Checking OCR integrity...
Checking the absence of a non-clustered configurationl...
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc"...
OCR config file “/etc/oracle/ocr.loc" check successful
Disk group for ocr location “+DATA" available on all the nodes
NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck' as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

Uzly Galera a cluster vyžadují, aby rozhraní API wsrep hlásilo několik stavů, což je odhaleno. V současné době existuje 34 vyhrazených stavových proměnných, které lze zobrazit pomocí příkazu SHOW STATUS.

mysql> SHOW STATUS LIKE 'wsrep_%';

Správa MySQL Galera Cluster je v mnoha ohledech velmi podobná. Existuje jen několik výjimek, jako je bootstrapování clusteru z počátečního uzlu nebo obnova uzlů pomocí operací SST nebo IST.

Bootstrapping cluster:

$ service mysql bootstrap # sysvinit
$ service mysql start --wsrep-new-cluster # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

Ekvivalentní webové řešení pro správu a monitorování Galera Cluster je ClusterControl. Poskytuje webové rozhraní pro nasazení clusterů, monitoruje klíčové metriky, poskytuje databázové poradce a stará se o úkoly správy, jako je zálohování a obnova, automatické opravy, šifrování provozu a správa dostupnosti.

Omezení pracovní zátěže

Oracle poskytuje technologii SCAN, která nám v Galera Cluster chybí. Výhodou SCAN je, že informace o připojení klienta se nemusí měnit, pokud přidáte nebo odeberete uzly nebo databáze v clusteru. Při použití SCAN se databáze Oracle náhodně připojuje k jednomu z dostupných posluchačů SCAN (obvykle třem) kruhovým způsobem a vyrovnává spojení mezi nimi. Lze konfigurovat dva druhy vyvažování zátěže:na straně klienta, vyvažování zátěže v čase připojení a na straně serveru vyvažování zátěže za běhu. Ačkoli v samotném clusteru Galera nic podobného není, stejnou funkcionalitu lze řešit pomocí dalšího softwaru, jako je ProxySQL, HAProxy, Maxscale v kombinaci s Keepalived.

Pokud jde o návrh pracovní zátěže aplikace pro Galera Cluster, měli byste se vyhnout konfliktním aktualizacím na stejném řádku, protože to vede k uváznutí v celém clusteru. Vyhněte se hromadným vkládáním nebo aktualizacím, protože mohou být větší než maximální povolená sada zápisu. To může také způsobit zablokování clusteru.

Při navrhování Oracle HA s RAC musíte mít na paměti, že RAC chrání pouze před selháním serveru a že potřebujete zrcadlit úložiště a mít síťovou redundanci. Moderní webové aplikace vyžadují přístup k datovým službám nezávislým na umístění a vzhledem k omezením architektury úložiště RAC může být obtížné toho dosáhnout. Musíte také strávit značné množství času, abyste získali příslušné znalosti pro správu prostředí; je to dlouhý proces. Na straně zátěže aplikace existují určité nevýhody. Distribuce oddělených operací čtení nebo zápisu na stejné datové množině není optimální, protože latence je přidána dodatečnou výměnou dat mezi uzly. Před migrací na RAC by měly být zkontrolovány věci, jako je rozdělení, mezipaměť sekvencí a řazení.

Redundance více datových center

Podle dokumentace Oracle může být maximální vzdálenost mezi dvěma boxy spojenými bod-bod a běžícími synchronně pouze 10 km. Pomocí specializovaných zařízení lze tuto vzdálenost zvýšit až na 100 km.

Galera Cluster je dobře známý pro své schopnosti replikace více datových center. Má bohatou podporu pro nastavení sítě Wider Area Networks. Může být konfigurován pro vysokou latenci sítě měřením RTT (Round-Trip Time) mezi uzly clusteru a úpravou nezbytných parametrů. Parametry wsrep_provider_options vám umožňují konfigurovat nastavení, jako je podozrivý_timeout, interaktivní_timeout, join_retrans_timouts a mnoho dalších.

Použití Galera a RAC v cloudu

Podle poznámky společnosti Oracle www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf žádný cloud třetí strany v současné době nesplňuje požadavky společnosti Oracle týkající se nativně poskytovaného sdíleného úložiště. „Nativní“ v tomto kontextu znamená, že poskytovatel cloudu musí podporovat sdílené úložiště jako součást své infrastruktury v souladu se zásadami podpory společnosti Oracle.

Díky architektuře sdíleného nic, která není vázána na sofistikované řešení úložiště, lze cluster Galera snadno nasadit v cloudovém prostředí. Věci jako:

• optimalizovaný síťový protokol,
• replikace s ohledem na topologii,
• šifrování provozu,
• detekce a automatické vyřazení nespolehlivých uzlů,

činí proces migrace do cloudu spolehlivější.

Licence a skryté náklady

Licence Oracle je složité téma a vyžadovalo by samostatný článek na blogu. Faktor clusteru to ještě ztěžuje. Náklady se zvyšují, protože musíme přidat některé možnosti pro získání licence na kompletní řešení RAC. Zde chceme pouze zdůraznit, co můžete očekávat a kde najdete další informace.

RAC je součástí licence Oracle Enterprise Edition. Licence Oracle Enterprise je rozdělena do dvou typů, na jmenovaného uživatele a na procesor. Pokud uvažujete o Enterprise Edition s licencí na jádro, pak cena jednoho jádra je 23 000 USD + Oracle DB EE 47 500 USD a ještě je třeba přidat ~ 22% poplatek za podporu. Rádi bychom odkázali na skvělý blog o cenách, který najdete na https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba vypočítal cenu čtyřuzlového Oracle RAC. Celková částka byla 902 400 USD plus dalších 595 584 USD za tříletou údržbu DB, a to nezahrnuje funkce jako dělení na oddíly nebo databázi v paměti, to vše s 60% slevou Oracle.

Galera Cluster je open source řešení, které může provozovat každý zdarma. Pro produkční implementace, které vyžadují podporu dodavatele, jsou k dispozici předplatná. Dobrý výpočet TCO lze nalézt na https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Závěr

I když existují značné rozdíly v architektuře, oba klastry sdílejí hlavní principy a mohou dosáhnout podobných cílů. Podnikový produkt Oracle je dodáván se vším po vybalení (a jeho cenou). S náklady v rozsahu>1 mil. USD, jak je vidět výše, jde o špičkové řešení, které by si mnoho podniků nemohlo dovolit. Galera Cluster lze označit za slušné řešení vysoké dostupnosti pro masy. V určitých případech může být Galera velmi dobrou alternativou k Oracle RAC. Jednou nevýhodou je, že si musíte vytvořit svůj vlastní zásobník, i když to lze pomocí ClusterControl zcela automatizovat. Rádi bychom slyšeli váš názor na toto.