Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Platí pro:
SQL Server v Linuxu
Počínaje SQL Serverem 2017 (14.x) se SQL Server podporuje v Linuxu i Ve Windows. Stejně jako nasazení SQL Serveru založeného na Windows musí být databáze a instance SQL Serveru vysoce dostupné v linuxu. Tento článek se zabývá základními informacemi, které vám pomohou pochopit Pacemaker s Corosync a jak jej naplánovat a nasadit pro konfigurace SQL Serveru.
Základy rozšíření/doplňku HA (High Availability)
Veškeré aktuálně podporované distribuce dodávají rozšíření pro vysokou dostupnost, které je založeno na klastrovacím systému Pacemaker. Tato sada obsahuje dvě klíčové komponenty: Pacemaker a Corosync. Všechny komponenty zásobníku jsou:
- Kardiostimulátor. Základní komponenta clusteringu, která koordinuje věci napříč clusterovanými počítači.
- Corosync. Architektura a sada rozhraní API, která poskytují například kvorum, schopnost restartovat neúspěšné procesy atd.
- libQB. Poskytuje věci jako například protokolování.
- Agent zdrojů Poskytuje se konkrétní funkce, aby se aplikace mohly integrovat s Pacemakerem.
- Agent pro plot. Skripty nebo funkce, které pomáhají izolovat uzly a řešit je, pokud mají problémy.
Poznámka:
Zásobník clusteru se běžně označuje jako Pacemaker v prostředí Linuxu.
Toto řešení se podobá některým způsobům, ale v mnoha ohledech se liší od nasazování clusterovaných konfigurací pomocí Windows. Ve Windows je integrovaná forma clusteringu zvaná cluster pro převzetí služeb Windows Server (WSFC) a funkce, která umožňuje jeho vytvoření, přebírání služeb při selhání, je ve výchozím nastavení zakázaná. Ve Windows jsou skupiny AG a FCI postaveny na WSFC a sdílejí úzkou integraci kvůli konkrétní knihovně DLL prostředků, kterou poskytuje SQL Server. Toto úzce propojené řešení je možné z velké části, protože je všechno od jednoho dodavatele.
V Linuxu má každá podporovaná distribuce k dispozici Pacemaker, přičemž každá distribuce může přizpůsobit a mít mírně odlišné implementace a verze. Některé rozdíly se projeví v pokynech v tomto článku. Clusteringová vrstva je opensourcová, takže i když se dodává s distribucemi, není úzce integrovaná stejným způsobem, jako je WSFC ve Windows. Proto Microsoft poskytuje mssql-server-ha, aby SQL Server a zásobník Pacemaker mohly poskytovat prostředí podobné, ale ne zcela totožné s prostředím pro skupiny dostupnosti (AG) a FCI, jako pod systémem Windows.
Kompletní dokumentace k Pacemakeru, včetně podrobnějšího vysvětlení, co vše jednotlivé části jsou, s úplnými referenčními informacemi, pro RHEL a SLES.
Poznámka:
Počínaje SQL Serverem 2025 (17.x) se nepodporuje SUSE Linux Enterprise Server (SLES).
Další informace o celé stacku najdete také na oficiální stránce dokumentace Pacemakeru na webu ClusterLabs.
Terminologie a koncepty kardiostimulátoru
Tato část popisuje běžné koncepty a terminologii implementace Pacemakeru.
Node
Uzel je server, který se účastní klastru. Cluster Pacemaker nativně podporuje až 16 uzlů. Toto číslo je možné překročit, pokud Corosync není spuštěný na dalších uzlech, ale pro SQL Server se vyžaduje Corosync. Proto maximální počet uzlů, které cluster může mít pro libovolnou konfiguraci založenou na SQL Serveru, je 16; to je limit Pacemaker a nemá nic společného s maximálními omezeními skupin AG nebo FCI uložených SQL Serverem.
Zdroj
WSFC i Cluster Pacemaker mají koncept prostředku. Prostředek je specifická funkce, která se spouští v kontextu clusteru, jako je disk nebo IP adresa. Například pod systémem Pacemaker se mohou vytvořit prostředky FCI i AG. Je to podobné tomu, co se provádí ve WSFC, kde při konfiguraci AG (skupina dostupnosti) vidíte prostředek SQL Serveru pro prostředek FCI nebo AG, ale není to zcela totožné, jelikož se SQL Server odlišně integruje s Pacemakerem.
Pacemaker má standardní a klonovací prostředky. Klonované prostředky jsou ty, které běží současně na všech uzlech. Příkladem je IP adresa, která se spouští na více uzlech pro účely vyrovnávání zatížení. Jakýkoli prostředek, který se vytvoří pro FCIs, používá standardní prostředek, protože FCI může v daném okamžiku hostit pouze jeden uzel.
Poznámka:
Tento článek obsahuje odkazy na termín slave (podřízený) , což je termín, který už Microsoft nepoužívá. Když se termín odebere ze softwaru, odebereme ho z tohoto článku.
Při vytváření AG vyžaduje speciální formu klonového prostředku, která se nazývá prostředek s více stavy. Zatímco skupina dostupnosti má pouze jednu primární repliku, skupina dostupnosti sama běží ve všech uzlech, na kterých je nakonfigurovaná, a může umožnit například přístup jen pro čtení. Vzhledem k tomu, že jde o živé použití uzlu, prostředky rozeznávají dva stavy: Povýšený (dříve Master) a Nepovýšený (dříve Slave). Další informace naleznete v tématu Vícestavové prostředky: Prostředky, které mají více režimů.
Skupiny prostředků nebo sady
Podobně jako u rolí ve WSFC má cluster Pacemaker koncept skupiny prostředků. Skupina prostředků (označovaná jako sada v SLES) je soubor prostředků, které fungují společně a mohou se při selhání přepnout z jednoho uzlu na druhý jako jeden celek. Skupiny prostředků nemůžou obsahovat prostředky, které jsou nakonfigurované jako povýšené nebo nepovýšené; proto je nelze použít pro AG skupiny. I když se skupina prostředků dá použít pro FCI, obecně se nedoporučuje konfigurace.
Omezení
WsFCs mají různé parametry pro prostředky a například závislosti, které indikují vztah nadřazeného/podřízeného mezi dvěma různými prostředky. Závislost je jen pravidlo, které říká WSFC, který prostředek musí být nejprve online.
Cluster Pacemaker nemá koncept závislostí, ale existují omezení. Existují tři druhy omezení: kolokace, umístění a řazení.
- Omezení kolokace určuje, zda by měly být dva prostředky spuštěné na stejném uzlu.
- Omezení umístění říká clusteru Pacemaker, kde může (nebo nemůže) být prostředek spuštěn.
- Pořadová omezení určují clusteru Pacemaker pořadí, ve kterém se mají prostředky spustit.
Poznámka:
Omezení kolokace nejsou vyžadována pro prostředky ve skupině prostředků, protože všechny prostředky se považují za jednu jednotku.
Kvorum, plot agenti a STONITH
Kvorum v rámci Pacemakeru je podobné WSFC v principu. Celým účelem mechanismu kvora clusteru je zajistit, aby cluster zůstal v provozu. WSFC a doplňky pro vysokou dostupnost pro linuxové distribuce mají koncept hlasování, kde každý uzel přispívá ke kvóru. Chcete, aby většina hlasů byla pro, jinak by se v nejhorším případě cluster vypnul.
Na rozdíl od WSFC není k dispozici žádný prostředek svědka pro práci s kvorem. Stejně jako u WSFC je cílem zachovat počet voličů lichý. Konfigurace kvora se liší mezi AGs a FCIs.
WSFCs monitorují stav účastnících se uzlů a řeší je, když dojde k problému. Novější verze WSFCs nabízejí například funkce, jako je kvazování uzlu, který se chová chybně nebo není k dispozici (uzel není zapnutý, síťová komunikace je mimo provoz atd.). Na straně Linuxu poskytuje tento typ funkčnosti tzv. fence agent. Koncept se někdy označuje jako šermování. Tito agenti plotu jsou však specifičtí pro nasazení a často je poskytují dodavatelé hardwaru a někteří dodavatelé softwaru, například poskytovatelé hypervisorů. Například VMware poskytuje agenta plotu, který lze použít pro virtuální počítače s Linuxem virtualizované pomocí vSphere.
Kvorum a omezování se pojí s jiným konceptem, který se nazývá STONITH, tedy sestřelení druhého uzlu. Funkce STONITH musí mít podporovaný cluster Pacemaker ve všech distribucích Linuxu. Další informace viz Oplocení v clusteru s vysokou dostupností Red Hat (RHEL).
corosync.conf
Soubor corosync.conf obsahuje konfiguraci clusteru. Nachází se v /etc/corosync. V průběhu běžných každodenních operací by tento soubor neměl být nikdy upravován, pokud je cluster správně nastavený.
Umístění protokolu clusteru
Umístění logů pro clustery Pacemaker se liší v závislosti na distribuci.
- RHEL a SLES:
/var/log/cluster/corosync.log - Ubuntu:
/var/log/corosync/corosync.log
Chcete-li změnit výchozí umístění protokolování, upravte corosync.conf.
Plánování clusterů Pacemaker pro SQL Server
Tato část popisuje důležité body plánování clusteru Pacemaker.
Virtualizace clusterů Pacemaker založených na Linuxu pro SQL Server
Použití virtuálních počítačů k nasazení linuxových nasazení SQL Serveru pro skupiny AG a FCI se vztahuje stejnými pravidly jako pro jejich protějšky založené na Windows. Existuje základní sada pravidel pro podporu virtualizovaných nasazení SQL Serveru poskytovaná Microsoftem v zásadách podpory pro produkty Microsoft SQL Serveru, které běží v prostředí virtualizace hardwaru. Různé hypervisory, jako jsou Hyper-V Microsoftu a ESXi VMware, můžou mít kromě toho různé odchylky, a to kvůli rozdílům v samotných platformách.
Pokud jde o skupiny AG a FCI v rámci virtualizace, zajistěte, aby byly pro uzly daného clusteru Pacemaker nastavené anti-spřažení. Při konfiguraci vysoké dostupnosti v konfiguraci skupiny dostupnosti nebo FCI by virtuální počítače hostující SQL Server nikdy neměly být spuštěné na stejném hostiteli hypervisoru. Pokud je například nasazená služba FCI se dvěma uzly, musí existovat alespoň tři hostitelé hypervisoru, aby jeden z virtuálních počítačů hostující uzel mohl jít v případě selhání hostitele, zejména pokud používáte funkce, jako je migrace za provozu nebo vMotion.
Dokumentaci k Hyper-V najdete v tématu Použití clusteringu hostů pro zajištění vysoké dostupnosti.
Síť
Na rozdíl od WSFC nevyžaduje Pacemaker vyhrazený název ani alespoň jednu vyhrazenou IP adresu pro samotný cluster Pacemaker. Skupiny AG a FCI budou potřebovat IP adresy (podrobnosti najdete v příslušné dokumentaci pro každou z nich), ale ne názvy, protože neexistuje žádný prostředek sítě pro síťové názvy. SLES umožňuje konfiguraci IP adresy pro účely správy, ale nevyžaduje se, jak je vidět v části Vytvoření clusteru Pacemaker.
Stejně jako WSFC by Pacemaker preferoval redundantní sítě, to znamená, že odlišné síťové karty (NICs nebo pNICs pro fyzické) mají jednotlivé IP adresy. Z hlediska konfigurace clusteru by každá IP adresa měla to, co se označuje jako vlastní okruh. Stejně jako u WSFCs se v současnosti virtualizuje mnoho implementací nebo ve veřejném cloudu, kde je na serveru prezentováno pouze jedno virtualizované síťové rozhraní (vNIC). Pokud jsou všechny řadiče pNIC a vNIC připojené ke stejnému fyzickému nebo virtuálnímu přepínači, neexistuje v síťové vrstvě žádná skutečná redundance, takže pro virtuální počítač je konfigurace více síťových adaptérů spíše iluzí. Redundance sítě je obvykle integrovaná do hypervisoru pro virtualizovaná nasazení a je rozhodně integrovaná do veřejného cloudu.
Jedním z rozdílů mezi použitím několika síťových karet spolu s Pacemakerem a WSFC je, že Pacemaker umožňuje mít několik IP adres na stejné podsíti, zatímco WSFC ne. Další informace o několika podsítích a clusterech s Linuxem najdete v článku Konfigurace skupin dostupnosti AlwaysOn s více podsítěmi a instancí clusteru s podporou převzetí služeb při selhání.
Kvorum a STONITH
Konfigurace a požadavky kvora souvisí s nasazením SQL Serveru, které jsou specifické pro skupiny dostupnosti (AG) nebo FCI.
PRO podporovaný cluster Pacemaker se vyžaduje STONITH. Ke konfiguraci STONITH použijte dokumentaci z distribuce. Příkladem je ohraničení založené na úložišti pro SLES. Existuje také agent STONITH pro VMware vCenter pro řešení založená na ESXI. Další informace naleznete v Agentovi zásuvného modulu Stonith pro VMware VM VCenter SOAP Fencing (neoficiální).
Interoperabilita
Tato část popisuje, jak může cluster založený na Linuxu pracovat s WSFC nebo s jinými distribucemi Linuxu.
WSFC
V současné době neexistuje žádný přímý způsob spolupráce WSFC a clusteru Pacemaker. To znamená, že neexistuje způsob, jak vytvořit AG nebo FCI, které fungují ve WSFC a Pacemakeru. Existují však dvě řešení interoperability, z nichž obě jsou navrženy pro skupiny aplikací. Jediným způsobem, jak se FCI může účastnit konfigurace napříč platformami, je, že se účastní jako instance v jednom z těchto dvou scénářů:
- AG s typem clusteru None. Další informace najdete v dokumentaci ke skupinám dostupnosti Windows.
- Distribuovaná skupina dostupnosti, což je zvláštní typ skupiny dostupnosti, která umožňuje konfiguraci dvou různých skupin dostupnosti jako jejich vlastní skupiny dostupnosti. Další informace o distribuovaných skupinách dostupnosti najdete v dokumentaci Distribuované skupiny dostupnosti.
Další linuxové distribuce
V Linuxu musí být všechny uzly clusteru Pacemaker ve stejné distribuci. To například znamená, že uzel RHEL nemůže být součástí clusteru Pacemaker, který má uzel SLES. Hlavním důvodem toho bylo dříve uvedené: Distribuce můžou mít různé verze a funkce, takže věci nefungovaly správně. Kombinování distribucí má stejný scénář jako kombinování wsFCs a Linuxu: použijte žádné nebo distribuované skupiny AG.