Není žádným tajemstvím, že řešení pro clustering databází Oracle docela dobře znám. Nedávno jsem dokončil clustering serveru SQL Server, řešení s vysokou dostupností, které trvalo dva roky od počátečního návrhu po konečnou implementaci. Tento proces zahrnoval dokumentaci požadavků, určení možností, mapování požadavků na detaily implementace, rozpočtování, pořízení, instalaci, konfiguraci a testování.
Nyní, když je můj projekt dokončen, jsem si myslel, že bych uvedl několik položek o clusteringu SQL Serveru z pohledu člověka z Oracle RAC. Všichni víme, že SQL Server a Oracle jsou oba motory RDBMS a mohou mít některé věci společné. Jsou to ale také úplně jiná stvoření. Takže pokud jste spokojeni s infrastrukturou Oracle Grid Infrastructure a RAC a Data Guard a uvažujete o implementaci řešení SQL Server HA, možná vám to poskytne dobré informace.
Náš současný produkční systém je 4uzlová primární databáze Oracle RAC. To zajišťuje vysokou dostupnost (a vysoký výkon) v našem primárním datovém centru. Data Guard používáme k přenosu redo do 3uzlové fyzické pohotovostní databáze RAC. I když SQL Server <> Oracle, chtěl jsem zachovat naši konfiguraci co nejpodobnější, aby se usnadnila administrace. Nasadili jsme tedy 2uzlový SQL Server Failover Cluster na našem primárním webu a 1uzlovou „pohotovostní“ databázi na našem webu DR.
Nyní k mým pozorováním, v žádném konkrétním pořadí.
- Řešení clusteringu HA serveru SQL Server je aktivní/pasivní. Oracle je Active/Active, což je pro mě „lepší“ a ano...to je subjektivní pojem. U naší Active/Passive implementace se mi nelíbila představa dvou fyzických serverů, které tam sedí a jeden je v podstatě nečinný po celou dobu. Máme tedy jeden fyzický server, který je ‚preferovaným‘ uzlem, a jeden virtuální server. Pokud fyzický server selže, clustering automaticky převezme instanci SQL Serveru při selhání na virtuální server a my jsme opět v provozu. Tento aktivní/pasivní cluster nijak neřeší škálovatelnost jako Oracle RAC, ale poskytuje mi vyšší dostupnost v našem primárním prostředí.
- Implementace shlukování je velmi snadná. Zapněte clustering na úrovni operačního systému. Protože se jedná výhradně o zásobník společnosti Microsoft, zabudovali do operačního systému clustering. Už je tu pro vás. Stačí jej zapnout. Poté spusťte Nástroje pro správu –> Správce clusteru s podporou převzetí služeb při selhání a průvodci vás provedou nastavením. Je to mnohem jednodušší než instalace Grid Infrastructure. Ale Oracle se musí potýkat s různými platformami OS, což tam ztěžuje. Bude zajímavé sledovat, jak SQL Server 2016 na Linuxu zvládne Failover Clustering.
- Oracle používá model sdíleného disku, zatímco SQL Server je sdílené nic. Ale musíte použít „sdílený disk“ způsobem, protože disk musí být dostupný na obou uzlech. Clustering MSFC (MS Failover Clustering) však připojí seskupený disk k aktivnímu uzlu. Když se SQL Server přesune do druhého uzlu, buď automaticky nebo ručně, MSFC odpojí disk v jednom uzlu a poté jej připojí k druhému. Je trochu zvláštní mít otevřené okno Průzkumníka Windows a vidět, jak se disk během tohoto přechodu objeví nebo zmizí.
- Grid Infrastructure používá pro operace kvora hlasovací disk. V MSFC můžete mít disk kvora, používat sdílení souborů nebo konfigurovat bez kvora. Pokud použijete druhou možnost, omezíte svou schopnost automatického převzetí služeb při selhání.
- Jsem zvyklý, že moje primární má svůj vlastní cluster a pohotovostní svůj vlastní cluster. U SQL Serveru musí být primární uzly a pohotovostní uzly součástí stejného clusteru. Naštěstí může cluster procházet podsítěmi, což se liší od Oracle GI. Přidání pohotovostního uzlu bylo super snadné, jen jsme mu odebrali hlasovací práva a nekonfigurovali jsme disk kvora pro pohotovostní uzel. To nám vyhovovalo, protože chceme, aby převzetí služeb při selhání do pohotovostního režimu bylo ruční operací.
- Pro záložní databázi můžete použít Database Mirroring, Log Shipping nebo AlwaysOn Availability Groups (AG). První dva jsou na cestě ven, takže jsem šel s AG. AG vyžadují, aby pohotovostní uzel byl součástí stejného clusteru jako primární. Existuje průvodce, který vás provede nastavením databází pro účast v AG. To je mnohem jednodušší než nastavení fyzického pohotovostního režimu Oracle.
- Pro ty z vás, kteří nenávidí dokumentaci Oracle, je čas být vděční. Mnohokrát jsem během tohoto procesu zjistil, že v dokumentaci MS chybí velmi velké kusy. Nikdy jsem například nezjistil, jak nakonfigurovat svůj pohotovostní uzel, aby neměl žádná hlasovací práva. Naštěstí jsme se tím dokázali proklikat.
Když bylo vše řečeno a hotovo, implementace řešení SQL Server nebyla tak náročná. Někdy jsem se musel spolehnout na své znalosti shlukování. Jindy zase překážela terminologie Microsoftu. Například zbytek světa tomu říká „split brain“, ale MS tomu říká „split cluster“. Někdy bylo největší překážkou překonat rozdíly v lexikonu.